Base de datos de pregunta de diseño - que es la mejor solución?

Question

Estoy usando Firebird 2.1 y estoy buscando la mejor manera de resolver este problema.

Estoy escribiendo una aplicación de calendario. entradas de la agenda de los diferentes usuarios se almacenan en una tabla Calendario grande. Cada entrada de agenda puede tener un conjunto de recordatorio -. Sólo un recordatorio / entrada

Estadísticamente, la mesa Calendario podría crecer a cientos de miles de registros a través del tiempo, mientras que no van a ser mucho menos recordatorios.

necesito para consultar los recordatorios sobre una base constante.

¿Cuál es la mejor opción?

a) almacenar información de los recordatorios en la tabla de calendario (en cuyo caso voy a la consulta cientos de miles de registros de IsReminder = 1)

B) Crear una tabla Recordatorios separada que contiene sólo el ID de entradas de calendario que tienen establecer recordatorios, luego volver a consultar las dos tablas con una operación de combinación (o tal vez crear una vista en ellos)

C) que puede almacenar toda la información acerca de los recordatorios en la tabla Recordatorios, y luego consulta sólo esta tabla. La desventaja es que alguna información necesita ser duplicado en ambas tablas, al igual que con el fin de mostrar el recordatorio, voy a tener que conocer y almacenar starttime del evento en la tabla Recordatorios - por lo tanto estoy manteniendo dos tablas con los mismos valores.

¿Qué opinas?

Y una pregunta más: La tabla Calendario contendrá el calendario de múltiples usuarios, separados sólo por un campo ID de usuario. Como no puede haber sólo 4-5 usuarios, incluso si pongo un índice en este campo, su selectividad va a ser muy malo - que no es bueno para una mesa con cientos de miles de registros. ¿Hay una solución aquí?

Gracias!

Answer 1

Hay ventajas y desventajas para las tres opciones. Whis uno es mejor depende de detalles que no han proporcionado. En general, no se preocupe demasiado acerca de la selección de tres o cuatro entradas de cien mil, siempre y cuando los índices que ha configurado permiten la estrategia de recuperación de la derecha. Si no entienden la indexación, es muy probable que estar en problemas, no importa cuál de las tres decisiones que tome.

Si fuera yo, me gustaría ir con la opción B. También me almacenar cualquier atributos de un recordatorio en la tabla de recordatorios.

Tenga mucho cuidado acerca de si se identifica un evento por EventId solo o por (identificación de usuario, EventId). Si elige esta última, le corresponde a utilizar una clave primaria compuesta para la tabla de eventos. No se preocupe demasiado acerca de las claves primarias compuestas, especialmente con Firebird.
Si se declara una clave primaria compuesta, tenga en cuenta que la declaración (identificación de usuario, EventId) no tendrá las mismas consecuencias que declarar (EventId, identificación de usuario). Ellos son lógicamente equivalentes, pero la estructura del índice generado automáticamente serán diferentes en los dos casos.

Esto a su vez afectará a la velocidad de las consultas como "encontrar todos los recordatorios para un usuario determinado".

Una vez más, si fuera yo, yo evitaría opción C, la introducción de la redundancia perjudicial en un esquema lleva consigo la responsabilidad de una programación muy cuidadosa cuando se va a actualizar los datos. De lo contrario, puede terminar con una base de datos que almacena las versiones contradictorias de un mismo hecho en diferentes lugares de la base de datos.

Y, si realmente quiere saber el efecto sobre perfromance, tratar las tres maneras, carga con los datos de prueba, y hacer sus propios puntos de referencia.

Answer 2

creo que necesita para crear, datos de usuario falsas realistas y medir la diferencia con algunas consultas típicas que se pueden esperar para funcionar.

La indexación, optimización de la consulta y los tipos de resultados de la consulta que necesita puede hacer una gran diferencia, así que no es fácil decir qué es lo mejor sin saber más.

Answer 3

Al elegir la opción (a), debe

• proporcionan un índice en "IsReminder" (o un índice combinado de IsReminder, identificación de usuario, lo que se adecue mejor a sus consultas destinadas)
• Asegúrese de que sus consultas utilizan este índice

La opción B es preferible a A si usted tiene más de una bandera booleana para cada recordatorio para tienda (por ejemplo, el número de minutos que el usuario se notificará antes del evento). Debería, sin embargo, hacer un poco de adivinar qué frecuencia en su programa, tendrá que unir las dos tablas.

Si es posible, evite la opción C. Si no desea referencia los tres casos, sugiero empezar con A o B, de acuerdo con las circunstancias descritas, y probablemente la solución que elija será lo suficientemente rápido, por lo que no tiene que molestarse con los otros casos.