cual es la mejor forma de diseñar

[Snd234]

Hola... estoy comenzado a diseñar el modelo de datos para un proyecto académico y me surgió la siguiente duda:

Resulta, que todos los modelos que hacia, utilizaba algunas tablas como por ejemplo; Forma_pago, Tipo_usuario, etc. Donde la información contenida en esas tablas era muy poca y no se editaba casi nunca (mejor dicho, nunca).

Entonces mi duda es, si es necesario o recomendado utilizar este tipo de tablas cuando la información es mínima, o es mejor dejar un campo en la tabla que necesite esta información?

Por ejemplo, si tenemos la tabla Productos y otra Tipo_Productos. Esta última puede tener nuevos datos que pueden ser usados para clasificar un Producto, por lo que se justifica su existencia.

Pero si por ejemplo tenemos Pagos y Forma_Pago. La última tabla tiene 3 registros. 'Efectivo', 'Cheque', 'Tarjeta Crédito', y difícilmente se pueda incluir una nueva forma de pago. Se justifica tener una tabla única para esa información? O es mejor hacer un campo 'forma_pago' dentro de la tabla Pagos que contenga textualmente la información del pago, o un numero, pero que su significado sea interpretado a través de la programación, donde tenga por ejemplo constantes que digan que el código 1 representa a la forma de pago 'Efectivo', la 2 a 'Cheque' y así sucesivamente???

Que dicen?

[gnzsoloyo]

Tablas primarias del tipo que mencionas, si bien casi nunca son editadas, no implica que no sean usadas en una consulta. Me explico:
Supongamos una base de datos académica, en la cual se puedan almacenar los tipos de cargo (Profesor titular, Adjunto, Jefe de Trabajos Prácticos, etc.). Si bien es muy poco probable que la misma sufra variaciones a través del tiempo, eso no implica que se deba evitar tenerla por la simple razón que si no estarías obligando cada vez que ingrese un docente a una cátedra a poner manualmente el tipo de cargo que tiene. El inconveniente de eso es que deberás lidiar con el elemento de mayor entropía de un sistema: El ser humano. Es muy habitual que los data entry abrevien los cargos (Porf. Tit, o bien Prof. Ttlar.), o simplemente lo ingresen mal y una entrada de tipo alfanumérica no es fácilmente detectable. En cambio, si lo que ingresas es un número, la cosa cambia:

Código:

ID DESCRIPCION
1 Profesor titular
2 Profesor adjunto
3 jefe de trabajos prácticos.

Obviamente cuando se hace el listado de una consulta, lo que se hace es enlazar los ID entre ambas tablas y se tiene un listado coherente.

¿Se entiende la idea?

SIEMPRE existen en todo sistema este tipo de tablas y SIEMPRE se usan, porque nadie va a ponerse a memorizar los códigos de todos los empleados y sus categorías de memoria, y los data entry siempre cometen errores que luego dan lugar a información inconsistente.
En definitiva, el objeto de esas tablas es minimizar los errores y disminuir el efecto "Ley de Murphy"...

[Snd234]

Pero eso se podría manejar a través de la programación, como había dicho anteriormente. Creando variables o constantes que identifiquen a cada valor.

Siguiendo tu mismo ejemplo, y programando en php seria algo como:

Código:

$tipo = array(
  1 => "Profesor titular",
  2 => "Profesor adjunto",
  3 => "Jefe de trabajos prácticos"
);

Entonces, esa información, que no será modificada por el usuario, se despliega y el selecciona la opción correcta, y allí se insertaría el índice correspondiente, y al querer saber luego que tipo es se consulta esa variable.

Además que es seria eficiente que obtener y mostrar los datos haciendo una consulta a la misma base de datos, ya que la información ya la tengo y es cosa de mostrarla.

[gnzsoloyo]

Esa es precisamente la visión de los programadores... Pero cuando trabajas en base de datos la visión es diferente. Lo que estás planteando es, disculpa, una visión muy antigua del modelo, previo incluso al desarrollo de la programación orientada a objetos.

Dime: ¿Cómo harías si se debe desarrollar una consulta que no está contemplada dentro del esquema inicial, usando el por ejemplo, ante la creación de nuevos cursos y nuevas facultades? ¿Cómo harías para programar un método flexible que pueda crear dinámicamente una tabla, sin saber a priori si vas a utilizar o no ciertos datos?

El principal problema de lo que planteas es que "congelas" el modelo de datos, de modo que si se produce, eventualmente, cualquier modificación al esquema inicial, hay que modificar toda la aplicación para adaptarla, mientras que en el otro caso solamente habría que incluir un registro...

Además, piensa esto: El sistema no tendría ninguna portabilidad, precisamente porque no permitiría cambiar las denominaciones de los items ingresados. ¿Y si el usuario quiere cambiarlos sin borrarlos?
Como ejemplo: Si la tabla contuviera cargos de una empresa de transporte, ¿qué pondrías como encargado de los transportes? ¿chofer o conductor? ¿Cómo llamarías a un transporte público de pasajeros? ¿Ómnibus, micro, microomnibus, camión, movil, vehiculo, bus, colectivo o uaua (como dicen en ciertas regiones)?
¿Y si el cargo deja de existir o simplemente no existe? ¿Cómo lo pones o lo sacas?

Una de las reglas principales del diseño de sistemas es: "La estructura del modelo de datos debe ser flexible, capaz de responder consultas que nunca se pensaron, y totalmente independiente de la aplicación que use los datos".

Resumen: Esas tablas SIEMPRE existen y DEBEN EXISTIR. Hace que los sistemas sean flexibles, fácilmente actualizables y muy portables.
Como anécdota, te cuento que lo de chofer o conductor ya lo hemos sufrido. En un desarrollo .Net los términos entre Argentina y México cambian... y eso implicó muchas horas de programación extra para sacarlos y poner otros.

[Snd234]

Gracias por tu respuesta, y por la fundamentación.

La verdad que la duda surgió ya que estoy en un proyecto y tengo varias tablas "tipo", de hecho ya lo tengo así y no lo voy a cambiar, pero ahora estoy comenzando otro proyecto académico y me surgió la duda si seguir utilizando este tipo de tablas o usarla como campos (ya que hay tablas con pocos datos y nula modificacion), ya que así me evito hacer "tantas consultas" a la base de datos. Claro, hay consultas que traen toda esa información de una vez, pero a veces me es necesario consultar registro por registro y eso equivale a una consulta por registro, lo que no es muy eficiente (siempre estoy pensando en minimizar las consultas a la base de datos).

Y que hay de tipos de datos enum en Mysql? Son recomendables usarlo en reemplazo de este tipo de tablas?

[jurena]

Estoy completamente de acuerdo con gnzsoloyo. Yo no habría sabido expresarlo mejor. Como usuario no técnico quisiera añadir a lo dicho que la presencia de esa tabla permite ordenar ascendente y descendente por el dato y no por el id, algo que con programación, si no me equivoco, requeriría cargar en un array y ordenar luego. Por supuesto, el añadido a esa tabla de otros campos permite el uso de abreviaturas, utilizar otros criterios de ordenación y agrupación, etc. Imaginemos que Profesor Titular y Profesor Titular de Escuela Universitaria quieren agruparse en el mismo grupo. Basta con añadir un campo a esa tabla llamado critagrup y poner 1 en ambos registros. Luego agrupamos por ese campo. En resumen, creo que merece la pena agregar esas tablas y no usar sólo el número de referencia o un campo ENUM en la tabla de datos.

[gnzsoloyo]

El uso de ENUM adolece del mismo problema, en este caso, que incorporar el listado de datos al programa, pero con un agregado que lo agrava: Como ENUM se define en la tabla, afecta toda inserción que se haya hecho o se haga en el futuro, dando lugar, si se redefine, a resultados inesperados.
Sería el caso de redefinir el ENUM para que admita NULL: EL campo pasaría a ser NULL si el valor ingresado no existiese, con todos los problemas que puede eso ocasionar.
En realidad los campos ENUM son útiles bajo circunstancias específicas, donde los valores o el rango posible de valores realmente es estricto e inmodificable. Ese sería el caso de un campo "SEXO" de una tabla "PERSONAS". Biológicamente hablando,sólo hay dos (ese campo no dice "PREFERENCIASEXUAL"...). Así también puede ser útil para conjuntos acotados como casado/soltero/divorciado/viudo/separado, etc.
Fuera de esos casos, ENUM debe ser manejado con cuidado por lo que te dije: como se define en la tabla, modificarlo es modificar la base de datos...

[kikolice]

segun mis conocimientos, la aplicacion NUNCA debe de manipular la informacion de la base de datos, el utilizar un array con los elementos a nivel aplicacion no deberia de suceder, yo me iria por lo mas flexible, como te dicen, crear una tabla especifica para esos datos aunque se suponga que nunca se van a modificar (esa regla generalmente se rompe creeme) incluso llendonos mas lejos en lugar de que la aplicacion acceda diractemente a las tablas de la base de datos bajarla aun mas creando APIs y que la aplicacion solo pueda acceder a esas apis, con eso logras independencia de herramienta, podrias tener una aplicacion trabajando con php, con .net con los que sea trabajando sobre la misma base de datos usando las mismas apis

[Fridureiks]

Me ha parecido muy interesante todo lo que ha comentado el compañero gnzsoloyo, yo personalmente en algunos trabajos recurrí a meter datos fijos por el lado de la programación pero luego de leer esto me doy cuenta que no estaba teniendo en cuenta todas las posibilidades.

Me pregunto si conocen alguna guia/libro que contenga este tipo de información sobre diseño y buenas prácticas. Pienso que nunca le di mucha importancia al asunto y ya es hora de cambiar eso.

Muchas gracias al que se tome la molestia

[Genetix]

Añadiendo a lo dicho

Estas interrogantes se plantean y se resuelven dentro del proceso de normalización, muchas veces se comete el error de crear las tablas sin tener un diseño previo y tratar de resolver los inconvenientes con programación, lo cual es resulta siempre desastrozo al final.

Siempre que se diseñe una DB se tiene que pensar como podría evolucionar la información en el futuro y tratar de anticiparse y recuerden que los sistemas siempre evolucionan.

Saludos!