Varios Tipos en una misma tabla

[Neftali [Germán.Estévez]]

Empezado por JoanKa

Esta bien esta estrucutura o Mejor seria para cada tipo de persona hacerle UNA TABLA cada uno con su respectivo PK

Mientras todos los datos sean iguales para todos los tipos yo lo mantendría en la tabla, es como un atributo más (tipificación); En el momento en que uno de esos tipos necesite un campo, que para los otros no tiene sentido (por ejemplo imagina que ahora para los CLIENTES, y sólo para éstos, necesitas añadir un campo ClienteInterno:Booleano -me lo invento-); En ese momento deberías dividirlo, porque te estará indicando que sn entidades diferentes.

Hazlo con previsión y si piensas que posteriormente te va a pasar ésto, divídelos de un principio y evitarás después más problemas.

De todas formas y aunque todos los tipos sean iguales también puedes dividirlos en tablas diferentes; depende de si los consideras entidades iguales o diferentes; Una pregunta que te puede servir para escoger es la siguiente:

¿Tiene sentido ver todos los elementos de esa clase juntos? ¿Tendrás un Grid (por ejemplo) donde salgan clientes, mezclados con proveedores, mezclados con Empleados,...?
Si la respuesta es NO, porque no tenga sentido verlos juntos, es indicativo de que son entidades diferentes y por lo tanto que tendrían que ir en tablas separadas. Si en algun momento tiene sentido llegar a ver mezclados clientes, con proveedores, con empleados,... significa que esa característica debe ir como atributo y por lo tanto en la misma tabla.

Espero no haberme alargado mucho y haber sido claro .

[rastafarey]

Mira te puedo dar varias opciones por las cuales a mi me resulta mas conveniente mesclar todas las tablas en una sola. primero el ODS es mas pequeño.

Segunda las tablas del sistema tiene menos registros y menos relaciones.

La unic adesventaja es que si en los triguers levantas excepiones tienes que verificar el tipo del campo a que identifica a dicah tabla o grupo y levantarla o hacer la validacion dependiendo del tipo.

Bueno es o es lo que pienso.

Son las razones que veo no es que sean absolutas.

Para poder ver cual es la mejor hay que hacer una prueva de estres a ver como respondes mejor.

[Neftali [Germán.Estévez]]

Empezado por rastafarey

Mira te puedo dar varias opciones por las cuales a mi me resulta mas conveniente mesclar todas las tablas en una sola. primero el ODS es mas pequeño.
Segunda las tablas del sistema tiene menos registros y menos relaciones.

Lo siento, pero no estoy de acuerdo.
No creo que se deba modificar el diseño de una Base de Datos para tener en cuenta que el resultado tenga menos tablas, menos relaciones o menos objetos de sistema. El diseño es, el que es, bueno o malo y tendrá los objetos que tenga que tener. Si luego hay que optimizar código, se hace, pero ese razonamiento me parace incorrecto.

Es una opinión. ojo!!.

[marcoszorrilla]

Yo tampoco estoy de acuerdo. Solamente una vez y esto era en Clipper hice algo así mezclé clientes y proveedores, a la larga me dio más trabajo en la codificación y siempre las consultas resultan más pesadas puesto que al mezclar la entidad cliente con Proveedor, siempre hay que filtrar por una de las dos para separarlas, lo que para mí quiere decir que deben de estar separadas en tablas distintas.

Otro problema, supongamos que implementamos un mecanismo que compruebe que todos los códigos de cliente comiencen por 430, para compatibilizar con la contabilidad, cuando de de alta un proveedor, me encuentro que ahora tiene que comenzar por 400....

Mi conclusión es cada entidad en una tabla distinta aunque sean parecidas.

Un Saludo.

[rastafarey]

Solo di esa opinion desde mi punto de vista no quiere decir que sea la mejor.

Por ejemplo realice una aplicaion.

Donde habian 62 tablas que tenian

CodNomObs
Id integer
codigo varchar
Nombre Varchar
tipo integer (usado para diferenciar cada tabla)

y las inclui en uns sola

el delphi

solo tube que hacer una sola forma para todoslo los mudulo
y solo cambiaba el tag d ela forma y me ahooro mucho tabajo.

En el codigo sql

Código SQL [-]
  Select * From CodNomObs Where Tipo = %d;

e igual para la insercion modificacion.

Código Delphi [-]
    With LAFormat.Craete(Self) Do try
       Tag := tecomponent(serden).tag;
       Inicializar;
       ShowModal;
   Fianally
      Free;
   End;

//el codigo de inicializar el cual llamo en onshow
begin
   Eldataset.Sql.text := format(Eldataset.Sql.text, [Tag]);
   Eldataset.Open; 
end;

//Para los caption cree un arreglo para todos los tipos con lo captions

Esta es mi opinion en este caso.
Por para esta aplicacion me convenia.

Pero tienen razon en cuanto a las reglas de diseños de base de datos.

Eso no se discute. Pero no siempre se adpata al tiempo y alo que se quiere.

[marcoszorrilla]

No se trata de ninguna lid, lo importante es que cada uno de su opinión, la razone y así entre tantas opciones, será más fácil elegir, a parte de enriquecer a la comunidad.

Un Saludo.

[Neftali [Germán.Estévez]]

Empezado por rastafarey

CodNomObs
Id integer
codigo varchar
Nombre Varchar
tipo integer (usado para diferenciar cada tabla)

y las inclui en uns sola...

Yo también he hecho algo similar en alguna ocasión (no es tan descabellado) utilizando una "Tabla General" para todos los tipificados de una aplicación (Tipos de IVA, Tipos de Estado Civil, Tipos de Retenciones, Tipos de Coloración, Tipos de vehículos,.... y 40 más...) cuando són tablas "sin información propia"/"sin vida propia"/"sin chica" vamos; Que sólo sirven para "tipificar" cosas y que tienen una estructura como tú dices simple y repetitiva (CODIGO, DESCRIPCIÓN, VALOR y TIPO -para diferenciarlas-); Que conste que tampoco es "estrictamente correcto", pero a veces tampoco hay que ser "más papista que el papa", como dicen aquí.

La diferencia de éste caso (o el ejemplo que tú das) y el suyo es que sus Entidades/Tabla no son tablas de tipificación o sin importancia, si no qe habla de Clientes/proveedores y creo que en ese caso -en mi opinión- no es aplicable.