diseño de base de datos - pregunta sobre la eficiencia (y la calidad del diseño general)

Question

Me temo que no sé lo que estoy haciendo.

1:

Tengo una llamada ticket tabla que tiene una columna llamada total. Cuando se actualiza el total de Quiero mantener un registro de ello (un total de edad, etc), así que decidí quitar la columna total y crear una tabla llamada ticket_total con columnas ticket_id, total y datetime (el más reciente, por supuesto, es el Total "actual").

o

2:

Entonces me di cuenta de que más adelante voy a querer dar a mis clientes la posibilidad de ordenar las entradas por total, o informes de tracción que se agregan los totales, etc Por lo tanto, decidí en lugar de volver a poner en la columna de la total ticket, y al cambio la columna de la total directamente cuando se actualiza el total, pero primero crear una fila de ticket_total como un registro de la total anterior.

Parece que la versión 2 sería muy eficiente, ya que no tendría que consultar la tabla ticket_total relacionada tanto, pero me pregunto lo que DB gurús por ahí piensan. Estoy aprendiendo diseño de base de datos y temer que nunca voy a ser bueno en él.

Answer 1

Me gustaría ir con la opción 2 que usted ha sugerido.

Sólo asegúrese de que usted está haciendo la actualización (de entrada) + Insert (en ticket_total) en una transacción para asegurar que la integridad se mantiene.

Answer 2

Su segunda alternativa es más rápido, pero si desea crear informes sobre los valores históricos del total, usted debe debe tener una tabla separada en la que almacena el valor que está reemplazando junto con una marca de tiempo. Este tipo de tabla se denomina tabla de auditoría .

Answer 3

Re: "eficiencia" - mejor es no preocuparse demasiado acerca de la eficiencia de la base de datos al comienzo de un proyecto. La optimización prematura es un error común a evitar.

Una mejor es centrarse en sus necesidades y el diseño de ellos. Más tarde, se puede probar para ver si donde los cuellos de botella de rendimiento son y trabajar en la solución de ellos.

Para las bases de datos más pequeñas (decenas de miles de filas), incluso consultas "ineficientes" a menudo van más servidores y de hoy dado muy rápido software.

Debe ser sencillo Le sugiero que evitar sobrecargar teclas de combinación y la semántica de mesa a menos que realmente tienen la necesidad.

Propuesta Tiene dos tipos de datos:. Información sobre las entradas de corriente, y una tabla de historia de los viejos valores "total"

Así que su ver se preferiría 2.

ticket
  id
  field_a
  field_b
  total    # current_total

ticket_total  # history of ticket total field
  id
  ticket_id
  total
  create_time

también sonidos "total" como una agregación de algo. Sugiero que se intenta llegar a un nombre de campo que es más descriptivo. - ¿Cuál es el campo de un total de? "Total_worktime"?

añadido Recuerde agregar índices de las tablas. Índice por cualquier cosa que se utiliza para los hallazgos. Por ejemplo, no la mesa de entradas tienen un customer_id? Asegúrese de que está indexado.

Answer 4

Me gustaría hacer ticket_total una vista, no una mesa. Me gustaría crear otra vista ticket_current dónde iba a filtrar los boletos por la fecha más reciente, es decir, si la mesa de la entrada es de doble llave en TICKET_ID y de fecha y hora. Si no es así, hay que saltarse la última parte.