J'ai fait quelques recherches et j'ai découvert que je devais enregistrer un itinéraire comme une séquence d'arrêts. Quelque chose comme:
Start -> Stop A -> Stop B -> Stop C -> EndJ'ai créé trois tableaux:
- Itinéraires
- Arrête
- RouteStops
... où RouteStops est une table de jonction.
J'ai quelque chose comme:
Itinéraires
+---------+
| routeId |
+---------+
| 1 |
+---------+
| 2 |
+---------+Gares
+-----------+------+
| stationId | Name |
+-----------+------+
| 1 | A |
+-----------+------+
| 2 | B |
+-----------+------+
| 3 | C |
+-----------+------+
| 4 | D |
+-----------+------+RouteStations
+-------------+---------------+
| routeId(fk) | stationId(fk) |
+-------------+---------------+
| 1 | A |
+-------------+---------------+
| 1 | C |
+-------------+---------------+
| 1 | D |
+-------------+---------------+
| 2 | A |
+-------------+---------------+
| 2 | D |
+-------------+---------------+La route 1 passe
Station A -> Station C -> Station DLa route 2 passe
Station A -> Station DEst-ce un bon moyen de stocker des itinéraires?
Selon Wikipedia :
[...] le système de base de données ne garantit aucun ordre des lignes sauf si une
ORDER BYclause est spécifiée [...]
Puis-je compter sur un tel schéma de base de données ou peut-être que cela devrait être fait différemment?
C'est en fait mon projet universitaire, donc je me demande simplement si un tel schéma peut être considéré comme correct. Dans ce cas, je ne stockerais probablement que plusieurs itinéraires (environ 3-5) et stations (environ 10-15), chaque itinéraire sera composé d'environ 5 stations. Je serais également heureux d'entendre à quoi cela devrait ressembler dans le cas d'une véritable et grande compagnie de bus.
la source
Réponses:
Pour toute analyse commerciale menant à l'architecture de base de données, je recommande d'écrire des règles:
Les 1re et 2e règles, comme vous l'avez remarqué, impliquent une relation plusieurs à plusieurs, vous avez donc conclu à juste titre à créer routeStations.
La troisième règle est intéressante. Cela implique qu'une colonne supplémentaire est nécessaire pour répondre à l'exigence. Où cela devrait-il aller? Nous pouvons voir que cette propriété dépend de la route ET de la station. Par conséquent, il doit être situé dans routeStations.
J'ajouterais une colonne au tableau routeStations appelée "stationOrder".
L'interrogation devient alors facile:
Remarques:
Pour développer sur la note 3, j'ai construit le cas d'utilisation:
Il s'agit d'Oracle 12c Enterprise.
Notez que dans le plan d'exécution ci-dessous, les routes de table ne sont pas utilisées du tout. l'Optimiseur de base de coûts (CBO) sait qu'il peut obtenir le routeId directement à partir de la clé primaire de routeStations (étape 5, INDEX RANGE SCAN sur ROUTESTATIONS_PK, Predicate Information 5 - access ("RS". "ROUTEID" = 1))
Maintenant, la partie amusante, ajoutons un nom de colonne à la table de routage. Il y a maintenant une colonne dont nous avons réellement besoin dans "routes". Le CBO utilise l'index pour trouver le rowID de la route 1, puis accède à la table (accès à la table par index rowid) et saisit la colonne "routes.name".
la source
Vous avez raison, il n'y a pas d'ordre d'enregistrement inhérent dans une table relationnelle. Cela signifie que vous devez fournir un moyen explicite de commander des stations sur chaque itinéraire.
Selon la façon dont vous prévoyez d'accéder aux données que vous pourriez
sequenceNumbercolonne àRouteStationspour stocker, évidemment, la séquence de chaque station dans chaque itinéraire.nextStationIdcolonne pour stocker un "pointeur" vers la station suivante dans chaque itinéraire.la source
Je n'ai vu personne dire quoi que ce soit à ce sujet, alors j'ai pensé que j'ajouterais pour votre note. Je placerais également un index Unique non clusterisé (en fonction de votre SGBDR) sur la table RouteStations / RouteStops sur les trois colonnes. De cette façon, vous ne pourrez pas faire d'erreurs et le bus se rendra aux 2 stations suivantes. Cela rendra les mises à jour plus difficiles, mais je pense que cela devrait toujours être considéré comme faisant partie d'un bon design.
la source
Je parle en tant que programmeur d'applications :
Ne pensez même pas à faire du routage ou des horaires avec des requêtes sur la base de données (ou dans un proc stocké), cela ne sera jamais assez rapide. ( À moins que ce ne soit qu'un problème de «devoirs». )
Même pour une application qui traite les données en mémoire, le chargement des données de la base de données ne sera jamais rapide à moins que toutes les données soient chargées au démarrage ou que les données soient stockées sous une forme démoralisée. Une fois les données démoralisées, il est inutile d'utiliser une base de données relationnelle.
Par conséquent, je penserais que la base de données est la copie «principale» des données et accepterais que je devrai également la stocker prétraitée dans la mémoire de l'application ou sur un serveur d'encaissement comme membase.
La réponse de ndefontenay donne un bon design de table comme point de départ, mais vous devez considérer que les itinéraires ont des horaires différents en fonction de l'heure de la journée et ont souvent des arrêts différents en fonction de l'heure, du jour de la semaine ou même des vacances scolaires.
la source