RE: [Python-es]Representación de asociaciones en bases de datos
Hernan Martinez Foffani
hernan en orgmf.com.ar
Jue Ago 22 21:49:04 CEST 2002
una ventaja de la opción 1 es que la representacion de la base de datos
queda MUY parecida a una normalizacion estandar. y eso puede ser util
para acceder a la base de datos relacional directamente, o para que un
sistema de terceros que no sea OO acceda al repositorio o también para
que un sistema que use tu interfaz pueda acceder a un repositorio ya
existente en 3ra forma normal.
en la opcion 2 se haría complicadísimo usar el query language del
motor para realizar consultas. a algunos esto les parecerá una
ventaja ;-)
es muy dificil pronosticar performance. en la opcion 2, OID1 y OID2
seguramente serán claves numéricas, no creo que tengas problemas por
alli. por otro lado la tabla RelObjs puede ser un cuello de botella
en actualizaciones multiusuarios/multitareas. pero son especulaciones.
como bien dices, quizás lo mejor es probar las dos.
en cuanto a mantenimiento... lo que sí te puedo asegurar es que si
cada atributo del modelo de objetos es una tabla, el administrador
no lo va a tener facil ;-)
otra alternativa es (aprovechando que tenés pensado implementar las
dos opciones) darle al programador la posibilidad de elegir si
quiere o no "congelar" el diseño de la clase.
yendo a mi preferencia personal, si el repositorio de datos requiere
administración (por ejemplo si estuvieran en Oracle) prefiero "ver"
y manipular comodamente los datos. je... debe ser que estoy curado
de espanto.
si el repositorio no requiere administración, en ese caso prefiero
ni enterarme :-D
saludos,
-Hernan
Más información sobre la lista de distribución Python-es