[Php-avanzado] SRS versión final???

Maximiliano Lizondo lizondomaximiliano en gmail.com
Lun Feb 3 22:00:54 ART 2014 

Oka, me pongo con las modificaciones. jaja si, de hecho el asunto no es
descriptivo de nada...era un día sin ideas. Saludos!


El 3 de febrero de 2014, 20:17, Leonardo Tadei - Pegasus Tech Supply <
leonardot en pegasusnet.com.ar> escribió:

> Hola Maximiliano,
>
>         te respondo intercalado:
>
> El lun, 03-02-2014 a las 18:51 -0200, Maximiliano Lizondo escribió:
> > Leo, estoy normalizando y hasta ahora tengo esta primera versión:
> >
> >
> > DICCIONARIO:
> > ------------
> >
> >
> > Países: nombre de país
> > Provincias: nombre de provincia, país
> > Localidades: nombre de localidad, país, provincia, código postal
> > Proveedores: razón Social, país, provincia, localidad, dirección,
> > email, página web, teléfono
> > (Se considera proveedores a sellos discográficos y comerciantes, que
> > son gestionados por el sistema UNICAMENTE a través de un usuario
> > administrador)
> > Tipo de documento: país, DNI/CI/LE/LC
> > Tipo de envío: país, provincia, localidad, correo argentino/correo
> > privado/encomienda por ómnibus, precio de envío
> > Clientes: nombre de cliente, tipo de cliente, tipo de documento,
> > número de documento, país, provincia, localidad, dirección, email.
> > (Se considera cliente a cualquier individuo que accede al sistema para
> > registrarse en el mismo)
> > Tipo de cliente: particular/revendedor
> > Tipos de moneda: nombre de moneda, país
> > Productos: nombre de producto, código de identificación, proveedor,
> > formato de producto
> > Lista de precios de productos: productos, tipos de moneda, precio de
> > producto, clientes
> > Formatos de productos: nombre de formato, CD/TAPE/VINYL
> > Estado de pedido:
> >   *en proceso (pedido siendo procesado por el sistema)
> >   *cancelado (pedido "en proceso" que es luego cancelado por el
> > sistema)
> >   *verificado (pedido "en proceso" que es luego verificado por el
> > sistema)
> >   *entregado (pedido "verificado" que es luego entregado en el
> > domicilio del cliente)
> > Pedidos:  cliente, productos, tipo de envío, precio total del pedido,
> > estado de pedido, fecha de estado
> >
> >
> >
> >
> > TABLAS:
> > -------
> >
> >
> > Localidades:
> > id_localidad
> > nombre_localidad
> > codigo postal
> > id_provincia
> >
> >
> > Paises:
> > id_pais
> > nombre_pais
> >
> >
> > Provincias:
> > id_provincia
> > nombre_provincia
> > id_pais
> >
> >
> > Clientes:
> >
> > id_cliente
> > nombre_cliente
> > tipo_cliente
> > tipo_documento
> > numero_documento
> > direccion
> > email
> > id_localidad
> > id_lista_precios
>
>         Te faltan las tablas para los Tipos de Documento y para los Tipos
> de
> Cliente.
>
> > Proveedores:
> >
> > id_proveedor
> > razón Social
> > dirección
> > email
> > página web
> > teléfono
> > id_localidad
> >
> >
> > Productos:
> >
> > id_producto
> > nombre_producto
> > formato de producto
> > código de identificación (comercial)
> > id_proveedor
>
>         falta la tabla de Formatos de Producto
>
> > Listas_de_precios: (no está completa porque tengo dudas con esto,
> > explico abajo)
> > id_lista_precios
> > ***productos, tipos de moneda, precio de producto, clientes
> >
> >
> > Pedidos:
> > id_pedido
> > productos
> > tipo de envío
> > precio total del pedido
> > id_cliente
>
>         Varias cosas. Por una parte, en Pedidos tenés que volver a poner
> los
> datos relevantes del Cliente, porque si ponés solo una referencia, al
> hacer ABM de un Cliente cambiás los Pedidos ya registrados, lo cual no
> debe pasar.
>         Por otra parte, tenés acá una relación 1-N con una tabla que podría
> llamarse PedidosItems que será la que tenga los datos de los Productos
> (equivalentes a los renglones de un pedido en papel, con las cantidades
> de cada Producto y los datos del mismo).
>         No me acuerdo si está en la SRS, pero suena razonable que el Pedido
> tenga una fecha.
>         También debe tener un Estado de Pedido!
>
> >
> > Estados_de_pedidos:
> > id_estado
> > nombre_estado
> > fecha_estado
> > id_pedido
>
>         No. Te hace falta tener una tabla con los Estados de Pedidos, pero
> el
> Estado de un Pedido en sí, será una referencia en Pedidos a esta tabla,
> ya que un Pedido no puede estar en más de un Estado a la vez.
>
> >
> > Bueno, la duda que tengo es respecto a las listas de precios. En mi
> > caso, las mismas se asignan por cliente. Podrían existir varias listas
> > y cada cliente podría tener asignadas varias de ellas (es una
> > funcionalidad que me recomendaste hacerla no tan restrictiva, como
> > sería asignar listas en base al "tipo de cliente").
>
>         Bueno, mi recomendación era que el sistema soporte varias listas, y
> poder asignarle a un Cliente cualquiera de las existentes, y no varias a
> la vez (que no se me ocurre para qué serviría en este caso).
>
> > El tema es cómo encajan las listas de precios en la estructura de las
> > tablas normalizadas. Yo había pensado que, como existe la posibilidad
> > que haya varias listas, armar una tabla "Listas_de_precios" con los
> > campos "id_lista", "descripcion" e "id_cliente". En ese caso, el
> > contenido del campo "descripción" sería la lista de precios en un
> > archivo .pdf o algo similar.
> > Por favor, decime si estoy muy errado o qué alternativa podría usar.
>
>         Estás más o menos. Por una parte, hace falta tener una tabla
> Listas_de_Precios, que tendrá un id y un nombre.
>         Luego hace falta ponerle los precios a los Productos. Esto se hará
> con
> una tabla con id, id_lista, id_producto, precio.
>         Posiblemente no sea exactamente así por el papel que juega la
> Moneda
> (de la que tampoco hay tabla).
>         Luego, si un Cliente puede tener solo una Lista de Precios a la
> vez,
> que es lo que especificaste, simplemente en la tabla Clientes tendrás
> una referencia a qué Lista de Precios es la de él... si en cambio un
> Cliente tiene muchas Listas de Precios, entonces te quedará una relación
> N-M, que necesitará una tabla aparte.
>
> >  Gracias!
>
>         Por nada!
>
>
> PD: qué asunto poco descriptivo!
>
>
> --
> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> Web: http://leonardo.tadei.com.ar
> Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
>
> _______________________________________________
> Lista de correo: Php-avanzado
> Mensajes a la lista: Php-avanzado en pato2.fi.mdp.edu.ar
> Administración Web:
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> Desubscripción:
> php-avanzado-request en pato2.fi.mdp.edu.ar?subject=unsubscribe
>



-- 
*Ing. Maximiliano Andrés Lizondo*

   - *Teléfonos: **0223-493-5488* (particular) - *2236-321708* (móvil)
   - *Perfil profesional en LinkedIn: *
   http://ar.linkedin.com/pub/maximiliano-andr%C3%A9s-lizondo/61/906/344
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20140203/5e6514c7/attachment-0001.html>

Más información sobre la lista de distribución Php-avanzado