¿Es necesario crear una base de datos con la menor cantidad de tablas posible?

52

¿Deberíamos crear una estructura de base de datos con un número mínimo de tablas?

¿Debería estar diseñado de manera que todo se quede en un solo lugar o está bien tener más mesas?

¿De todos modos afectará algo?

Estoy haciendo esta pregunta porque un amigo mío modificó alguna estructura de base de datos en mediaWiki. Al final, en lugar de 20 mesas, solo usaba 8, y le llevó 8 meses hacerlo (era su tarea universitaria).

EDITAR

Concluyo la respuesta como: el tamaño de las tablas NO importa, hasta que el caso sea excepcional; en cuyo caso la desnormalización puede ayudar.

Gracias a todos por las respuestas.

Shaheer
fuente
15
El número mínimo de tablas es fácil, solo serialice el conjunto en master_table (table_name, col_name, col_type, row_id, value).
Inca
¿Qué? No lo
entiendo
12
Dado que cada campo en una base de datos se define por la combinación del nombre de la tabla, el nombre de la columna, la clave primaria y el valor, siempre puede reducir el número de tablas al desnormalizar en una sola tabla que almacena solo eso. No muy útil, pero completamente posible.
Inca
bueno, estaba preguntando por saber, y si algo es menos útil que el existente, ¿por qué molestarse en cambiarlo? Quiero decir, ¿proporcionará alguna mejora en algo? rendimiento por ejemplo?
Shaheer
1
@Hamza: podría proporcionar un rendimiento mejorado. Realmente depende de las circunstancias específicas. No hay casi suficiente información aquí para nosotros proporcionar una respuesta concreta.
FrustratedWithFormsDesigner

Respuestas:

155

IGNORAR el número de tablas. Preocúpese más por obtener el diseño correcto. Si su principal preocupación es la cantidad de tablas, probablemente no debería diseñar sistemas de bases de datos.

Si su amigo solo necesitaba 8 tablas, y el sistema funciona bien con eso, entonces 8 es el número correcto, y los 12 restantes podrían no haber sido necesarios para lo que sea que estuviera haciendo.

Las posibles excepciones pueden ser entornos peculiares que tienen límites estrictos en los números de tabla, pero no puedo pensar en un ejemplo concreto de un sistema de este tipo fuera de mi cabeza.

FrustratedWithFormsDesigner
fuente
107
+1:If your major concern is quantity of tables, you should probably not be designing database systems.
Joel Etherton
99
Corolario: una tabla de base de datos no ocupa [mucho] espacio extra. Son los datos los que ocupan espacio. Normalización = más tablas = menos repetición = menos espacio utilizado. Al tratar de minimizar el número de tablas, no solo compromete el diseño, sino que también desperdicia espacio . Este "golf de mesa" es malo, a menos que algunas de las mesas sean literalmente redundantes.
Aaronaught
1
+1, aunque no creo que sepamos lo suficiente como para decir que el número correcto es 8 en su caso, ya que no podemos comparar los esquemas (el original podría resistir mejor a un volumen transaccional más alto que la aplicación actualmente, por ejemplo)
Adam Robinson
2
@Hamza: Ok, entonces él podría tener buenas habilidades de PHP y buenas habilidades de base de datos, y ese proyecto podría requerir ambos, pero no asuma que tener uno implica automáticamente el otro. Muchos desarrolladores pueden tener una habilidad pero no la otra.
FrustratedWithFormsDesigner
44
@ Tom Anderson - Entonces aún no deberías estar diseñando sistemas de bases de datos.
Joel Etherton
71

Una base de datos debe tener exactamente tantas tablas como sea necesario. No menos, no más.

Adam Crossland
fuente
3
english.stackexchange.com/questions/495/less-vs-fewer No para convertir esto en una discusión, pero aquí hay una discusión interesante sobre el debate "menos" versus "menos", incluidos sus orígenes, del idioma inglés SE , ya que parece entusiasmarlos;)
Corey
17

Las tablas de la base de datos deben cumplir con el Principio de Responsabilidad Única, al igual que las clases. Para comenzar, cada tabla no debe tratar con más de un grupo de datos relacionados. Dejando de lado el rendimiento, esto hace que la bestia sea más fácil de administrar, porque las tablas en sí serán más pequeñas. Esto también le brinda un mejor rendimiento, porque las tablas más pequeñas son más rápidas de buscar y unir.

No se preocupe más por la cantidad de mesas que por la cantidad de clases, no se preocupe en absoluto. Concéntrese en crear un código bueno, limpio y legible, no en la cantidad de espacio que ocupa. Refactorice agresivamente una vez que tenga un producto que funcione para mejorarlo, ¡y también me refiero a la base de datos! Verá columnas que deberían estar en otras tablas, o no son necesarias, etc. Perfil para ver qué consultas están tardando más y por qué, y abordar esos problemas si realmente son un problema.

Michael K
fuente
44
En un modelo de datos normalizado, sí, este es el mejor enfoque, sin embargo, si la base de datos está destinada a informar o principalmente a acceso de lectura, las tablas "aplanadas" desnormalizadas funcionarán mejor en grandes conjuntos de datos. Un número menor de tablas en este caso dará como resultado menos uniones y un mejor rendimiento.
maple_shaft
2
@maple Absolutamente de acuerdo. Sin embargo, debe crear un perfil para determinar qué conjuntos de datos deben agruparse, por lo que debe comenzar a normalizar la OMI. YMMV, los expertos probablemente pueden hacerlo de la cabeza :) Jeff tiene una publicación sobre la desnormalización que también puede encontrar interesante.
Michael K
1
Buena y sucinta publicación, ¡he leído esta antes! A veces puedes aprovechar lo mejor de ambos mundos. Si la presentación de informes no necesita ser 100% en tiempo real, mantenga dos esquemas, uno que sea el esquema normalizado transaccional para el uso de la aplicación y el otro un esquema desnormalizado que se transmite regularmente y se adapta para informar el acceso a los datos.
maple_shaft
1
Más información sobre el tema con una explicación de Star Schema: publib.boulder.ibm.com/infocenter/rbhelp/v6r3/…
maple_shaft
1
@maple_shaft, estoy de acuerdo en que las bases de datos de informes a menudo están denominadas para el rendimiento, pero no son algo que esperaría que un estudiante o un programador junior pueda asumir. Sé que ciertamente no permitiría que mis almacenes de datos sean manejados por nadie que no tenga experiencia probada.
HLGEM
7

Una base de datos de producción para una aplicación comercial puede contener cientos o incluso miles de tablas. Necesita la cantidad de tablas que necesita para los requisitos empresariales. Tratar de reducir el número de tablas solo por tener menos tablas generalmente dará como resultado una base de datos que es más difícil de consultar, tiene problemas de integridad de datos y es mucho más difícil de mantener que una base de datos normalizada.

Hay momentos en que se necesita desnormalización. Esto solo debe hacerlo alguien que sepa exactamente lo que está haciendo y por qué. Es muy fácil acumular la denominación, por lo que solo debe hacerlo un especialista en bases de datos o un desarrollador senior de aplicaciones con años de experiencia en bases de datos. Una persona sin experiencia debe esforzarse por alcanzar, como mínimo, la tercera forma normal (a menos que esté haciendo el almacenamiento de datos, que es un área para la que no consideraría contratar a una persona sin experiencia) en cualquier base de datos que diseñe.

Cuando la gente dice que reduzca las tablas porque las uniones son caras, generalmente son ignorantes o tienen bases de datos mal diseñadas a las que les faltan índices críticos o usan claves naturales de columnas múltiples grandes. Las bases de datos relacionales están diseñadas para usar combinaciones y las combinaciones pueden ser bastante eficientes si los FK están indexados correctamente y usan campos pequeños para unirse (los enteros son más eficientes). Notará que las grandes empresas que tienen bases de datos del tamaño de un terrabyte de alguna manera logran obtener un rendimiento excelente y utilizan combinaciones.

Ningún diseñador de bases de datos serio intenta reducir el número de tablas solo porque quiere menos tablas. Reduce el número de tablas porque los datos ya no son necesarios o tiene un problema de rendimiento que no puede resolver de otra manera (y hay muchas maneras de intentarlo antes de asumir el gran riesgo de que sus datos denormalicen una tabla) .

HLGEM
fuente
Google diseñó BigTable y excluyó deliberadamente las uniones ya que no es paralelizable.
Lie Ryan
2
@Lie Ryan, BigTable es un caso especial que NO es apropiado para la mayoría de las aplicaciones comerciales, ya que la integridad de los datos no es una gran preocupación. Google no necesita muchas reglas comerciales complejas para la búsqueda. Apuesto a que su aplicación financiera corporativa no usa BigTable. No obstante, la mayoría de las aplicaciones comerciales que tienen bases de datos grandes pueden, de hecho, usar combinaciones y funcionar bien si el diseñador es conocedor. Las bases de datos empresariales tienen muchas formas de mejorar el rendimiento (incluida la partición) y, por lo tanto, no necesitan perder las características de integridad de datos de una base de datos relacional.
HLGEM
+1 para ti, @HLGEM, tanto por la respuesta como por el comentario; Es una pena ver a muchos desarrolladores que se suben al carro de la base de datos de documentos porque piensan "une = lento", solo para intentar resolver problemas relacionales que fueron resueltos por bases de datos relacionales hace 20 años.
Adam Robinson
5

Dado que cada campo en una base de datos se define por la combinación del nombre de la tabla, el nombre de la columna, la clave primaria y el valor, siempre puede reducir el número de tablas al desnormalizar en una sola tabla que almacena solo eso. No muy útil, pero completamente posible.

Las tablas son una capa abstracta que ayuda con los problemas de manejo de datos. Por eso se crean. Lo hice en broma, pero entender que puede reducir cada conjunto de datos a una tabla maestra señala de inmediato por qué no debería hacerlo: porque las tablas le aportan algo. En un nivel conceptual, le brindan una estructura que es más fácil de entender para los humanos que los datos serializados. En el nivel intermedio, traen el concepto de normalización: evitar guardar datos redundantes y dar un solo punto para los cambios, en lugar de cambiar algo en varios lugares. En un nivel técnico, las bases de datos traen la mayoría de las cosas que desea hacer con datos, numerosas herramientas, y las implementaron y probaron más de lo que probablemente lo hará usted mismo. Piense en los tipos de datos, valores predeterminados, derechos de usuario, índices, restricciones de clave externa, etc. Ha sido probado, utilizado por muchos, optimizado, depurado. (No a la perfección, pero aún así).

Como una base de datos es una herramienta, lo principal es decidir cómo usar la herramienta. El número de tablas no es importante. Minimizar siempre es posible pero a costa de descartar los beneficios. (Si lee más sobre la normalización, se encontrará con los pocos casos de desnormalización, pero aun así se trata de las decisiones correctas en lugar de simplemente reducir a ciegas el número de tablas).

Inca
fuente
gracias, que es mucho más claro ahora !, y me han leído acerca de la normalización por cierto, lo hago él, incluso en las bases de datos CakePHP, que anima a otra y algo diferente enfoque.
Shaheer
3

Debe usar el número correcto de tablas. En teoría, podría conformarse con una sola tabla de tabla denormalizando toda la base de datos, pero la base de datos sería inutilizable. Tu amigo parece que tiene demasiado tiempo en sus manos.

Neil Butterworth
fuente
2

Tener el número mínimo de mesas me parece un objetivo muy peculiar.

Ciertamente, reducir un esquema de 20 tablas a 8 podría ser algo bueno (si se hace bien, podría reducir las uniones y aumentar el rendimiento, eliminar las columnas no utilizadas, etc.) pero igualmente podría dificultar la comprensión y mejorar en el futuro.

Pensándolo de otra manera, ¿crees que la normalización es algo bueno? La normalización generalmente conduce a un mayor número de tablas, pero también conduce a soluciones más mantenibles, una duplicación de datos reducida y una administración de datos más fácil.

Por supuesto, también puede conducir a un rendimiento más lento (suponiendo que la base de datos denormalizada esté bien diseñada).

En última instancia, debe pensar cuáles son sus requisitos en estas áreas, pero como posición de inicio predeterminada, diría que busque un nivel razonable de normalización y luego observe si eso está causando problemas específicos donde menos tablas podrían ser una solución.

Jon Hopkins
fuente
0

El número no es importante. El diseño es Mira algunos sistemas por ahí. Magento, PHPBB, etc. Tienen docenas de tablas en sus sistemas y funcionan bien.

Ryan Street
fuente
0

Junto con las preocupaciones por la normalización y el rendimiento, puede usar "que requerirá otra tabla" como una forma de administrar el alcance de una aplicación. Esa característica requerirá una nueva tabla y todo el tiempo, energía y esfuerzo para diseñar, construir, probar, administrar en las actualizaciones y todas las demás codificaciones involucradas. Agregar 5 campos a las tablas existentes (cuando corresponda) es mucho más fácil que una tabla de 5 columnas.

JeffO
fuente
0

Si diseña una base de datos tratando de minimizar la creación de tablas, pronto verá la dificultad abrupta y errará en sus formas.

El recuento de tablas no debe estar en la vanguardia de su mente al crear un diseño de base de datos. Ponga las cosas donde necesitan ir lógica y relacionalmente.


fuente
0

Creo que el número de tablas es importante y puede tener un gran impacto en el rendimiento si elige dividir los datos que, para todos los propósitos y propósitos comerciales, deben permanecer juntos, en varias tablas (es decir, tendría una base de datos normalizada). Por lo general, cuando hace esto, se verá obligado a UNIRSE a Operaciones (o no equivalente a SQL) para obtener todos los datos que necesita y para tablas suficientemente grandes estructuradas de esta manera, el rendimiento se empantana rápidamente.

No voy a entrar en detalles, pero creo que el hecho muy real de que el número de tablas puede influir en el rendimiento es una de las razones por las cuales no se han inventado bases de datos SQL como Cassandra, Mongo y Google BigTable (sic). y también es por eso que fomentan la desnormalización de los datos (y, en consecuencia, evitan una gran cantidad de tablas / colecciones, etc.).

Lo mismo podría decirse de los servidores de búsqueda como el Solr de Apache, que en realidad no fomenta o facilita la división de sus documentos en múltiples "tablas" o "tipos de entradas", alentándolo a tener un esquema de "uno que abarque todo" que tenga campos comunes. a todos los tipos de documentos que desea indexar (y, en consecuencia, evite tener que realizar operaciones similares a JOIN).

No estoy diciendo que el simple hecho de tener tablas x en un esquema necesariamente lo hará más lento que un esquema con tablas x / 2 todo el tiempo, pero hay ciertos contextos en los que puede conducir a desaceleraciones debido a la consecuente Se necesitan operaciones adicionales para agregar los datos en todas esas tablas. Continuando con esto, tampoco creo que esté bien decir "cualquier cantidad de tablas y la normalización extrema de los datos no tienen ningún impacto en el rendimiento".

Shivan Dragon
fuente
0

El tío Bob argumentaría que más es más simple.

Ver http://c2.com/cgi/wiki?FearOfAddingTables

"un buen diseño generalmente se simplifica agregando tablas"

Creo que casi todas las entidades son de muchos a muchos, lo que requiere más tablas.

Haga una tabla de países con el código del continente. Oh, no puedes porque en realidad hay 8 países transcontinentales. Lo mismo con las monedas. Panamá usa dos.

Neil McGuigan
fuente
-2

Entonces la respuesta es SI.

Pero dependa de cuál es el verdadero significado del número "mínimo" de tablas.

Por ejemplo (un anti-ejemplo).

Si tengo los siguientes objetos

  1. los usuarios
  2. clientes

y ambos comparten los mismos estados (campos) y no hay una restricción de seguridad entonces, es más adecuado hacer una sola tabla

  1. table_persons

más bien dos tablas diferentes

  1. usuarios_tabla
  2. table_customers

la desventaja es que en table_persons necesitaremos agregar un nuevo campo (type_of_person).

Otro error (error si realmente no es necesario hacerlo) es "dividir" una tabla, leer como: separar una sola tabla en dos.

  1. table_persons

en dos mesas

  1. table_info_persons
  2. table_extra_info_persons

porque estás obligando a algunas consultas a unir dos tablas y es malo.

magallanes
fuente
oye, tu respuesta es muy descriptiva y
útil
2
Esto me da flashbacks a mi primera aplicación empresarial y la base de datos detrás de ella y qué pesadilla hizo el DBA por ser un nazi de mesa en cosas como esta. Absolutamente nunca uniría a clientes y usuarios, esas son entidades comerciales completamente dispares.
-1: usuarios y clientes tienen diferentes campos; Si no en este momento, lo tendrán en algún momento en el futuro. Por eso merecen mesas separadas.
Sjoerd
1
@Sjoerd, @Chris: Si bien ese puede ser el caso, eso no es necesariamente cierto. Cosas como esas dependen de la aplicación. Dicho esto, estoy de acuerdo con el sentimiento. Con demasiada frecuencia, los desarrolladores de bases de datos verán "nombres de campo comunes" significa que son los mismos datos. Esto se vuelve especialmente fácil de hacer cuando mira la base de datos desde el ORM primero (en otras palabras, al revés). Si bien los conceptos de OO se pueden modelar en la base de datos, las bases de datos son filas y relaciones, no objetos .
Adam Robinson
1
¡+1 para "las bases de datos son filas y relaciones, no objetos", lo agregaré a mis citas favoritas!
Shaheer