Es adecuada esta estructura?

[eybel]

Queria saber si esta estructura esta bien elegida o si hay algun data type que no es adecuado... no se con respecto a los telefonos, si debo usar decimal o int?

Para encriptar el passsword uso SHA1 con PHP...

Código PHP:

  Table users
===========
user_id, firstname, lastname, birthdate, email, password, picurl, sex, phone, address, city, state, zipcode, activated, token
-----------
user_id          int(11) PK
firstname        varchar(100)
lastname         varchar(100)
birthdate        date
email            varchar(255)
password         char(64)
picurl           varchar(100)
sex              char(1)
phone            decimal(15,0)
address          varchar(255)
city             varchar(255)
state            char(2)
zipcode          decimal(5,0)
activated        tinyint(1)
token            char(23) 
   

[Nano_]

Saludos

Estas podrian ser unas posibles sugerencias

Código MySQL:

user_id          int(11) PK #Es el numero de documento?
firstname        varchar(100) #OK
lastname         varchar(100) #OK
birthdate        date #OK
email            varchar(255) #Un correo de 255 caracteres?
password         char(64) #Vas a manejar md5 o que tipo de hash?
picurl           varchar(100) #no se que signifique
sex              char(1) #OK
phone            decimal(15,0) # Podrias manejarlo como varchar ya que si es un telefono fijo o celular no tienen la misma longitud o podrias crear otro campo para el movil
address          varchar(255) # Muy largo
city             varchar(255) # Podrias tener otra tabla aparte donde manejes las ciudades y aca tener el identificador de la ciudad
state            char(2) 
zipcode          decimal(5,0) 
activated        tinyint(1)
token            char(23)
 

Es bueno que a medida que vallas construyendo tus tablas indiques una descripción de cada campo para poderlos identificar mas fácil (Diccionario de Datos) en el caso que el nombre no sea claro

[eybel]

Gracias!! voy a usar SHA1 para encriptar el password. picurl es picture URL ahi voy a guardar los links de fotos de perfil. Lo de las ciudades es buena idea gracias. No te entendi lo de diccionarios de datos, osea puedo poner en SQL comentarios o descripciones?

Por otro lado, queria preguntar si usar mysqli_insert_id() es buena idea cuando uno crea un sistema de registro de usuarios. Que pasa si hay muchos usuarios registrandose al mismo tiempo, mysqli_insert_id() devuelve el ultimo no? no se confundiria si hubo otro usuario que tmb se registro justo a tiempo?

[gnzsoloyo]

Pues en mi opinión haría estas observaciones:

user_id INT(11) PK
Autoincrementales terminan siendo malas ideas.

password CHAR(64)
Depende de los requirimietos de la encriptación.

picurl VARCHAR(100)
100 bytes pueden ser insuficientes.

sex CHAR(1)
Yo lo manejaría como TINYINT(1) y no como CHAR. No necesitas guardar una letra, sólo codificar lo que representa.

phone DECIMAL(15,0)
Se deben manejar como CHAR o VARCHAR, sin lo cual no puedes poner ceros a la izquierda ni símbolos en caso de querer hacerlo.

city VARCHAR(255)
Las ciudades conviene tenerlas en una tabla donde las relaciones por ID. Evitas problemas de consistencia.

state CHAR(2)
2 bytes sólo resulta funcional para EE.UU. No todos los países codifican con sólo dos letras.

zipcode DECIMAL(5,0)
No es funcional. Hay países que usan sistemas alfanuméricos.

token CHAR(23)
Depende del sistema usado.

[eybel]

gnzsoloyo, porque decis que autoincrementales terminan siendo mala idea? eso es lo unico que leo en los libros cuando te explican como hacer un sistema de usuarios... porque lo decis?

gracias por el review. lo voy a tener en cuenta.

[gnzsoloyo]

Es algo que he explicado en diversos posts, y tiene que ver con los el modelo E-R, y requiere una explicación algo extensa. Veremos si puedo ponerlo claramente:

En ninguna parte del los fundamentos del modelo Entidad-Relación, el fundamento delas bases de datos relacionales, se dice que una PK debe ser numérica y autoincremental. Lo que se dice es que una clave primaria debe surgir del análisis de la entidad representada en ese sistema, y debe ser usado como PK aquel atributo o conjunto de atributos que permita identificar unívocamente un único registro en una tabla.
Pero cuando habla de atributos, se está hablando de datos que son propios de la entidad. En el caso de una persona, serían su nombre, apellido, documento, edad, sexo, fecha de nacimiento y otros; en una factura, el numero de la misma, la sucursal de emisión, la fecha, la dirección y el resto de los datos. En definitiva, cada entidad que se representa tiene un conjunto de atributos, alguno o algunos de los cuales pueden servir para identificarlo.
Muchas veces, el identificador es evidente, como el numero de documento; en otros casos es menos evidente, como el numero de factura, el cual se repite en diferentes terminales de emisión en un mismo supermercado, o en las diferentes sucursales de una empresa. En esos casos debe apoyarse en algun dato adicional: el numero de caja, o el de sucursal.
Pero la mayoría de los programadores no piensa en términos de analisis de sistemas orientados a las bases de datos, por lo cual recurren a un sistema simple y fácil para ellos: Numerar los registros secuencialmente. Eso no es que viole el modelo E-R, pero omite varios pasos en el desarrollo de las bases de datos, y termina generando problemas a largo plazo. Lo hacen así porque es fácil de hacer, sin medir las consecuencias.
Es cierto que es mucho más fácil armar un ID numérico incremental, pero ese atributo es un agregado, no es parte de la entidad, con lo cual para poder mantener la consistencia y cardinalidad de los registros se requiere que haya validaciones extra, verificaciones y generación de índices adicionales, todos los cuales se pagan con performance.
Para que quede claro: Como no es un valor propio de la entidad, tu puedes terminar ingresando mil veces los datos de la misma persona en la misma tabla, simplemente porque cada vez que lo ingreses su ID será distinto. Para evitar duplicaciones de datos tienes que recurrir a verificar, por ejemplo, su numero de documento de identidad (y nacionalidad en ocasiones) a fin de no duplicarlo. Pero en ese caso, ¿por qué no usas directamente el documento como PK?
Precisamente allí surge la cosa: Cuando tienes una base distribuida, uno de los principales problemas es que el mismo dato, para idéntica tabla, puede terminar ingresando en diferentes bases con diferentes PK, porque cada conjunto de Ids depende de la base a donde se inserte, y no del objeto en si. Y luego, cuando quieres integrar los datos de dos bases.... simplemente se arma el caos.
Entre los fundamentos que se te explican en la universidad, cuando cursas base de datos, se dice que una PK debe identificar el objeto, en todo el universo de objetos de la misma clase. Esto significa que ese mismo registro yo debo poder portarlo de base en base, y de tabla en tabla sin necesidad de ningún dato adicional a si mismo para ser identificable.
Obviamente eso, con un ID numérico y autoincremental es imposible.
A esto puedes agregarle que un ID autoincremental depende de la definición de la tabla, de su base y del servidor, y que si realizas determinados borrados, el valor puede reiniciarse, lo que trae problemas para mantener la consistencia histórica de los datos. Como además depende de la definición de la tabla, es susceptible a errores de creación de la tabla en diferentes locaciones, ya que el rango representable de claves depende del tipo de dato usado, y no de su atributo de auto_increment.

Como nota: En el estudio de las bases de datos se explica puntualmente que los ID numéricos, incrementales o no, sólo se deben usar si llegados a la 3FN en su normalización, no se ha encontrado un determinante que pueda ser CC.

En definitiva, los problemas que puede traer el uso de un ID numérico autoincremental pueden ser:
- No permite consolidar datos entre diferentes bases, por solapamiento de numeraciones.Esto trae problemas para definir datamarts o datawarehouses.
- No conserva la secuencialidad de las claves si se reinicia la tabla.
- No permite correctas restauraciones de datos a partir de backups.
- No es un identificador confiable para los objetos, ya que sólo define la unicidad del registro y no de su contenido.
- Obliga a generar validaciones extra en los datos.
- No guarda relación con los ordenamientos necesarios para las consultas.
- La eliminación de registros deja "huecos" de numeración que no deben ser usados (esto resulta frustrante a los programadores).
- Obliga a usar índices adicionales para lograr consultas optimizadas (las PK es lo primero en ser leído, y si no contiene datos relevantes termina siendo data inútil).

Cuando adquieres experiencia en el uso de PK no autonuméricas, empiezas a entender que las ventajas que proveen superan por mucho las exigencias de implementarlas.

Ahora bien, si tienen esos problemas, ¿por qué se usan y en los manuales aparecen este tipo de PK?
Bueno, la respuesta es simple:
1) Son fáciles de entender.
2) Son sencillos de crear.
3) Son simples de usar.
4) Los programadores de aplicaciones los comprenden sin problemas.
5) Parecen "naturales" a los usuarios sin estudios formales.
6) Todos los lenguajes de programación tienen funciones para aprovecharlas.

Personalmente, y por experiencia, las considero una pésima opción porque tarde o temprano te encontrarás con problemas originados por ellas. Si no es así, entonces tuviste suerte o tu sistema no creció lo suficiente.