[Ontwerp database] Per bedrijf een database of alles in 1 db

[EmilneM]

In een webapplicatie moeten gebruikers van verschillende bedrijven online een aantal zaken kunnen regelen. Per bedrijf kan het aantal databaseregels al snel oplopen tot zo'n 1.000.000 regels.

Het lijkt mij netjes om per bedrijf een apparte database in te gaan richten ipv alle bedrijven bij elkaar in één database en d.m.v. een BedrijfId onderscheid maken. In een algemene database zouden dan de alle gebruikersgegevens worden opgeslagen. Nadeel is hier dat onderhoud moeilijk is omdat bij een wijziging in de databasestructuur alle databases aangepast moeten worden. Voordeel lijkt mij de performance en het voorkomen van onnodige fouten.

Hoe kijken jullie hier tegenaan?

[Swerfer]

EmilneM schreef op donderdag 07 september 2006 @ 09:23:
In een webapplicatie moeten gebruikers van verschillende bedrijven online een aantal zaken kunnen regelen. Per bedrijf kan het aantal databaseregels al snel oplopen tot zo'n 1.000.000 regels.

Het lijkt mij netjes om per bedrijf een apparte database in te gaan richten ipv alle bedrijven bij elkaar in één database en d.m.v. een BedrijfId onderscheid maken. In een algemene database zouden dan de alle gebruikersgegevens worden opgeslagen. Nadeel is hier dat onderhoud moeilijk is omdat bij een wijziging in de databasestructuur alle databases aangepast moeten worden. Voordeel lijkt mij de performance en het voorkomen van onnodige fouten.

Hoe kijken jullie hier tegenaan?

Ik zou toch kiezen voor 1 database omdat je dan makkelijker wijzigingen ed kan aanbrengen in tabel structuren en procedures ed.

Om performance problemen hoef je je niet druk te maken als je een goede indexen aanbrengt. Denk hierbij aan een index op BedrijfId.

Juist omdat alles in 1 database komt voorkom je onnodige fouten. Immers bij meerdere databases heb je juist een grotere kans dat je een fout maakt bij het wijzigen van de database structuur, omdat je de wijziging ook meermalen moet doorvoeren.

[[ash]]

Ik zou alles in losse databases zetten. Door bugs en ontwerpfouten in de software zou het zomaar voor kunnen komen dat bedrijven elkaars gegevens kunnen zien. Denk ook aan backup en restore, dit is namelijk veel makkelijker als ze allemaal een eigen database hebben. En stel dat een van bedrijven in de applicatie zo intensief gebruikt dat ze andere server aanschaffen is het veel makkelijker om zijn database te verplaatsen. En zo kan ik nog wel meer redenen verzinnen.

Ik zou niet bang zijn om onnodige fouten te maken omdat je wijzigingen meerdere malen moet doorvoeren zoals Swerfer aangeeft. Ik neem aan dat je de wijzigingen eerst test en daarna geauotmatiseerd uitvoert.

En wat gebeurt er straks als er een bedrijf is die extra functionaliteit wil en de andere niet.

[Janoz]

Performance is nauwelijks een issue. Dat hoef je iig niet mee te nemen in je overweging. Ikzelf zou enkel de volgende punten meenemen in mijn overweging.

- Is het ook 1 applicatie of heeft enke klant zijn eigen versie
- hoe groot is de kans dat de applicaties uit elkaar gaan groeien qua functionaliteit
- hoe belangrijk is het om de gegevens appart te houden (mbt een bug die bedrijf x toegang geeft tot data van Y)

@ash: Het verplaatsen van de gegevens van 1 bedrijf uit een gezamelijke database is natuurlijk nauwelijks een probleem. Gewoon een dump maken waarbij je op bedrijfs ID filtert.

[Pin0]

De vraag die je ook kan stellen is in hoeverre is het mogelijk een query te runnen die in een bepaalde tabel van alle databases de stuctuur veranderd...

[The Eagle]

Apart bedrijf = aparte DB. D'r zijn genoeg manieren om een DB te koppelen, en ik moet eerlijk zeggen: als ik een bedrijf was zou ik ook niet willen dat mijn gegevens gemixt werden met andere bedrijven.
Als jij een webapplicatie hebt, dan kun je zo'n splitsing helemaal makkelijk maken. Bovendien, mocht er iets crashen dan is er maar 1 bedrijf uit de lucht ipv de hele zut

[[ash]]

Janoz schreef op donderdag 07 september 2006 @ 09:48:
@ash: Het verplaatsen van de gegevens van 1 bedrijf uit een gezamelijke database is natuurlijk nauwelijks een probleem. Gewoon een dump maken waarbij je op bedrijfs ID filtert.

Ik zeg ook niet dat het onmogelijk is, maar het kan vrij lastig zijn ivm gerelateerde data. En om in elk tabel een bedrijfs ID op te nemen is niet echt 'normaal' te noemen.

[Paul]

Hoe is het verder zelf geregeld? Komen al die bedrijven binnen op http://EmilneM/webapp of gaan ze naar http://bedrijfa/webapp resp http://bedrijfb/webapp etc (en die dus niet stiekem intern redirecten naar http://EmilneM/webapp)?

Als het letterlijk 1 website is zou ik zeggen: alles in 1 database, anders moet je voor je sessie-tabel en je inloggegevens naar 1 database connecten, om daaruit de gegevens (user, pass, dbnaam) van de andere database te halen en kun je daarna pas naar de goede DB.

Het hangt ook een beetje van het doel van de app af. Is het iets waardoor JIJ (of jouw bedrijf) iets met die gegevens moet gaan doen (zeg: website van de belastingdienst, veel bedrijven met gegevens van die bedrijven gescheiden) of is de applicatie er eentje die een bedrijfsproces van het bedrijf van de gebruiker stroomlijnt?

In het 2e geval zou ik alles uit elkaar halen, in het eerste geval is 1 DB handiger. In het 2e geval zijn de apps ook vaak fysiek gescheiden (als in, die van bedrijf a staan op een server in hun serverhok in Lutjebroek, die van bedrijf B staat op hun colocated bak in Amsterdam etc).

[BtM909]

The_Eagle schreef op donderdag 07 september 2006 @ 09:59:
[...]Bovendien, mocht er iets crashen dan is er maar 1 bedrijf uit de lucht ipv de hele zut

Single point of Failure blijft, want alles op 1 server... alles op 1 locatie... alles in 1 land...

[kasper_vk]

Dit vraagstuk heb ik ook al eerder voor m'n kiezen gehad.
Uiteindelijk hebben we toen voor 1 database gekozen, met als gevolg dat alle tabellen voorzien werden van een soort bedrijfs-id, die toen in alle primary keys opgenomen werd en dus ook in alle foreign keys overgenomen werd.
Iedere query moet worden voorzien van die bedrijfcode en dus word je applicatie waarschijnlijk ook 'bewust' van het feit dat je in een 'gedeelde' database zit te vissen.
Hierom zou ik persoonlijk voor losse databases kiezen; daarnaast zou ik ook het risico nooit willen lopen dat bedrijf X de gegevens van Y ziet (of kan wijzigen!), want je haalt je dan mogelijk de grootste ellende op je hals; die fout is bij meerdere databases veel moeilijker te maken makkelijker te voorkomen.

Volgens mij is het het meest natuurlijk om 2 database per bedrijf te maken; dat scheelt

Volgens mij is het grotendeels een gevoelskwestie. Wat ook van belang is: delen de applicaties van de verschillende bedrijven bepaalde gegevens? Bijvoorbeeld omdat jij in jouw toepassingen bepaalde tabellen aan ieder bedrijf beschikbaar stelt?
In dat geval zou dat in het voordeel van de 1-database oplossign spreken, aangezien je dan natuurlijk ongewenste data-verschillen kan voorkomen tussen (de databases van) verschillende bedrijven.

[ Voor 3% gewijzigd door kasper_vk op 07-09-2006 11:30 ]

[Boss]

Om hoeveel bedrijvan gaat het?

En om het aanpassen van verschillende databases zou ik me geen zorgen maken. Er zijn genoeg programma's waarmee je versie beheer van een database-structuur kan doen en met een paar kliks een hele set databases kunt upgraden naar een volgende versie.

[Anoniem: 142961]

Wij zijn in de (voorloop van de prefase van de) ontwerpfase van een soortgelijk probleem waarbij we bij meerdere klanten een offline database distribueren die systeemtabellen bevat van de online database.

De systeemtabellen in de offline database moeten bijgewerkt worden wanneer er iets veranderd in de systeemtabellen van de online (en leidende) database.

We overwegen inmiddels ook de optie om de systeemtabellen mee te distribueren in een aparte database. En dit is wellicht het aanknopingspunt aan het probleem van de TS. Door het gebruik van een aparte database, snijden we onszelf niet in de vingers door de (gegevens in de) database van een klant in de war te schoppen.

Maar zoals Kasper_vk terecht vertelt, wanneer je dus de gegevens tussen bedrijven onderling (en bij ons tussen systeemdata en "gewone" data onderling) JOIN-ed of beschikbaar stelt, dan is het wellicht geen optie om aparte databases te gebruiken.

[Knutselsmurf]

Als je de databases op dezelfde server draait, is het geen enkel probleem om de systeemtabellen shared te maken. Als je de rechten goed instelt, heeft iedere klant een eigen database-user en daarmee lees- en schrijfrechten op z'n eigen database en leesrechten op de shared systeemdatabase. Je kunt namelijk koppelingen maken naar tabellen in een andere database. Eventueel kun je dar nog een view tussen zetten.

Binnen de database van de klant heb je dan een view 'stamtabel' met als definitie

SQL:

select * from shareddatabase.stamtabel;

Binnen de database van de klant kan er dan gejoined worden op 'stamtabel' alsof het een tabel in de eigen database is.

[MicroWhale]

De database is een soort dienst die je levert? Zo ja, 1 db per bedrijf. In technisch opzicht is er niks op tegen om alles in één database te stoppen. Als je uptime, service en risico mee gaat nemen dan zul je twee databases per bedrijf moeten gaan bijhouden.

Eén database is toegankelijk, terwijl de andere bijv. elke nacht (of beter: direct) bijgewerkt, zodat deze ook up-to-date is. Als er dan één uitvalt, kan naar de andere overgeschakeld worden.

Twee db's per klant, zorgt ervoor dat niet alles uitvalt in geval van storing.

Dit garandeert uptime en beperkt het risico van uitval.

[JaQ]

Persoonlijk zou ik dit altijd in een database zetten. Je kan eventueel met meerdere schema's gaan werken, zoals Knutselsmurf voorsteld, maar dat is wel een klein beetje een knutseloplossing (nofi) Je hebt dan namelijk nog steeds meerdere database schema's waarvan de tabeldefinities in sync moeten zijn, ergo: hoofdpijn.

Oracle kent een hele leuke feature die virtual private database (VPD) heet. Dit is eigenlijk niets meer dan een policy op je database die iedere query automagisch uitbreid met een conditie, bijvoorbeeld een bepaald bedrijfs-id (die uiteraard dan weer gekoppeld is aan een user). Hierdoor sluit je op database niveau uit dat bedrijf a bij de gegevens van bedrijf b kan. Om toch bij alle dat te kunnen bestaat een apparte database rol, maar deze is default alleen uitgedeeld aan sys (de database administrator user). Ik verwacht dat mssql ook wel zoiets heeft, postgresql misschien ook nog wel. Als je een database gebruikt die geen vergelijkbare feature heeft, kan je dit uiteraard nabouwen, maar probeer de scheiding op een zo laag mogelijk niveau aan te brengen.

Als je dus een goede scheiding in je database software hebt gelegd, heb je maar 1 keer hoofdpijn gehad (namelijk over de technische implementatie). Het in sync houden van meerdere databases is hoofdpijn voor de levensduur van het pakket (en dat klinkt als pijn zonder einde....)

Als je availlability garanties wilt gaan geven, zou ik eerder gaan kijken naar een standby database, dan naar een database per bedrijf. Deze standby database moet uiteraard op een andere machine (en andere fysieke locatie) staan, anders ben je nog nergens. Persoonlijk heb ik goede resultaten met Postgresql, MySql en Oracle gezien m.b.t. replicatie en standby databases (ik heb geen ervaring met mssql). Een oplossing zoals Oracle RAC is uiteraard nog mooier, maar die kost ook een serieuze bak geld. De applicatie moet wel heel erg kritisch zijn voordat ik voor RAC zou gaan kiezen, vooral omdat dit ook een enigzins prijzige Oracle DBA impliceerd.

De hoeveelheid data die je benoemd (zo'n 1 miljoen rijen per bedrijf) is nauwelijk iets om je zorgen over te maken. De performance van je applicatie is meer afhankelijk van de implementatie dan de hoeveelheid data. Een goed databaseontwerp en correct getunede queries blijven bij grotere hoeveelheden data nog steeds prima functioneren. De grootte van het onderliggende stuk ijzer is prima te calculeren en zal je nog meevallen.

[-FoX-]

Ik zou nooit voor meerdere DB's verkiezen als deze gedeeld wordt door slechts 1 applicatie; dit drijft de onderhoudskosten erg omhoog en dat is het laatste wat je wil!

Onnodige fouten kunnen opgelost worden door goed te testen en alleen daardoor. Zelfs met meerdere databases kan je niet zeker zijn. Want wat als je nu een bedrijfsprofiel laat verwijzen naar de verkeerde database? Zelfde probleem.. meer kosten (onderhoud)

Je kan de bedrijfsgegevens filteren op query en je kan daarenboven zelfs nog een extra security filter in de applicatie zelf implementeren, die eventuele lekken toch nog afsluiten.

[-FoX-]

Voor welke optie ga je nu gaan?

[Aetos]

Neem de kans dat een klant fouten maakt en wil teruggaan naar een de backup state van een tijdje terug mee in je overwegingen. (denk ook na over twee klanten die dat willen).. en een die absoluut niet terug wil.

Als je alles in een database stopt heb je dan een koppijnprobleem van de grootste proporties. Als je per klant alles in een database stopt en die ook gebackupped hebt dan is het een kwestie van de backup terugzetten.

Er zijn genoeg DBMS systemen die meerdere databases kunnen draaien in een server.

Het probleem van een webapp kan je oplossen door een portal voor al je webapps te zetten.
En meerdere instanties van je applicatie (per klant een) gebruiken. Je kan dan ook nog meerdere versies van je applicaties ondersteunen voor verschillende klanten.

[Olaf van der Spek]

BtM909 schreef op donderdag 07 september 2006 @ 10:09:
Single point of Failure blijft, want alles op 1 server... alles op 1 locatie... alles in 1 land...

Dat is niet helemaar waar. Stel dat je met onderhoud of een upgrade bezig bent voor een bedrijf en er gaat iets mis, dan heeft de rest daar geen last van.

Swerfer schreef op donderdag 07 september 2006 @ 09:31:
Juist omdat alles in 1 database komt voorkom je onnodige fouten. Immers bij meerdere databases heb je juist een grotere kans dat je een fout maakt bij het wijzigen van de database structuur, omdat je de wijziging ook meermalen moet doorvoeren.

Dat doe je toch met down/upgrade scripts en dergelijke en niet met de hand mag ik hopen?

De belangrijkste (en IMO eigenlijk enige) vraag die van belang is, is of de data inderdaad gedeeld wordt. Als het gedeelde data is, stop je die gedeelde database, anders lijkt een prive database me de beste optie.

[ Voor 11% gewijzigd door Olaf van der Spek op 17-09-2006 22:55 ]