Bonjour à tous,
 
Mon entreprise a un nouveau projet d'appli fonctionnant en mode SaaS (pour faire simple, disons un portail de planification, consultation de planning, transmission de consignes...). Je suis en charge de l'analyse et de la conception, mais je n'y connais vraiment rien en infrastructure/stockage/réseau.
 
Je pensais à ça :
- tous les utilisateurs de toutes les boîtes ont accès au même portail
- selon leur login/mdp, le serveur les redirige vers la bonne page d'accueil et tape dans la bonne base de données
 
Est-ce la bonne méthode ?
 
 
Autre chose, on me demande d'estimer l'espace de stockage nécessaire ainsi que le coût de cet espace... Comment savoir réellement quel espace sera nécessaire ? Quel système de BDD utiliser ? MySQL est-il réellement totalement gratuit ? Avec MySQL je suppose qu'il n'y a pas d'histoire de "licence par utilisateur" comme avec Oracle ou SQL Server, donc on part serein sans limite d'utilisateur et sans surcoût éventuel ? Quels éléments prendre un compte pour calculer le coût d'un tel système selon le nombre d'utilisateurs ?
 
Merci.

Salut.
 
Quel serait la volumétrie d'utilisateur ?
L'appli serait accessible via navigateur ou par un exe ?
 
MySQL est gratuit mais je ne connais pas les avantages et inconvénient par rapport à une autre solution.
 
Concernant le stockage, je pense que ça ne sera pas énorme car si c'est que de la planification et ce qui est lié, cela devrait être limité

La volumétrie si je me base sur un de nos logiciels actuels, une BDD va de 1 à 5 Go pour un seul client, et on a environ 90 clients hébergés.
 
L'appli doit être accessible via le web (genre de chez eux et tout ça), en fait je me pose la question si :
1- ils accèdent tous à la même page et sont redirigés selon leur login/mdp
2- ils accèdent à leur propre page, ce qui veut dire autant de dossiers web à mettre à jour

Je pense que tu peux estimer facilement la volumétrie du stockage a prendre si tu as moyens de connaitre l'évolution de l'espace utilisé par les bdd.
Apris si tu n'a pas moyens de le savoir, tu prends large (90*5Go=450Go soit 1To a prendre) au prix du disque actuel, tu peux taper sur 2To d'espace disque en RAID
 
Pour l'appli, je pense qu'une page login qui redirige là où il faut est plus logique

Merci beaucoup pour ces infos.

En faisant des schémas je viens de réaliser un truc.
 
Si on a une base par client (sur le même serveur) et qu'on vérifie le login/mdp de l'utilisateur pour déterminer la suite de sa navigation, comment chercher dans la bonne base ce login/mdp ?
 
Là après c'est peut-être plus du développement mais bon, je demande quand même.

et pourquoi ne pas faire qu'une seule base de données ?

Je suppose qu'il est plus sûr d'avoir des bases séparées, en cas de départ du client par exemple, et qu'il veuille récupérer ses données.
 
En plus ça impliquerait de toujours avoir la notion de la société d'appartenance dans les tables, pour pas que les utilisateurs d'une société aient les infos d'une autre. Parce que le but c'est que ce soit un portail commun, que lorsqu'un utilisateur se connecte et qu'il est manager, par exemple, il puisse voir les plannings des salariés dépendants de lui.
 
Je crains qu'une base commune à plusieurs sociétés (déjà 90 sociétés sur notre logiciel actuel) complique les requêtes et soit source d'erreurs.
 
Je demanderai l'avis des dév plus expérimentés de ma boîte, mais je pense que la solution de la base commune fait peur  
 
La solution d'une base intermédiaire contenant tous les login et la société d'appartenance, et renvoyant vers la bonne base, est-elle viable et propre ?
 
Merci.

dans ce cas tu as plusieurs solutions, rapidement :
 
1) une base de gestion des accès qui redirigera les utilisateurs vers la bonne base de données.
 
2) differentes pages web personnalisées qui pointent chacune vers la base de données dediée.
 
3) une seule et unique base de données qui contient avec non pas au niveau des tables mais au niveau de la structure des tables la notion de société. (base Multi tenant chez Progress Software ou base de données chez Oracle par exemple).
 
ensuite à voir: mais entre gerer 90bases et 1 base, personnellement mon choix est fait: je prefere gerer et securisé une base plutot que d'avoir a jongler avec 90bases (et la gestion de leur serveur et des backup...etc....)
 

Merci pour les infos.
 
J'ai du nouveau. J'en ai parlé avec mon (plus ou moins) chef de projet, et pour lui le mieux c'est une base de données globale. Voilà une bonne nouvelle.
 
Du coup je partirais naturellement vers un seul dossier web qui chargerait les préférences société et utilisateur.
 
Par contre quel système de BDD utiliser ? Y a-t-il un réel avantage aux solutions payantes ? MySQL est-il techniquement limité dès que le projet atteint une certaine importance ?
 
Merci.

Bonjour,

Avez-vous étudié la possibilité d'utiliser un service Saas déjà existant?

Il faut compter de 3€ à 5€ par utilisateur et par mois suivant le nombre d'utilisateurs.

Je ne connais pas le besoin, donc pas de logiciel en tête.
Mais ça vaut surement le coup de faire un peu de veille, de contacter des éditeurs et voir ça avec eux.

Edit: j'avais pas vu que c'est vous qui vouliez proposer un service Saas à vos clients.

Je suis tombé sur mon propre topic en recherchant dans Google, je ne me souvenais pas avoir posté ça  
 
Du coup déterrage
 
On n'a pas fait le projet que j'évoquais en juin 2014, mais on a de nouveau un projet en mode SaaS (oui on a un boss un peu foufou ).
 
Je me demandais quelle était la technique pour héberger plusieurs clients sur une même BDD ? Ca veut dire qu'il faut systématiquement un champ dans les tables avec la société d'appartenance du client et l'inclure dans les recherches ? Ça fait pas un peu McGyver comme technique ?  
 
Merci.

Je suis intéressé par les résultat de vos recherches et je serais soulagé que vous les partagiez puisque je suis sur un projet d'étude et le travail demandé est un logiciel en mode SaaS.  
 
Merci d'avance

Alalala le "cloud"

 
Voilà comment on a fait :
1) Une BDD par client pour toutes les données
2) Un seul répertoire contenant le site (HTML, CSS, Python, etc.)
3) Une page de connexion unique qui fait appel à une BDD contenant tous les accès de relations "utilisateur - environnement d'entreprise" et isole donc les requêtes sur la bonne BDD client après la connexion