[Php-avanzado] tablas

[Leonardo Tadei - Pegasus Tech Supply]

Hola Lucas,

	Te lo comento intercalado:

El vie, 28-11-2008 a las 20:53 -0200, unes pacio escribió:
> #usuarios
> 
> ID_usuario (int, no nulo, autoincrement, primaria, unica)
> usuario (tinytext, no nulo, unico)
> pass (tinytext, no nulo)
> fecha_de_suscripcion (datetime, no nulo)
> puntos (int)

	Toda clave primaria es única.
	Tinytext no es el tipo de campo MySQL correcto para hacer esto. Usá
CHAR o VARCHAR
	La fecha, si se asigna automáticamente al dar de alta un usuario debe
ser timestamp en vez de datetime.


> #email (los usuarios pueden tener un email, no tener email o tener
> muchos)
> 
> email (tinytext, no nulo, unico)
> ID_usuario (int, no nulo)

	Te conviene poner los ID primero, porque un segundo campo no puede ser
clave de una tabla, y te conviene que este ID lo sea, para agilizar las
relaciones.

> #nombre (los usuarios pueden tener un nombre, no tener nombre o tener
> muchos)
> 
> nombre (tinytext, no nulo, unico)
> ID_usuario (int, no nulo)
> 
> 
> #apellido (los usuarios pueden tener un apellido, no tener apellido o
> tener muchos)
> 
> apellido (tinytext, no nulo, unico)
> ID_usuario (int, no nulo)

	Estas tablas de Nombres y Apellidos no tienen sentido.
	Si quisieras discriminar un primer apellido de un segundo apellido
(cosa que en gral los sistemas no requieren) a estas tablas les falta la
semántica necesaria.
	En general no querés ni buscar ni mostrar personas ordenadas por su
segundo nombre....
	Creo que con poner nombre y apellido como campos en "Usuarios" es
suficiente... salvo alguna justificación tuya en otro sentido.

	Otra vez, los campos tinetext no son apropiados para estos campos.

> #archivo (los usuarios pueden tener un archivo, no tener archivos o
> tener muchos)
> 
> ID_archivo (int, no nulo, autoincrement, primaria, unica)
> archivo (varbinary, no nulo)
> ID_usuario (int, no nulo, unica)

	Si vas a guardar los archivos en la DB, en luar de hacerlo en el
sistema de archivos, a esta tabla le falta el tipo y el nombre. Si no al
guardarlo perdés información.
	Tenés un ejemplo de como manejar esto en el final del apunto de PHP
Inicial. El ejemplo es con imágenes, pero sirve para cualquier tipo de
archivo.

> #permiso_r (son los usuarios que tienen permiso de lectura de este
> archivo, aparte del dueño)
> 
> ID_archivo (int, no nulo)       (ambos campos son primarios)
> ID_usuario (int, no nulo)
> 
> 
> #permiso_w (son los usuarios que tienen permiso de escritura de este
> archivo, aparte del dueño)
> 
> ID_archivo (int, no nulo)       (ambos campos son primarios)
> ID_usuario (int, no nulo)

	Te falta alguna manera de modelar los directorios (o "partes" en tu
mail original)... un sistema que pone todos los archivos juntos no es
muy usable.
	
	Por otra parte, tu estructura de permisos no permite definir los
archivos "publicos"

	Para finalizar, no veo como guardarás el esquema de acceso a los grupos
que sale de "...y debe disponer de una parte privada, otra/s visible/s a
grupo/s específico/s y otra publica (visible desde la web)"

> Espero no haberle errado mucho con la normalizacion. Saludos

	No está mal para un primer planteo.
	Sin embargo faltan cosas, como el manejo de los grupos, pero el
principal problema creo que es el sobrediseño, o sobrenormalización en
este caso, de datos atómicos como nombre y apellido.

	Seguimos!
-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key