No he entendido nada :| Bueno, el primer párrafo si ;))
Saludos On 16 ene, 15:00, Guillermo Schwarz <[email protected]> wrote: > Me parece muy superficial la discusiòn. > > De partida el modelamiento de base de datos relacionales parte de la idea E. > F. Codd (http://www.dcc.uchile.cl/~rbaeza/inf/codd.html) de modelar las > dependencias funcionales > (http://cs.gmu.edu/~aobaidi/spring-02/Normalization.ppt), que no son otra > cosa que pares X -> Y (como un Dictionary o un HashMap). Eso se puede > representar directamente en Smalltalk. > > La representación E-R y la representación en tablas son sólo el resultado de > tratar de convertir las dependencias funcionales en una representación > entendible por humanos y por máquinas respectivamente. Lo simpàtico del > asunto es que las dependencias funcionales podrìan representarse > directamente en Smalltalk sin necesidad de mecanismos intermedios, derivando > luego el modelo E-R o el modelo en tablas según sea necesario. > > Podrìas tener aplicaciones funcionando, cambiar las dependencias > funcionales, y que la aplicación se adapte a los cambios sin necesidad de > reprogramar nada ni de detener la aplicación. > > Para los que tengan dificultades entendiendo lo anterior, serìa factible > hacer un generador de còdigo que genere interfaces de usuario, modelo de > datos y migrador de datos en forma automática, aunque claramente prefiero > que la aplicación no se detenga y siga funcionando sin necesidad de > programar nada. > > Saludos, > Guillermo. > > 2011/1/13 Juan <[email protected]> > > > > > > > > > Hola gente > > > Bueno aporto un poco, creo que gaboto dijo algo claro y clave. > > Tenes que pensar el dominio para modelarlo sin restricciones , lo de > > la base de datos ,yo y quizas todo el mundo ,no se, lo llamo programacion > > orientada al modelo de datos. o sea en bases de datos relacionales > > se programa , los progamas son orientados a la representacion de los datos. > > Entonces cuando cambias algun tipo de dato o definicion el programa sufre > > cambios > > a veces muy grandes. > > El mapeo es una solucion intermedia. o sea se programa en "objetos" o en > > lenguajes objetosos, excepto claro esta el smalltalk. y se mapea los > > "objetos" a la db , teniendo > > mas o menos exito. > > En gral cuando se parte de esta formacion se tiende a mapear, una clase una > > tabla una instancia una row. > > Ese es el modelo de pensamiento que hay que romper, hay que pensar tu > > objeto tu parte del modelo que necesita conocer? , las facturas ? ,ok. son > > muchas ? bueno conocera una coleccion , y cada factura que necesita conocer? > > , (por conocer digamos ,normalmente lo tiene o lo usa) podes arrancar con un > > modelo exploratorio , en verdad deberias. y experimentar con los > > colaboradores ( cosas q conoce otros objetos del dominio) e ir moviendolos > > agregando sacando etc, hasta que pueda cumplir con su cometido ( el modelo > > funcione) . > > Luego pensa en la persistencia, no al reves. lo ultimo. o sea que el modelo > > ande primero > > luego la persistencia , asi como tambien te indicaron aqui y por > > necesidades de perfomance u otras haces las "chanchadas" o sea ensucias a tu > > modelo. > > por ensuciar digamos que es la parte donde la persistencia afecta a tu > > modelo . > > bueno acoto hasta aca. > > saludos > > mdc > > > 2011/1/13 Gastón Dall' Oglio <[email protected]> > > >> > Buenas, ya que estamos yo también me meto jeje. > > >> Buenas. Yo creo que la lista esta para que todo el que tenga algo que > >> aportar lo haga :) > > >> Ya que estamos con el tema base de objetos y de datos, les consulto si > >> alguno sabe que orientación tienen las bases de datos que se encuadran bajo > >> el enfoque nosql. ¿Están tratando de hacer algo orientado a objetos o algo > >> totalmente novedoso? > > >>http://nosql-database.org/ > > >> El 13 de enero de 2011 10:58, Gaboto <[email protected]> escribió: > > >> Buenas, ya que estamos yo también me meto jeje. > >>> Solo un comentario. Para hacer un buen modelo en la base de objetos lo > >>> que quizá deberías hacer es pensar en que tenés un programa en memoria y > >>> que > >>> nunca se apaga. Es decir, imaginate que vos tenes que hacer un programa > >>> que > >>> no tiene que persistir nada porque la compu siempre está prendida, > >>> Entonces, > >>> en ese caso como harías? yo tendría las colecciones que correspondan y > >>> agregaría algún diccionario por eficiencia, etc. > >>> La consistencia del modelo la tendría que manejar el modelo mismo, > >>> asegurandose de poner y sacar las cosas de las colecciones cuando > >>> corresponda. No hay ningún trigger mágico ni nada de eso, que viene de > >>> otro > >>> paradigma. > >>> Yo creo que la idea de una base de objetos es justamente esa, hacer lo > >>> más transparente posible la persistencia, aunque en realidad haya algunas > >>> sutiles diferencias en la práctica... > >>> Luego con el tiempo, como ya mencionaron acá, te vas a ir dando cuenta de > >>> si hay que hacer alguna "chanchada" o algo para ir optimizando los > >>> tiempos. > > >>> 2011/1/13 Gastón Dall' Oglio <[email protected]> > > >>>> Muchas gracias por sus comentarios! > > >>>> Sí, el become ya me parecía una mala idea por lo que he leído. > > >>>> Saludos. > > >>>> El 13 de enero de 2011 08:48, Esteban Lorenzano > >>>> <[email protected]>escribió: > > >>>> hola, > >>>>> bueno, me meto en el thread :) > >>>>> IMHO, el problema es que seguís pensando tu estructura de datos en > >>>>> relacional, no en objetos (por eso lo pensás como una estructura de > >>>>> datos y > >>>>> no como un grafo de objetos, je). > >>>>> Yo la primer pregunta que me haría es "para qué quiero la colección de > >>>>> todas las facturas? las necesito, o es solo que 'me parece' que tienen > >>>>> que > >>>>> estar en una colección aparte (como si la colección fuera una tabla)" > >>>>> realmente me parece que es una instancia muy nueva de tu aplicación > >>>>> (por lo que veo) para saber si realmente necesitas tener una colección > >>>>> de > >>>>> facturas aparte. En estos momentos no hay nada que te impida hacer algo > >>>>> como: > > >>>>> allInvoices > >>>>> ^self customers > >>>>> inject: Set new > >>>>> into: [ :all :each | all, each invoices ] > > >>>>> eso puede demostrarse no eficiente con el tiempo, pero también puede > >>>>> demostrarse que no necesitás #allInvoices y entonces te ahorrás todo el > >>>>> problema de mantener invoices en dos lugares. > >>>>> Si pese a todo decidís que sí necesitas mantenerlo aparte, lo que te > >>>>> recomiendo es lo mismo que te recomendó Andrés, y le agrego que, para > >>>>> borrar > >>>>> facturas, hagas algo como: > > >>>>> Customer>>removeInvoice: anInvoice > >>>>> self invoices remove: anInvoice. > >>>>> IndexadorDeFacturas instance remove: anInvoice. > > >>>>> usar el become (forward o no), suele no ser una respuesta correcta. > >>>>> Entre otras cosas porque te hace un scan de todos los objetos en > >>>>> memoria, en > >>>>> pharo/squeak, dado que no tienen object table. > > >>>>> nunca dejes de pensar desde el punto de vista del modelo, olvidate de > >>>>> pensar en la estructura! > > >>>>> Saludos, > >>>>> Esteban > > >>>>> El 13/01/2011, a las 7:42a.m., andres escribió: > > >>>>> > Yo personalmente evitaría eso porque: > > >>>>> > 1. Estás asumiendo cosas sobre las colecciones que contienen a la > >>>>> factura. Si el día de mañana se te ocurre cambiar el tipo de > >>>>> colecciones y > >>>>> esas colecciones por algún motivo no pueden contener nils las rompés. > >>>>> > 2. Tenés que redefinir el protocolo de colecciones para manejar tus > >>>>> casos ad-hoc (ej. si tenés un array el #size ya no te sirve; tenés que > >>>>> hacer > >>>>> (select:[..| noNil]) size). > >>>>> > 3. Estás asumiendo que nadie mas referencia a la factura (ej. un > >>>>> inspector, un reporte, un histórico de facturas, etc). Si así fuera > >>>>> rompés > >>>>> todo. > >>>>> > 4. Como regla genérica el #become no se debe usar para resolver > >>>>> problemas de diseño; eso te lleva a una seguidilla de hackasos. Mejor es > >>>>> definir alguien que sepa sincronizar bien las colecciones de facturas. > >>>>> Por > >>>>> ejemplo, podés definir que el indexador global de facturas no puede > >>>>> agregar > >>>>> o eliminar facturas, sólo el cliente lo hace. Entonces te queda: > > >>>>> > (private) IndexadorDeFacturas>>agregarFactura: unaFacura > >>>>> > self factuas add: > >>>>> unaFactura. > > >>>>> > (public) Cliente>>agregarFactura: unaFacura > >>>>> > self factuas add: unaFactura. > >>>>> > IndexadorDeFacturas instance > >>>>> agregarFactura: unaFacura. > > >>>>> > Si uno es lo suficientemente disciplinado como para no usar el > >>>>> protocolo privado del indexador de facturas ya no hay problemas. > > >>>>> > IMHO es mucho menos esfuerzo hacer ese diseño que todo el quilombo > >>>>> que te trae el become. > > >>>>> > HTH, > >>>>> > Andrés > > >>>>> > Gastón Dall' Oglio escribió: > >>>>> >> Hola gente. > >>>>> >> Capaz es una burrada pero bueno, no me quiero quedar con las dudas. > >>>>> >> Supongamos que tengo unaFactura que esta referenciada desde una > >>>>> colección > >>>>> >> perteneciente a un cliente (sus facturas) y también desde una > >>>>> colección de > >>>>> >> todas las facturas. Para el tema de resolver el "borrado en cascada" > >>>>> puedo > >>>>> >> hacer algo como: > >>>>> >> unaFactura become: nil > >>>>> >> 1) Esto me asegura que ya nadie la referencia, y será liberada. > >>>>> >> 2) Ambas colecciones quedan con la misma cantidad de elementos, solo > >>>>> que > >>>>> >> ahora tienen una referencia a nil. Que exista una factura nil es > >>>>> fácil de > >>>>> >> ignorar con un #select: o permanente con un #removeAll: > >>>>> >> 3) El tiempo normal que demora un #become: aumenta considerablemente > >>>>> por > >>>>> >> tratarse de objetos persistidos por Magma. > >>>>> >> Saludos! > >>>>> >> El 12 de enero de 2011 18:40, Hernán Morales Durand < > >>>>> >> [email protected]> escribió: > >>>>> >>> Hola Gerard, > > >>>>> >>> El día 12 de enero de 2011 10:59, gerard <[email protected]> > >>>>> escribió: > >>>>> >>>> Lo que hecho de menos es una "manera de hacer" estandar que > >>>>> prevenga > > ... > > leer más » -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
