[pgsql-ayuda] Relacionar tablas

Mario Oroz jmoroz@uol.com.ar
Tue, 27 Mar 2001 13:09:08 -0300


----- Original Message -----
From: JARRIN FLORES JORGE ALEXIS <JJARRIN@puceuio.puce.edu.ec>
To: <pgsql-ayuda@tlali.iztacala.unam.mx>
Sent: Monday, March 26, 2001 7:27 PM
Subject: RE: [pgsql-ayuda] Relacionar tablas


> Situación actual:

PERSONAS
*id_ciudadano
  nombre
  dirección
  telefono

ESTUDIANTES
    dato_estudiante1 --> donde debe constar la clave primaria de la tabla,
*id_universitaria
    INHERITS de PERSONAS
De esta forma la persona puede ser estudiante y empleado sin ninguna duplicacion
de datos.



 EMPLEADOS
      dato_empleado1 --> donde debe constar la clave primaria de la tabla,
*id_empleado
      INHERITS de PERSONAS

PROVEEDORES
     dato_proveedor1 --> donde debe constar la clave primaria de la tabla,
*id_proveedor
     INHERITS de PERSONAS

> Una solución es tipificar en una sola tabla con un atributo que describa el
> tipo de entrada, p ej. e = estudiante; f = empleado; p = proveedor., pero

Seria innecesaria una tabla de este tipo

> existe el inconveniente de que si el empleado es también estudiante (cosa no
> muy rara en mi caso), no podría incluirlo en la tabla a menos que cambie el
> id, cosa que no puedo por cuanto no es un número aleatorio ni arbitrario,
> esto se resolvería con incluir en la llave primaria el atributo de
> tipificación pero no evito el problema de la duplicación de datos.
> Una solución más sólida (para mí) es la siguiente:
>
> persona------------<estudiante
> |----------- empleado
> |----------- proveedor

Es algo parecido a lo que escribi arriba.

> La relación a varios en estudiante es porque este puede pertenecer a varias
> carreras, miren que ninguna es mandatoria.
No entiendo lo que queres decir con que ninguna es mandatoria.

supertipo  =>   personas------------estudiantes    <= subtipos que heredan
                         |------------------- empleados
                         |------------------- proveedores

                                        estudiante <-------->> carreras

Un estudiante (una instancis de estudiantes ) puede estar inscripto en 1 o
muchas carreras (varias instancias de carreras ), mientras que navegando a la
inversa desde una instancia de carrera obtengo un solo estudiante.

  Así el modelo funciona, pero
> tengo la curiosidad de probar la herencia de PostgreSQL en el mismo esquema
> y si los conceptos de tipificación se pueden adaptar transparentemente a la
> herencia.
>
> Si la tabla persona contiente más de 10.000 registros, la estudiante más de
> 5000, la de empleado 2000 y la de proveedores unos 500 y tengo tres sistemas
> trabajando sobre las mismas tablas, claro mirándolas de diferente manera,
> ¿el rendimiento de PostgreSQL será mejor usando "INHERITS" que la típica
> forma de "Foreing Keys"?

Por que supones que las Foreign y las Inherits tienen el mismo sentido.
No creo que las inherits te solucionen tan bien el problema de la integridad
referencial como las foreign.
Yo veo la Inherits tal como se describen los Subtipos y Supertipos en los DER
(Diagramas de Entidad Relacion -paso previo a una normalizacion en el analisis
de sistemas).
No recuerdo bien el tema y no se si se implementan este tipo de herramientas
donde estudies porque aca en la Argentina estamos un poco atrasados en
cuestiones de Planes de estudios.

 ¿y si cambio la implementación de Foreing Keys por
> la de INHERITS, cuales serían los riesgos, ventajas o desventajas?.
Es jodido tratar de esplicarlo reoricamente, yo no puedo, es cuestion de
enterrar la cabeza en tu PC y realizar  pruebas.


  Por
> otro lado está el asunto de los bloqueos, de los cuales me he desentendido
> hasta resolver mi curiosidad.
>
> Claro que tendré que preparar cuidadosamente el escenario de las pruebas (el
> modelo es mucho más complejo que el que les muestro), en cuanto lo haga les
> avisaré, a menos que alguien me diga que ha hecho algo parecido y me cuente
> sobre el resultado.
>
> Bueno, espero no haber molestado mucho.
>
> Atte,
> Jorge
>

Saludos
Mario -- Pipati.

--------- Pie de mensaje -------------------------------------------
Archivo historico: http://tlali.iztacala.unam.mx/maillist/pgsql-ayuda
Cancelar inscripcion:
mail to: majordomo@tlali.iztacala.unam.mx
text   : unsubscribe pgsql-ayuda