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

¿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.

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.

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

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.

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) .

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).

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.

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.

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.

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.

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.

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".

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.

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.