Las explicaciones son varias, y algunas en realidad son algo largas...
Cita: Esa tabla es de un componente de Joomla.
Joomla, como herramienta, es una aplciación multipropósito, que no respeta fielmente el modelo Entidad-relación, en aras de dar flexibilidad a las construcciones. Pero cuando agregas algo, debes tratar de atenerte a diseños correctos. De lo contrario estarás agregando ineficiencia y atentando contra la performance.
Cita: El autoincremente ya venia así, ¿que problemas me puede traer?
El autoincremental es innecesario porque la PK definida como compuesta, ya genera lo que s una PK, y ese auntoincremental pierde sentido. Los auutoincrementales se usan por simplicidad para programar, pero no son necesarios en una BDD salvo para determinados usos. Una PK no necesita ser ni numérica ni incremental, sino identificar univocamente cada registro de la tabla, y con esos dos campos componiendo la PK es más que suficiente.
Cita: Y si, ese campo params es una cadena de texto y esta separado por comas, cada uno es un "parámetro" se podría decir.... la mitad de las tablas que tiene Joomla son asi.... Desde la ignorancia... ¿Cuál es el problema?
Una de las estrictas prohibiciones del modelo E-R es que
no deben existir campos multivaluados, bajo ninguna circunstancia. La existencia de campos multivaluados muestra que es una base desnormalizada (viola la 1FN).
Ese tipo de campos son usados en herramientas como Joomla y otros, porque se basan en taxonomías, y no en relaciones, las relaciones se construyen en ese caso programáticamente, lo que hace que la base se transforme en una bolsa de bolsas de datos, con alto riesgo de inconsistencia.
El problema a corto plazo es que como esos campos tienen múltiples valores, no sirven para relacionar estructuralmente las entidades, no son adecuados para consultas eficientes y optimizadas, y tienden a generar gran cantidad de redundancia.
Escribir consultas sobre campos multivaluados lleva, entre otras cosas, a usar funciones de cadena en MYSQL para poder lograr los resultados. El uso de excesivas funciones tarde o temprano conspira contra la performance.
Además, puede obligar a leer datos desde la aplicación, procesarlos en la aplicación, enviar nuevas consultas con esos datos, recuperar otro bloque a procesar y volver a inciar el ciclo, antes de obtener lo que realmente se deseaba. Todo es vaivén de idas y vueltas entre la aplicación y la base implica dos cosas: 1) exceso de acoplamiento entre aplicación y base (un defecto de software grave), y 2) Exceso de transacciones a la base, que conlleva costos operativos y de proceso.
En síntesis: en la práctica es una mala idea... y en diseño de datos, un campo multivaluado es suficiente para reprobar cualquier examen sin que el profesor siga leyendo lo que se escribió.
Cita: Lo de los VARCHAR, lo mismo, es de joomla. Pero no, no sabia que ya no tenían limite.
Todo tipo de columna tiene límite. Lo que decía es que el límite del VARCHAR no es 255, sino 65535, como dice el manual.
Cita: Ítem almacena un entero, un numero.
Si "item" guarda un número, corresponde que uses columnas numéricas, no de cadena. Los números no se almacenan como cifras, sino como binarios, lo que significa que para almacenar un valor entre -128 y +127 , o bien entre 0 y 255 se usa 1 byte (8 bits de ancho), y no 4 bytes como cadena. Y para almacenar un numero como 18446744073709551615 se usan 8 bytes, en lugar de 20...
Cita: -Puedes explicarme el por que no poner un valor por default en un campo clave?
Un campo que es PK no puede tener valor por default por la simple razón de que es PK: Sus valores son únicos en la tabla, y si pusieses un valor por default, si no ingresas los valores correspondiente se podría generar un valor PK ya existente, lo que dispararía un error de inserción por clave duplicada.
Además, uno de los principios de las PK es que son datos
obligatorios, por lo que
jamás puedes dejarlos nulos, ni intentar poner un nulo.
¿Se entiende?
Ergo, si los campos son PK, no deben tener valores por default.