2011/1/12 gerard <[email protected]> > 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. >
No, no es una BD es una base de objetos no de datos. Lo de hacer "animaladas", y bueno, sí, yo hice un montón y después con la experiencia vas haciendo menos. Creo que si te olvidás de la persistencia y grabás el image es la manera más simple de no pensar orientado a tablas pero bueno, paciencia. > 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. > Yo guardo una instancia de "XXXSystem" (un singleton) como root pero se puede guardar, como decís vos, cualquier otra cosa. > > 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. > Bueno, si querés podés, si te sentís cómodo con eso, podés hacer algo similar no creo que dependa de la persistencia eso. Otra opción es usar los métodos estandar de Collection para hacer eso. > > ¿Y grandes volúmenes de datos? 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. Cada cliente tiene su colección de facturas y cuando consultes un rango de fechas, le pedís a todos tus clientes las facturas, las ordenas y las seleccionás. Cuando eso se ponga lento porque tenés muchas facturas, o mejor dicho, muchos clientes, ahí agregar a tu sistema, o a tu empresa, una collección indexada con todas las facturas (es barato, es solo una referencia más a cada factura). Y sí, tenés que programar ordenadamente la consistencia como dice Andrés. > 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. > Ummm, puede pasar que te olvides de sacarlo de algún lado pero salta con cualquier test. Lo agregás y listo. Debería ser en un solo lugar donde tocar. > > No sé si me he expresado bien. > Sí, creo que te preguntas cosas porque ya conoces los problemas de otro paradigma y querés anticiparte a todo. Creo que lo mejor, aunque parezca disparatado, es no pensar y solo ponerse a mandar mensajes. Después aparecen solos los problemas y ahí hay que pensar un cacho. > > Saludos. > Nos vemos > > > > 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]> > > > > > > >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
