Que es mejor? Optimizando estructura

[leif_sk8er]

Buenas, tengo 4 dudas sobre como guardar unos datos, como puede ser mas optimo su almacenado.

DUDA 1:
En el sistema que estoy haciendo guardo la posicion en la que se encuentran unos divs en la pantalla del usuario que paso a traves de JS. Tengo que guardar el top, el left, el ancho, el alto y el eje z en el que está. Actualmente lo que hago es guardar en un campo varchar la siguiente cadena: identificadorDiv|top|left|ancho|alto|z

Pero claro, puesto que todo son numeros... ¿Seria mejor guardar cada valor en un campo por separado, teniendo 6 campos smallint (o del tipo que corresponda) en vez de solo uno que sea un varchar?

¿Que es lo mas optimo?


DUDA 2
Cuando un campo va a almacenar un valor de 1 a 8 en la actualidad lo que hago es usar enum, pero acabo de ver que entra dentro del grupo de los char en MYSQL. Entonces mi pregunta es ¿Es mejor usar enum o es mejor usar un campo tinyint de 1 caracter unsigned?


DUDA 3
Estoy guardando la duracion de unas canciones. En la base de datos guardo como varchar (5) cadenas como esto "3:43"... Creo que aqui es mejor guardarlo como int pasando eso a segundos... aunque tb podria guardar como float de este tipo 3.43 y luego partir por el punto en el php. ¿Que seria mejor para el almacenamiento?


DUDA 4
Cuando estableces un campo INT 11 por ejemplo el 11 es orientativo no? me refiero a que si pones 12 caracteres te los guarda igual no? Es que las fechas las guardo siempre como INT 11, que son los time que devuelve la funcion time de php (los segundos del server). Pero el campo int solo guarda hasta 10 caracteres, para almacenar 11 deberia usar bigint... ¿Pasa algo si lo guardo como int 11 en vez de bigint 11?

Muchas gracias por todo.

[leonardo_josue]

Hola leif_sk8er:

Antes que nada me gustaría aclarar que lo que voy a comentar son opiniones a título personal y tienen que ver en cuanto a la experiencia que he tenido con Base de Datos, igual y alguien te puede dar alguna otra recomendación, pero creo que te puede ayudar en algo:

DUDA 1. En lo particular no recomiendo utilizar campos tipo varchar con delimintadores y sería más conveniente manejar cada campo por separado. Una de las razones principales es que tú estás suponiendo que la cadena siempre va a tener un formato u orden determinado, pero por error podrías alterar dicho orden y la presentación de tu div podría verse afectada. Además, el mantenimiento de dicha tabla sería más fácil, ya que cambiar un atributo sería de manera directa, sin tener necesidad de contar posiciones ni nada por el estilo e incluso.

En cuanto a manejar los campos tipo numérico, esto no es completamente necesario, te recuerdo que al manejar dimensiones en HTML puede poner por ejemplo width="100%" lo que sería diferente a poner width="100". podrías por lo tanto manejar los campos como tipo varchar hasta de 4 posiciones por ejemplo.

DUDA 2. siempre he preferido la utilización de catálogos en lugar de enumeraciones, no importa si son muy pequeños. Por ejemplo en el trabajo manejamos catálogos con solo dos registros (0 = SI, 1 = NO) pues nos ocurrió hace tiempo que teníamos un campo tipo bit (0 y 1) y al parecer cumplía con todos los requerimientos, pero al tiempo hubo la necesidad de manejar un tercer estado y por lo tanto el campo bit ya no nos sirvió. al manejar catálogos, simplemente agregas un registro a tu tabla catálogo y manejas su respectivo indice donde lo requieras.

DUDA 3. Aquí habría que preguntarte si necesitas hacer algún cálculo con la duración o simplemente es informativo, ya que no abría mucha diferencia en cuanto al almacenamiento, también dependería de la duración máxima de tus canciones (para la opción de convertir la duración en segundos) por ejemplo con un smallint podrías manejar una duración de hasta 32767/60 Seg = +500 minutos y sólo ocuparáis 2 bytes de almacenamiento.

DUDA 4. Esta es una pregunta recurrente en el foro, el once no tiene que ver con la capacidad de almacenamiento del campo, sino en la forma de presentar los enteros, me remito al siguiente párrafo de la documentación para tratar de explicar su uso:

MySQL soporta otra extensión para especificar de forma óptima el ancho a mostrar de un tipo entero en paréntesis después de la palabra clave para el tipo (por ejemplo, INT(4)). Esta especificación opcional del ancho de muestra se usa para alinear a la izquierda la muestra de los valores con ancho menor que el ancho especificado para la columna.

El ancho de muestra no restringe el rango de valores que pueden almacenarse en la columna, no el número de dígitos que se muestran para valores con ancho que exceda el especificado para la columna.

Cuando se usa en conjunción con el atributo de extensión opcional ZEROFILL, el relleno por defecto de espacios se replaza por ceros. Por ejmplo, para una columna declarada como INT(5) ZEROFILL, un valor de 4 se muestra como 00004.

Saludos
Leo.