Hasta donde yo tengo entendido, nosql es más que nada como una movida de nuevas propuestas para la persistencia que son novedosas ya que no siguen el modelo relacional. No es un paradigma determinado. Una base de objetos por ejemplo sería parte del movimiento nosql, pero existe hace mucho más tiempo ;). Pero hay otros modelos, uno por ejemplo consiste en tener una especie de diccionarios con clave valor (creo que era cassandra).
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 >>>> >>>> que uno haga algunas cosas no del todo recomendables... Aunque sean >>>> >>>> objetos no deja de ser una BD, y seguro que pudes hacer algunas >>>> >>>> animaladas espectaculares sólo por no tener claro un concepto. >>>> >>>> >>>> >>> Hay un texto muy bueno que se llama algo como "Objectivity: Hitting >>>> >>> the relational wall", te va a servir para lo conceptual. >>>> >>> >>>> >>>> Otro ejemplo, yo guardo como root un Dictionary. Tengo definidas >>>> unas >>>> >>>> clases "Entity", que al arrancar la imagen Smalltalk se aseguran, >>>> cada >>>> >>>> una por separado, de que en ese diccionario exista una entrada con >>>> el >>>> >>>> mismo nombre de la clase y una OrderedCollection. Eso lo hice con >>>> la >>>> >>>> idea de que automáticamente ya existiera una colección vinculada a >>>> >>>> cada clase Entity... pero ahora veo que quizás eso es una tontería >>>> y >>>> >>>> que sería perfectamente válida una instancia root que tuviera un >>>> >>>> montón de colecciones, una por cada entidad. Por otro lado veo >>>> algunos >>>> >>>> ejemplos o screencast de Magma que usan el otro sistema: una >>>> entrada >>>> >>>> en un diccionario por cada entidad. >>>> >>>> >>>> >>> Es preferible que el objeto raíz sea un objeto de "primera clase" >>>> >>> (Mundo, Fabrica, etc). Como dijiste, dentro de ese objeto pueden >>>> >>> existir varias variables de instancia nombradas que podés hacer >>>> >>> colecciones. Magma no te hace problemas si agregas nuevas variables >>>> de >>>> >>> instancia a ese objeto raíz. >>>> >>> >>>> >>>> En fin, me gustaría que todas las clases-entidades tuvieran un >>>> >>>> comportamiento homogeneo. En un ORM, al generarse el código, sé que >>>> >>>> una relación 1:N me va a generar una clase con una colección y una >>>> >>>> serie de métodos estandard, para añadir un elemento a la colección, >>>> o >>>> >>>> eliminarla etc Es decir un comportamiento general, dependiendo de >>>> las >>>> >>>> relaciones. >>>> >>>> >>>> >>>> ¿Y grandes volúmenes de datos? >>>> >>> ¿Cuanto es grande? En el caso de Magma es casi obligatorio hacer >>>> >>> índices, analizar las consultas que vas a tener, las profundidades >>>> de >>>> >>> tus objetos y en base a eso escribir ReadStrategies razonables para >>>> >>> tus requerimientos. Magma aguanta índices de hasta 4096 bits, pero >>>> >>> pasando los 128-bits son un dolor de cabeza si tenés millones de >>>> >>> objetos (en mi caso tengo 20 millones). Lo normal es que trabajes >>>> con >>>> >>> índices de 32 o 64 a 128 bits (fijate que tienen que ser múltiplos >>>> de >>>> >>> 8). Más bits en los indices, más reducidos los resultados de un >>>> >>> #where:, y menos escaneo lineal del #select: posterior, pero más >>>> >>> procesamiento por cada objeto. >>>> >>> >>>> >>>> Si tienes una lista inmensa de >>>> >>>> facturación y debes de empezar a patearte los items para obtener >>>> las >>>> >>>> facturas de un determinado cliente como lo haces? Por un lado >>>> podrias >>>> >>>> hacer que cada cliente tuviera su propia colección de facturas, con >>>> lo >>>> >>>> que podrías ir directamente a la colección de facturas del cliente, >>>> >>>> perfecto. Pero ¿y si quiero todas aquellas facturas creadas el >>>> último >>>> >>>> més sea cual sea el cliente? Entonces ya no tiene sentido acudir a >>>> las >>>> >>>> colecciones de facturas de los clientes, sería más trabajoso; >>>> debería >>>> >>>> ir a una lista "general" de facturas y empezar a seleccionar las >>>> que >>>> >>>> estan en el rango de fechas correcto; es decir, debo tener una >>>> >>>> colección de facturas y otras colecciones parciales de facturas en >>>> >>>> cada cliente. >>>> >>> Lo de las colecciones maestras grandes es una costumbre del mundo >>>> >>> relacional, los programadores relacionales se acostumbran a usarlas >>>> >>> furiosamente, en vez de dispersarlas en el dominio en colecciones >>>> más >>>> >>> chicas que no son tan violentadas. Esto no significa que tenés que >>>> ir >>>> >>> a hacer 40 colecciones chicas, y en todo casi si lo hacés, la >>>> >>> performance viene cambiando la indexación, pero es una opción para >>>> >>> reducir complejidad. >>>> >>> >>>> >>> Una opción interesante es que podés usar #where: y persistir los >>>> >>> resultados, es decir, los MagmaReaders, en otra MagmaCollection y >>>> esto >>>> >>> te daría consultas predefinidas. Lo bueno es que si persistís un >>>> >>> Reader y agregás más objetos a la colección original luego, es >>>> decir, >>>> >>> a la cual le hiciste el #where:, los objetos agregados van a >>>> aparecer >>>> >>> la próxima vez que enumeres el Reader. Pero antes de enumerar un >>>> >>> Reader entero (no te lo recomiento tampoco, es mejor cuando lo usás >>>> >>> para resultados paginados) tenés que revisar la profundidad de los >>>> >>> objetos que van a ser consultados y hacerte una ReadStrategy >>>> >>> apropiada. Fijate en MagmaCollectionTester>>#testPersistentReader >>>> >>> >>>> >>>> Podría ir más lejos en el ejemplo y plantear varias >>>> >>>> entidades a las que les interesaría tener su propia relación con >>>> las >>>> >>>> facturas... Bien: ahora el usuario quiere eliminar una factura, y >>>> >>>> cuando lo haga debo de ser muy consciente de todas las colecciones >>>> >>>> donde puede estar ubicada esa factura para poder eliminarla "bien". >>>> >>>> Debo ir a la lista de facturas del cliente, a la lista general de >>>> >>>> facturas que he mencionado etc etc Veo muy complicado no dejarse >>>> >>>> ningún cabo suelto. No me refería tanto a que pasara el GC, que >>>> >>>> realmente da igual, sino a la posibilidad de dejarse instancias que >>>> ya >>>> >>>> no deberian estar, de ahí la comparación con el ON DELETE ACTION. >>>> >>>> >>>> >>> Las consultas tambien pueden ser objetos, y como tales pueden ser >>>> >>> persistidas. Fijate si lo de arriba te sirve. Si tenés problemas de >>>> >>> performance, usá un Message spy. Si no tenés problemas, escribí como >>>> >>> si nada pasara :) >>>> >>> >>>> >>> Saludos >>>> >>> >>>> >>> >>>> >>>> No sé si me he expresado bien. >>>> >>>> >>>> >>>> Saludos. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 12 ene, 14:11, Facundo Vozzi <[email protected]> wrote: >>>> >>>>> Hola, >>>> >>>>> Mariano ya te respondió casi todo, para agregar algo, podés leer >>>> sobre >>>> >>>>> algunos enfoques de persistencia (incluído Magma) en el libro de >>>> >>> Seaside:http://book.seaside.st/book/advanced/persistency. >>>> >>>>> Vas a ver que hablan de persistencia basada en Imagen, que es solo >>>> eso >>>> >>>>> guardar la imagen con una global que apunte a tu root (un >>>> singleton, por >>>> >>>>> ejemplo). Después cambiar a que se persista con Magma o Goods es >>>> casi un >>>> >>>>> tramite para GemStone tenés que laburar un cacho más. >>>> >>>>> >>>> >>>>> Respecto de las relaciones, los delete cascade, triggers y >>>> cualquier >>>> >>> yerba >>>> >>>>> de la BD relacional tenés que hacer lo siguiente: OLVIDARTE. Para >>>> usar >>>> >>> una >>>> >>>>> base de objetos y sacarle provecho tenés que hacer tu módelo lo >>>> más >>>> >>>>> orientado a objetos que te salga y no preocuparte por problemas de >>>> otro >>>> >>>>> paradigma. Quedate tranquilo que vas a tener otros problemas para >>>> >>> resolver >>>> >>>>> :-P pero, simplemente, no los mismos. >>>> >>>>> >>>> >>>>> Saludos, >>>> >>>>> Facu >>>> >>>>> >>>> >>>>> 2011/1/11 gerard <[email protected]> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>>> Buenas. estoy realizando una pequeña aplicación, sólo con >>>> propósito de >>>> >>>>>> pruebas, para trabajar con una base de datos orientada a objetos. >>>> Como >>>> >>>>>> solo quería hacer unas pocas pruebas me he decantado por Magma y >>>> >>>>>> Pharo. >>>> >>>>>> Ahora bien, mi problema es que dudo sobre la manera en que deben >>>> >>>>>> hacerse según que cosas cuando guardas datos como objetos. >>>> >>>>>> 1. Relaciones 1:N. Por ejemplo, una temporada de fútbol tiene >>>> varias >>>> >>>>>> jornadas, correcto? Es lógico pensar que cada objeto temporada >>>> debería >>>> >>>>>> de tener una colección de objetos jornada. Ahora bien, cada >>>> objeto >>>> >>>>>> jornada debería tener una referencia a su tempoarada no? bien, al >>>> >>>>>> menos en algunos ORMs lo he visto. >>>> >>>>>> 2. Al eliminar, por ejemplo, una temporada, deberíamos tener en >>>> cuenta >>>> >>>>>> que debemos cargarnos tambien aquellas jornadas que pertenecen a >>>> esa >>>> >>>>>> temporada, y a su vez todos los partidos etc etc lo que vendría a >>>> ser >>>> >>>>>> una ON DELETE CASCADE de las BBDD relacionales... >>>> >>>>>> Básicamente da la sensación de que sería relativamente fácil en >>>> un >>>> >>>>>> momento dado dejar datos inconsistentes en la BD, o que en >>>> volúmenes >>>> >>>>>> de datos grandes a la hora de patearse una colección inmensa la >>>> demora >>>> >>>>>> sería muy grande... o que no tienes según que automatismos, cómo >>>> los >>>> >>>>>> triggers, para asegurarte que suceda algo al añadir un nuevo >>>> registro >>>> >>>>>> etc etc >>>> >>>>>> Finalmente, ¿existe algún manual de "buenas prácticas" con DB de >>>> >>>>>> objetos? >>>> >>>>>> Saludos y gracias por la ayuda. >>>> >>>>>> -- >>>> >>>>>> To post to this group, send email to >>>> [email protected] >>>> >>>>>> To unsubscribe from this group, send email to >>>> >>>>>> [email protected]<clubsmalltalk%[email protected]> >>>> <clubsmalltalk%[email protected]<clubsmalltalk%[email protected]> >>>> > >>>> >>> <clubsmalltalk%[email protected]<clubsmalltalk%[email protected]> >>>> <clubsmalltalk%[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]> >>>> <clubsmalltalk%[email protected]<clubsmalltalk%[email protected]> >>>> > >>>> >>>> http://www.clubSmalltalk.org >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> Hernán Morales >>>> >>> Information Technology Manager, >>>> >>> Institute of Veterinary Genetics. >>>> >>> National Scientific and Technical Research Council (CONICET). >>>> >>> La Plata (1900), Buenos Aires, Argentina. >>>> >>> Telephone: +54 (0221) 421-1799. >>>> >>> Internal: 422 >>>> >>> Fax: 425-7980 or 421-1799. >>>> >>> >>>> >>> -- >>>> >>> To post to this group, send email to [email protected] >>>> >>> To unsubscribe from this group, send email to >>>> >>> [email protected]<clubsmalltalk%[email protected]> >>>> <clubsmalltalk%[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]<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]<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
