Hulp gezocht met Database Design

[DPLuS]

Momenteel ben ik bezig met het ontwikkelen van een product, te weten een raamwerk aan webdiensten.
De individuele webdiensten kunnen door klanten afgenomen worden.
Die klanten kunnen per webdienst ook weer eigen klanten hebben.

Nu wilde ik eerst alles in 1 database proppen.
Maar bij tien webdiensten zou ik in mijn model al gauw tegen de 300 tabellen aanlopen.
Niet echt handig dacht ik zo.

Daarom ben ik nu een multi-database design aan het overwegen.
Een voorbeeld:
De klanten van individuele diensten van het raamwerk zou ik in 1 database kunnen proppen.
Per webdienst zou ik ook een database kunnen inrichten, met daarin de parameters en data van de klanten.
Aangezien de primary key van de klant niet wijzigt zou ik het relationele aspect kunnen afdwingen in de business logic van mijn applicatie.

Persoonlijk ben ik van mening dat een multidatabase design op het gebied van beheer en schaalbaarheid een betere keuze is.

Wat is jullie mening?

Btw: dit raamwerk zal in PHP5 geprogrammeerd worden en als database backend is gekozen voor Mysql v5.

[Cheatah]

Leg eens uit waarom je 300 tabellen denkt nodig te hebben voor 10 diensten?

[CodeCaster]

Je zult denk ik toch wat meer informatie moeten geven. Wat voor diensten ga je leveren aan de klanten, en wat wil je hiervoor per klant opslaan?

En wat is het probleem aan 300 tabellen? Zolang ze een duidelijke naamgeving hebben zoals $klantnummer."_diensten" lijkt me hier helemaal niks mis mee.

[Pogostokje]

Ik begrijp niet helemaal waarom je een database van 300 tabellen nodig hebt voor iets als dit. Maar, vooropgesteld dat je dat echt nodig hebt, wat schiet je er mee op als je meerdere databases gaat inrichten? In totaal zul je nog altijd aan die 300 tabellen komen alleen zitten ze dan ook nog over meer databases verspreid. Voor het beheer klinkt dat niet als iets prettigs.

Weet je echt zeker dat je zoveel tabellen nodig hebt? Ik kan het mij bijna niet voorstellen.

[Martijn02]

quote:

CodeCaster schreef op donderdag 03 mei 2007 @ 20:57:
En wat is het probleem aan 300 tabellen? Zolang ze een duidelijke naamgeving hebben zoals $klantnummer."_diensten" lijkt me hier helemaal niks mis mee.

Omdat je databaseserver dan 300 tabellen (filedescriptors), tabeldefinities en table-caches open moet hebben? (er van uitgaande dat je ze allemaal gebruikt) Daarbij is $klantnummer."_diensten" sowieso een bad-practice. Maak dan een diensten tabel, en neem een veld klantnummer op.

TS: Begin maar aan een lijstje met tabellen, dan gaan wij waarschijnlijk roepen dat je iets niet slim doet. 300 tabellen is erg lastig te beheren, en komt in de praktijk denk ik nooit voor. (maar als iemand een voorbeeld heeft hoor ik het graag)

[P_de_B]

Om nu te zeggen dat driehonderd tabellen per definitie te veel is vind ik wat ver gaan. Waar het om gaat is of het voor de verschillende diensten steeds dezelfde zijn? Dus voor elke nieuwe dienst een kopie van de oorspronkelijke (met eventueel een volgnummer in de naam), of zijn de diensten zo verschillend dat ze elk 30 tabellen gebruiken?

Als je 300 tabellen nodig bent zou ik niet omdat dat veel klinkt over meerdere databases gaan verdelen, dat is qua onderhoud nog lastiger.

Ik ga echter mee met verschillende mensen hierboven: weet je zeker dat je zoveel tabellen nodig bent? Geef eens wat meer informatie.

[144479]

quote:

Martijn02 schreef op donderdag 03 mei 2007 @ 21:06:
[...]

Omdat je databaseserver dan 300 tabellen (filedescriptors), tabeldefinities en table-caches open moet hebben? (er van uitgaande dat je ze allemaal gebruikt) Daarbij is $klantnummer."_diensten" sowieso een bad-practice. Maak dan een diensten tabel, en neem een veld klantnummer op.

TS: Begin maar aan een lijstje met tabellen, dan gaan wij waarschijnlijk roepen dat je iets niet slim doet. 300 tabellen is erg lastig te beheren, en komt in de praktijk denk ik nooit voor. (maar als iemand een voorbeeld heeft hoor ik het graag)

Onze ERP database bevat meer dan 1000+ tabellen. (Microsoft Dynamics NAV)

[Martijn02]

quote:

Cagalli schreef op donderdag 03 mei 2007 @ 21:12:
[...]
Onze ERP database bevat meer dan 1000+ tabellen. (Microsoft Dynamics NAV)

Ok, dat was misschien wat te kort door de bocht... Ik zat met mijn gedachten meer bij genoemde webdiensten e.d. (nu niet gaan roepen dat je ERP-systeem ook een web-interface heeft)

[DPLuS]

Laat ik het anders even wat algemener houden:

Wanneer zou een multi-database design beter van toepassing zijn dan een single-database design?

Of moet het streven juist zijn om zoveel mogelijk gebruik te maken van 1 database?

[Creepy]

Again, geef eens wat meer informatie over wat je nu precies wilt opslaan en wat voort een design je nodig denkt te hebben. Dan hebben we veel meer context en kunnen we makkelijker beoordelen wat nu een handige optie is.
Een database per klant zou een goede optie kunnen zijn. Maar 1 database voor alles misschien ook wel.

[EfBe]

De hoeveelheid tabellen is geen graadmeter of iets goed is of niet. De ziekenhuisdatabases die ik gezien heb hadden allemaal meer dan 1500 tables. Navision is wat anders, die creeert voor elk bedrijf dat je aanmaakt nieuwe tables (en de meest ranzige die je kunt bedenken) en de grootste die ik gezien heb had 5300 tables.. puur omdat er meerdere bedrijven inzaten.

Als je verschillende diensten apart wilt houden, dan is de logische stap om schemas te nemen binnen een catalog. Echter, jij hebt gekozen voor de rampedatabase 'mysql' en die ondersteunt geen schemas en je moet dan over op catalogs. Het nadeel van catalog per dienst is dat in je database je veelal geen FKs kunt aanmaken die over een catalog heen gaan (in mysql iig niet).

Dus:
1) ga over op postgresql
2) maak meerdere schemas aan, 1 per dienst

EfBe wijzigde deze reactie 05-05-2007 09:13 (5%)