Une question à laquelle je voudrais répondre est la suivante :avez-vous déjà besoin de voir des données sur les clients pour votre propre rapport ou utilisation ? Dans ce cas, vous devez choisir le numéro un ou vous aurez un cauchemar pour obtenir de bons rapports.
Ferez-vous une personnalisation par client? Cela indiquerait que séparer les choses pourrait être un meilleur choix. Si vous ne personnalisez jamais, alors ne vous séparez pas.
J'ai travaillé avec des systèmes dans toutes ces options et la première est de loin la meilleure pour la maintenance à long terme. Cependant, tous sont réalisables si vous êtes organisé et planifiez bien. Si vous optez pour l'option séparée, vous devez être en mesure d'appliquer des modifications à tous les clients et donc d'apporter des modifications à la base de données via des scripts conservés dans le contrôle de code source. Vous devrez peut-être même conserver un contrôle de source par version de base de données, afin que les clients puissent choisir de mettre à niveau ou non. Dans l'option 1 bien sûr, personne n'a la possibilité de rester sur l'ancienne version. Si cela correspond mieux aux besoins de votre entreprise, c'est un plus pour l'option 1.
Je suis tout à fait d'accord avec Ollie Jones, si vous utilisez la première option, vous devez avoir une bonne conception de la sécurité de la base de données pour empêcher les clients de voir les données d'autres clients. Une fois, nous avons déplacé un client d'un serveur où il était le seul client vers une base de données partagée et un seul proc qui a manqué de demander le client_ID (ce n'était pas nécessaire dans l'ancien système et les développeurs étaient devenus bâclés) a fini par envoyer un e-mail à tous les commerciaux de tous les autres clients avec des informations sur le premier client. Cela a coûté beaucoup d'argent à l'entreprise (à la fois pour résoudre le problème, pour envoyer des excuses par e-mail et nous avons presque perdu un client en conséquence et avons dû leur accorder des réductions de coûts pour les garder) et de nombreuses excuses rampantes et le développeur juste de justesse manqué de perdre son emploi. Que ce soit une leçon que vous n'apprenez pas à la dure.
