[Php-avanzado] Normalización 3

[Leonardo Tadei - Pegasus Tech Supply]

Hola Daniel,

El sáb, 12-10-2013 a las 18:40 -0300, Daniel Billia escribió:
> 03)es que como te decía en el requerimiento funcional que uno seleccionaba
> la provincia sola o la ciudad , por eso lo deje con dos campos
> si opinas que el cliente con cargar la ciudad 
> tome automáticamente la provincia lo modifico así.

	Estás confundiendo la implementación de la pantalla con el
almacenamiento. Son cosas independientes y técnicamente hablando, tienen
poco que ver.
	Te pregunté explícitamente si un cliente podía tener solo provincia y
no tener localidad, y tu respuesta fue que no.
	En la pantalla para dar de alta o modificar un cliente, seguramente se
elegirá la provincia, luego aparecerán las localidades de esa provincia
y luego se elegirá la localidad.
	Pero esto no significa que en la tabla de clientes tengan que estar los
dos campos!!! La normalización dice que tiene que estar solo la
localidad, porque por una relación se halla la provincia. Poner los dos
campos ahí sería una repetición.

	Es resumen, el funcionamiento de la pantalla que usará una persona para
dar de alta un cliente es como vos decís, pero en la tabla la referencia
a la provincia no iría.

> 05)en la tabla rubros el largo del nombre es 30
> me pareció un longitud razonable si pensas que es mejor
> aumentarle el tamaño ??

	No manejo el nombre de los rubros de este problema, pero teniendo en
cuenta que si guardás codificada en HTML una vocal con acento ocupa ella
sola 7 caracteres, el tamaño puede ser poco.
	Además, el espacio en disco es muy barato ;-)

> 06)Pienso que es suficiente ya que se adjunta modelo y marca

	Ok.

> 07)en el histórico guardo también el apellido solo que puse
>     como etiqueta del archivo nombre

	La priemra forma normal dice que no tenés que guardar dos datos en un
solo campo. Divilo en nombre y apellido por separado.

> Si las tablas accesos y registros son muy 
> parecidas la tablas registros la utilizo solo
> para controlar lo que el cliente hace con su 
> registración y el estado de la registración o cuando
> hay  una solicitud de login y password cuando se olvido.
> El acceso es el histórico cuando ingresa a la web 
> para realizar alguna consulta como referencia cuantas veces ingreso.

	Ahora entiendo!
	Dejalo así que está bien.

> 08)el estado lo guardo numérico si es -1 no esta 
> habilitado 1 esta ingresado al sistema y 
> habilitado mas de 1 es que pidio su login y contraseña,
> la especificación esta como RNF 1

	Los datos posibles del "estado" no están en el diccionario... además de
que, como ya charlamos, estos es un RF (pero no vale la pena seguir
perdiendo tiempo con la SRS por la separación de RF de los RNF)

	No es una correcta Normalización que un valor -1, 1, etc tenga un
sentido específico que solo sabe el que hizo el software. Tenés que
crear una funcionalidad para "mostrar los estados de registro", porque
si son fijos no vale la pena gestionarlos, modificar el requerimiento
para que quede "El sistema debe registrar acceso del los clientes con su
estado de registro".
	Luego en la tabla Registros el estado es como ahora, un entero, pero
pasa a ser una referencia al valor que habrá en la tabla
EstadosRegistro.

> 09)si la lista de consulta se carga un articulo 
> para cada línea se puede confrontar si el 
> articulo existe en la lista y lo agrega no lo 
> coloque es opción cada vez que carga un articulo genera una nueva linea.
> El estado es numérico si es -1 esta pendiente al 
> ingreso del proveedor cunado el proveedor carga 
> la lista de productos el estado toma el numero de 
> pedido realizado como un grupo y el campo de 
> pedido esta para el proveedor si esta pendiente se identifica en ese campo.

	Y todo esto de dónde sale, Daniel?
	No hay ni asomo en la SRS de que la consulta/pedido tenga este
funcionamiento.
	Yo te sugiero, dado que estamos ya a mediados de Octubre y que tu
cursada se vence, que no incluyas esta funcionalidad en la versión que
me vas a entregar. Yo no tengo problema en que una vez que egreses,
sigas consultando o yendo a la facultad para hacer la versión 2 de este
software.
	Si querés hacer esto de la consulta/pedido ahora, tenenos que volver
sobre la SRS, definir este funcionamiento que describís, especificar que
se muestren los "estados de pedidos", normalizar el pedido como tal (con
una cabecera y un detalle, no esto de repetir datos por cada item) y ver
si todavía no nos encontramos con alguna funcionalidad oculta.
	Fijate que me explicás esto en términos de Proveedores y de la
existencia de un Artíuclo, cuando este sistema no especifica que
siquiera existan Proveedores ni Stock !!!


> 10)el campo imágenes esta equivocado no me di 
> cuenta cunando lo cree no asigne los campos el     name text 40,type text 20

	Ok.

> 11)el campo detalle como no fijo una largo del detalle lo asigne como blob.

	Ok.

> Un buen fin de semana

	Igualmente!


PD: me quedé un poco preocupado por el tema de los pedidos...

-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
Web: http://leonardo.tadei.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key