Varios Tipos en una misma tabla
 

Hola a todos.

Tengo una duda que algunos me dice SI otros me dicen No. Aqui va!!!!

En una Tabla_Personas tengo un campo "tipo_persona" que identifica al cliente "C", empleado "E", proveedor "P" y transportista "T"

Es decir en una misma tabla lo tengo todo junto tanto a los C,E,P,T y cuando deseo hacer una consulta los separo por este campo, por lo tanto si quiero hacer una consulta de cliente voy a esta tabla y selecciono el los datos delmismo por el campo tipo_persona="C",

Mi pregunta es????

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

Cliente
id_cliente, nom, direcc................etc

Provedor
id_proveedor, nom, direcc................etc
.
.
.
etc

Gracias, Saludos

En principio deberías tener:

Muchas veces, por comodidad en la programacion, se hace como tu lo has hecho. Si tienes que acceder constantemente a los datos personales, es mejor tener el tipo_persona en la misma tabla.

esto creo que es un debate, porque se puede hablar bastante ;)

Saludos

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 ;).

respuesta
 

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.

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!!.

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.

Es mi punto de vista
 

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.

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.

Otra opinion
 

Bueno, pienso que depende mucho de la cantidad de registros de cada tabla, sin embargo creo que es mejor tener cada tipo de perdona separado, pues ayuda a simplificar las consultas (si por ejemplo debes crecer y colocar los datos en un servidor al que accedan varios cleintes). Además lo que dice
neftali:

es para tener en cuenta.

Pienso que si. debes separa las tablas, de manera que no se te junten lo limones con los mamoncillos.

CLIENTE
CLI_ID
CLI_NOMBRE
CLI_DIR
...

EMPLEADO
EMP_ID
EMP_NOMBRE
EMP_DIR
...

PROVEEDOR
PRO_ID
PRO_NOMBRE
PRO_DIR
...

ETC

Con respecto a lo de:
Realmente el tamaño no será mucho mas grande como para considerarlo ventaja ante el tiempo de creación de las tablas y los indices y claves.

Bueno, esta es mi opinión... Es solo eso, una opinión

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.