avis sur la construction d'une table

Bonjour,

je construis une bdd pour quelqu'un qui loue plusieurs appartements (mobil-homes, studio, 2 pièces) dans des villes différentes, à des dates différentes, prix...

J'aimerais votre avis sur la manière de procéder. Faut-il une table par appartement ? Pour faire mes essais en php en local, j'ai construit une table comprenant la ville, dates, prix, images, lien, quantité disponible (il y a plusieurs mobil-homes identiques), libre ou loué...

Merci.

Salut,

certainement pas une table par appartement, imagine la taille de la base d'ici dix ans et le genre de maintenance que ça pourrait engendrer.

Il faut penser d'abord en terme d'entité/association. Pour ce genre de problème, nous avons quoi ? Si on reprend ton énoncé, ça donne « appartement », « type », « location », « ville », « dates », « prix », « images », « lien », « quantité » et « libre »

Je commencerais par éliminer « quantité » : même s'il y a plusieurs exemplaire d'un même appartement, chacun est géré individuellement à de très rarissimes exceptions près. Pour le reste, il faut établir ce qui est une entité de ce qui est une propriété d'une entité. Par exemple, on peut partir du fait que appartement sera une entité : prenons alors les autres mots-clé et demandons-nous si le rapport entre les deux est de 1 à 1, de 1 à plusieurs, ou de plusieurs à plusieur. Prenons « type » : est-ce qu'un appartement appartient à un et un seul type ou bien peut appartenir à plusieurs types ? Et pour l'inverse ? Est-ce qu'un type ne correspond qu'à un et un seul appartement ou bien peut concerner plusieurs appartements ? À priori, à moins que tu n'aies des règles de gestion qui nécessiteraient un système différent, on peut considérer que « type » sera également une entité et le lien sera le suitvant : un appartement appartient à un type et un seul, mais un type peux concerner 0 à n appartements.

Continuons avec les dates : là, il faut être plus précis : les dates de quoi ? S'il s'agit des dates définies à l'étblissement d'un bail, un appartement peut avoir 0 à n date de débt de bail ainsi que 0 à n date de fin de bail, on ne eut donc pas considérer date comme une propriété de appartement, mais en revanche, le lien s'établit automatiquement avec « location » qui serait alors à considérer comme une entité, un appartement pouvant être concerné par 0 à n locations et une location s'appliquant à un et un seul appartement avec une date de début et une date de fin facultative. pour le « prix », c'est en lien direct avec un bail, mais il peut y avoir une subtilité : si le bail se poursuit sur plusieurs années avec une mise à jour du prix annuelle, faut-il conserver l'historique des tarifs utilisés depuis le début du bail ? Selon le cas, ce sera soit une simple propriété de location, soit à mettre comme un élément externe à location même si ça devra y être directement lié, par exemple, on pourrait avoir une entité « période_bail » qui aurait pour propriétés periode_debut, periode_fin et tarif avec un lien direc vers location, une période n'appartenant qu'à une et une seule location, mais une location pouvant comporter 1 à n périodes.

À ce stade, on va déjà avoir déjà quatre tables : je te suggère de continuer ce raisonnement en oubliant jamais un principe fondamental : si ta base est bancale au départ, tu auras beau avoir un gourou de la programmation pour coder la suite, l'applicationcomplète finira tôt ou tard par être tout aussi bancale, ne néglige donc surtout pas cette analyse, la base sera le coeur de ton application.

merci pour la réponse,

je vais prendre le temps de lire et relire et réfléchir et je reviens ver toi. Merci encore.