De quelles associations ai-je besoin entre les modèles dans ce scénario?

Question

Je fais un système de réservation en utilisant des rails.

J'ai 3 modèles - visiteurs, chambres et réservations.

Les visiteurs peuvent rester dans les chambres.

Une réservation peut avoir beaucoup de visiteurs et être dans de nombreuses chambres (ou partagée). Une réservation a également une date de début/fin.

Les visiteurs pourraient potentiellement se déplacer entre les pièces d'une réservation, et les dates de début/fin de ces allocations de salle devraient être connues.

Une seule table de jointure suffirait-elle ici? C'est à dire. visitor_id, room_id, booking_id?

Ou à quoi ressembleraient les associations entre ces modèles? Aurais-je besoin de tables supplémentaires, c'est-à-dire l'allocation des chambres.

Merci beaucoup.

Answer 1

Je pense que vous devriez avoir une table room_allocations.

Answer 2

Les visiteurs pourraient se déplacer entre les chambres dans une réservation et les dates de début/fin de ces chambres allocations devraient être connues.

Est-il possible de créer une nouvelle réservation si le visiteur change de chambre? Dans ce cas, vous n'avez pas besoin de la table supplémentaire.

Answer 3

Une réservation peut avoir de nombreux visiteurs et être dans de nombreuses chambres (ou partagé). Une réservation a également une date de début/fin.

On ne sait pas ce que vous voulez dire par «ou partagé».

Sinon, une procédure générale consiste à lister vos entités, puis à définir des relations entre elles. Il serait quelque chose comme ça - et je ne cherche pas à donner des réponses définitives, mais pour illustrer comment y penser pourrait aller:

Entités

d'abord essayer de définir vos attributs et les regrouper en entités . Faire un dictionnaire de données est agréable, surtout si vous travaillez en équipe.

Relations

Essayez d'être précis - en disant que la réservation peut avoir est moins utile beaucoup de visiteurs par rapport à la relation donnant un nom (sémantique est- très important dans la conception du système).

Disant réservation faite par visiteur (s)/visiteur (s) réservé une réservation est mieux, parce que vous, il vous permet de distinguer entre une relation avec un nom: réservation est faite pour les visiteurs/visiteurs réservés (et vous aide également à comprendre si vous avez les deux et aide à déterminer la cardinalité, les nommer dans les deux sens peut aussi aider, même si parfois vous vous retrouvez avec un langage maladroit - qui pourrait ou non indiquer des problèmes de conception, par exemple ici ) réservé une réservation semble mauvais et me fait douter si la réservation n'est pas une table de relation en soi - un weak entity). Donc, si vous partez et nommez toutes les relations, nous pourrions vous répondre beaucoup plus précisément.

Remarque: Avoir un trois voies beaucoup à plusieurs table de relation peut être dénormalisé dans un non-trivial way. Et l'une des raisons pour lesquelles la normalisation est très importante n'est pas d'avoir une conception de base de données belle et idéaliste, mais de pouvoir gérer les incohérences potentielles dans votre base de données (comme si vous décidiez d'avoir un design dénormalisé pourrait représenter, qui sont assez évident jusqu'à 3NF).

Answer 4

Quelque chose comme cela devrait vous aider à démarrer:

Il existe des moyens probablement plus nets pour couvrir Réservation & Réservation Chambre. En termes d'OO, vous pouvez le modéliser en utilisant le modèle composite. Cela rendrait probablement la logique plus propre. Vous aurez toujours besoin de mapper aux tables bien sûr; Le fait de savoir si cela vaut la peine d'explorer dépend des besoins plus larges de votre application.

hth.