database - tutorial - ¿Debería poner propiedades de registro opcionales en una tabla separada?
tutorial django (3)
Tengo una tabla de aproximadamente 1,000 registros. Alrededor de la mitad de ellos utilizará un conjunto de campos que contienen ciertas características. Hay alrededor de 10 campos relevantes. La otra mitad de los registros no necesitará esa información completada.
Esta tabla es central para la base de datos y tomará la mayor parte de las operaciones. Aunque con solo 1,000 registros, no es mucho.
El hardware en el que está almacenada la base de datos es antiguo y lento (girando disco duro, no SSD ...) por lo que quiero tener una estructura bastante optimizada para aprovecharlo al máximo. Obviamente, el aumento del tamaño de la base de datos solo debido a los campos en blanco no es una preocupación importante, pero si se ralentiza las consultas, entonces eso no es bueno.
Creo que debería describir la configuración. Actualmente, Access 2007 client y Access backend, aunque el backend pronto se moverá al servidor SQL. Actualmente el backend está en el rack del servidor principal, pero cuando se mueve a SQL Server obtendrá su propio rack de servidor anterior.
Entonces, ¿debería hacer una tabla separada para almacenar el conjunto de características antes mencionado, o debería dejarlo como está?
La consulta general de colocar los campos opcionales en una tabla separada y luego usar una combinación no proporciona muchos beneficios para el tamaño o la administración de datos. Especialmente si es de 1 a 1 como en tu ejemplo. Para el tamaño, los campos opcionales NULL no te afectarán mucho. Y sí, el 75% es un buen umbral aleatorio para cuando deberías comenzar a mover cosas, pero incluso así, en realidad no estás normalizando nada moviendo los campos opcionales (si son 1 a 1 con el registro y siempre estarás ir a buscarlo junto con el registro principal).
Vale la pena señalar: con la mayoría de las bases de datos, obtener filas grandes en consultas individuales es mejor que varias consultas pequeñas ... en caso de que luego tenga la necesidad de obtener los datos opcionales en la segunda tabla en una consulta separada. Sin embargo, en Access 2007 esto puede importar menos.
Y sin importar si mueve esos campos opcionales o no, agregue índices para esos campos que puede usar en un where / having / join .
Mi impresión de lo que has dicho es que deberías usar tablas separadas. Las dependencias que desea representar y las necesidades de integridad de los datos ("reglas de negocios") deberían determinar a qué tabla (s) pertenece cualquier atributo.
En tu caso, parece que tienes dos tipos de hechos para representar. Esos tipos de hechos tienen distintos conjuntos de atributos y, por lo tanto, pertenecen a diferentes tablas. Si combina dos tipos de hechos diferentes en una tabla y establece un conjunto de atributos nulable, puede comprometer la integridad de los datos: es decir, permitiendo valores para algún atributo cuando las reglas comerciales no requieren tal valor y permitiendo que un valor esté ausente cuando las reglas comerciales de hecho lo requieren.
Para una forma más formal de responder a esto, vea la Quinta Forma Normal y el Principio de Diseño Ortogonal. Si aún no conoce estos principios de diseño, entonces debe familiarizarse con ellos.
La partición vertical tiene sentido para un gran conjunto de datos para hacer que la caché sea más eficiente. 1000 filas no califican como "grandes" incluso en un hardware bastante antiguo.
Entonces, a menos que haya otras razones para rediseñar esta tabla (no fusionó las búsquedas, ¿verdad?), Ya está listo.