Ver Mensaje Individual
  #2 (permalink)  
Antiguo 26/02/2015, 08:32
Avatar de gnzsoloyo
gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 5 meses
Puntos: 2658
Respuesta: Campos correctos para tabla en MySQL

De neuvo:
1) El valor numerico que se pone entre paréntesis de los INT, MEDIUMINT, BIGINT, no representa la cantidad de dígitos del numero, ni restringe los valores a ingresar. Se usa para otras cosas y puede traer problemas al momento de crear vistas y backups. No ingreses valores alli que no sean los por default.

luego:

2) Una foto dificilmente tenga sólo 48 caracteres de longitud en el nombre. Es mejor manejar un valor más amplio, como 200, para evitar truncamientos indetectables.

3) Los numeros telefonicos, especialmente si puede tener más de uno, es conveniente quue sean puestos en otra tabla, de modo de no restringir ni su cantidad, ni su obligatoriedad.

4) Los numeros telefónicos se almacenan como caracteres (VARCHAR), por necesidades de sistema, entre otras cosas porque eso permite poner también digitos de larga dintancia (DDI, DDN), cuando el usuario los incorpora, y además permite poner simbolos suuales en la codificación (-, +).

5) Adicionalmente, los numeros tienen que tener un minimo de 14 caracteres de longitud, que es el maximo estandar del sistema telefonico mundial.

6) Paises con 32 caracteres o más, existen varios, así como ciudades (hay una llamada Taumatawhakatangihangakoauauotamateaturipukakapiki maungahoronukupokaiwhenuakitanatahu, en Nueva Zelanda). Es conveniente dejar al menos 200 caracteres para eso.

7) Las IP es conveniente no almacenarlas como caracteres, pero de hacerlo debes usar la longitud del IPv6, no del IPv4.

8) Si vas a usar un DNI declarado como UNIQUE, el ID numerico autoincremental es superfluo. No es obligatorio usar IDs numericos, sólo es usual y cómodo para los programadores, pero una PK no necesita ser ni numerica ni autoincremental para ser la adecuada.

9) El estado de "conectado" que pones en ese campo es irrelevante y no representa algo real. Un usuairo está conectado cuando tiene una sesión activa, sea en la aplicación o en la base. Para eso se usan tablas de login, en los que das de alta al usuairio cuando se conecta, y registras la hora de salida cuando se desloguea.

10) Tipo de usuario, no es buena idea manejarlo pcomo SET o ENUM. Eso obligaría a que cualquier agregado de tipo implique un ALTER TABLE... con todo lo que eso implique. Es conveneinte una tabla especifica para eeso, de donde se tome el dato como FK en la tabla usuarios.

Creo que por el momento alcanza.
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)