Diseño y optimización de base de datos
Voy a iniciar un nueva aplicación contra mysql, y resulta que no sé dónde leí que para empezar bien a diseñar la base de datos, la creación de los campos debería ser por orden, me explico: primero los de longitud fija y luego los de longitud variable, entiendo que un varchar, es longitud variable, pero no sé como calificar un integer ... Fijo o variable, me refiero a que un integer tiene n bytes (no recuerdo ahora cuantos son, eso seria fijo), pero claro, un integer es el "1" y el "32456" (cada uno de una longitud, por lo que el valor es variable) ... ¿Puedes aclararme esa duda, concretamente sobre los datos numéricos?
Por otra parte, siendo experto como eres de mysql, podrías decirme algo más respecto a la optimización de una base de datos mysql, y si es lo mismo optimizar una base de datos mysql, que cualquiera de otro tipo ...
Algoran:
Los enteros INT son de longitud fija porque ocupan una cantidad de bytes (4 para ser exactos) suficientes para contener todos los valores desde -2147483648 hasta 2147483647, salvo que uses la opción UNSIGNED, con lo que descartas el uso de negativos y aprovechas los 4 bytes para contener enteros positivos de 0 a 4294967295.
Las longitudes exactas en bytes de los distintos campos están en http://dev.mysql.com/doc/refman/5.0/es/storage-requirements.html
Hay muy buena información sobre los tipos de datos en el Capítulo 11 del manual MySQL: http://dev.mysql.com/doc/refman/5.0/es/column-types.html Te dejo el enlace no porque no quiera responder, sino porque, si deseas información en general, lo que respondiera sería un resumen de lo que allí dice. Y es bueno que conozcas ese capítulo porque brinda información valiosa, desde lo básico hasta dudas avanzadas. Hasta diría que es apasionante.
Yo generalmente utilizo con más frecuencia los siguientes tipos de campos:
INT para valores enteros
BYTE cuando sabía que usaría enteros positivos entre 0 y 255
DECIMAL para importes monetarios.
DOUBLE para números con varios decimales (no he tenido que usar más de 6 hasta el momento)
DATE para fechas (no me interesa la hora, sino utilizaría DATETIME)
VARCHAR para cadenas alfanuméricas, indicando la longitud máxima. Ej: VARCHAR(60)
TEXT para campos de observaciones
Cada motor de bases de datos responde de diferente manera a las condiciones de trabajo. Con "Condiciones de trabajo" quiero decir si habrá más números que alfanuméricos, si se almacenarán grandes cantidades de texto, si usarás transacciones o no, si se escribirá inmediatamente en disco o manejarán buffers en memoria, etc. Cada servidor tiene puntos fuertes y débiles que no son iguales para todos. Por eso, es difícil optimizar todos de la misma manera.
Sobre optimización, como manifiestas tu deseo de aprender más que de solucionar un problema concreto, vuelvo a indicar la lectura del capítulo 7, en especial la parte 7.4 http://dev.mysql.com/doc/refman/5.0/es/optimizing-database-structure.html que habla sobre optimizar el diseño de la tabla.
Por ejemplo, los permisos otorgados tienen mucha influencia. Si a un usuario se le concede solamente permiso para acceder a la base de datos, será todo mucho más rápido que si se otorgan derechos individuales sobre tablas y columnas, porque en ese caso deberá controlar los permisos casi en cualquier tarea que ejecute.
Yo personalmente uso y recomiendo el motor InnoDB, porque tiene menos problemas de rendimiento y más funcionalidades (es transaccional, con eso te digo todo).
He tratado de dar una respuesta breve pero el tema es amplio, si tienes más preguntas estaré gustoso de tratar de resolverlas.
Creo que me ha de servir bastante, aunque la respuesta podría haber sido más breve, diciendo: "si es fijo o variable un tipo de dato, no lo determina la longitud de su valor sino la definición o sea los bytes", de esta manera ya estás indicando que p.ej varchar, al tenerle que indicar tú la longitud es variable, el text pasa igual (aunque no le indiques la longitud), el date o datetime, son fijos, mientras que los integer son fijos, ya que por definición son 4 bytes, representen el valor "1" o el "23458" ... mientras que los decimal y alguno otro, supongo que deben ser variables, aunque ahora lo consultaré en los enlaces que me has indicado ...
Aunque en el manual ponga lo que quiera, me gusta hablar con gente con experiencia. Ya que p.ej en la optimización de consultas, una cosa lógica es poner la tabla a la que pertenece el campo en la select, pero hay una duda que siempre he tenido a la hora de generar de consultas, en una consulta que relacione Paises y sus Ciudades, ¿cual sería la mejor?
a) select Pais.Nombre, Ciudad.Nombre from Pais left join Ciudad on (Pais.id=Ciudad.idPais)
b) select Pais.Nombre, Ciudad.Nombre from Ciudad left join Pais on (Ciudad.idPais=Pais.id)
He leido teorias sobre todo, pero no termino de verlo claro ...
¿Que te parece a ti?
Saludos.
Algoran, cuando lees una respuesta o un libro, si lo comprendiste y puedes explicarlo con otras palabras, es mérito tuyo, no un defecto de quien escribió antes. ¿Qué culpa tiene de usar palabras diferentes a las tuyas, si dice lo mismo?
Pero a veces, mucho resumir arruina las cosas. No busques una definición genérica. Como programador, es mejor guiarse por la documentación precisa. El manual MySQL te suministra el largo en bytes de cada tipo de dato, son especificaciones técnicas, que no pueden resumirse en un solo enunciado.
Sobre tu consulta, comencemos por decir que tiene que haber un índice en cada tabla, basado en los campos que usas como id.
Respecto a rendimiento, ejecuta las querys en un programa apropiado para gestión de MySQL, que te devuelva el tiempo de ejecución en milisegundos de cada una, y compara cuál fue más efectiva. No solamente las querys, la configuración del servidor y el estado de la red inciden en la velocidad de respuesta.
Confío en no decepcionarte, pero además de tener experiencia en MySQL la tengo trabajando en proyectos reales, donde se miden los resultados, más que polemizar sobre cómo deberían ser en teoría. Ya que quieres una respuesta breve y universal, te digo una: "la consulta más rápida es la mejor".
