Comme la plupart des commentaires l'indiquent, c'est généralement une mauvaise idée de coder toutes les données dans une chaîne qui n'a pratiquement aucun sens pour la base de données. Il est généralement préférable de définir les éléments de données et leurs relations et de représenter ces structures dans la base de données. Le Wikipedia article on data models est un bon aperçu de ce qui est impliqué (bien que ce soit plus général que ce dont vous avez besoin). Le problème que vous décrivez semble assez simple pour que vous puissiez le faire avec un crayon et du papier. Une manière de commencer est d'écrire une liste de relations logiques entre les concepts de votre problème. Par exemple, la liste peut ressembler à ceci (vos règles peuvent être différentes):
- Chaque employé suit un horaire unique.
- Chaque employé a un prénom et un nom, ainsi qu'une identification d'employé. Différents employés peuvent avoir le même nom, mais l'ID de chaque employé est unique à cet employé.
- Un horaire comporte un jour de début et de fin de la semaine ainsi qu'une heure de début et de fin de journée.
- L'heure de début et de fin est la même pour tous les jours de l'horaire.
- Plusieurs employés peuvent être dans le même horaire.
De cela, vous pouvez lister les noms utilisés dans les règles. Ce sont des candidats pour les entités (colonnes) dans la base de données:
- employé
- ID employé
- prénom de l'employé
- employé nom
- Horaire
- Horaire début jour
- Horaire de départ
- Horaire fin de la journée
- heure de fin Horaire
Pour les règles que j'ai énuméré, les horaires semblent exister indépendamment des employés.Comme il faut être un moyen d'identification qui l'employée suit, il est logique d'ajouter une entité:
Si vous regardez ensuite les verbes dans les règles ("suit "," a ", etc.), vous commencez à maîtriser les relations. Je regrouperais tout jusqu'à présent dans deux relations:
Employees
ID
first_name
last_name
schedule_ID
Schedules
ID
start_day
start_time
end_day
end_time
Cela semble être tout ce dont on a besoin en termes de structures de données. (Une alternative raisonnable à start_day et end_day pour la table Schedules serait un champ booléen pour chaque jour de la semaine.) L'étape suivante consiste à concevoir les index. Ceci est motivé par les requêtes que vous vous attendez à faire. Vous pouvez vous attendre à rechercher les éléments suivants:
- Quel horaire est employé avec ID = xyz suivant?
- Qui est au travail le lundi à midi?
- Quels jours n'ont personne au travail?
Étant donné que les employés et les horaires sont identifiés de manière unique par leurs ID respectifs, ils doivent être les champs primaires de leurs tables respectives. Vous souhaitez également avoir des règles de cohérence pour les données. (Par exemple, vous ne voulez pas un employé sur une planification qui n'est pas définie.) Cela peut être géré en définissant une relation "clé étrangère" entre le champ Employees.schedule_ID et le champ Schedules.ID, ce qui signifie que Employees.schedule_ID doit être indexé. Cependant, puisque les employés peuvent partager le même horaire, il ne devrait pas être un index unique.
Si vous avez besoin de rechercher des horaires par jour de la semaine et heure de la journée, ceux-ci pourraient également valoir la peine d'être indexés. Enfin, si vous voulez rechercher les employés par leur nom, ces champs devraient peut-être aussi être indexés.
Veuillez ne pas le stocker comme une chaîne "cryptée". –
J'espère que vous croyez que vous voulez dire modèle. –
Peut-être qu'il veut dire "encoder" et "décoder"? –