2

J'ai une application où j'aurai des évènements récurrents. Ainsi un événement peut se répéter par jour, "tous les n jours", par semaine, "toutes les n semaines le lundi/mardi/mercredi/etc", et par mois, "tous les n mois les 1er, 2e, 3e, etc."Architecture MySQL: colonnes nulles vs. jointures

Quelle est la meilleure façon de gérer cela dans une perspective de conception de table? Je peux penser à deux façons, mais je ne suis pas sûr de savoir lequel est le meilleur.

1) 5 colonnes pour le tableau ci-dessus, 1 pour le jour et 2 pour la semaine et le mois. Celui qui n'est pas utilisé serait nul. Dans mon application, je pouvais voir les null et choisir de les ignorer.

2) Avoir une seconde table, par exemple events_dateinfo ou quelque chose, contre laquelle je m'associerais pour la requête.

On dirait que l'option 2 est probablement plus «normalisée» et ce n'est pas le cas, mais cela vous semble-t-il trop compliqué pour une chose si simple? En outre, si je devais passer à l'option 2, existe-t-il un moyen de traduire les lignes en colonnes, c'est-à-dire de sélectionner les attributs de 2 semaines pour un événement spécifique et de les traiter comme des colonnes?

Répondre

1

Si j'ai compris que le bon événement peut avoir plus d'un programme (c'est pourquoi vous voulez "traduire les lignes en colonnes").

Vous n'aurez pas besoin de 2 mais 3 tables dans ce cas; le troisième doit être la table de jonction. Vous pouvez facilement ajouter de nouveaux horaires si vous avez besoin dans le futur avec ce schéma. Donc, quelque chose comme ceci:

table events (event_id, event_name, description) 
table schedules (sch_id, schedule) 
table event_schedule (event_id, sch_id) 

Il n'y a pas de possibilité PIVOT dans MySQL comme je sais, mais vous pouvez utiliser la fonction GROUP_CONCAT() dans SELECT; ce sera une ligne par événement et tous les horaires pour un événement seront dans une colonne.

SELECT e.event_name AS Event, GROUP_CONCAT(s.schedule SEPARATOR ', ') AS Schedule 
     FROM events e 
    (LEFT) JOIN event_schedule es 
    ON e.event_id = es.event_id 
    JOIN schedules s 
    ON s.sch_id = es. sch_id 
     GROUP BY e.event_name; 
0

Je préférerais gérer ce normalisé, les événements dans une table, et la récurrence des événements dans un autre.

En manipulant les index de manière appropriée, vous pouvez gérer la demande de données via des vues ou, si les données sont plus grandes, sous la forme d'une table d'audit avec des déclencheurs.