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