Cloisonnement SQL pour appli en SAAS

Bonjour à tous,

Dans le cadre du démarrage d'un projet en PHP/MySQL, j'aimerais avoir votre avis et surtout un éclaircissement sur la façon d'utiliser des bases de données.

Le modèle retenu est nClients ----> nBases donc 1 client par base.
1 base commune contenant les identifiants des bases clients (sinon je vois pas comment faire autrement).

Du coup la réflexion se porte sur les futures mises à jour de ces bases.

Habitué à HFSQL de PCSoft, c'est assez simple, on travaille sur l'analyse et lors des MAJ ca modifie les données.
Le cas simple: j'ajoute un champ dans mon schéma, à part maintenir à jour un fichier texte des requêtes à faire (Alter table.... ) et à chaque connexion vérifier la version et injecter les infos sql j'ai pas d'autres solutions.
Mais le risque d'erreur est énorme puisque par habitude je créé une colonne dans une table, vient l'heure du café ou du fameux coup de fil et là vous oubliez que vous avez ajouté cette colonne.... A la mise en prod c'est la cata !!!

J'ai déjà vu des appli justement qui s'occupait de synchroniser toutes les bases avec une base modèle (celle sur laquelle en développe par exemple), avez vous des infos, remarques ou suggestion pour ca ?

C'est vrai que la fonction SAAS de PCSoft est assez bien foutu, mais pour ce projet on veut pas de Webdev (beurk).

Merci de vos retours,
Bons Dev :-)

Tout dépend du facteur n.... En effet du nombre de base va dépendre la facilité ou la difficulté de la maintenance et des performances de votre système...
En effet, en multipliant à outrance le nombre de base vous allez multiplier la maintenance associé, par exemple pour la sauvegarde (qui malheureusement doit être fait à froid dans MySQMerde) mais aussi les ressources système (espace utilisé par connexion, par base, par fichiers ouverts..), la défragmentation, la mise à jour des stats....
La limite étant d'environ 100 bases sur un serveur costaud.

Au delà il faudra ventiler sur plusieurs serveurs, ce qui risque de vous revenir fort cher....

Si vous envisagez une solution professionnelle, il vaut mieux vous tourner vers d'autres SGBDR qui gèrent mieux que MySQmerde ce genre de fonctionnalités.

En effet, tous les SGBDR, (sauf MySQMerde qui en est resté à la version 2 du SQL datant de 19992 - et encore pas tout...) gèrent es "schémas" SQL qui sont des conteneurs logiques à l'intérieur d'une même base. Ces conteneurs permettent de cloisonner la base, un peu comme si cela était des "sous base". Dans ce cas, une base peut comporter plusieurs millions de sous-bases sans que cela n'affecte en rien, ni la maintenance ni les performances.
Exemple : MS SQL Server ou vous pouvez aller jusqu'à 4 milliards de schéma SQL dans une seule et même base.

A +

Merci pour la réponse.
Dans un premier temps, nous compterons 50 bases de 100 tables environ.
Les bases peuvent être sur un même serveur ou si le client souhaitez monter son propre serveur et héberger sa base pas de souci.

Du coup, ma question portait surtout sur le fait que quand on fait une modif dans le code (ajout d'un champ dans une table par exemple) est ce que le seul moyen est de se souvenir de ce que l'on a fait ou existe t il une application qui permette de voir les modif faite sur la base de dév et génère donc le code adéquat sur les bases des clients.

De là à dire Merde ou pas merde, je pense que c'est plus en fonction de la taille, des compétences et des moyens de chacun....

Citation:

---

Envoyé par nerborac

Du coup, ma question portait surtout sur le fait que quand on fait une modif dans le code (ajout d'un champ dans une table par exemple) est ce que le seul moyen est de se souvenir de ce que l'on a fait ou existe t il une application qui permette de voir les modif faite sur la base de dév et génère donc le code adéquat sur les bases des clients.

---

La plupart des SGBDR, sauf MySQmerde, acceptent la création de déclencheurs DDL qui permettent de lancer du code sur des événements DDL comme CREATE, ALTER ou DROP.
Dans certains SGBDR, ceci peut être traqué au niveau du serveur et automatisé pour le répliquer sur d'autres bases. C'est le cas de SQL Server.
Principe : on créé un trigger DDL de niveau serveur pour traquer toute activité DDL effectué sur une base "template" puis on applique la commande DDL ainsi récupérée, sur l'ensemble des bases clones.

A +