mi jefe dice ke la normalizacion es mala

[Rocket]

Holas
llevo 3 dias en este trabajo, vine a hacerme cargo del analisis, implementacion de nuevos proyectos y cosas asi... y no me gusta nada como hacen las cosas aki.

primero trabajan con access, usan ajax con asp, eso me gusto. ahora kiere pasar todo el asp ke esta super mal hecho a dll para ke fucione mas rapido y pasar de access a mysql lo ke es bueno tambien pero cuando le dije le dije a mi jefe ke la bdd habia ke normalizarla ya ke tenia redudancia de datos, ninguna tabla relacionada y cosas asi me dijo ke no le gustaba eso por ke la base de datos se ponia lenta

le explike lo de los indices, innodb y todo eso pero no...

y no se, puede ser solo por gustos pero no me gustaria trabajar con un modelo de datos desordenados pero a lo mejor es verdad ke ade mas rapido ya ke se accede solo a una tabla, aunke no creo ke sea tanta la diferecia...

ya no se ke pensar... ke dicen??
tiene razon mi jefe o yo, y si tengo razon yo ke fundamentos le puedo dar a mi jefe para hacer un buen modelo de base de datos??

[PequeñoMauro]

Al respecto te cuento algo. Donde estoy trabajando, lo que vendria a ser Grados y Titulos (para bachiller, titulación, doctorado, maestria, etc, etc ah, y trabajo en una universidad), usaban un sistema para ver los datos de los que estudiaban. La persona que veia eso parece que era programador, el programa lo hizo en PHP, la cosa es que creo una tabla pues el sistema no era tan problemático. Pero paso el tiempo y hubo más requerimiento.
Esta persona lo que hacia era agregar más campos, y harta información redundante, a tal punto que la tabla llego a tener como 130 campos!!!!. El sistema se hizo super lento.
Pero no solo es eso, para interpretar todo eso es un rompecabezas.
Asi como para construir una casa se necesita un plano, para realizar un sistema a la cual se tendrá acceso a información de una BD, ésta debe también primero formularse mediante un modelo.
A mi parecer existe una diferencia abismal, y de hecho lo que inicien, irá incrementandose y teniendo más requerimientos, y ahi verán el problema...

[Carxl]

Hola!! Como van??

Esto que te está pasando es mas común de lo que crees, las personas que nunca han leido o no han estudiado nada de sistemas, tienden a ser caprichosas e insensatas.

Lo único que te queda por hacer es venderle la idea a tu jefe através de un costo beneficio. A lo que me refiero es que comiences a realizar una lista de los pro y los contra de las dos implementaciones, y seguramente encontrarás mas beneficios en un modelo normalizado.

el tiempo de respuesta a largo plazo, la facilidad de actualizacion, las fáciles modificaciones. Algo así tendrás que hacerlo pero con palabras y métodos como para niños que apenas comienzan a entender.

Espero que esto te ayude y sí, mil veces mejor un modelo normalizado.

PDT: creo que tu jefe le faltan algunas asesorias.

[FNX_NET]

mmmmmmmmmm, uta haveces las formas normales no son compatibles en la pega, por la velocidad de implemtentacion, los desalloradores siempre van pillados.
al normalizar la base de datos tu debera hacer casi debeuno el sistema.

pero al hacer esto, el sistema aguantara de mejor forma actualizaciones y nuevos requerimientos
va ahcer mas rapido, ya que no va a levarntar datos duplicado, lo que ahora espacio y tiempo en las consultas, asi que sera mas rapido.

cuando hay una base de datos mal echa, que ella es el piso donde se construye, puede hacer que la casa el sofware se caiga, y si se sigue construyendo sobre ese piso mal echo, se tendra que hacer cuantas veces denuevo hasta que hagan caso y arreglen el piso.

una tabla normaliada, permite que a cualquier cambio que se haga sera mas rapido y limpio, con ello ahorraran dinero y tiempo que el desarrollo de actulizaciones.

al tener una tabla normalizada encontrar y implementar una solucion es mas facil, ya que los software de dba no los dejaria trabajar tranquilo al tener rebundancia de datos.

[haron]

vete de esa empresa.... o tomatelo con filosofia.

de todas formas creo que no deberias quejarte tanto. no es bueno para la salud estar constantemente quejandose, aunque tengas razon.

tomatelo con filosofia: la empresa es una mierda, te pagan poco, no haces lo que te gusta, pero tampoco vas a estar toda la vida en esa empresa! esto es solo temporal.

ademas! que bien sientan los desayunos de bocadillo y jamón con los compañeros de trabajo! y que buena está la secretaria!

qué más da si la base de datos es Access o MySQL o yo que sé, si en el fondo esas cosas no existen. son bits almacenados en un puto ordenador que nuestra inteligencia esquizofrénica interpreta como una base de datos o un servidor web.

lo que verdaderamente existe e importa es: el jamón, un beso, una caricia, una chupadita... esas son las cosas que importan.

pd: quedate en la empresa solo hasta que encuentres otro curro.

[MACGREGOR]

JAJAJA.
Haron tiene mucha, pero mucha razón.

De todas formas te daré un consejo. Intenta hacerle entender a tu jefe que las Bases de Datos no son hojas excell con tantos campos como te hagan falta.

Que eliminar información redundante no solo es bueno, si no imprescindible.
Explicale que en caso de un error en los datos, al realizar una consulta no aparecerán todos los resultados que en realidad hay guardados.

Que todo en una sola tabla es más rápido?
Depende de la cantidad de información que contenga, y del campo por el que se esté buscando.
En el 99,9% de los casos siempre es más rápido un esquema normalizado.

Explicale que cuando buscas en 2 tablas (normalizadas) se busca utilizando un índice, segun la implementación del (SGBD) Sistema Gestor de Base de Datos comparas dos números que ocupan normalmente 2,4 ó 8 bytes.
Si comparas en una sola tabla 1 campo tipo texto con una cadena de carácteres....
Piensa que cada carácter ocupa un byte y los compara secuencialmente.
Eso puede llegar a ser eterno con mucha información.

También tienes otra opción (bueno no descartes lo de buscar otro trabajo )
explicarle que cada vez que se añada un campo nuevo en una tabla hay que retocar todos los programas (o informes de access) que consulten la DB.
Y lo que más le dolerá será que le digas que se tardará más tiempo (y por lo tanto dinero) en hacer cualquier programa basado en una DB mal construida.

Finalmente existe otra opción que suele ser la que mejor resulta con ese tipo de personajes que llegan a jefes sin saber ni como.
Última opción: MENTIR. El no tiene ni idea así que tragará con lo que tu le digas.
Esta opción en realidad no la recomiendo ya que seguramente cuando le digas que si lo haces como él quiere se sobrecalentará el condensador de fruzo... Él irá corriendo a explicarle a todo el mundo que ha descubierto una forma revolucionaria más rápida y mejor para solucionar el problema y sin recalentar el CONDENSADOR DE FRUZO!!!

PD: Por si alguien no lo sabe el condensador de fruzo es una frase sacada de la película REGRESO AL FUTURO. Algo absurdo en sí mismo.

Un saludo.

[Mithrandir]

La desnormalización la pagas con espacio en disco y con complejidad en mantenimiento y controles adicionales.

Házle ver que el dejar las cosas desnormalizadas hará que tengas que añadir tal cantidad de código de comprobación y de validación, que al final tendrá un programa igual de "lento" que el normalizado.

Por cierto... si tiene un programa que se hace lento al normalizarlo es que tiene un volumen de datos tal, que Access no lo soporta.

Mi abuelita sigue diciendo que desvelarse es malo