Barrapunto

Del artículo:

Estoy confundido .... O_o

No os perdáis sus bricoconsejos sobre optimización SQL: http://www.deambulando.com/2007/02/16/optimiza-tus -sentencias-sql/ [deambulando.com]

No existe ningún dilema, salvo en bases de datos grandes y circunstancias muy especiales en que probablemente ya hay alguien que sepa lo que hace.

Las bases de datos no normalizadas que nos encontramos no es porque se hayan sopesado factores en contra o a favor, sino porque se ha encargado hacer la base de datos al más imbécil de la empresa, cosa que por desgracia ocurre muy a menudo.

Plantear siquiera la pregunta como una lista de factores a favor y en contra me parece irresponsable.

Dado que has preguntado, entiendo que no debes de ser un experto, y probablemente no sepas nada sobre los grados de normalización y otras cosas que he leído.

Sinceramente te recomiendo que te leas algún manual, incluso aunque sea un resumen, o una guía rápida (la Wikipedia es genial para estas cosas) sobre normalización. Puede ser un rato un poco coñazo, pero este tipo de conocimientos te serán muy útiles en muchas situaciones. Hoy en día todo son bases de datos.

En cualquier caso, para que te hagas una idea, como en la vida real uno quiere poder pensar en las soluciones rápidamente, mira tus datos y hazte estas preguntas:

• ¿Hay campos nulos? Si los hay, es posible que esos campos puedan estar en otra tabla. Fíjate bien.
• ¿Hay datos que se repiten a lo largo de la tabla? Si hay datos que se repiten constantemente, es más que probable que puedas sacarlos a otra tabla y simplemente poner un número en ese campo. Así, en un campo provincia, todos los de Barcelona tendrían un 08 y los de Madrid un 28, en lugar de poner un campo lleno de cadenas con los nombres de las provincias. Otra tabla tendría la lista y ya está.
• Conceptualmente hablando ¿Hay datos que no necesitan estar juntos? Por ejemplo, puedes tener el nombre completo de una persona y su DNI en una tabla, pero luego tener otra para poner sus atributos físicos como color de ojos, etc. simplemente porque no siempre que busques a una persona querrás saber esos datos. Mira tus consultas y tú mismo sabrás qué datos sacas normalmente de una tabla. Si siempre sacas los mismos, te recomiendo dejar esos en una tabla, y sacar los que no obtengas en todas tus consultas.

Con que te hagas estas preguntas, y tengas un poco de interés y leas un poquito por ahí (estos puntos son como referencia rápida para cuando ya sepas algo, ni de coña te valen por sí solos, tienes que pensar en la integridad de los datos, que no haya duplicación de información y unas cuantas cosas más), podrás pensar en una normalización que sea exagerada y que todavía respete un poco el rendimiento

Por cierto, he leído algo por ahí sobre procedimientos almacenados. Llevo años en esto de las BBDD, y si algo te puedo decir es que los uses. Tú mismo podrás gestionar qué JOINs se hacen, qué claves se usan, y todo lo demás. L@s programadores/as se podrán encargar de programar y punto, sin poder joder el rendimiento ni los datos porque no les das pie.

Y después de este tostón, ¡feliz año!

Parece claro que lo más importante es aplicar el sentido común. Yo creo que una 3FN es más que razonable y suficiente para el diseño de una base de datos. Lo importante, yo creo, es empezar pensando en la normalización y después desnormalizar aquellos puntos que sean necesarios, de forma razonada y justificada. Si comenzamos por un diseño desnormalizado puede salir... cualquier cosa. Es un poco la filosofía que se sigue también con los paradigmas de programación como O-O y buenos diseños (Code Complete, Steve McConnell). La idea es: vamos a seguir la regla todo cuanto podamos, luego lo miramos con perspectiva y cortamos/añadimos los pespuntes que sobren/falten.

De poco me sirve para este debate conocer que existen BBDD desnormalizadas o normalizadas, y eso puede dar una idea equivocada al que empieza en esto (si Flickr o BBVA tienen BBDD desnormalizadas, ¡a desnormalizar se ha dicho, que estos tipos tienen que saber!). La idea es tener una perspectiva y ver por qué se desnormaliza, qué se persigue con ello y qué problemas traía la normalización consigo, que es lo que habéis dicho más o menos todos en vuestros comentarios.

Igual tienes que volver a hacer la asignatura... la primera forma normal es la menos restrictiva y la quinta la que más. Sin acritud.

¡Uf! ¡Cómo está el patio! En vez de un Colegio de Informáticos, lo que hace falta es que los informáticos vayan al colegio. :-D

¿Por qué /. no tiene un tipo de moderación "-1 No-Divertido"?

¿Y a ti quién te normaliza? ;)