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:
Código:
Tabla Tipos esto creo que es un debate, porque se puede hablar bastante ;) Saludos |
Cita:
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. |
Cita:
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
e igual para la insercion modificacion.
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
Cita:
neftali: Cita:
Cita:
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: Cita:
Bueno, esta es mi opinión... Es solo eso, una opinión |
Cita:
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. |
La franja horaria es GMT +2. Ahora son las 01:39:13. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi