Comment Concevoir un SaaS Base de données
J'ai une application web que j'ai créé pour une entreprise de camionnage que je voudrais proposer en mode SaaS. Quelle est la meilleure façon de concevoir la base de données?
Dois-je créer une nouvelle base de données pour chaque entreprise? Ou dois-je utiliser une base de données avec les tables qui ont un préfixe du nom de la société? Ou dois-je Utiliser une base de données avec un de chaque table et il suffit d'ajouter un id d'entreprise champ à la table? Ou est-il un autre moyen de le faire?
- SAS? Logiciel en tant que Service?
- Ce que vous avez dit est trop vague. Ce n' "Société" représenter dans votre application?
- oui le Logiciel en tant que Service
- Une société est un groupe d'utilisateurs qui ont accès aux mêmes données. Donc, Une Entreprise de Camionnage peut avoir 5 pour les utilisateurs d'accéder à leurs données. L'Entreprise de camionnage B a 20 utilisateurs l'accès à un jeu complètement différent des données. Cela vous aide?
- Les plus courantes abréviation est "SaaS". Normalement, SAS se réfère à la SAS, inc. sas.com. Il n'est pas clair si vous parlez de l'entreprise ou de l'offre de services de l'idée. Vous pourriez vouloir corriger votre question.
- ok. Je vais le faire. Merci.
- Conception de base de données et la conception d'un schéma de questions sont hors-sujet à Débordement de Pile. Peut-être dba.stackexchange.com serait un meilleur choix.
- double possible de Quels sont les avantages de l'utilisation d'une base de données unique pour CHAQUE client?
- Je suis amusé par le fait que les gens croient qu'il peut y avoir une seule réponse correcte à cette question, et en plus il est potentiellement dommageable pour désigner une approche correcte. @sauteur avec slalom est vrai qu'il aurait été voté comme hors-sujet -- il y a trop de considérations pour qu'il y ait une réponse unique.
Vous devez vous connecter pour publier un commentaire.
confrontés à une situation similaire de 10 ans, nous avons opté pour une base de données par client. nous avons des centaines (voir des milliers) de clients. en regardant en arrière, il était l'une des meilleures décisions que nous avons prises. les sauvegardes sont faciles. la copie d'un seul client à notre bureau pour l'analyse est facile (il suffit de prendre la dernière sauvegarde). mise à l'échelle est facile (le déplacement d'un seul gros client vers un autre serveur peut libérer des ressources sur un souligné sql server). joel & jeff a eu une discussion à ce sujet sur un un débordement de pile podcast (pas récent) et joel fait la même chose que je fais ... chaque client reçoit sa propre base de données. base de données les puristes prétendent souvent pour regrouper tout le monde dans une db, mais je ne ferais jamais ça.
-ne
Oui - Ne Dickinson était sur l'argent. Cependant, l'affinement ci-dessous.
Seigneur, non! La modification de vos requêtes de base de données pour différentes pour le client ferait de vous rendre fou! Aussi, vous auriez presque certainement exécuter le SQL dynamique (d'où le nom de la table est modifiée dans le code avant l'exécution de la requête), ce qui nuirait à la performance comme la plupart des serveurs comme à cache des plans de requêtes et de résultats intermédiaires - cela ne fonctionne pas si la table des noms de continuer à changer.
Vous pouvez le faire si vous voulez avoir une sorte de modèle évolutif pour vos clients. Alors que le provisionnement d'une nouvelle base de données pour chaque client vous donne beaucoup de flexibilité, il implique également des coûts et de la complexité. Vous devez créer un nouveau calendrier de sauvegarde, ont un modèle du cycle de vie pour traiter expiré clients, etc.
Donc vous pourriez dire que "essai gratuit" et "bronze" les clients sont tous regroupés dans une seule base de données, à l'aide de l'id de la société à séparer; "silver" les utilisateurs à obtenir leur propre base de données (mais vous gardez toujours le champ customer_id dans le schéma, de sorte que vous n'avez pas à modifier les requêtes entre les deux niveaux de la clientèle), et "or" les clients reçoivent leur propre serveur de base de données.
J'ai fait quelque chose de similaire il y a quelques années à une société SaaS - et les clients sont généralement heureux d'avoir un chemin de mise à niveau de l'infrastructure (lire: les performances et la résilience) ainsi que des fonctionnalités.
Quels sont les avantages de l'utilisation d'une base de données unique pour CHAQUE client?
Dois-je utiliser un seul ou plusieurs bases de données de configuration pour une multi-application client?
https://stackoverflow.fogbugz.com/default.asp?W24218 (transcription du podcast, la discussion autour de 50 minutes)
Nous avons des bases de données ici partagé avec les clients et certains où chaque client a son propre serveur et de la base de données. Ceux où le client est sur son propre serveur sont les plus faciles à gérer, et le moins susceptible de causer un problème quand un développeur a oublié d'ajouter le clientid et envoyé à un client, les données relatives au client de b par accident (PAS un exemple choisi au hasard).
En gardant chacun sur son propre serveur ou d'une instance nous permet de garder la structure de la base de la même avec le même nom et le rend plus facile à propager les modifications à tous les serveurs, car nous n'avons pas à changer le nom de base de données.
Si vous utilisez des instances distinctes pour chaque client, assurez-vous de concevoir et mettre en œuvre un système efficace de propagation de tous les changements à tous les clients. Si ces bases de données se désynchroniser, ils peuvent devenir horrible à gérer. Vous verrez que si vous les laissez sortir de la synchronisation, chaque client de demander des changements et vous aurez 27 façons de faire la même chose. Vous avez de généraliser quand ils sont sur la même base de données, lorsqu'ils sont séparés, vous devez utiliser l'auto-discipline pour s'assurer que les nouvelles fonctionnalité est la même pour chaque client.
Il dépend, ici, je travaille dans une entreprise qui a de nombreux "services Internes" traités comme les autres entreprises.
Ainsi, certains de ces rapports doivent inclure toutes les sociétés, les comptes du Client doit aussi être partagé entre les entreprises. Ici, nous avons un CompanyId Champ dans les tableaux qui l'exige.
Le Préfixe solution est sûrement l'un à éviter.