1 centrale database of elke klant zijn eigen database?

[Verwijderd]

Een tijdje geleden heb ik voor mezelf in PHP/MySQL een klanten/facturatie web-applicatie geschreven. Wel handig om al mijn klanten in bij te houden en ze na werk een factuur te sturen.

Nu willen 2 van mijn klanten dit ook gaan gebruiken. Wat zal ik nu doen? De bestaande database uitbreiden voor meerdere gebruikers met hun eigen klanten en facturen, dus overal een extra ID aanhangen, of elke gebruiker een eigen MySQL database geven? Het gaat dus om vertrouwelijke informatie en ik neig dus voor de veiligheid naar ieder zijn eigen database. Ik sta nu nog in de startblokken dus nu is de tijd om de goede keuze te maken. Wat vinden jullie?

[[ti]]

Dit is een veelvoorkomende vraag waar al heel veel over is geschreven. "Multi tenant database" is een goede term voor om op te zoeken. Lees bijvoorbeeld eens MSDN: Multi-Tenant Data Architecture waarin een aantal mogelijkheden met de voors/tegens zijn beschreven.

edit:
Hoi Woy

[ Voor 3% gewijzigd door [ti] op 17-09-2014 12:03 ]

[Woy]

Je geeft hier eigenlijk veel te weinig informatie om de juiste keuze te kunnen maken. Security is namelijk best een goed argument om voor Multi Tenant met gescheiden databases te werken, maar er zijn nog veel meer overwegingen die je moet maken zoals bijvoorbeeld scalability en maintainability.

Hier is een artikel van MS die er het een en ander over zegt: MSDN: Multi-Tenant Data Architecture

Het is wel een wat ouder artikel, maar dat doet niet zoveel af aan de materie.

edit:
* Woy trapt [ti]

[ Voor 3% gewijzigd door Woy op 17-09-2014 12:01 ]

[Gamebuster]

Ligt eraan hoeveel klanten je verwacht te hebben. Als je max 10 grote klanten hebt, lekker 1 db per klant. Als klanten zich "automatisch" moeten kunnen aanmelden en je hebt meer te maken met grote hoeveelheden kleinere klanten (en enkele grote), dan alles in 1 db.

[pedorus]

Databases kun je ook automatisch aanmaken natuurlijk. Als het erg weinig data is, is een aparte db enkel wellicht nogal overkill.

Ik zie sterke overeenkomsten met dit andere draadje van TS: [MySQL] Records verwijderen en aanmaken, of hergebruiken?

[Verwijderd]

Aha. meteen 2 maal hetzelfde artikel aangehaald, bedankt. Ik heb het even vluchtig gelezen en nu lijkt het me nog beter om het gescheiden te gaan doen. Het bespaart me het werk van overal een extra ID voor de gebruiker toe te voegen met alle bijbehorende checks. En daarnaast geeft het me ook wel een veiliger gevoel, ieder zijn eigen database met daarin zijn eigen data. Qua scalability lijkt het me ook beter. Als bijvoorbeeld 1 user veel meer records heeft dan een ander, zou ik die -mocht het ooit nodig zijn in de toekomst- wellicht makkelijker kunnen verplaatsen naar een eigen server.

@ Gamebuster: Dat automatisch aanmaken hoeft niet hoor, ik kan het ook "even" handmatig aanmaken.

@ pedorus: Klopt. Ik heb geen idee wat ze er allemaal in gaan zetten, maar ik verwacht niet meer dan 1000 klanten per gebruiker. Ook dat van dat andere draadje klopt. Maar dat was eigenlijk een 2e vraag van me in dat draadje (waar ik het voorbeeld van Exact Online aanhaalde) en de titel dekte dat dus niet meer goed.

[Barryvdh]

Nouja, als je puur wat tekstuele data en relaties op slaat moet je het toch redelijk extreem maken als je hem los moet trekken vanwege de hoeveelheid data.

Het is inderdaad wel meer werk om op te zetten (en de goede checks in te bouwen, het gaat vaak genoeg alsnog fout in sommige gevallen), maar dan moet je wel een goede manier hebben om het eea. te automatiseren, zoals database migraties enzo. Want 'even' een extra kolom toevoegen moet je dan op alle database doen natuurlijk. Dat is met 10 gebruikers niet zo'n ramp, maar als je er 1000 hebt wordt het wat lastiger.

Ik zit net zelf met hetzelfde vraagstuk, iemand toevallig nog goede tips/tools hier voor (database wijzigingen doorvoeren op alle databases etc), of gebruiken jullie daar gewoon een php scriptje voor?

En dit kwam ik ook laatst tegen: https://github.com/ramsey/uuid
Dat als je uuid ipv auto-increment id's gebruikt, je later makkelijker de data zou kunnen samenvoegen omdat je geen conflicterende id's hebt.

[[ti]]

Barryvdh schreef op woensdag 17 september 2014 @ 12:22:
Ik zit net zelf met hetzelfde vraagstuk, iemand toevallig nog goede tips/tools hier voor (database wijzigingen doorvoeren op alle databases etc), of gebruiken jullie daar gewoon een php scriptje voor?

Ik gebruik .NET met Entity Framwork, daarin heb je zgn. migrations die dit voor je afhandelen: MSDN: Entity Framework Code First Migrations -- misschien dat php ORM-tools heeft die iets dergelijks hebben?

Als je zoiets handmatig gaat maken dan is het simpelweg het makkelijkst om in een "version"-tabel bij te houden welke versie van het database schema actief is. Bij het opstarten van de applicatie check je de versie, en als ie oud is dan werk je de database bij. Entity Framework Migrations doet iets dergelijks automatisch voor je (en meer).

[Barryvdh]

Mja waarschijnlijk moet dat met doctrine of Laravel /eloquent ook wel redelijk gaan met meerdere databases.

[Dekaasboer]

Als je nog een easy read wil over iemand die daar mee werkt kijk dan eens naar de posts van Brent over kCura relativity.
http://www.brentozar.com/...ses-microsoft-sql-server/

[Verwijderd]

Barryvdh schreef op woensdag 17 september 2014 @ 12:22:
Nouja, als je puur wat tekstuele data en relaties op slaat moet je het toch redelijk extreem maken als je hem los moet trekken vanwege de hoeveelheid data.

Ja, dat denk ik ook wel. Al heeft elke factuur ook weer een aantal records onder zich hangen want elk product of dienst dat op de factuur staat heeft een eigen record. En zo kan het wellicht dan toch nog gaan oplopen. Maar heel erg veel qua bestandsgrootte zal het wel niet worden.

Het is inderdaad wel meer werk om op te zetten (en de goede checks in te bouwen, het gaat vaak genoeg alsnog fout in sommige gevallen), maar dan moet je wel een goede manier hebben om het eea. te automatiseren, zoals database migraties enzo. Want 'even' een extra kolom toevoegen moet je dan op alle database doen natuurlijk. Dat is met 10 gebruikers niet zo'n ramp, maar als je er 1000 hebt wordt het wat lastiger.

Klopt. De veiligheid is voor mij het belangrijkste, ook al kan het nog steeds misgaan natuurlijk. En 'even' een extra kolom toevoegen bij 1000 klanten/databases is natuurlijk veel omslachtiger dan het in 1 database doen. Ik denk dat ik daar dan een loopje in PHP voor ga gebruiken, als ik dat nodig heb.

Ik zit net zelf met hetzelfde vraagstuk, iemand toevallig nog goede tips/tools hier voor (database wijzigingen doorvoeren op alle databases etc), of gebruiken jullie daar gewoon een php scriptje voor?

En dit kwam ik ook laatst tegen: https://github.com/ramsey/uuid
Dat als je uuid ipv auto-increment id's gebruikt, je later makkelijker de data zou kunnen samenvoegen omdat je geen conflicterende id's hebt.

Met dat laatste heb ik inderdaad ook wel eens last gehad, toen ik een database van een autobedrijf moest samenvoegen. Ik heb toen een tijdje uuid's gebruikt maar ben toch weer overgstapt op auto-increments. Als ik ooit weer zoiets moet samenvoegen zet ik die oude auto-increments van de 2 tabellen op 'normaal' en maak ik wel een extra auto-increment tabel en voeg ik ze daarna samen. Of zoiets...

[telefoontoestel]

Uit eigen ervaring zou ik ook adviseren voor het gebruik van een aparte database per klant, helemaal aangezien je het hebt over klantgevoelige informatie die je niet door een query fout inzichtelijk wilt maken aan andere klanten.

Je kan dan eventueel wel een aparte configuratie database aanmaken waarin je allerlei algemene gegevens over de verschillende klanten kwijt kan en ook aan kan geven van welke database gebruik gemaakt moet worden. Op die manier kun je een combinatie maken tussen algemene centrale gegevens en gevoelige klant eigen gegevens apart.

Als basis kun je ook een standaard geconfigureerde database gebruiken waarop je eventuele nieuwe klantdatabases baseert.

Waar je wel rekening mee moet houden is dat je bij het maken van database wijzigingen (tabellen etc.) je deze op alle databases door laat voeren.

[ Voor 19% gewijzigd door telefoontoestel op 17-09-2014 13:20 ]

[Verwijderd]

Dank je, Telefoontoestel! Goede tips, duidelijk!

[Johnsel]

Ik zou voor gescheiden db's gaan, je wilt namelijk zo veel mogelijk scheiding tussen je applicaties/klanten zodat bij een lek zo min mogelijk toegankelijk wordt. Ik ben zelf eens via een lek in een makelaarswebsite in de backend van een online casino geraakt. Dat eindigde niet goed voor de betreffende partij.

[Gomez12]

Het nadeel met dit soort vraagstukken is altijd dat er niet echt 1 antwoord valt te geven, het is afhankelijk van geval tot geval.

Met weinig klanten is het al snel aantrekkelijk om meerdere dbases aan te gaan maken.
Maar als jij op een gegeven 1000 dbases hebt dan baal je weer gigantisch dat je het niet ooit gewoon in 1 database hebt gedaan omdat je dan alles in sync moet houden en gelijk moet houden etc.

Maatwerk is bijv ook altijd leuk met meerdere dbases, Leg jij maar eens uit dat het aanmaken van 1 custom tabel voor 1 klant opeens giga-veel geld moet gaan kosten omdat jij het moet synchen met alles en dat de anderen er geen gebruik van mogen maken etc terwijl de vragende klant toch echt op papier heeft staan dat hij zijn eigen database heeft en dat hij dus het probleem niet ziet.

En veelal heb je toch wel algemene tabellen (bij een factuurprogramma kan ik bijv denken aan een postcode-tabel of plaatsnamen tabel wat gewoon voor iedereen gelijk is, maar ook aan een btw-tabel) ga je die over elke dbase synchen of wil je dan toch een programma wat verbinding maakt met 2 dbases (1 centrale voor de algemene gegevens en 1 klantgerichte) of ... of...

[Verwijderd]

Daar zeg je wat Gomez 12, ook in je laatste alinea met een combi van 2 db's... Interessante materie. Ik ga daar nog eens goed over nadenken... Maar de klantgerichte inhoud stop ik zeker wel in een gescheiden db, daar ben ik inmiddels wel over uit.

[ Voor 35% gewijzigd door Verwijderd op 17-09-2014 14:51 ]

[HansvDr]

Ik heb een ASP.Net applicatie gebouwd waar we beide doen. Er is 1 centrale database met login gegevens, rechten, en verdere gezamenlijke data.

De klant kan op 1 of meerdere applicaties inloggen (afhankelijk van zijn rechten, de administrator op allemaal)

Elke applicatie heeft zijn eigen database.

Voor updates van de applicatie databases heb ik een command-line tooltje gemaakt die een die een extern SQL script kan uitvoeren op elke applicatie database.

Als een klant op 1 applicatie mag gaat hij na inloggen naar die applicatie, anders volgt er een keuze scherm.

[ Voor 11% gewijzigd door HansvDr op 17-09-2014 15:14 ]

[Verwijderd]

Okee, maar da's iets anders, want bij jou heeft elke applicatie zijn eigen database maar bij mij zou dan elke klant zijn eigen database krijgen. Maar ik snap het principe en denk dat ik het ook op die manier ga doen!

[underrated]

Elke situatie heeft z'n eigen oplossing natuurlijk Ik ben begonnen met 1 database per klant, wat veel flexibiliteit gaf, en tegelijkertijd veel gedoe bij globale updates.

Nu heb ik 1 centrale database met gezamenlijke data (menustructuur, modules, rechten etc) en per klant een database met hun eigen data. Voor mij werkt t goed want kan updates makkelijker doorzetten, dmv een vergelijkbaar tooltje als HansvDr. Het heeft m'n systeem iets minder flexibel gemaakt; maar geen klant die daar veel aan had.

Met MySQL kan je makkelijk meerdere database aanspreken, dus vwb performance is er ook geen probleem.

[Gomez12]

underrated schreef op donderdag 18 september 2014 @ 13:25:
Met MySQL kan je makkelijk meerdere database aanspreken, dus vwb performance is er ook geen probleem.

Wat heeft het 1e gedeelte van die zin te maken met het 2e gedeelte van die zin?

Met meerdere databases wordt juist de performance ingewikkelder / moeilijker / problematischer omdat je een hele hoop gratis performance weggooid en je een hele hoop makkelijke performance onbereikbaar hebt gemaakt...

Met minitabellen is dit allemaal niet echt een probleem, maar als jij 1tabel hebt met 1 miljoen factuurkoppen en je hebt 1 tabel met 10 miljoen factuurregels dan wens ik je veel succes met je performance als je die niet binnen 1 dbase houdt

[kristiano]

Ik weet niet hoezeer je vasthangt aan MySQL, maar Oracle heeft daar VPD voor, best of 2 worlds in mijn ogen... de DB verzorgt jouw security en je kan daarnaast een aparte applicatie schrijven die voor alle klanten de rechten&gebruikers beheeft of monitort, statistieken trekt, ... (over alle klant DB's heen dan)

http://docs.oracle.com/cd...k.102/b14266/apdvpoli.htm

DB modifications hoef je maar één keer te maken.

Het probleem wordt natuurlijk anders als je de vraag doortrekt en je afvraagt of je dat allemaal op één server gaat hosten of telkens een aparte deployment (die dan een aparte datasource heeft).
In je DAO zou je afhankelijk van een user variabele kunnen beslissen welke connectie je maakt.

Over MySQL kan ik jammer genoeg weinig relevant zeggen, maar ik dacht dat dit wel een interesante toevoeging zou kunnen zijn .

Voor VPD er was hebben wij wel nog views gegenereerd op basis van een schema die telkens filterden op 'application_code', grants naar een app specifieke user en dan nog triggers die controleerden dat wat aangepast/ingevoegd/gewist wordt effectief toebehoort aan de juiste applicatie. Home made VPD als het ware.
Dit zou toch wel mogelijk moeten zijn met MySQL en hun pl/sql variant?

[Verwijderd]

Een database per klant geeft je wel een stuk flexibiliteit. Zo kun je klanten makkelijker bij een andere server onderbrengen en zo je configuratie vrij simpel houden. Ik zou je niet te druk maken om performance verlies(tenzij je dat nu al merkt), aangezien je daar prima caching oplossingen voor kunt bedenken als dit probleem zich voordoet. Ik zou eerst zorgen dat de applicatie rendabel wordt

[Ramon]

Van MySQL naar Oracle gaan in één topic? FAIL!

De vraag die je je moet stellen is: Heb jij zin om meerdere installaties bij te houden, of wil je het liever bij één installatie houden?

Meerdere installaties bijhouden is meer werk, maar dat is allemaal goed te automatiseren met deploymentscriptjes die automatisch database-migraties uitvoeren. Belangrijk is wel om één codebase te houden, dus versiebeheer is een must. Ook je poot stijf houden als het gaat om één klant die iets specifieks wil: JIJ moet dan beoordelen of je dat wilt maken voor AL jouw klanten, wil je dat niet (om wat voor reden dan ook), dan moet je het eigenlijk niet bouwen.

[Woy]

Gomez12 schreef op vrijdag 19 september 2014 @ 00:46:
[...]
Met meerdere databases wordt juist de performance ingewikkelder / moeilijker / problematischer omdat je een hele hoop gratis performance weggooid en je een hele hoop makkelijke performance onbereikbaar hebt gemaakt...

Ik weet niet over welke performance verschillen je het hebt, maar ik zie het probleem niet zo zeer. Juist met grote tabellen wil je ook grote databases gaan partitioneren. Vaak zal dat dan alsnog aan de hand van een klant(id) zijn, aangezien je meestal toch alleen binnen de gegevens van 1 klant wil zoeken.

Losse databases maken per klant is gewoon een omslachtige manier van handmatig partitioneren.

Ik zou de beslissing sowieso ook af laten hangen van andere factoren, zoals hoe je de scheiding met de front-end doet. Als je alsnog voor alle klanten één enkele front-end hebt, waar dus aan de hand van login gegevens verbonden wordt met een andere database, zou ik dat niet doen. Je hebt dan nog steeds een security risk.

Als je echt compleet losse installaties maakt, en dus ook verschillende deployments van de applicatie dan kan het wel een voordeel bieden. Je kan op die manier bijvoorbeeld ook verschillende versies van de applicaties naast elkaar draaien.

Conclusie: Er is niet één juiste oplossing, maar het is afhankelijk van een hele hoop factoren.

[Sander]

Meerdere DB's zou ook mijn keuze zijn, met name ook vanwege security en om klanten later makkelijk eigen backups te kunnen geven. Ten aanzien van het beheren ervan hebben wij een vrij simpele logic (eigenlijk zelfde als flyway in JAVA) die tot nu toe prima werkt. Binnen het project hebben we een folder waar alle SQL mutaties worden opgeslagen met oplopende versie nummers + een migratie script. Deze checked in de DB in de versie tabel welke SQLs al gedraaid zijn en draait alle die er nog niet in staan in volgorde van versies. Bij fouten, rollback + error message teruggeven. Dit loopt nu met 15DB's en normaliter zijn fouten die gebeuren er al met deployen van de lokale machine naar de testomgeving uitgehaald.

Voor ons is deze keuze ook gebaseerd op feit dat sommige van onze klanten DB's van 15 / 20mb gebruiken, waar andere op 1GB zitten. Op dit moment allemaal prima, maar later iets waar we mogelijk willen gaan spreiden over meerdere clusters of dedicated hardware voor sommige klanten. Door deze splitsing dan al te hebben is die keuze puur operationeel en komt er geen ontwikkelaar meer aan te pas.

[ Voor 21% gewijzigd door Sander op 19-09-2014 08:39 ]

[kristiano]

Ramon schreef op vrijdag 19 september 2014 @ 08:32:
Van MySQL naar Oracle gaan in één topic? FAIL!

dankjewel, vriendelijk van je...

Ik had het zelf ook wel opgemerkt, maar de alternatieve oplossing met views/triggers en aparte users heb je misschien niet gezien?

Af en toe over het hek kijken kan zeker geen kwaad... je leert er soms iets van.
Maar inderdaad, soms is het als een kind dat voor het raam van een speelgoedwinkel staat te kijken maar nog lang niet jarig is, je verlekkeren op iets wat je nooit zal hebben, maar naar mijn mening inspireert het wel.

[Sebazzz]

Tip: Lees de serie Multi-tenancy van Ayende Rahien door. Op basis van zijn voorstellen kan je een oplossing samenstellen die voor jou het beste is.

[Verwijderd]

Woy schreef op vrijdag 19 september 2014 @ 08:35:
[...]
Ik zou de beslissing sowieso ook af laten hangen van andere factoren, zoals hoe je de scheiding met de front-end doet. Als je alsnog voor alle klanten één enkele front-end hebt, waar dus aan de hand van login gegevens verbonden wordt met een andere database, zou ik dat niet doen. Je hebt dan nog steeds een security risk.

Het wordt echt maar 1 front-end. Geen customizations voor klanten. Het enige wat ze kunnen is een logootje uploaden en de layout van hun factuur wat indelen.

Hmmm, even denken, over die security risk. Volgens mij ben je met losse db's toch 2 'stappen' veiliger:
1. Het is natuurlijk heel erg, maar een hack/fout heb ik liever dat er een database met klantgegevens van 1 klant in de verkeerde handen valt, dan een database met alle klanten.
2. Per klant kan ik wel een losse config-file in een aparte map zetten die alleen voor die klant beschikbaar is en dan nog alleen als die ingelogd is. Dus dan heb je qua veiligheid ook nog rechten van het configbestand met de databaseconnectie in die aparte map, die alleen die klant kan draaien. (Of heb je dan eigenlijk al 2 front-ends? Hoe dan ook, 1 zo'n losse connect-file voor elke klant in een aparte map is natuurlijk goed te doen).

[BoringDay]

Elke klant een eigen database, nooit gaan mixen die dingen.

- De data is van de klant;
- Gaat er wat mis, gaat het bij alle klanten mis;
- Wanneer 1 klant weinig data verbruikt en de andere extreem veel hebben ze er allebei onder te leiden;

Kortom teveel risico en zoveel extra werk zal het ook niet zijn om elke klant te voorzien van een database.

[Ramon]

kristiano schreef op vrijdag 19 september 2014 @ 08:42:
[...]


dankjewel, vriendelijk van je...

Ik had het zelf ook wel opgemerkt, maar de alternatieve oplossing met views/triggers en aparte users heb je misschien niet gezien?

Af en toe over het hek kijken kan zeker geen kwaad... je leert er soms iets van.
Maar inderdaad, soms is het als een kind dat voor het raam van een speelgoedwinkel staat te kijken maar nog lang niet jarig is, je verlekkeren op iets wat je nooit zal hebben, maar naar mijn mening inspireert het wel.

Sorry mijn reactie was ietwat overtrokken. Het is zeker goed om over de schutting te kijken om te zien hoe de buren het doen. Ik heb alleen genoeg verhalen gehoord over de licentiepraktijken van Oracle om meteen een vieze smaak in mijn mond te krijgen als ik dat hoor

[ACM]

Gomez12 schreef op vrijdag 19 september 2014 @ 00:46:
Met minitabellen is dit allemaal niet echt een probleem, maar als jij 1tabel hebt met 1 miljoen factuurkoppen en je hebt 1 tabel met 10 miljoen factuurregels dan wens ik je veel succes met je performance als je die niet binnen 1 dbase houdt

Maar is het echt nu al relevant om daar rekening mee te houden?

De topicstarter heeft het nu over maximaal 3 databases, zijn eigen en die van 2 klanten. Die drie bedrijven zijn blijkbaar klein genoeg dat ze niet nu al een eigen administratieafdeling hebben die een complete workflow-omgeving heeft staan.

Het zou natuurlijk mooi zijn als ze groot groeien... maar de kans daarop is ook weer niet heel groot. En het is dan ook nog eens de vraag hoe groot de kans is dat - als dat gebeurt - die klanten dan het systeem van de TS dan nog steeds (willen blijven) gebruiken.

Een andere belangrijke vraag voor Slingeraap2:
Hoe erg vind je het dat jouw eigen facturatie technisch vermengd wordt met die van twee van je klanten... Ik kan me nog voorstellen dat als je dit als dienst aan je klanten gaat aanbieden, dat je uiteindelijk meerdere klanten in zo'n omgeving samenpakt en daar een grote database voor gebruikt... maar ook je eigen data er nog weer bij (degene waar je ook het gebruik van deze dienst mee afrekent)?

[Verwijderd]

Inderdaad, het zal zo'n vaart niet lopen, vermoed ik.

Tsja, haha, goede vraag. Ik zou die van mijzelf nog gescheiden kunnen houden, als een soort productie/test-omgeving. Ik maak dan natuurlijk toch altijd backups voor ik weer wat ga updaten/upgraden. Maar in het geval van 1 centrale database zou ie natuurlijk er gewoon bij kunnen zitten. Wel zo goed voor het vertrouwen. Maar ik had al besloten -mede door alle tips hier- om elke klant zijn eigen database te gaan geven. Ik vind dat toch een veiliger idee, en wat BoringDay zegt 3 posts hierboven.

[mrwiggs]

Google App Engine heeft hier een mooie oplossing voor.

[TheNephilim]

Niet alleen veiligheid, maar (voor mij) zou vooral flexibiliteit de doorslag geven. Je kunt één klant dan makkelijk verhuizen naar een meer performante omgeving en/of iets bij de klant zelf.