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. >
No necesariamente. En una verdadera base de objetos creo que eso debería ser indiferente. Si por tu negocio tiene sentido, entonces sí. Sino, no. Además podes pensar en responsabilidades, y no datos. Ponele, yo podría pedirle a una jornada su temporada, pero ésta no está como variable de instancia, sino que hace una búsqueda sobre todas las temporadas para ver quien tiene a dicha jornada. Todo esto para darte un ejemplo. > > 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... > Acá tenes que tener en cuenta que en Smalltalk no podes borar un objecto. Lo máximo que podes hacer es desreferenciarlo. En tu ejemplo, cuando elimines una temporada, se borrarán todas las referenias a las jornadas. Si algunas de esas jornadas estaba solamente siendo referenciadas por esa temporada, entonces cuando corra el garbage collector se la llevará. Mientras tanto (hasta que venga el GC) no pueden ser accedidas desde ningún otro objecto, así que no pasa nada. El único problema sería si tu código de negocio haría chanchadas como Jornada allInstances pues ahí si todavía estan visibles los objectos (hasta que pase el GC). Pero por lo general las applicaciones tiene roots o objectos donde las cosas están almacenadas. No soles haces un allInstances. > Básicamente da la sensación de que sería relativamente fácil en un > momento dado dejar datos inconsistentes en la BD, No. No debería haber inconcistencias. > o que en volúmenes > de datos grandes a la hora de patearse una colección inmensa la demora > sería muy grande... es cierto que el GC en bases de objectos no es trivial y si, la performance es importante. > 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 > Esto es fácil. Es Smalltalk. Las cosas se resuelven en los objectos. Suponete que quiero trigear algo cuando se agrega una jornada a una Temporada...fácil: Temporada >> addJornada: unaJornada self hacerLoQuiera. self jornadas add: unaJornada Y listo. Bueno, en magma deberías tener un diccionario donde desde algún lugar lleges a la temporada no.... > > Finalmente, ¿existe algún manual de "buenas prácticas" con DB de > objetos? > > Ni idea. Pero seguramente Smalltalk es de lo más existente en relación a bases de objetos > Saludos y gracias por la ayuda. > > saludos > -- > 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
