Mejor Practica?

Hola, yo no lo uniria en la misma tabla ya que seguramente no necesitaran
los mismos campos, por ej quizas un empleado necesite la fecha de nacimiento
pero un cliente no. Yo los separaria cada cual en una tabla



Salu2

Microsoft MVP SQL Server
www.sqlgururs.org
Email:


"JHenao" wrote in message
news:

Saludos,
Me gustaría que me aconsejaran en una decisión de diseño de una BD.
El escenario : un sistema en el que intervienen Clientes, Vendedores,
Proveedores y Empleados.
En dilema:
¿Como regla general, Seria buena practica unir estas entidades en una
sola
tabla ya que son similares y establecer la diferencia a través de un
campo
tipo, o es mejor que
conserven la independencia?

Personalmente soy amigo de la segunda pero me plantearon la otra
alternativa
y la verdad no estoy seguro.

JHenao
MCP
Medellín - Colombia

Yo solo dejaria Vendedores y Empleados juntos, pues es muy posible que
'Vendedores' sea un subconjunto de datos de Empleados y por tanto tendrias
datos duplicados. Bastaria con un campo 'TipoEmpleado'.


saludos,

Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com


"JHenao" escribió en el mensaje
news:

Saludos,
Me gustaría que me aconsejaran en una decisión de diseño de una BD.
El escenario : un sistema en el que intervienen Clientes, Vendedores,
Proveedores y Empleados.
En dilema:
¿Como regla general, Seria buena practica unir estas entidades en una
sola
tabla ya que son similares y establecer la diferencia a través de un
campo
tipo, o es mejor que
conserven la independencia?

Personalmente soy amigo de la segunda pero me plantearon la otra
alternativa
y la verdad no estoy seguro.

JHenao
MCP
Medellín - Colombia

Aunque mi experiencia no es mucha, te aconsejaria lo siguiente:

Que en una tabla tengas los datos generales que todos tienen en comun y si
deseas ya tienes datos especificos por cada uno de ellos en otras tablas.
En una tabla adicional podrias tener que son cada uno, es decir algo asi:

tablatodosqueson
codigotodos campoqueson
C1 1
C1 2
C2 2

Siendo C1 el codigo de esta entidad y 1 si son clientes, 2 trabajador, 3
etc.

Saludos

PD Esto es por si cambias datos de algunos de ellos, osea basicos lo haras
para todos y no tendrias que estar haciendo en cada tabla

"JHenao" escribió en el mensaje
news:

Saludos,
Me gustaría que me aconsejaran en una decisión de diseño de una BD.
El escenario : un sistema en el que intervienen Clientes, Vendedores,
Proveedores y Empleados.
En dilema:
¿Como regla general, Seria buena practica unir estas entidades en una
sola
tabla ya que son similares y establecer la diferencia a través de un
campo
tipo, o es mejor que
conserven la independencia?

Personalmente soy amigo de la segunda pero me plantearon la otra
alternativa
y la verdad no estoy seguro.

JHenao
MCP
Medellín - Colombia

Para mi es una MUY MALA PRACTICA de diseño de BD querer juntarlas en una
sola. Recuerda que son ENTIDADES (conjuntos) diferentes y por tanto con
reglas declarativas de integridad diferentes. Imagina por ej. que el
cliente o el proveedor sean una empresa, o que un vendedor no sea
necesariamente un empleado, o que los empleados requieran necesariamente
especificar su sueldo, su puesto y departamento, etc. etc., cuantas
excepciones tendrías que manejar? No crees que sería innecesariamente
costoso el mantenimiento?

Me parece que tu confusion viene de uno de esos viejos vicios de los
programadores de tratar de ver orientación a objetos (OO) en una BD
relacional para luego erroneamente manejar las reglas de integridad desde la
aplicacion. Todo lo que sea una entidad o una relación diferenciada debes
presentarla en una tabla independiente y usar el propio SGBD para definir
las reglas de integridad y/o negocios hasta donde sea posible.

Ricardo Passians




"JHenao" wrote in message
news:

Saludos,
Me gustaría que me aconsejaran en una decisión de diseño de una BD.
El escenario : un sistema en el que intervienen Clientes, Vendedores,
Proveedores y Empleados.
En dilema:
¿Como regla general, Seria buena practica unir estas entidades en una
sola
tabla ya que son similares y establecer la diferencia a través de un
campo
tipo, o es mejor que
conserven la independencia?

Personalmente soy amigo de la segunda pero me plantearon la otra
alternativa
y la verdad no estoy seguro.

JHenao
MCP
Medellín - Colombia

Antonio

Tal vez te refieras al PUESTO, que ocupa un EMPLEADO en la compañia

Saludos
IIslas


"Antonio Ortiz" wrote:

Yo solo dejaria Vendedores y Empleados juntos, pues es muy posible que
'Vendedores' sea un subconjunto de datos de Empleados y por tanto tendrias
datos duplicados. Bastaria con un campo 'TipoEmpleado'.


saludos,

Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com


"JHenao" escribió en el mensaje
news:
> Saludos,
> Me gustaría que me aconsejaran en una decisión de diseño de una BD.
> El escenario : un sistema en el que intervienen Clientes, Vendedores,
> Proveedores y Empleados.
> En dilema:
> ¿Como regla general, Seria buena practica unir estas entidades en una
> sola
> tabla ya que son similares y establecer la diferencia a través de un
> campo
> tipo, o es mejor que
> conserven la independencia?
>
> Personalmente soy amigo de la segunda pero me plantearon la otra
> alternativa
> y la verdad no estoy seguro.
>
> JHenao
> MCP
> Medellín - Colombia
>