Een vraag die ik graag beantwoord zou willen zien, is:moet u ooit gegevens van verschillende klanten zien voor uw eigen rapportage of gebruik? In dit geval moet je met nummer één gaan, anders heb je een nachtmerrie om goede rapportage te krijgen.
Ga je aanpassingen doen door de klant? Dit zou erop wijzen dat het scheiden van zaken een betere keuze zou kunnen zijn. Als je nooit zult aanpassen, scheid dan niet uit.
Ik heb met al deze opties met systemen gewerkt en de eerste is verreweg de beste voor langdurig onderhoud. Maar ze zijn allemaal werkbaar als je goed georganiseerd bent en goed plant. Als je voor de aparte optie gaat, moet je in staat zijn om wijzigingen door te voeren naar alle clients en dus wijzigingen aan de database door te voeren via scripts die in bronbeheer worden bewaard. Mogelijk moet u zelfs een broncontrole houden per databaseversie, zodat klanten kunnen kiezen om te upgraden of niet. Bij optie 1 heeft natuurlijk niemand de mogelijkheid om bij de oude versie te blijven. Als dat beter aansluit bij uw zakelijke behoeften, is dat een pluspunt voor optie 1.
Ik ben het volledig eens met Ollie Jones, als je optie één gebruikt, moet je een goed databasebeveiligingsontwerp hebben om te voorkomen dat klanten de gegevens van andere klanten zien. We hebben ooit een client verplaatst van een server waar ze de enige client waren naar een gedeelde database en slechts één proc die niet om de client_ID vroeg (het was niet nodig in het oude systeem en de ontwikkelaars waren slordig geworden) eindigde met het e-mailen van alle verkopers van alle andere klanten met informatie over de eerste klant. Dit heeft het bedrijf veel geld gekost (zowel om het probleem op te lossen als om excuses per e-mail te sturen en we verloren daardoor bijna een klant en moesten hen wat kostenbesparingen geven om ze te behouden) en veel kruiperige excuses en de ontwikkelaar slechts ternauwernood miste het verlies van zijn baan. Laat dit een les zijn die je niet op de harde manier leert.