Hola gente! Me meto yo tambien en este thread ;-) ... cortito y al pie...
Rapidamente, NoSql tambien apunta a escalabilidad horizontal (pongo mas maquinas, y atiendo mas clientes), concurrencia, tener varios servidores donde estan los datos NoSQL, se cae uno, y todo sigue andando. Mis enlaces (Julio 2010) sobre el tema, y un video/presentacion: http://ajlopez.wordpress.com/2010/07/19/nosql-resources/ Enlaces mas nuevos que me interesaron en: http://delicious.com/ajlopez/nosql Algo que mencione en algun thread aca en esta lista, hmmm... con Mariano... es: tener un Smalltalk corriendo en red de maquinas, no en UNA maquina.... The network is the machine ;-) En NoSQL, seria algo como: the network is the database ;-) Veo que mencionaron en este thread el de programar como si todo esta en memoria.... Justamente, siempre recuerdo a Smalltalk en eso. De Nuevo, mencionando a Smalltalk, NoSql, y Software Transactional Memory (algo parecido a lo que presente en Smalltalks 2010): http://msmvps.com/blogs/lopez/archive/2010/08/08/look-ma-no-database.aspx Aprovecho a preguntar: Si trabajan en Smalltalk todo en memoria (no Gemstone, no Magma, no nada... todo en memoria local, simple imagen de Smalltalk), como manejan la concurrencia? Que pasa si algun cliente/pagina web quiere hacer una transferencia de cuenta a cuenta, y otro cliente/pagina web tambien? Nos leemos! Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Esteban A. Maringolo Sent: Tuesday, January 18, 2011 2:32 PM To: [email protected] Subject: Re: [clubSmalltalk] Re: Programación con un gestor de base de datos orientado a objetos Acaso Smalltalk no es NoSQL desde el vamos? NoSQL es la forma moderna de llamar a un shared dictionary/hashtable anidado? Saludos! Esteban A. Maringolo El día 18 de enero de 2011 12:00, Gastón Dall' Oglio <[email protected]> escribió: > 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-ph aro/ > 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) 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 >>> >>> >>> -- >>> 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 >> >> -- >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [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 -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [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
