Besoin conseils pour optimiser des requetes lourdes !!Résolu

Question

Bonjour à tous,

 
Je désire développer un système de réservations par calendrier pour un
site où les gens peuvent annoncer leurs maisons, villas à louer.

J'aimerais avoir l'avis de gens qui s'y connaissent bien en structure de base de données.

Le système doit pouvoir indiquer certains jours qui sont libres, et d'autres où c'est déjà loué.

J'ai donc une table comme celle-ci:

adId - ID de l'annonce  (index)
date - le jour correspondant
status - Loue, ou pas loue le jour de la date ci dessus

avec 365 rangées pour tous les jours de l'année suivant le jour d'aujourd'hui.


Je
pensais peut-être utiliser des périodes de jours (debut / fin) à la
place, mais évidemment ça ne peut pas marcher très bien, parce que dès
que l'utilisateur va vouloir modifier le status de certains jours, ça
va devenir compliqué et en plus inutile de faire ça comme ça.

Me voilà donc avec ce systeme d'enregistrement qui comporte 365 rangées de données par maison à louer. 

Admettons que j'arrive avec 5 000 clients qui louent chacun une maison, 
ça me donne 1 825 000 lignes de données, c'est énorme...

Sachant
que lorsque quelqu'un visite la page de la maison à louer, je fais un
SELECT du numero de l'annonce pour pouvoir montrer un calendrier des
dates demandées pour voir si elles sont libres ou pas.

..
j'aimerais savoir si mon application s'en trouvera ralentie, et si oui,
à quel point... et si vous avez une idée de comment faire ça à la place
ne vous gênez pas pour me le dire,

merci !!

malalam · Accepted Answer

Hello,

juste une remarque : pourquoi stockes-tu en base de données les jours ou ta maison est libre...? Si tu ne stockais que les jours d'occupation, et que dans ton application, tu remplisses les blancs, tu allègerais sérieusement ta base. Très sérieusement.
Maintenant 1 825 000 lignes, c'est très gérable si ta table est bien indexé. ce qui me fait bcp plus peur, c'est quand tu parles de 365 rangées : tu as une table avec 368 champs...?
Si oui, l'idée est mauvaise.
A minima, pour faire simple :
1 table d'annonces (id annonce, lieu, etc...texte annonce...id utilisateur tant qu'à faire)
1 table "calendrier" avec juste l'id de ton annonce, et une date (d'occupation, j'insiste...).
1 table utilisateur (id utilisateur, infos diverses utilisateur)

codefalse · Answer

Je dirai comme Malalam, tu met dans une table tes données des jours réservés, et pour l'affichage du calendrier, tu récupere les dates, les dates réservées, et tu les compares, et hop :)

g0ldstein · Answer

Bonjour,
très bien merci pour l'idée des jours dont l'occupation n'est pas spécifiée, ça va certainement alléger le tout, je doute que les utilisateurs les remplissent tous. Peut-être même que certain ne géront pas du tout le calendrier.

Malalam, le truc c'est que j'utilise le composant AdsManager pour Joomla, je sais pas si tu connais. Donc il y a une table pour les annonces et pour plein d'autres trucs. Moi je fais un module pour que les user gèrent leur calendrier, et donc il n'y a en effet que très peu de champs, 3 (ceux dans mon post de depart). 

Ça me rassure que tu dises que ça soit bien gérable. Je ne met qu'un index sur le adId (ID de l'annonce) pour l'instant, crois tu que je devrais en mettre un sur la date aussi? C'est vrai que les index ralentissent les UPDATE ? Que me conseilles-tu?

Merci infiniment pour vos réponses très constructives.

g0ldstein · Answer

up

malalam · Answer

Je ne connais que très mal Joomla et "up" ne sert à rien si ce n'est à spammer les gens qui se sont inscrits à ton post...j'avais déjà vu ton message.
Je ne suis pas convaincu qu'ujn index ralentisse un update. Mais bon, si tu l'as lu, c'est peut-être vrai : pose-toi la question...vas-tu faire plus d'update que de select...?

g0ldstein · Answer

Désolé, je ne pensais pas que ça envoyait un courriel à chaque nouveau message.
Merci pour ta réponse !

Besoin conseils pour optimiser des requetes lourdes !!

6 réponses

Votre réponse

Discussions similaires