performance - una - Diseño de normalización de la base de datos: tablas únicas o múltiples




normalizacion de base de datos pdf (5)

Mi opinión sería que si

 // Then depending on user selection, either these fields need to be specified 
 // (could be factored out to a separate table):
 {
 - InternalAccountID (integer, with a FK)
 - InternalCompanyID (integer, with a FK)
 }

 // Or these (could be factored out to a separate table):
 {
 - ExternalAccountNumber (free text string)
 - ExternalCompanyName (free text string)
 - ExtraInformation (free text string)
 }

siempre son 1: 1 con un pedido (es decir, no puede tener 3 ID de cuenta), luego déjelo como una sola tabla. Para solucionar su problema nulo, podría agregar una columna más llamada InternalCustomer (boolean) o CustomerType (varChar) que podría usar para definir a un cliente interno o externo para saber cuál de los dos conjuntos de campos debe mirar para un cliente específico.

Dado que no conocemos el uso completo de esta información o el esquema para toda la base de datos, cualquier respuesta al respecto no puede ser totalmente calificada.

¿Debería esto estar representado en la base de datos como 1 tabla o 3 tablas? Mi amigo y yo tenemos opiniones diferentes sobre esto, así que me gustaría ver las opiniones generales sobre esto. (Tal vez debería ser un voto para cualquiera de las soluciones?)

Create Table Order
// Basic fields of the table
 - ID (Primary key)
 - CustomerID  (integer, with a FK)
 - Quantity
 - ProductID  (integer, with a FK)

 // Then depending on user selection, either these fields need to be specified 
 // (could be factored out to a separate table):
 {
 - InternalAccountID (integer, with a FK)
 - InternalCompanyID (integer, with a FK)
 }

 // Or these (could be factored out to a separate table):
 {
 - ExternalAccountNumber (free text string)
 - ExternalCompanyName (free text string)
 - ExtraInformation (free text string)
 }

1 enfoque de tabla:

Pros:

  • rendimiento (una inserción en lugar de dos, control FK, sin uniones)
  • probablemente tome menos espacio (las tablas adicionales tienen campos + índices + campo ID extra)
  • una mesa en lugar de tres
  • difícilmente justificable dividirse en tablas nuevas solo para 2 + 3 campos (¿o qué?)

Contras:

  • Campos Nullable
  • Columna "tipo" potencialmente extra (se puede omitir)
  • Rompe 3NF (?)

Pros y contras amablemente solicitados, así como las opiniones personales. :)

EDITAR: Intenté simplificar el ejemplo utilizando diferentes entidades de las que realmente estoy usando, por lo que cualquier sugerencia para modificar el modelo realmente no me ayudaría. Es decir, se centran más en los aspectos técnicos que en el modelo de dominio.


A medida que aumenta el volumen, la selección de dos tablas puede ser mucho más rápida que una . A veces, este tipo de refactorización (partición) se realiza en bases de datos maduras para aumentar el rendimiento.

Imagina usar esto para una unión de varias tablas, donde algunos criterios están en esta tabla, pero otros están en tablas diferentes.

select from order join customer using (customer_id)
where
    order.order_date between ? and ?
    and customer.name = ?

Puede terminar obteniendo todas las filas de order para las fechas del disco, y luego descartando muchas de ellas porque no coinciden con la combinación. Esta captura del disco está destinada a ser lenta y puede estropear su memoria caché RAM.

select from order join order_detail using (order_id) join customer using (customer_id)
where
    order.order_date between ? and ?
    and customer.name = ?

En este caso, cuando carga todas las filas de order desde el disco, no va a doler tanto como antes, porque la tabla es más estrecha y más pequeña. No necesita cargar todos los campos largos que son irrelevantes para el filtrado. Eventualmente, después de unirse al customer , solo obtendrá esas filas order_detail que coinciden con todos los criterios.

Si espera que esto sea grande, debe considerar dividir la tabla para que los campos que son más críticos para las búsquedas se encuentren en una tabla, y los campos "datos" en otra (s) tabla (s) uno-a-uno.

La conclusión es: la forma y el dominio normales son una cosa, pero el rendimiento a menudo requiere compensaciones . Puede ocultar algunos de ellos (cubrir la división con una vista), pero no todos (campos duplicados / agregados por una selección más rápida).


No iría con la solución de 3 mesas. Al dividir estos datos en 3 tablas, no puede tener ninguna consulta que devuelva un encabezado de orden completo sin unirse con la clave externa, y cada inserción de un nuevo pedido actualiza varias tablas e índices, lo que es un problema para la concurrencia. Sugeriría usar 2 tablas, una para InternalOrders y otra para ExternalOrders. Para aquellos casos en los que necesite una consulta consolidada de datos de ambos conjuntos de órdenes, defina una vista que sea la unión de ambas tablas.

Me sorprende ver la identificación del producto y la cantidad como parte del encabezado de la orden. Cada base de datos de seguimiento de pedidos que he visto divide los artículos ordenados como una tabla separada, utilizando el ID del pedido como una clave externa, de modo que un solo pedido puede incluir varios productos (o el mismo producto con diversas cantidades, tiempos de entrega, etc. )


No soy purista, así que 3nf es bueno cuando tiene sentido ... pero no tienes que dar por hecho que siempre lo hará.

Desde un punto de vista pragmático, ¿cuál es tu objetivo? Su lista de pros y contras es un buen comienzo. Agregaría algunas ideas más a la lista, como mejor le parezca.

1) ¿ Alguna otra tabla en su base de datos deberá relacionarse (por ejemplo, unirse) a esta información? Ese es el punto de un RDB.

2) ¿Su base de datos crecerá? Incluso si 1 mesa tiene sentido ahora, ¿siempre tendrá sentido? Te arrepentirás si crees que deseas agregar más tablas, y tu tabla no normalizada te está obligando a "solucionarlo", lidiando con filas adicionales devueltas, tiempos de ejecución más lentos, etc.

3) ¿Qué sucede cuando su cliente obtiene una nueva cuenta externa o qué tiene usted? ¿Creará un nuevo disco? ¿Cómo responderá a preguntas como "¿Cuál es el número de cuenta de la gente del cliente?".

...

Creo que, en general, voy por escalable, que en este caso puede significar 3nf. 1 tabla es más fácil de tratar en un ámbito muy limitado, pero si algo cambia alguna vez, se tratará con "¿Cómo divido esta tabla en tablas 3nf correctamente relacionadas, sin desordenar todas las dependencias que se han creado en ¿eso?". Ese no es divertido.


Espero que esto se explique por sí mismo.







maintainability