Nous avons construit un système de planification pour contrôler les rendez-vous de nos clients. Ce système système est similaire à celui utilisé par Prometric pour programmer un examen. Les principaux principales préoccupations sont les suivantes : garantir qu'il n'y a pas de surprogrammation, prendre en charge au moins cent mille rendez-vous. au moins cent mille rendez-vous par mois et permettre d'augmenter/diminuer facilement la capacité du centre d'examen.
Nous avons conçu la conception suivante basée sur les vecteurs de capacité. Nous avons supposé que chaque rendez-vous nécessite au moins cinq minutes. Un vecteur est composé de 288 créneaux (24 heures * 12 créneaux par heure), chacun étant représenté par un octet. Le site vecteur permet au système de représenter jusqu'à 255 rendez-vous toutes les cinq minutes. L'information utilisée est composée de deux vecteurs : un pour stocker la la capacité du centre d'examen (CAPACITÉ NOMINALE) et une autre pour stocker la capacité utilisée (CAPACITÉ UTILISÉE) . Pour récupérer la capacité actuelle (CAPACITÉ ACTUELLE) le système prend la CAPACITE NOMINALE du test et soustrait la CAPACITE UTILISEE.
La base de données a la structure suivante :
CAPACITÉ NOMINALE
La capacité nominale représente la capacité pour les jours ouvrables (lun-ven).
| TEST_CENTER_ID | NOMINAL_CAPACITY
| 1 | 0000001212121212....0000
| 2 | 0000005555555555....0000
...
| N | 0000000000010101....0000
CAPACITÉ UTILISÉE
Ce tableau enregistre la capacité utilisée pour chaque jour / centre de test.
| TEST_CENTER_ID | DATE | USED_CAPACITY
| 1 | 01/01/2010 | 0000001010101010...0000
| 1 | 01/02/2010 | 0000000202020202...0000
| 1 | 01/03/2010 | 0000001010101010...0000
...
| 2 | 01/01/2010 | 0000001010101010...0000
...
| N | 01/01/2010 | 0000000000000000...0000
Après que le client a choisi le centre de test et une date, le système présente les créneaux disponibles en effectuant le calcul suivant. Par exemple :
TEST_CENTER_ID 1
DATE 01/01/2010
NOMINAL_CAPACITY 0000001212121212...0000
USED_CAPACITY 0000001010101010...0000
AVAILABLE_CAPAC 0000000202020202...0000
Si le client décide de prendre un rendez-vous, le système verrouille l'option choisie. jour choisi (une ligne dans le tableau # CAPACITE UTILE) et augmente l'octet correspondant.
Le système fonctionne bien pour l'instant, mais nous prévoyons des problèmes de contention si les nombre de rendez-vous augmente trop.
Est-ce que quelqu'un a un meilleur/un autre modèle pour ce problème ou des suggestions pour l'améliorer ?
Nous avons pensé à éviter la contestation en submergeant la représentation d'un vecteur en heure et en passant à une stratégie de verrouillage optimiste. Par exemple :
| TEST_CENTER_ID | DATE | USED_CAPACITY_0 | USED_CAPACITY_1 | ... | USED_CAPACITY_23
| 1 | 01/01/2010 | 000000101010 | 1010... | ... | ...0000
De cette façon, il ne sera pas nécessaire de verrouiller une rangée et de réduire les événements de collision.