La mejor manera de almacenar tiempos de eventos en la base de datos (My) SQL

Question

Estoy tratando de decidir la mejor manera de almacenar los tiempos de eventos en una base de datos MySQL. Deben ser lo más flexibles posible y representar "eventos únicos" (comienza en un momento determinado, no necesariamente necesita una hora de finalización), eventos de "todo el día" y "días múltiples", eventos repetidos, eventos repetidos todos los días , posiblemente, eventos del tipo "3er sábado del mes", etc.

Por favor, sugiera algunos esquemas de bases de datos probados y comprobados.

Answer 1

Igual que el cron ¿verdad? Grabando tanto el tiempo de inicio como el de finalización de esa manera.

Answer 2

Tabla: Eventos

• StartTime (dateTime)
• EndTime (dateTime) null para ningún momento final
• RepeatUnit (int) null = noRepeat, 1 = horas, 2 = día, 3 = semanas, 4 = DAYOFMONTH, 5 = mes 6 = año
• NthDayOfMonth (int)
• RepeatMultiple (int), por ejemplo, establecer RepeatUnit a 3, y esto a 2 para cada quince días
• Id: si es necesario, StartTime podría ser adecuado para identificar un evento de manera única.
• Nombre (cadena) - nombre dado al evento, si es necesario

Esto podría ayudar. Se requeriría una cantidad decente de código para interpretar cuando las repeticiones son. Partes de los campos de tiempo que están en resoluciones más bajas que la unidad de repetición tendrían que ser ignoradas. Hacer el tercer sábado del mes tampoco sería fácil ... la información de NthDayOfMonth sería necesaria solo para realizar este tipo de funcionalidad.

El esquema de la base de datos requerido para esto es simple en comparación con el código requerido para determinar dónde caen las repeticiones.

Answer 3

Necesita dos tablas. Uno para almacenar los eventos repetitivos (repeatevent de mesa) y otro para almacenar los eventos (evento de mesa). Las entradas simples solo se almacenan en la tabla de eventos. Las entradas repetitivas se almacenan en la tabla repeatevent y todas las entradas individuales para el evento repetido también se almacenan en la tabla de eventos. Esto significa que cada vez que ingresa una entrada que se repite, debe ingresar todas las entradas individuales resultantes. Puede hacerlo mediante el uso de activadores o como parte de su lógica comercial.

La ventaja de este enfoque es que los eventos de consulta son simples. Todos están en la mesa del evento. Sin el almacenamiento de eventos repetitivos en la tabla de eventos, tendría una compleja lógica SQL o empresarial que haría que su sistema fuera más lento.

create table repeatevent (
id int not null auto_increment, 
type int, // 0: daily, 1:weekly, 2: monthly, .... 
starttime datetime not null, // starttime of the first event of the repetition 
endtime datetime, // endtime of the first event of the repetition 
allday int, // 0: no, 1: yes 
until datetime, // endtime of the last event of the repetition 
description varchar(30) 
) 

create table event (
id int not null auto_increment, 
repeatevent null references repeatevent, // filled if created as part of a repeating event 
starttime datetime not null, 
endtime datetime, 
allday int, 
description varchar(30) 
) 

Answer 4

Trabajé en una aplicación de planificador que sigue vagamente el estándar iCalendar (para grabar eventos). Le recomendamos que lea RFC 2445 o este esquema publicado por Apple Inc. icalendar schema para ver si son relevantes para el problema.

mi esquema de base (evento recurrente/todo el día no fue considerado en el momento)

event (event_id, # primary key 
     dtstart, 
     dtend, 
     summary, 
     categories, 
     class, 
     priority, 
     summary, 
     transp, 
     created, 
     calendar_id, # foreign key 
     status, 
     organizer_id, # foreign key 
     comment, 
     last_modified, 
     location, 
     uid); 

la clave externa calendar_id en la tabla anterior se refiere este

calendar(calendar_id, # primary key 
     name); 

mientras organizer_id se refiere el presente (con otras propiedades como el nombre común, etc. faltante)

organizer(organizer_id, # primary key 
      name); 

Otra documentación que puede resultar más fácil de leer se encuentra here

esperanza esto ayuda

Answer 5

Uso de fecha y hora y de MySQL construido en función NOW(). Cree el registro cuando comience el proceso, actualice su columna que rastrea el tiempo de finalización cuando finaliza el proceso.