Yo no sigo opinando porque no me da el conocimiento para tanto... Igual agradezco sus opiniones.
Y ya que toqué el tema NoSQL hice los deberes y encontré un artículo () una forma de acceder a una de estas bases desde Pharo, se los paso por si les interesa. Me viene al pelo como persistencia porque estamos evaluando hacer una aplicación con mapas en Smalltalk y puede andar para almacenar imágenes de lugares:) http://miguel.leugim.com.mx/index.php/2010/03/31/accessing-cassandra-from-pharo/ http://wiki.apache.org/cassandra/ Saludos! El 16 de enero de 2011 18:08, Gaboto <[email protected]> escribió: > 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]<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
