¿Cuál es el mejor diseño de base de datos?¿Más tablas o más columnas?[cerrado]

Question

Un ex compañero de trabajo insistió en que una base de datos con más tablas con menos columnas cada una es mejor que una con menos tablas con más columnas cada una.Por ejemplo, en lugar de una tabla de clientes con nombre, dirección, ciudad, estado, código postal, etc.columnas, tendría una tabla de nombres, una tabla de direcciones, una tabla de ciudades, etc.

Sostuvo que este diseño era más eficiente y flexible.Quizás sea más flexible, pero no estoy capacitado para comentar sobre su eficiencia.Incluso si es más eficiente, creo que esos beneficios pueden verse superados por la complejidad añadida.

Entonces, ¿hay algún beneficio significativo en tener más tablas con menos columnas en comparación con menos tablas con más columnas?

Answer 1

Tengo algunas reglas generales bastante simples que sigo al diseñar bases de datos, que creo que pueden usarse para ayudar a tomar decisiones como esta...

1. Favorecer la normalización.La desnormalización es una forma de optimización, con todas las compensaciones necesarias y, como tal, debe abordarse con prudencia. YAGNI actitud.
2. Asegúrese de que el código del cliente que hace referencia a la base de datos esté lo suficientemente desacoplado del esquema para que volver a trabajarlo no requiera un rediseño importante de los clientes.
3. No tenga miedo de desnormalizar cuando proporcione un beneficio claro para el rendimiento o la complejidad de la consulta.
4. Utilice vistas o tablas posteriores para implementar la desnormalización en lugar de desnormalizar el núcleo del esquema. cuando el volumen de datos y los escenarios de uso lo permitan.

El resultado habitual de estas reglas es que el diseño inicial favorecerá las tablas sobre las columnas, centrándose en eliminar la redundancia.A medida que avance el proyecto y se identifiquen los puntos de desnormalización, la estructura general evolucionará hacia un equilibrio que comprometa la redundancia limitada y la proliferación de columnas a cambio de otros beneficios valiosos.

Answer 2

Yo estaría a favor de más tablas, pero sólo hasta cierto punto.Usando su ejemplo, si separó la información de su usuario en dos tablas, digamos USUARIOS y DIRECCIÓN, esto le brinda la flexibilidad de tener varias direcciones por usuario.Una aplicación obvia de esto es un usuario que tiene direcciones de facturación y envío separadas.

El argumento a favor de tener una tabla CITY separada sería que solo tienes que almacenar el nombre de cada ciudad una vez y luego consultarlo cuando lo necesites.Eso reduce la duplicación, pero en este ejemplo creo que es excesivo.Puede ser más eficiente en cuanto a espacio, pero pagará el precio en uniones cuando seleccione datos de su base de datos.

Answer 3

No suena tanto como una pregunta sobre tablas/columnas, sino sobre normalización.En algunas situaciones tienen un alto grado de normalización ("más tablas" en este caso) es bueno y limpio, pero normalmente se necesitan una gran cantidad de JOIN para obtener resultados relevantes.Y con un conjunto de datos lo suficientemente grande, esto puede afectar el rendimiento.

jeff escribió un poco sobre esto con respecto al diseño de StackOverflow.Véase también la publicación a la que Jeff enlaza Dare Obasanjo.

Answer 4

Un diseño completamente normalizado (es decir, "Más tablas") es más flexible, más fácil de mantener y evita la duplicación de datos, lo que significa que será mucho más fácil hacer cumplir la integridad de sus datos.

Esas son razones poderosas para la normalización.Elegiría normalizar primero y luego solo desnormalizar específico mesas después viste que el rendimiento se estaba convirtiendo en un problema.

Mi experiencia es que en el mundo real, no se llegará al punto en que sea necesaria la desnormalización, incluso con conjuntos de datos muy grandes.

Answer 5

Depende del tipo de base de datos.MS SQL Server, por ejemplo, tiende a preferir tablas más estrechas.Ése es también el enfoque más "normalizado".Es posible que otros motores prefieran lo contrario.Los mainframes tienden a caer en esa categoría.

Answer 6

Cada tabla solo debe incluir columnas que pertenezcan a la entidad identificada de forma única por la clave principal.Si todas las columnas de la base de datos son atributos de la misma entidad, entonces solo necesitarás una tabla con todas las columnas.

Sin embargo, si alguna de las columnas puede ser nula, deberá colocar cada columna que acepte valores NULL en su propia tabla con una clave externa a la tabla principal para poder normalizarla.Este es un escenario común, por lo que para un diseño más limpio, es probable que agregue más tablas que columnas a las tablas existentes.Además, al agregar estos atributos opcionales a su propia tabla, ya no necesitarán permitir valores nulos y evitará una serie de problemas relacionados con NULL.

Answer 7

La base de datos de tablas múltiples es mucho más flexible si cualquiera de estas relaciones uno a uno puede convertirse en uno a muchos o muchos a muchos en el futuro.Por ejemplo, si necesita almacenar varias direcciones para algunos clientes, es mucho más fácil si tiene una tabla de clientes y una tabla de direcciones.Realmente no veo una situación en la que sea necesario duplicar algunas partes de una dirección pero no otras, por lo que las tablas separadas de dirección, ciudad, estado y código postal pueden ser un poco exageradas.

Answer 8

Como todo lo demás:Eso depende.

No existe una regla estricta con respecto al recuento de columnas frente al recuento de tablas.

Si sus clientes necesitan tener varias direcciones, entonces tiene sentido tener una tabla separada para eso.Si tiene una muy buena razón para normalizar la columna Ciudad en su propia tabla, entonces también puede hacerlo, pero no lo había visto antes porque es un campo de formato libre (normalmente).

Una mesa con un diseño normalizado y pesado es eficiente en términos de espacio y parece "bueno para un libro de texto", pero puede volverse extremadamente compleja.Se ve bien hasta que tienes que hacer 12 uniones para obtener el nombre y la dirección de un cliente.Estos diseños no son automáticamente Fantástico en términos de rendimiento, lo que más importa:consultas.

Evite la complejidad si es posible.Por ejemplo, si un cliente puede tener solo dos direcciones (no muchas arbitrariamente), entonces podría tener sentido mantenerlas todas en una sola tabla (ID de cliente, nombre, dirección de envío, dirección de facturación, ciudad de envío, ciudad de facturación, etc.).

Aquí está la publicación de Jeff. en el tema.

Answer 9

Tener tablas con menos columnas tiene ventajas, pero también debe observar el escenario anterior y responder estas preguntas:

¿Se le permitirá al cliente tener más de 1 dirección?De lo contrario, no es necesaria una tabla separada para la dirección.Si es así, entonces una tabla separada resulta útil porque puede agregar fácilmente más direcciones según sea necesario en el futuro, donde resulta más difícil agregar más columnas a la tabla.

Answer 10

Consideraría la normalización como el primer paso, por lo que las ciudades, condados, estados y países estarían mejor en columnas separadas...El poder del lenguaje SQL, junto con los DBMS actuales, le permite agrupar sus datos más adelante si necesita verlos en alguna otra vista no normalizada.

Cuando se esté desarrollando el sistema, podría considerar "desnormalizar" alguna parte si lo considera una mejora.

Answer 11

Creo que en este caso es necesario el equilibrio.Si tiene sentido poner una columna en una tabla, entonces póngala en la tabla, si no es así, entonces no lo haga.El enfoque de sus compañeros de trabajo definitivamente ayudaría a normalizar la base de datos, pero eso podría no ser muy útil si tiene que unir 50 tablas para obtener la información que necesita.

Supongo que mi respuesta sería: utilice su mejor criterio.

Answer 12

Hay muchos aspectos de esto, pero desde la perspectiva de la eficiencia de la aplicación, las tablas mote pueden ser más eficientes en ocasiones.Si tiene algunas tablas con un montón de columnas cada vez que la base de datos realiza una operación, tiene la posibilidad de realizar un bloqueo, más datos no estarán disponibles mientras dure el bloqueo.Si los bloqueos se escalan a páginas y tablas (bueno, con suerte, no a tablas :)), puede ver cómo esto puede ralentizar el sistema.

Answer 13

Mmm.

Creo que es un lavado y depende de tu modelo de diseño particular.Definitivamente, factorice las entidades que tengan más de unos pocos campos en su propia tabla, o entidades cuya composición probablemente cambie a medida que cambien los requisitos de su aplicación (por ejemplo, factorizaría la dirección de todos modos, ya que tiene tantos campos, pero 'd especialmente hágalo si cree que existe alguna posibilidad de que necesite manejar direcciones de países extranjeros, que pueden tener una forma diferente.Lo mismo con los números de teléfono).

Dicho esto, cuando lo tengas funcionando, mantente atento al rendimiento.Si ha creado una entidad que requiere que realice uniones grandes y costosas, tal vez sea una mejor decisión de diseño volver a convertir esa tabla en el original.

Answer 14

Hay enormes beneficios para consultas utilizando la menor cantidad de columnas posible.Pero la mesa en sí puede tener una gran cantidad. jeff dice algo sobre esto también.

Básicamente, asegúrese de no solicitar más de lo que necesita al realizar una consulta: el rendimiento de las consultas está directamente relacionado con la cantidad de columnas que solicita.

Answer 15

Creo que debes observar el tipo de datos que estás almacenando antes de tomar esa decisión.Tener una tabla de direcciones es fantástico, pero sólo si la probabilidad de que varias personas compartan la misma dirección es alta.Si cada persona tuviera direcciones diferentes, mantener esos datos en una tabla diferente solo introduciría uniones innecesarias.

No veo el beneficio de tener una tabla de ciudades a menos que las ciudades en sí mismas sean entidades que le interesen en su aplicación.O si desea limitar la cantidad de ciudades disponibles para sus usuarios.

La conclusión es que decisiones como esta deben tener en cuenta la aplicación en sí antes de comenzar a buscar eficiencia.En mi opinión.

Answer 16

Cuando diseñe su base de datos, debe estar lo más cerca posible del significado de los datos y NO de la necesidad de su aplicación.

Un buen diseño de base de datos debería durar más de 20 años sin cambios.

Un cliente puede tener varias direcciones, esa es la realidad.Si decidió que su aplicación está limitada a una dirección para la primera versión, ¡lo importante es el diseño de su aplicación, no los datos!

Es mejor tener varias tablas en lugar de varias columnas y usar la vista si desea simplificar su consulta.

La mayoría de las veces tendrá problemas de rendimiento con una base de datos; se trata de rendimiento de la red (consulta en cadena con resultado de una fila, recuperación de columna que no necesita, etc.), no de la complejidad de su consulta.

Answer 17

Primero, normalice sus tablas.Esto garantiza que evitará datos redundantes, lo que le brindará menos filas de datos para escanear, lo que mejora sus consultas.Luego, si llega a un punto en el que las tablas normalizadas a las que se está uniendo hacen que la consulta tarde demasiado en procesarse (cláusula de unión costosa), desnormalice donde sea más apropiado.

Answer 18

Es bueno ver tantas respuestas inspiradoras y bien basadas.

Mi respuesta sería (lamentablemente):Eso depende.

Dos casos:* Si crea un modelo de datos que se utilizará durante muchos años y, por lo tanto, posiblemente deba adaptarse a muchos cambios futuros:opte por más tablas y menos filas y una normalización bastante estricta.* En otros casos puedes elegir entre más tablas-menos filas o menos tablas-más filas.Especialmente para personas relativamente nuevas en el tema, este último enfoque puede resultar más intuitivo y fácil de comprender.

Lo mismo es válido para elegir entre el enfoque orientado a objetos y otras opciones.