Pienso totalmente lo contrario. Saludos 2011/1/16 Guillermo Schwarz <[email protected]>
> tienes que leer respecto de lo que son las dependencias funcionales, ya que > esa es la base del modelo relacional. > > una vez entendido eso, el resto se trata de: ¿en qué contextos se puede > aplicar las dependencias funcionales? > > pues bien, hasta el momento, desde mi punto de vista, en todos. desde la > generación de interfaces de usuario a la especificiación de requerimientos, > pasando por el modelamiento de bases de datos. > > saludos, > Guillermo. > > 2011/1/16 gerard <[email protected]> > > 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<http://www.dcc.uchile.cl/%7Erbaeza/inf/codd.html>) >> de modelar las >> > dependencias funcionales ( >> http://cs.gmu.edu/~aobaidi/spring-02/Normalization.ppt<http://cs.gmu.edu/%7Eaobaidi/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]<clubsmalltalk%[email protected]> >> >> http://www.clubSmalltalk.org >> > > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<clubsmalltalk%[email protected]> > > http://www.clubSmalltalk.org > -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
