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

51

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

¿Debe diseñarse de forma que todo se quede en un lugar o está bien tener más mesas?

¿De alguna manera afectará algo?

Estoy haciendo esta pregunta porque un amigo mío modificó la estructura de una base de datos en mediaWiki. Al final, en lugar de 20 mesas, estaba usando solo 8, y le tomó 8 meses para hacerlo (era su asignación universitaria).

EDIT

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.

    
pregunta Shaheer 13.06.2011 - 16:57

13 respuestas

153

IGNORE el número de tablas. Preocúpate por obtener el diseño correcto. Si su principal preocupación es la cantidad de tablas, probablemente no debería estar diseñando 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 las 12 restantes podrían no haber sido necesarias para lo que fuera que estuviera haciendo.

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

    
respondido por el FrustratedWithFormsDesigner 13.06.2011 - 17:09
71

Una base de datos debe tener exactamente la cantidad de tablas que necesita. No menos, no más.

    
respondido por el Adam Crossland 13.06.2011 - 17:09
17

Las tablas de la base de datos deben cumplir con el principio de responsabilidad única, al igual que las clases. Cada tabla debe tratar con no más de un grupo de datos relacionados para comenzar. Dejando de lado el rendimiento, esto hace que toda la bestia sea más fácil de manejar, porque las tablas en sí mismas 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 para buscar y unirse.

No te preocupes por la cantidad de tablas más de lo que te preocupas por la cantidad de clases, no te preocupes en absoluto. Enfócate en hacer un código bueno, limpio y legible, no en cómo Mucho espacio que ocupa. Refactorice agresivamente una vez que tenga un producto en funcionamiento para mejorarlo, ¡y también me refiero a la base de datos! Verá columnas que deberían estar en otras tablas, o que no son necesarias, etc. Perfil para ver qué consultas están demorando más tiempo y por qué, y resolver esos problemas si realmente son un problema.

    
respondido por el Michael K 13.06.2011 - 17:13
7

Una base de datos de producción para una aplicación empresarial puede contener cientos o incluso miles de tablas. Necesita la cantidad de tablas que necesita para los requisitos comerciales. Tratar de reducir el número de tablas solo por tener menos tablas generalmente resultará en 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 la desnormalización. Esto solo debe hacerlo alguien que sepa exactamente lo que está haciendo y por qué. Es muy fácil eliminar las anomalías, por lo que solo debe hacerlo un especialista en bases de datos o un desarrollador de aplicaciones senior 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é realizando el almacenamiento de datos, que es un área en la que no consideraría contratar a una persona sin experiencia) en cualquier base de datos que diseñe.

Cuando las personas dicen reducir 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 utilizan grandes claves naturales de columnas múltiples. Las bases de datos relacionales están diseñadas para usar uniones y las juntas pueden ser bastante eficientes si los FK están correctamente indexados y usan pequeños campos para unirse (los enteros son más eficientes). Notará que las grandes empresas que tienen bases de datos de tamaño terrabyte de alguna manera logran obtener un excelente rendimiento y utilizan uniones.

Ningún diseñador de bases de datos serio intenta reducir el número de tablas solo porque quieren 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 formas de intentarlo antes de asumir el riesgo extenso para tus datos de desnormalización de una tabla).

    
respondido por el HLGEM 13.06.2011 - 18:17
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 principal y el valor, siempre puede reducir el número de tablas desnormalizando en una sola tabla que almacena solo eso. No es muy útil, pero es completamente posible.

Las tablas son una capa abstracta que ayuda con los problemas de tratar con datos. Es por eso que son creados. Hice una broma, pero comprender que puede reducir cada conjunto de datos a una tabla maestra, inmediatamente señala por qué no debería hacerlo, porque las tablas le aportan algo. En un nivel conceptual, le ofrecen una estructura que es más fácil de entender para los seres humanos que los datos serializados. En el nivel intermedio traen el concepto de normalización: para evitar guardar datos redundantes y dar un punto único para los cambios, en lugar de cambiar algo en varios lugares. A 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 usted mismo. Piense en los tipos de datos, los valores predeterminados, los derechos de usuario, los índices, las restricciones de clave externa, etc. Ha sido probado, utilizado por muchos, optimizado, depurado. (No en la perfección, pero aún así.)

Dado que una base de datos es una herramienta, lo principal es decidir cómo usarla. El número de tablas no es importante. Minimizar siempre es posible, pero a costa de desechar los beneficios. (Si lee más acerca de la normalización, encontrará algunos casos de desnormalización, pero incluso entonces se trata de decisiones correctas en lugar de simplemente reducir ciegamente el número de tablas).

    
respondido por el Inca 13.06.2011 - 19:34
3

Debes usar el número de tablas right . En teoría, podría conformarse con una tabla única mediante la normalización de toda la base de datos, pero la base de datos sería inutilizable. Su amigo parece que tiene demasiado tiempo en sus manos.

    
respondido por el Neil Butterworth 13.06.2011 - 17:09
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, puede reducir las uniones y aumentar el rendimiento, eliminar columnas no utilizadas, etc.) pero también podría hacer que sea más difícil de entender y mejorar el avance. .

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 fáciles de mantener, reduce la duplicación de datos y facilita la administración de datos.

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

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

    
respondido por el Jon Hopkins 13.06.2011 - 17:25
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.

    
respondido por el Ryan Street 13.06.2011 - 23:55
0

Junto con las preocupaciones por la normalización y el rendimiento, puede usar "que requerirá otra tabla" como 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 toda la otra codificación involucrada. Agregar 5 campos a las tablas existentes (cuando sea apropiado) es mucho más fácil que una tabla de 5 columnas.

    
respondido por el JeffO 05.08.2011 - 21:53
0

Si diseñas una base de datos intentando minimizar la creación de tablas, pronto verás la abrupta dificultad y errarás en tus caminos.

El conteo de tablas no debe estar al frente de su mente al crear un diseño de base de datos. Ponga las cosas donde necesitan ir de forma lógica y relacional.

    
respondido por el user29981 05.08.2011 - 23:08
0

Creo que la cantidad de tablas es importante y puede tener un gran impacto en el rendimiento si eliges dividir los datos que deberían, para todos los propósitos y propósitos del negocio, permanecer juntos en varias tablas (es decir, tendrías una base de datos normalizada). ). Por lo general, cuando hace esto, se le obligará a Operaciones de UNIÓN (o equivalentes que no sean de SQL) para obtener todos los datos que necesita y para tablas suficientemente grandes estructuradas de esta manera, el rendimiento se reducirá 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 que las bases de datos noSQL como Cassandra, Mongo y Google BigTable (¡sic!) tienen se han inventado, y es por eso también que fomentan la des-normalización de los datos (y, por consiguiente, evitan un gran número 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", lo que lo alienta a tener un esquema "uno abarca todos" que tiene campos comunes a todos los tipos de documentos que desea indexar (y, por lo tanto, evita tener que realizar operaciones tipo 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 llevar a ralentizaciones. Debido a las consecuentes operaciones adicionales necesarias para agregar los datos en todas esas tablas. Continuando con esto, tampoco creo que esté bien decir "cualquier número de tablas y la normalización extrema de los datos no tiene ningún impacto en el rendimiento".

    
respondido por el Shivan Dragon 04.10.2012 - 17:39
0

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

Consulte enlace

"un buen diseño generalmente se simplifica al agregar tablas"

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

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

    
respondido por el Neil McGuigan 06.10.2014 - 23:31
-2

Entonces la respuesta es SÍ.

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

Por ejemplo (un anti-ejemplo).

Si tengo los siguientes objetos

  1. usuarios
  2. clientes

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

  1. table_persons

en lugar de dos tablas diferentes

  1. table_users
  2. table_customers

los contras son más que en las personas de tabla que necesitaremos para agregar un nuevo campo (tipo_de_persona).

Otro error (error si no es realmente necesario hacerlo) es "dividir" una tabla, se lee como: separa una tabla en dos.

  1. table_persons

en dos tablas

  1. table_info_persons
  2. table_extra_info_persons

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

    
respondido por el magallanes 13.06.2011 - 22:50

Lea otras preguntas en las etiquetas