Que tal Gerard. Mas allá de lo que ya te comentaron, mi humilde aporte
es que no te vuelvas loco con potenciales problemas de performance antes
de tiempo. Uno muchas veces trae preconcpetos de otros paradigmas que no
aplican en el entorno de trabajo actual. Por ejemplo, en el caso que
mencionás de las facturas, tené en cuenta que los objetos se cargan por
demanda y, dependiendo de la BDOO, uno puede definir índices. O sea que
si en tu modelo te parece correcto que un cliente tenga sus facturas y
luego necesitás iterar por todas las facturas entre dos fechas pasando
por los clientes, eso no implica que tengas que traer a memoria todas
las facturas persistidas. Cuando se levante un cliente sus v.i.
seguramente serán proxies a disco y al hacer la consulta lo harás por el
índice, por lo que no vas a necesitar traer a memoria instancias que no
te sirven. Esto implica que va a ser igual de rápido que hacer un
"select" sobre la clase Factura directamente? Seguramente no, va a ser
mas lento, pero a lo que apunto es que no te mandes a hacer optimización
temprana por cosas que no sabés si van a ser un problema.
Respecto del problema de consistencia (i.e. de tener dos colecciones de
facturas -la del cliente vs. el listado general- que tienen que estar
sincronizadas) fijate que es un problema de diseño, no de persistencia.
Ese mismo problema lo tendrías si lo hacés en memoria. En líneas
generales deberías intentar evitar ese tipo de cosas, o asegurarte que
manejas bien la consistencia, cosa que puede ser simple o complicada
dependiendo de lo organizado que seas para programar :).
Mis 2 ctvs.
Saludos,
Andrés
gerard 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.
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.
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? 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. 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.
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]>
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
