database - tipos - objetivo del diseño de base de datos
¿Cuál es el mejor diseño de base de datos: más tablas o más columnas? (18)
Un ex compañero de trabajo insistió en que una base de datos con más tablas con menos columnas es mejor que una con menos tablas con más columnas cada una. Por ejemplo, en lugar de una tabla de clientes con columnas de nombre, dirección, ciudad, estado, postal, etc., tendrías una tabla de nombres, una tabla de direcciones, una tabla de ciudades, etc.
Él argumentó que este diseño era más eficiente y flexible. Quizás es más flexible, pero no estoy calificado para comentar sobre su eficiencia. Incluso si es más eficiente, creo que esas ganancias pueden ser superadas por la complejidad añadida.
Entonces, ¿hay algún beneficio significativo para más tablas con menos columnas en menos tablas con más columnas?
Cada tabla solo debe incluir columnas que pertenezcan a la entidad identificada de forma exclusiva por la clave principal. Si todas las columnas en la base de datos son todos atributos de la misma entidad, entonces solo necesitaría una tabla con todas las columnas.
Sin embargo, si alguna de las columnas puede ser nula, deberá colocar cada columna con nulos en su propia tabla con una clave externa a la tabla principal para 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ían permitir nulos y evitaría una gran cantidad de problemas relacionados con NULL.
Como todo lo demás: depende.
No existe una regla rígida con respecto al recuento de columnas frente al recuento de tablas.
Si sus clientes necesitan tener varias direcciones, entonces una tabla separada para eso tiene sentido. Si tiene una muy buena razón para normalizar la columna de la Ciudad en su propia tabla, eso también puede ir, pero no lo he visto antes porque es un campo de formulario libre (por lo general).
Un diseño pesado y normalizado de mesa es eficiente en términos de espacio y se ve como "bueno para los libros de texto", pero puede volverse extremadamente complejo. Se ve bien hasta que tenga que hacer 12 uniones para obtener el nombre y la dirección de un cliente. Estos diseños no son automáticamente fantásticos en términos de rendimiento que más importa: consultas.
Evite la complejidad si es posible. Por ejemplo, si un cliente puede tener solo dos direcciones (no arbitrariamente muchas), entonces podría tener sentido mantenerlas todas en una sola tabla (CustomerID, Name, ShipToAddress, BillingAddress, ShipToCity, BillingCity, etc.).
Aquí está la publicación de Jeff sobre el tema.
Creo que el equilibrio está en orden en este caso. Si tiene sentido colocar una columna en una tabla, colocarla en la tabla, si no es así, entonces no. 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, usa tu mejor juicio.
Creo que tienes que mirar el tipo de datos que estás almacenando antes de tomar esa decisión. Tener una tabla de direcciones es excelente, pero solo si la probabilidad de que varias personas compartan la misma dirección es alta. Si cada persona tiene direcciones diferentes, mantener esos datos en una tabla diferente simplemente introduce uniones innecesarias.
No veo el beneficio de tener una mesa en la ciudad a menos que las ciudades en sí mismas sean entidades que te importen en tu solicitud. O si desea limitar el número de ciudades disponibles para sus usuarios.
En pocas palabras, las decisiones como esta deben tener en cuenta a la aplicación antes de comenzar a disparar para obtener eficiencia. IMO.
Cuando diseñe su base de datos, debe estar lo más cerca posible del significado de los datos y NO de su aplicación.
Un buen diseño de base de datos debe soportar más de 20 años sin cambios.
Un cliente puede tener múltiples direcciones, esa es la realidad. Si decidió que su aplicación está limitada a un destinatario para la primera versión, ¡se trata del diseño de su aplicación, no de los datos!
Es mejor tener varias tablas en lugar de varias columnas y usar vista si quiere simplificar su consulta.
La mayoría de las veces tendrá un problema de rendimiento con una base de datos, es sobre el rendimiento de la red (consulta en cadena con un resultado de fila, columna de recuperación que no necesita, etc.), no sobre la complejidad de su consulta.
Depende del sabor de tu base de datos. MS SQL Server, por ejemplo, tiende a preferir tablas más estrechas. Ese es también el enfoque más ''normalizado''. Otros motores pueden preferirlo al revés. Los mainframes tienden a caer en esa categoría.
Discutiría a favor de más tablas, pero solo hasta cierto punto. Usando su ejemplo, si separó la información de su usuario en dos tablas, digamos USUARIOS y DIRECCIÓN, esto le da la flexibilidad de tener varias direcciones por usuario. Una aplicación obvia de esto es un usuario que tiene direcciones de envío y facturación separadas.
El argumento a favor de tener una mesa CITY separada sería que solo tiene que almacenar el nombre de cada ciudad una vez, luego consultarlo cuando lo necesite. 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 combinaciones cuando seleccione datos de su base de datos.
Es bueno ver tantas respuestas inspiradoras y bien basadas.
Mi respuesta sería (por desgracia): depende.
Dos casos: * Si crea un modelo de datos que se utilizará durante muchos años y posiblemente tenga que adaptarse a muchos cambios futuros: obtenga más tablas y menos filas y una normalización bastante estricta. * En otros casos, puede elegir entre más filas sin tablas o menos tablas, más filas. Especialmente para personas relativamente nuevas en el tema, este último enfoque puede ser más intuitivo y fácil de comprender.
Lo mismo es válido para elegir entre el enfoque orientado a objetos y otras opciones.
Existen ventajas al tener tablas con menos columnas, pero también necesita ver su escenario anterior y responder estas preguntas:
¿Se le permitirá al cliente tener más de 1 dirección? Si no, entonces no es necesaria una tabla separada para la dirección. Si es así, una tabla separada se vuelve útil porque puede agregar fácilmente más direcciones según sea necesario en el futuro, donde se hace más difícil agregar más columnas a la tabla.
Hay grandes beneficios para las consultas con el menor número de columnas posible. Pero la mesa en sí puede tener un gran número. Jeff dice algo sobre esto también.
Básicamente, asegúrese de no solicitar más de lo que necesita cuando realiza una consulta: el rendimiento de las consultas está directamente relacionado con el número de columnas que solicita.
Hay muchos aspectos en esto, pero desde una perspectiva de eficiencia de la aplicación, las tablas mote pueden ser más eficientes a veces. Si tiene algunas tablas con un grupo de columnas cada vez que la base de datos como para realizar una operación tiene la posibilidad de hacer un bloqueo, se dejarán de tener disponibles más datos mientras dure el bloqueo. Si los bloqueos se escalan a la página y las tablas (bueno, afortunadamente no tablas :)) puede ver cómo esto puede ralentizar el sistema.
Hmm.
Creo que es un lavado y depende de su modelo de diseño particular. Definitivamente restar importancia a las entidades que tienen más de unos pocos campos en su propia tabla, o entidades cuyo maquillaje probablemente cambiará a medida que cambien los requisitos de su aplicación (por ejemplo, me gustaría factorizar la dirección, ya que tiene tantos campos, pero Especialmente, hazlo si crees que hay alguna posibilidad de que necesites manejar direcciones de países extranjeros, que pueden ser de otra forma. Lo mismo ocurre con los números de teléfono).
Dicho eso, cuando lo tengas funcionando, mantente atento al rendimiento. Si ha hecho girar una entidad que requiere que realice uniones grandes y costosas, tal vez se convierta en una mejor decisión de diseño para volver a convertir esa tabla en el original.
La base de datos de varias tablas es mucho más flexible si alguna de estas relaciones uno a uno puede llegar a ser una para muchos o muchos para 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 puedo ver una situación en la que deba duplicar algunas partes de una dirección pero no otras, por lo que las tablas de dirección, ciudad, estado y postal separadas pueden ser un poco exageradas.
No suena tanto como una pregunta sobre tablas / columnas, sino sobre la normalización. En algunas situaciones, un alto grado de normalization ("más tablas" en este caso) es bueno y está limpio, pero normalmente requiere un gran número de UNIONES para obtener resultados relevantes. Y con un conjunto de datos lo suficientemente grande, esto puede atascar el rendimiento.
Jeff escribió un poco al respecto del diseño de . Ver también la publicación a la que Jeff se une por Dare Obasanjo .
Primero, normaliza tus tablas. Esto garantiza que evite los datos redundantes y le proporcione menos filas de datos para escanear, lo que mejora sus consultas. Luego, si se topa con un punto donde las tablas normalizadas a las que se está uniendo provocan que la consulta tarde en procesarse (cláusula de unión costosa), desnormalice donde sea más apropiado.
Tengo algunas reglas básicas bastante simples que sigo al diseñar bases de datos, que creo que se pueden usar para ayudar a tomar decisiones como esta ...
- Favore la normalización. La desnormalización es una forma de optimización, con todos los intercambios necesarios, y como tal, debe YAGNI con una actitud YAGNI .
- Asegúrese de que el código del cliente que hace referencia a la base de datos esté lo suficientemente desacoplado del esquema que la reelaboración no requiera un rediseño importante del cliente (s).
- No tengas miedo de desnormalizar cuando proporciona un beneficio claro para el rendimiento o la complejidad de la consulta.
- Utilice vistas o tablas descendentes 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, con un enfoque en la eliminación de la redundancia. A medida que avance el proyecto y se identifiquen los puntos de desnormalización, la estructura general evolucionará hacia un equilibrio que se compromete con una redundancia y proliferación de columnas limitadas a cambio de otros beneficios valiosos.
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 su integridad de datos será mucho más fácil de aplicar.
Esas son razones poderosas para normalizar. Preferiría normalizar primero, y luego solo desnormalizar tablas específicas después de ver que el rendimiento se estaba convirtiendo en un problema.
Mi experiencia es que en el mundo real, no llegarás al punto en que la desnormalización sea necesaria, incluso con conjuntos de datos muy grandes.
consideraría la normalización como el primer paso, por lo que las ciudades, los condados, los estados, los países serían mejores columnas separadas ... el poder del lenguaje SQL, junto con el DBMS-és de hoy le permite agrupar sus datos más adelante si necesita ver en alguna otra vista no normalizada.
Cuando se está desarrollando el sistema, puede considerar "no normalizar" alguna parte si lo ve como una mejora.