Commentaires sur diagramme

[MaxLap]

Salut, j'ai regardé un peu ton diagramme. Je sais pas s'il devait être final, alors peut-être que tu as déjà remarqué certains des commentaires. Pour rendre le suivi plus facile, je mets une image du diagramme, donc si tu fais un changement, mes commentaires vont être cohérent quand même.

Si tu as des questions, hésites pas, par chat, en réponse à ici, ou on peut s'organiser un appel par chat.

La première chose qui me saute aux yeux est du naming:

• On met toujours le id après le nom du truc pour les foreign key. Donc pas id_room mais plutôt room_id. C'est le standard en rails.
• Les nom de tables sont toujours au pluriel. Donc rooms, adjacent_rooms, room_views, room_types, users, reservation_rooms.
• mettre first_name plutôt que firstname.
• Sur la table reservations, je ne sais pas ce qu'est sold et read.

Maintenant, point de vue plus structurel:

• À quoi sert le id_adjacent_room qui est sur la table Rooms?
• Pour la gestion de haute et base saison, gardons les choses simples: laissons toute l'information dans les room_pricings plutôt que d'avoir 2 tables qui interagissent. C'est possiblement
• Les specs mentionnent qu'il doit être possible de modifier les prix des chambres. Il faudrait penser a ce qui va se passer si une chambre a été loué, puis qu'on veut changer le prix de la chambre pour les futures réservations.

Autre détails:

• Tu n'as pas à faire de système de login. Donc tu n'as pas à avoir de password dans le système. (On considère que c'est trop de travail pour se battre avec Rails ou une Gem d'authentification sans vraiment apprendre quoi que se soit). Sur cette logique là, je renommerais donc Users à Customers.

[CebDev]

Merci pour ton retour.

Effectivement, j'ai encore un peu de mal avec les conventions de naming. Pour les noms des tables, je corrige deja ca au fur et a mesure quand je les cree.

"Sur la table reservations, je ne sais pas ce qu'est sold et read."

• sold etait prevu pour valider le paiement de la reservation, j'allais justement demander si il fallait gerer cet aspect
• read etait juste un feature pour notifier sur le dashboard les nouvelles reservations recues et non consultees. Je vais le retirer.

_"À quoi sert le id_adjacentroom qui est sur la table Rooms?" J'avais prevu cette table pour gerer la contrainte de chambres contigues sans imposer un numerotation des chambres particulieres. Ca te parait inutile ?

Pour le gestion du pricing et la conservation de son historique, les tables Room_pricings et Rate_periods ont un attribut archived qui ne figurent pas sur la version du diagram que tu as consulte. En cas de modification de tarif des chambres ou un changement de politique pour les hautes et basses saisons, les FK precedents restent les memes et pour les prochaines reservations le tarif se basera sur les donnees les plus recentes. Aujourd'hui je travaillais justement sur la partie des hautes et basses saisons.

Je note pour la gestion des users.

Desole pour le texte sans accents mais je suis sur un clavier US et sur ma VM, je n'arrive pas a configurer un clavier internationnal :(

[MaxLap]

Pour sold: C'est certain que d'avoir le prix réel de la réservation qui serait gardé en DB est bien. Dans ce cas, c'est juste que le nom de la colonne n'est pas clair. Nommer les choses correctement est très important. Un nom clair permet de faire du code clair et le rend plus facile à lire/comprendre pour d'autres développeurs (ou pour toi-même lorsque tu repasses dans le code quelques mois plus tard). Déjà, le nom sold rend difficile de juste imaginer le type de la donnée, ça sonne comme un boolean. Un nom comme total_price rend ça vraiment plus clair. (hint: c'est peut-être aussi quelque chose qu'on pourrait vouloir aileur dans le système aussi.)

Pour read: Puisque ce n'est pas un requis pour l'instant, je pense que j'éviterais d'ajouter des distractions de plus. Mais juste pour fin d'apprentissage, mettre ça directement sur la réservation signifie que si l'un de plusieurs employés le "read", les autres ne le verraient plus. Ce n'est pas clair que ce serait le comportement désiré, donc disons qu'il y aurait des questions à pauser pour évaluer comment un tel système devrait fonctionner.

Pour le id_adjacent_room. Tu as la table adjacent_rooms qui a 2 attributs qui pointent sur room. Ça je comprends. C'est de l'attribut id_adjacent_room sur la table rooms que j'ai des questions. Qu'est-ce que tu va mettre là dedans? Ça ne peut pointer que sur une rangée dans la table adjacent_rooms.

D'accord pour le pricing. Je te laisse repasser là dessus pour simplifier. N'oublie pas que tu peux aussi poser des questions sur quelle comportement est préférable si tu vois plusieurs options qui semble répondre aux specs. Elles sont volontairement pas précises à 100%, pour vous faire creuser et vous permettre de vous exprimer.

Autre petit commentaire, au lieu de archived, qui sonne comme un boolean (et c'était probablement ton plan), je te suggère de plutôt la nommer archived_at et d'en faire un timestamp de quand l'archivage a eu lieu. Ça facilite la tracabilité.

[CebDev]

_"Pour le id_adjacent_room. Tu as la table adjacent_rooms qui a 2 attributs qui pointent sur room. Ça je comprends. C'est de l'attribut id_adjacent_room sur la table rooms que j'ai des questions. Qu'est-ce que tu va mettre là dedans? Ça ne peut pointer que sur une rangée dans la table adjacentrooms."

Effectivement ce field n'a rien à faire là. Un moment dégarement !

J'ai corrigé le naming, apporté quelques corrections et revu la shéma. Cela te parait-il plus cohérent ?

J'avais déjà créé la table et les actions pour rate_periods. La solution pour effacer ça de mon projet est elle de créer un nouveau fichier de migration avec un drop table ou quelque chose du genre ?

[MaxLap]

Oui, ça me semble mieux

Désolé du délai de réponse, j'ai eu une panne de courant en PM.

Comme tu es au début du projet et que rien est en production, le plus simple est de juste effacer la migration que tu avais et de recréer la base de donnée.

[CebDev]

Pas de souci, merci