Cuántas combinaciones son factibles en la práctica

Question

Esta pregunta podría ser más adecuada para los programadores.stackexchange. Si es así, por favor migre.

Actualmente estoy reflexionando sobre la complejidad de los modelos de datos típicos. Todo el mundo sabe que los modelos de datos deben estar normalizados, sin embargo, por otro lado, un modelo de datos normalizado requerirá bastantes combinaciones para volver a ensamblar los datos más adelante. Y las uniones son operaciones potencialmente costosas, dependiendo del tamaño de las tablas involucradas. Entonces, la pregunta que estoy tratando de resolver es cómo uno normalmente haría esto. Es decir. en la práctica, ¿cuántas uniones sería aceptable en las consultas típicas al diseñar un modelo de datos? Esto sería especialmente interesante al contar múltiples uniones en consultas individuales.

Como ejemplo digamos que tenemos usuarios, que poseen casas, en las que hay habitaciones, que tienen cajones, que contienen elementos. Normalizarlo trivialmente con tablas para usuarios, casas, salas, cajones y elementos en el sentido explicado anteriormente, requeriría más adelante que me una a cinco tablas cuando obtenga todos los elementos que pertenecen a un determinado usuario. Esto me parece una gran cantidad de complejidad.

Lo más probable es que el tamaño de las tablas también esté involucrado. Unirse a cinco tablas con pocos datos no es tan malo como tres tablas con millones de filas. ¿O esta consideración es incorrecta?

Answer 1

Hay reasons for the Database Normalizations, y he visto consultas con más de 20 tablas y subconsultas unidas, funcionando bien durante mucho tiempo. Encuentro que el concepto de normalización es una gran victoria, ya que me permite introducir nuevas características que se agregarán a las aplicaciones de trabajo existentes sin afectar las partes que hasta ahora funcionan.

Bases de datos viene con diferentes características para hacer la vida más fácil:

• se pueden crear vistas de las consultas más comúnmente utilizados (aunque este no es el único caso de uso para visitas);
• algunos RDBMS proporcionan Common Table Expressions (CTE), que le permiten utilizar subconsultas con nombre y también consultas recursivas;
• algunos RDBMS proporcionan lenguajes de extensión (como PL/SQL o PL/pgSQL), que le permiten desarrollar sus propias funciones para ocultar la complejidad de su esquema y usar solo llamadas API para operar sus datos.

Hace un tiempo atrás hubo alguna pregunta relacionada en How does a SQL statement containing mutiple joins work? También podría valer la pena examinarla.

Desarrollar una aplicación con una base de datos normalizada es más fácil, ya que con el enfoque adecuado puede aislar su esquema mediante vistas/funciones y hacer que su código de aplicación sea inmune a los cambios de esquema. Si opta por el diseño desnormalizado, es posible que los cambios de diseño afecten una gran parte de su código, ya que los sistemas desnormalizados tienden a optimizar su rendimiento a costa de las posibilidades de cambio.

Answer 2

Un modelo de datos totalmente normalizado tiene un mayor costo en rendimiento pero es más resistente al cambio. Un modelo de datos plano como una moneda de diez centavos ajustada para una consulta funcionará mucho mejor, pero tendrá que pagar el precio cuando las especificaciones cambien.

Entonces, ¿quizás la pregunta es si el uso de su modelo de datos (consultas) cambiará mucho? Si no; no los normalice solo sintonícelos para las consultas específicas (pregunte a su DBA). De lo contrario, normalízate y solo con el plan de ejecución de consultas si utilizas muchas combinaciones, no puedo darte un número específico.

Answer 3

La normalización de bases de datos es una forma de arte en sí misma.
Si estructura sus uniones correctamente, solo agarrará las columnas necesarias.
Debería ser mucho más rápido ejecutar una consulta con millones de registros con múltiples tablas y simplemente unir los campos necesarios, de lo contrario, si tiene una o dos tablas con todos los registros. En el segundo ejemplo, está recuperando todos los datos y ordenarlos sería una pesadilla de codificación.
MySQL es muy bueno solo para recuperar los datos solicitados.
El hecho de que la consulta sea larga no significa que sea más lenta.
He visto sentencias de consulta de más de 20 líneas de código que fueron muy rápidas.

Ten fe en la consulta que escribes y si no escribes un script de prueba, pruébalo.

Answer 4

para resolver su pregunta la respuesta está en:

http://en.wikipedia.org/wiki/Database_normalization

Si el rendimiento se convierte en un problema utilizando desnormalización esos problemas pueden ser resueltos. No se debe pensar en ese paso inicial (a menos que ya tenga una carga esperable). Desnormalizar cuando realmente se necesita y según las mediciones.