16/12/2002, 08:36
|
| O_O | | Fecha de Ingreso: enero-2002 Ubicación: Santiago - Chile
Mensajes: 34.417
Antigüedad: 22 años, 4 meses Puntos: 129 | |
| Como bien dice Herminio ... cada proyecto requiere de tu técnica .. o bien un campo ENUM o una tabla extra para tener esos datos que usaras sus Id's correspondientes para establecer una integridad referencial entre ambos.
Personalmente, si son pocos datos y fijos (al menos que no varien contantemente salvo algun tipo de "upgrade" o actualización muyyy de vez en cuando) .. mantengo esos datos en un campo ENUM.
Si son esos datos susecptibles a ser modificados a menudo .. prefiero usar una tabla extra y gestionar las claves foraneas (keys) ...
A veces .. normalizar al extremo implica mucho tiempo de proceso (varias consultas) para procesar una peticion a tu base de datos ya que tienes que ir recorriendo todas las tablas implicadas para obtener un resultado "legible" (es decir .. para representar esos "Id's" que guardas en tus tablas "padre" de las "hijas").
La ventaja que tiene "normalizar" es que la información se hace lo menos redundante posible .. optimizando el tamaño de tu base de datos .. pero no así la velocidad de acceso.
En un campo ENUM tenemos la rapidez de que "ahi mismo" en la misma tabla tenemos el campo "legible" listo para ser presentado con la técnica que propuso BVis ..
Estos Campos ENUM se pueden optimizar un pco .. para tener una base de datos un poco mas ligera (de peso - tamaño) .. se trata de tener en un array (PHP) los valores (usuarlmente string - cadenas) que tengan ese ENUM ... pero en el campo ENUM guardar solo Identificativos Numericos que serán los que usemos como indices en nuestro Array PHP para representar su valor "legible" ..
Esto aligeraría la base de datos .. pero en cada consulta le sumamos el proceso de gestinar el array por parte de PHP .. ademas de que si acccedemos a esta base de datos con otro software escrito en otro lenguaje .. este a su vez deberá implementar la lógica del Array ...
Un ejemplo seria a la hora de usar un administrador de Mysql tipo phpMyadmin .. este tiene la virtud de generar una lista desplegable con las opciones de un campo ENUM a la hora de crear/modificar un registro sobre el propio administrado directo en Mysql ... ahí, en este caso, solo veriamos nuestros indices numericos .. y seriamos nosotros (administrador o quien gestione esa base de datos) el que tenga que tener en un "papel" u otro medio las correspondecias ENUM numerio con --> valor a presentar.
Yo he usado este último método en una aplicación .. pero lo hice porque sabía que del entorno PHP+Mysql e incluso mi propia apliación no va a salirse .. Pero si algun dia por A o B motivo se ha de atacar esa Base de datos desde otra aplicación .. tendrán q "apañarselas" con mi "optimizacion de peso de la base de datos" .. En tal caso .. al guardar identificadores numéricos .. no seria nada dificil ni "drastico" implemtar una tabla extra (para la base de datos .. q seria una replica del array q ya usaba) y establecer las claves foraneas (keys). en las consultas que correspondan ...
Un saludo, |