Discussion :

[afourti]

Bonjour,

Voila je cherche à faire un design de base de données pour un système de management d’hôtel pour 3 sites différents et je cherche le moyen le plus performant pour faire ça :

1. Je crée une base pour chaque site
2. Je crée une seule base pour tout le monde mais du coup je ne sais pas comment faire pour gérer les droits...

Le contraintes :
chaque hôtel ne doit voir que ses propres logements mais peut avoir accès aux informations clients
Il y a 3-4 personne qui doivent avoir accès à tout les clients et toute la disponibilité pour pouvoir saisir les réservations
il y a une commerciale qui doit avoir accès à tout également

La deuxième solution me parait la plus pratique mais les droits.....je sais pas trop :p

Un conseil svp?

Merci bcp

[Artemus24]

Salut afourti.

Y-a-t-il un quelconque intérêt de tout centraliser dans une seule base de données ?

La volumétrie est-elle une contrainte que tu peux rencontrer ?
Question performance, est-ce aussi un point délicat ou pas ?
La question de la sécurité. A ne pas négliger non plus.

As-tu déjà chiffrer ces trois points ci-dessus ? C'est primordiale avant de faire quoi que ce soit d'autre !

Quand tu parles de site, dois-je comprendre qui tu héberges en local, dans l'hotel ? Ou bien chez un hébergeur distant ?
Est-ce toi qui va prendre la décision du choix du matériel ? Ou bien, c'est hors de propos car tu as déjà trouvé un hébergeur ?

Après avoir créé tes sites, qui va les gérer ? Est-ce encore toi, ou bien un administrateur par hotel ?

Mais la première question et la plus importante que tu dois te poser, est le choix du SGBDR !
Je suppose que ton choix s'est porté sur MySql car tu le connais.

Si la question de la performance est primordiale, il faudrait envisager un autre SGBDR.
Car MySql n'est pas très adapté quand la volumétrie devient gigantesque.

Question des droits d'accès, ce n'est pas un problème. Un bon SGBD sait gérer cela facilement, même MySql.
Vas-tu descendre au niveau de la colonne dans ta table ou juste au niveau des tables ?

Es-tu assez familiarisé avec les View ? Car la View est destiné à gérer les droits d'accès dans ton cas.
As-tu déjà défini les types de populations qui vont accéder à ta base de données ?

Sinon, as-tu la connaissance système pour bien configurer et paramétrer ton futur SGBD ?
Il ne s'agit pas juste de créer une base de données qui fonctionne en test.
Il s'agit surtout de faire les bons choix dès le départ, pour ne pas avoir à le regretter par la suite.

As-tu aussi envisager les sauvegardes (backup) ? Un point qui est très souvent négligé.

@+

[afourti]

Merci pour toutes ces précisions.
Effectivement la volumétrie et la performance avec le temps vas devenir une grosse contrainte donc j'ai besoin d'une SGBD qui puisse tenir la route sur au moins plusieurs années.
Les hôtels sont ouvert 24/24 7/7
Je devrai peut être vous exposer plus en détails mon projet car pour le moment j'ai que ça concernait 3-4 hôtels, mais ça c'est juste pour un test, si ça marche bien il y aura plus de 40 hôtels dessus donc une volumétrie beaucoup plus importante.
Oui j'ai opté pour MysQL car c'est une base de donnée connu par quasi toute la planète
Pourquoi centraliser la base, c'est parce qu'il y a une centrale de réservation qui doit avoir accès à tous les hôtels, un commercial qui doit avoir accès à 3 ou 4 hôtel au même temps par exemple alors qu'un réceptionniste ne peut avoir accès qu'à l'hôtel dans lequel il travaille d’où ma question pour la gestion d'accès.
Le matériel est hors propos, nous avons tout ce qu'il faut pour le moment, et ce sont des accès locaux dont nous disposons.

En parallèle, je viens de passer pas mal d'heures à étudier MongoDB que je pense va être plus adaptée du coup dans mon cas.
Mais encore une fois il reste à voir comment je dois modéliser la base Mongo.
Concernant le backup avec MongoDB,il y a la config ReplicaSet qui est a l'air d'être super!

Tu as l'air d'être bien calé en database donc si tu as d'autres idées je serai preneur

Merci beaucoup,

Ahmed

[SQLpro]

Merci pour toutes ces précisions.
Effectivement la volumétrie et la performance avec le temps vas devenir une grosse contrainte donc j'ai besoin d'une SGBD qui puisse tenir la route sur au moins plusieurs années.
Les hôtels sont ouvert 24/24 7/7

Le problème est que MySQL est connu pour ne pas savoir faire du 7/7 24/24. En effet aucune sauvegarde à chaud => arrêt du serveur pour la sauvegarde. Pas nom plus de réindexation ONLINE ni de DDL ONLINE => blocage de la base pendant ces phases là... Enfin pour de forte volumétrie ou des bases complexe, l'optimisation est catastrophiques.....

Je devrai peut être vous exposer plus en détails mon projet car pour le moment j'ai que ça concernait 3-4 hôtels, mais ça c'est juste pour un test, si ça marche bien il y aura plus de 40 hôtels dessus donc une volumétrie beaucoup plus importante.
Oui j'ai opté pour MysQL car c'est une base de donnée connu par quasi toute la planète

Hélas très mal. Rares sont les experts MySQL et rares sont les profils de gens qui la maitrise...; C'est un SGBD non relationnel de bidouilleur à destination des bidouilleurs pour faire des blogs ou des CMS... pas du transactionnel (réservation, vente... !

Pourquoi centraliser la base, c'est parce qu'il y a une centrale de réservation qui doit avoir accès à tous les hôtels, un commercial qui doit avoir accès à 3 ou 4 hôtel au même temps par exemple alors qu'un réceptionniste ne peut avoir accès qu'à l'hôtel dans lequel il travaille d’où ma question pour la gestion d'accès.
Le matériel est hors propos, nous avons tout ce qu'il faut pour le moment, et ce sont des accès locaux dont nous disposons.

En parallèle, je viens de passer pas mal d'heures à étudier MongoDB que je pense va être plus adaptée du coup dans mon cas.

Encore pire... MongoDB est conçu pour le big data et orienté en recherche textuelle, pas du tout adapté à du transactionnel !

Mais encore une fois il reste à voir comment je dois modéliser la base Mongo.
Concernant le backup avec MongoDB,il y a la config ReplicaSet qui est a l'air d'être super!

Tu as l'air d'être bien calé en database donc si tu as d'autres idées je serai preneur

Merci beaucoup,

Ahmed

A +

[afourti]

Merci pour ta réponse.
Par contre je tiens à préciser que ce n'est pas de la vente, il s'agit là d'une "petite" application en PHP qui nous servira de saisir les réservations et non pas réserver en ligne, pas de paiement.
En gros le client appelle / envoie un mail pour réserver, on saisie la réservation dans l’outil (nom prénom adresse etc...) et lorsqu'il arrive à l’hôtel il paie directement ou nous envoyons la facture à sa comptabilité...ça n'a vraiment rien a voir avec les sites de réservation en ligne.

[escartefigue]

Merci pour ta réponse.
Par contre je tiens à préciser que ce n'est pas de la vente, il s'agit là d'une "petite" application en PHP qui nous servira de saisir les réservations et non pas réserver en ligne, pas de paiement.
En gros le client appelle / envoie un mail pour réserver, on saisie la réservation dans l’outil (nom prénom adresse etc...) et lorsqu'il arrive à l’hôtel il paie directement ou nous envoyons la facture à sa comptabilité...ça n'a vraiment rien a voir avec les sites de réservation en ligne.

Peut être, mais c'est vraiment ballot de se limiter par construction à un tel usage, en compromettant des évolutions éventuelles (pour ne pas dire très probables) qui permettraient au client de faire des modifications au comptoir

Ca semble normal pour un client arrivant à l'hotel de lui offrir la possibilité de souscrire à un service qu'il n'avait pas réservé initialement
Ca semble aussi normal de pouvoir corriger une faute d'orthographe sur le nom, une erreur de saisie d'adresse ou de n° de téléphone etc...
bref une application qui de base s'interdit les fonctionnalités temps réel me semble un choix très hasardeux !

[afourti]

Euu là je t'avoue que je ne te suis pas trop....Qu'est ce qui m'empecherai de faire tout ça avec Mongodb par exemple? Modifier une erreur de saisie dans une résrvation est tout à fait possible...chaque réservation aura "son portfeuille" donc si par exemple le client veut acheter un service, ce sera rajouter à son compte...ou j'ai peut etre raté quelque chose?

[SQLpro]

Merci pour ta réponse.
Par contre je tiens à préciser que ce n'est pas de la vente, il s'agit là d'une "petite" application en PHP qui nous servira de saisir les réservations et non pas réserver en ligne, pas de paiement.
En gros le client appelle / envoie un mail pour réserver, on saisie la réservation dans l’outil (nom prénom adresse etc...) et lorsqu'il arrive à l’hôtel il paie directement ou nous envoyons la facture à sa comptabilité...ça n'a vraiment rien a voir avec les sites de réservation en ligne.

Toutes les réservations, nécessitent une gestion de stock et pour un hôtel, la gestion du stock dépend fortement du temps !
Quid de requêtes analysant une demande de séjour du 16 au 22 sur un stock de chambre dont la quantité fluctue d'un jour à l'autre ?
Toute gestion de stocke est fortement transactionnelle....
Pour information, les requêtes temporelles sont les plus complexes et souvent les plus couteuses... Déjà que MySQL se vautre simplement en lisant l'horloge système....
https://bugs.mysql.com/bug.php?id=65778

A +