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) 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]<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] http://www.clubSmalltalk.org
