Re: normalizacion

Apena estoy revisando mis correos y este como dicen esta interesante.

Yo en hice algo malo al no aplicar la normalización pero, digo PERO es
un sistema con vb6 y access (Hace ya unos ~ 10 años). Que por lo mal
hecha me dio problemas después cuando me pedían que les agregara
cosas. Ya después me canse de inventar tanta cosa en el programa, que
mejor modifique la base de datos ya con los conocimientos y
experiencia de los años. Al estar modificando se me hizo mas fácil que
el importe (la suma del importe de factura-productos), porcentaje del
impuesto, impuesto en cantidad, porcentaje de descuento, descuento en
cantidad, subtotal y total este en la factura. En lugar de tener una
consulta que me sume estos datos. En el equipo que se tenia era una
perdida de tiempo por todo lo que tardaba.
quedabo algo así.

importe, % desc, $ desc, subtotal, % impu, $ impu, total
1000, 5, 50, 1050, 15, 157.5, 1157.5

Esto servia para 1) cuando queria ver los datos de generales de una
factura, 2) al hacer los diferentes reportes.
En ambos casos despues de hacer el cambio se disminuyo drasticamente
el tiempo requerido de los reportes. En estos casos donde el espacio
no es un factor como la velocidad si lo veo bien y hasta necesario
hacer estos cambios.

El día 28 de julio de 2008 5:51, Calabaza <calalinux(at)gmail(dot)com> escribió:
> Este e-mail me vino al privado, lo reenvio:
>
> El día 28 de julio de 2008 3:22, David Prieto <davidp(at)sgth(dot)es> escribió:
>>
>>> quisiera saber su opinión sobre el asunto q hacen muchos programadores
>>> (los cuales tambien diseñan las base d datos) y es q
>> por favor, escribe completo las palabras que no estamos utilizando un
>> móvil... =)
>>
>>> en la tabla factura
>>> guardan tanto el codigo de cliente, como el nombre y apellidos del
>> cliente.
>>> Cómo todos ustedes saben eso rompen con las reglas d normalización.
>>
>>> Q opinan uds. sobre ese asunto, a q se deberá esto??
>>
>> Opino que en muchos muchos casos esto es necesario.
>>
>> Ya se ha comentado que la factura no debe modificar su contenido una vez
>> emitida, y que si el día de mañana tu cliente número 1234 cambia de
>> domicilio, cuando reimprimas la factura debe salir igual que la primera vez.
>>
>> También habrá casos (el típico "cliente 99999", de "clientes varios"), que
>> no hace falta tenerlo en la base de datos como cliente, pero que sí que
>> tienes que guardar sus datos en cada factura.
>>
>>> MI opinión es que la persona que diseña una bd así no conoce las formas
>> normales,
>>> y si las conoce y no las utiliza se puede deber a que:
>>> o es un super dba que esta tratando de conseguir algo a cambio de
>>> redundancia pero la controla
>>> o conoce las formas normales pero no las entiende. =)
>>
>> MI opinión es que un buen diseño de una base de datos pasa por normalizar
>> primero y des-normalizar un poco después. He visto bases de datos
>> intratables por culpa de tanta normalización.
>
>> davidp.
>
> Sin comentarios, porque ya se ha hablado mucho de esto en este hilo.
> Un abrazo,
> --
> §~^Calabaza^~§ from Villa Elisa, Paraguay
> ----------------
> A hendu hína: Billy Idol - Rebell Yell
> http://foxytunes.com/artist/billy+idol/track/rebell+yell
> --
> TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
>

--
________________________________________
Lo bueno de vivir un dia mas
es saber que nos queda un dia menos de vida