Duda optimizar campos tabla

[neodani]

Buenas,

Me gustaría saber vuestra opinión sobre la siguiente estructura de la tabla

Código SQL:

CREATE TABLE partidos (
    id INT(11) NOT NULL AUTO_INCREMENT,
    idsoccer INT(1) NOT NULL,
    competicion INT(1) NOT NULL,
    fecha DATETIME NOT NULL,
    ronda VARCHAR(6),
        estado VARCHAR(6),
    home VARCHAR(25) NOT NULL,
    away VARCHAR(25) NOT NULL,
    ht VARCHAR(5),
    ft VARCHAR(5),
    PRIMARY KEY(id)
);
 

Los datos que van en ella son de este estilo:

Código:

1 | 684585 | 23 | 2009-08-29 20:00 | 1 | FT | Real Madrid | 3-2 | 2-1 | Deportivo La Coruna |
2 | 684589 | 23 | 2009-08-29 22:00 | 1 | FT | Zaragoza | 1-0 | 0-0 | Tenerife |
3 | 684593 | 23 | 2009-08-30 17:00 | 1 | FT | Racing Santander | 1-4 | 1-3 | Getafe |
4 | 684586 | 23 | 2009-08-30 17:00 | 1 | FT | Athletic Bilbao | 1-0 | 0-0 | Espanyol |

En detalle...

id | idsoccer | competicion | fecha | ronda | estado | home | ft | ht | away

ID > lo pongo yo auto_incremental para que no haya repetidos
IDSOCCER > es el ID que asigna la pagina externa (que parseo) al partido
COMPETICION > si es primera división, segunda, copa, etc... pero lo guardo como un valor entero puede ir de 1 a 99.999 x ej.
FECHA > la fecha del partido
RONDA > sería la jornada en liga, o 1/8, 1/4 1/2, final.. en caso de eliminatorias
ESTADO > si ha acabado FT, HT media parte, PLAY jugando...
HOME > equipo que juega en casa
FT > resultado al final del encuentro
HT > resultado a la media parte
AWAY > equipo que juega fuera de casa

Los resultados serán como mucho de 11-11 de (5 caracteres) siendo lo normal 3

Agradezco vuestros comentarios y sugerencias

[ikaroraul]

Esta buena... tomaste bien la longitud de campos... ahroa solo no te olvids de validar tb ese dato en el formulario de registro... muy bueno... pocos hacen ese trabajo usualmenten le mente varchar(255).

Felicitaciones

[neodani]

Iniciado por ikaroraul

Esta buena... tomaste bien la longitud de campos... ahroa solo no te olvids de validar tb ese dato en el formulario de registro... muy bueno... pocos hacen ese trabajo usualmenten le mente varchar(255).

Felicitaciones

Gracias,

De todas formas no me queda muy claro el número que va dentro del int(1) a que hace referencia...

SMALLINT, para números enteros, con rango desde -32768 a 32767. Si se configura como unsigned, 0 a 65535.

MEDIUMINT para números enteros; el rango de valores va desde -8.388608 a 8388607. Si se configura como unsigned, 0 a 16777215

Entiendo que si configuro un SMALLINT unsigned puedo llegar hasta los 65535 valores, correcto? entonces para que se pone el numero entre parasentesis en los int()?¿?

Segun la doc oficial de mysql

Another extension is supported by MySQL for optionally specifying the display width of integer data types in parentheses following the base keyword for the type (for example, INT(4)). This optional display width may be used by applications to display integer values having a width less than the width specified for the column by left-padding them with spaces. (That is, this width is present in the metadata returned with result sets. Whether it is used or not is up to the application.)

¿Lo llena de ceros delante? yo pensaba que los ceros se ponian con zerofill...

Muchas gracias de antemano!

[ikaroraul]

mmmm pues la verdad tenia la idea de que int (valor) valor te limitada a la cantidad de digitos... pero probando pues = me deja poner mas digitos que 1, pues la verdad ya me entro la duda... :S

[gnzsoloyo]

El valor entre paréntesis de un INT no es la cantidad de dígitos, sino el ancho de representación que usa, por ejemplo, ZEROFILLED.
Sólo en los DOUBLE, FLOAT y DECIMAL, en el caso de MySQL, se usan para definir la cantidad de dígitos.
El rango de representación de un entero está dado por el tipo de dato y su rango.

[neodani]

Iniciado por gnzsoloyo

El valor entre paréntesis de un INT no es la cantidad de dígitos, sino el ancho de representación que usa, por ejemplo, ZEROFILLED.
Sólo en los DOUBLE, FLOAT y DECIMAL, en el caso de MySQL, se usan para definir la cantidad de dígitos.
El rango de representación de un entero está dado por el tipo de dato y su rango.

Pero entonces en los INT no sirve de nada poner un número entre parentesis a no ser que sino le añades el ZEROFILLED (para que te rellene 0 delante) estoy en lo cierto?

Muchas gracias!

[gnzsoloyo]

No. Para que te quede claro, sería mejor que leyeras el manual de referencia: Tipos de columna
Específicamente:

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 ejemplo, para una columna declarada como INT(5) ZEROFILL, un valor de 4 se muestra como 00004. Tenga en cuenta que si almacena valores mayores que el ancho de muestra en una columna entera, puede tener problemas cuando MySQL genera tablas temporales para algunos joins complicados, ya que en estos casos MySQL cree que los datos encajan en el ancho original de la columna.

Usa el manual. El 90% de las veces las respuestas esenciales están allí.

[neodani]

Iniciado por gnzsoloyo

No. Para que te quede claro, sería mejor que leyeras el manual de referencia: Tipos de columna
Específicamente:
Usa el manual. El 90% de las veces las respuestas esenciales están allí.

Gracias gnzsoloyo, te agradecería si puedes confirmarme esto, por favor:

Si no vas a usar los valores almacenados de la forma 0001, 0002, etc... es mejor no usar paréntesis cuando defines los enteros.

Ya que la frase
"no el número de dígitos que se muestran para valores con ancho que exceda el especificado para la columna." no me es clara del todo.

Muchas gracias

[gnzsoloyo]

En todo lo que signifique representación de datos, deja de lado lo que implique almacenamiento y déjaselo a la aplicación.
Lo que dice el manual hace referencia al uso de consultas en SQL, y no a lo que luego uses en la aplicación, y el caso al que te refieres es un buen ejemplo.
Si usas ese tipo de definición de campos, con los paréntesis, y usas la consola de MySQL, obtendrás esos "0001", "0002", etc.; pero cuando uses una interfase, esos mismos datos llegarán a la aplicación como 1, 2, etc. a pesar de ponerle el ZEROFILL, porque cuando las tablas pasan a la aplicación sufren una conversión de tipos a Integer, Int32, Int, Decimal, Double, o lo que sea que se use en ese lenguaje. Esto hará que los ceros a la izquierda de la coma desaparezcan (¿Recuerdas el concepto de "cero a la izquierda"?), a menos que los datos numéricos sean convertidos en cadenas...
En cualquier caso, es absolutamente innecesario ponerle el ZEROFILL a mi juicio, porque si lo que quieres es rellenar la representación, bien puedes usar funciones como LPAD() o RPAD(), que hacen exactamente esa tarea, pero en el SELECT (y los lenguajes de programación cuentan con funciones similares).

Resumiendo: Si quieres ponerle esa condición, pónsela, pero no afectará el resultado a menos que uses cierto tipo de interfases, y serán ignorados a la hora de usarlos en las aplicaciones .Net, PHP, Java, Jscript o cualquier otra, porque esos casos usan tipos propios de dato.
El uso de ese formato, al decir de Seven of Nine: "Es irrelevante"...

¿Se comprende?

[neodani]

Iniciado por gnzsoloyo

En todo lo que signifique representación de datos, deja de lado lo que implique almacenamiento y déjaselo a la aplicación.
Lo que dice el manual hace referencia al uso de consultas en SQL, y no a lo que luego uses en la aplicación, y el caso al que te refieres es un buen ejemplo.
Si usas ese tipo de definición de campos, con los paréntesis, y usas la consola de MySQL, obtendrás esos "0001", "0002", etc.; pero cuando uses una interfase, esos mismos datos llegarán a la aplicación como 1, 2, etc. a pesar de ponerle el ZEROFILL, porque cuando las tablas pasan a la aplicación sufren una conversión de tipos a Integer, Int32, Int, Decimal, Double, o lo que sea que se use en ese lenguaje. Esto hará que los ceros a la izquierda de la coma desaparezcan (¿Recuerdas el concepto de "cero a la izquierda"?), a menos que los datos numéricos sean convertidos en cadenas...
En cualquier caso, es absolutamente innecesario ponerle el ZEROFILL a mi juicio, porque si lo que quieres es rellenar la representación, bien puedes usar funciones como LPAD() o RPAD(), que hacen exactamente esa tarea, pero en el SELECT (y los lenguajes de programación cuentan con funciones similares).

Resumiendo: Si quieres ponerle esa condición, pónsela, pero no afectará el resultado a menos que uses cierto tipo de interfases, y serán ignorados a la hora de usarlos en las aplicaciones .Net, PHP, Java, Jscript o cualquier otra, porque esos casos usan tipos propios de dato.
El uso de ese formato, al decir de Seven of Nine: "Es irrelevante"...

¿Se comprende?

Comprendido, mil gracias gnzsoloyo