[Php-avanzado] Tablas tesis Leandro Schereik

[Leonardo Tadei - Pegasus Tech Supply]

Hola Leandro,

El vie, 19-03-2010 a las 02:12 +0000, Leandro Schereik escribió:
> Hola Leo vi tus comentarios aca van las tablas con algunas
> correcciones.
> 
> Para los usuarios tengo dos alternativas no se cual es la correcta:
> 1: Seria una tabla para compradores y otra para administradores: 
> 
>  tblcompradores
>  --------------
> 
> 
>  id               int(11)
>  nombre        varchar(100)
>  ape             varchar(100)
>  tel              varchar(50)
>  email           varchar(255)
>  usuario        varchar(20)
>  pass            varchar(20)
>  
>  tbladministradores
> 
>  id               int(11) 
>  usuario        varchar(20)
>  pass            varchar(20)
>  
> 
> 2: La otra solucion seria una tabla para compradores y otra para
> tipos de usuarios:
> 
> 
> tbltipuser
> ----------
> 
>  
> id integer
>  
> tipo varchar(50)
>  
>  
> Nota: esta tabla contendrá inicialmente los siguientes registros
> fijos:
>  
> id: 1 tipo: Administrador
>  
> id: 2 tipo: Usuario Normal
> 
> 
> 
> 
>  tblcompradores
>  --------------
> 
> 
>  id               int(11)
>  nombre        varchar(100)
>  ape             varchar(100)
>  tel              varchar(50)
>  email           varchar(255)
>  id_tip_user      int(11)
>  usuario        varchar(20)
>  pass            varchar(20)
> 
> 
> Vos me diras cual es la mejor solucion? 


	Ambas son correctas desde la normalización, así que te garantizan que
todo funcione bien. Incluso hay otras opciones más complejas que no
valen la pena discutir.
	
	Ambas opciones también tienen pros y cons: la 1ra ofrece mayor
versatilidad porque si te cambia la definición del Comprador, no hay
impacto en el funcionamiento de los Administradores; también es más
reusable porque podrás usar estos administradores en cualquier sistema
futuro. La contra es que tenés que vértelas con 2 tablas en vez de solo
con una.
	La 2da tiene como ventaja que tendrás un sistema más homogéneo y podrás
copiar y pegar más código para este proyecto. La contra es que toda
query para login tendrá un WHERE múltiple, y si te equivocás en la query
podés tener compromisos altos de seguridad.

	Como ambas soluciones son correctas, usá la que te haga sentir más
cómodo... o tirá una moneda!

> Esta tabla queda igual.
> 
> tblcategorias
>  ------------
>  
>  id           int(11)
>  nombre    varchar(30)
> 
> 
> 
> 
>  Con respecto a los articulos agrego una tabla para los estados de los
> articulos.
> 
>  tblarticulos
>  ----------
>  
>  id                      int(11)
>  id_categoria        int(11)
>  id_estado           varchar(1)
>  nombre              varchar(100 )
>  precio                float
>  stock                 int(11)
>  imagen1             varchar(255)
>  imagen2             varchar(255)
>  imagen3             varchar(255)
> 
> 
>  tblestart
>  ---------
> 
>  id                  varchar(15)
>  estado            varchar(15)
> 
> 
> Nota: esta tabla contendrá inicialmente los siguientes registros
> fijos:
>  
> id: 1 estado: activo
> id: 2 descri: inactivo

	Ok. Esto además te permite agregar nuevos estados en el futuro, sin
tener que preocuparte por manejar la visualización de los datos.

> Con respecto a la ventas entiendo lo que me decis me acuerdo de esa
> clase con una tabla de
> "cabecera" y otra de "detalles" de la factura pero no tengo el ejemplo
> como para mirarlo. 
> ¿Me podras mandar ese ejemplo o alguno similar para agarrar la idea? 

	Las tablas varían según los datos del comprobante que estés guardando,
pero la estructura es una relación 1-a-muchos entre la cabecera y los
detalles:

Facturas:
---------
id	int(16)		auto_increment	// Key
id_cli	int(16)		// El cliente
nom_cli	varchar(100)	// El nombre del cliente al momento de la venta
tipo	int(4)		// tipo fisca: A, B, C, etc, relacionadas a otra tabla.
num1	int(4)		// nro fiscal de la sucursal
num2	int(8)		// nro fiscal de la factura
fec	timestamp	// fecha y hora de emisión
estado	char(1)		// puede cambiar de vacío a anulada.

Detalles de la factura:
-----------------------
id	int(16)		// el ID de la Factura. Relación 1-a-N
id_art	int(16)		// id artículo al momento de la venta
cod	varchar(20)	// cod artículo al momento de la venta
des	varchar(60)	// des artículo al momento de la venta
can	float(10,3)	// cantidad del artículo (según el sistema puede ser
entero o decimal)
pre	float(8,2)	// precio unitario al momento de la venta
tiva	float(6,2)	// valor del IVA al momento de la venta


	Dependiendo de las necesidades del sistema pueden ser con más o menos
campos. Un sistema informal no necesita datos fiscales; un sistema que
venda en cta cte necesitará "Forma de Pago" en la cabecera, etc.

> Muchas Gracias

	Por nada!
-- 

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