Keuze database structuur management applicatie

[isomis]

Ik zit met het volgende vraagstuk:

We zijn bezig met het ontwikkelen van een symfony applicatie. In deze applicatie krijgen zo verschillende organisaties toegang hebben tot meerdere modules (bundels).

Het is zo mogelijk dat er 100.000 organisatie aangemaakt gaan worden door een administrator. Qua database structuur heb je een tabel organisatie en alle andere tabellen zijn gekoppeld aan een record uit het tabel organisatie. Je moet dus in alle overige tabellen de organisatie_id gaan zetten.

Mijn vraag is of het niet verstandiger is om voor elke organisatie een aparte database te maken met de daar bijhorende tabellen?

Ik vind het namelijk nu technisch gezien erg vervelend dat ik op module niveau (bundle), elke keer de organisatie id moet gaan zetten bij elke record die erin geschoten gaat worden.

Hoe doet facebook dit eigenlijk? Hebben die 1 grote post tabel met een veld "profile_id" ?

[Daos]

Het is juist het principe van een relationele database dat je tabellen aan elkaar koppelt. Zie: Wikipedia: Relationele database

[Hydra]

isomis schreef op vrijdag 21 juni 2013 @ 14:18:
Mijn vraag is of het niet verstandiger is om voor elke organisatie een aparte database te maken met de daar bijhorende tabellen?

Afgezien van hierboven: wat nu als later een changerequest komt dat bepaalde entiteiten onder meer dan 1 organisatie moeten kunnen vallen? Zit je dan met je gescheiden databases.

[Gomez12]

isomis schreef op vrijdag 21 juni 2013 @ 14:18:
Ik vind het namelijk nu technisch gezien erg vervelend dat ik op module niveau (bundle), elke keer de organisatie id moet gaan zetten bij elke record die erin geschoten gaat worden.

Dan doe je dat toch niet?

Je moet het gewoon zo regelen dat je framework eenmaal het organisatie id ophaalt (of niet)
En dat elke query daarbuiten via een DAL loopt die automatisch het organisatie id aanvult. Als je DAL het regelt hoef jij er niet meer naar om te kijken (en het voorkomt dat je het een keer vergeet).

En 100.000 dbases wil je niet hebben (of je bent gelijk bereid om 1.000 servers neer te planten) voor een serieus product.

Hydra schreef op vrijdag 21 juni 2013 @ 18:28:
[...]
En wat nu als later een changerequest komt dat bepaalde entiteiten onder meer dan 1 organisatie moeten kunnen vallen? Zit je dan met je gescheiden databases.

Tja, ik weet het niet. Maar ook met 1 database is dat niet snel geregeld. Als je er geen rekening mee houdt dan heb je een drama, houdt je er wel rekening mee dan is het enkel potato, potato (of je het nou een org-id noemt of een db-prefix of een complete db-naam het is simpelweg een "vast" iets wat altijd in je DAL geregeld moet worden)

[isomis]

Gomez12 schreef op vrijdag 21 juni 2013 @ 18:36:
[...]

Dan doe je dat toch niet?

Je moet het gewoon zo regelen dat je framework eenmaal het organisatie id ophaalt (of niet)
En dat elke query daarbuiten via een DAL loopt die automatisch het organisatie id aanvult. Als je DAL het regelt hoef jij er niet meer naar om te kijken (en het voorkomt dat je het een keer vergeet).

En 100.000 dbases wil je niet hebben (of je bent gelijk bereid om 1.000 servers neer te planten) voor een serieus product.


[...]

Tja, ik weet het niet. Maar ook met 1 database is dat niet snel geregeld. Als je er geen rekening mee houdt dan heb je een drama, houdt je er wel rekening mee dan is het enkel potato, potato (of je het nou een org-id noemt of een db-prefix of een complete db-naam het is simpelweg een "vast" iets wat altijd in je DAL geregeld moet worden)

Ik zat hierna al te kijken. Binnen doctrine is het goed te regelen via een DAL. Thnx voor alle tips!

[drm]

Voor dit soort dingen kun je het beste een request listener en een service gebruiken. De service weet over welk organisatie-id het gaat (kan simpelweg een getter/setter zijn) en de request listener injecteert de organisatie id in die service. Je maakt vervolgens alle services die dat id moeten kennen afhankelijk van die service en je bent klaar. Het enige waar je op moet letten is dat de services waarschijnlijk binnen de request scope moeten zitten om er zeker van te zijn dat het organisatie-id altijd bekend is op het moment dat ze geinitialiseerd moeten worden. Binnen Symfony 2.3 heb je daar een mechanisme voor dat "synchronized services" heet, waarbij de request aan een setter meegegeven wordt voor alle services die er afhankelijk van zijn op het moment dat de scope verandert. Je kunt dat ook gebruiken voor jouw probleem.