Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

Hulp gezocht met Database Design

Pagina: 1
Acties:

Onderwerpen

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
  • Registratie: mei 2001
  • Niet online

Cheatah

Lágrimas negras

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

My intentions soon you will see. The sway of my scheme, imposed upon all.
Come follow me, my puppets to be. I'll attach my strings, manipulation begins.


  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

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.

As always, we are nailed to a cross of our own construction.


  • Pogostokje
  • Registratie: september 2001
  • Laatst online: 18-02 21:13

Pogostokje

* twiet *

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.

... ook ik heb soms per ongeluk gelijk.


  • Martijn02
  • Registratie: september 2000
  • Laatst online: 20-02 16:50

Martijn02

/* No Comment */

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
  • Registratie: juli 2003
  • Niet online
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.

Oops! Google Chrome could not find www.rijks%20museum.nl


  • 144479
  • Registratie: mei 2005
  • Laatst online: 16-10-2015
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
  • Registratie: september 2000
  • Laatst online: 20-02 16:50

Martijn02

/* No Comment */

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)

Acties:
  • 0Henk 'm!
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?

Acties:
  • 0Henk 'm!

  • Creepy
  • Registratie: juni 2001
  • Laatst online: 20:58

Creepy

Moderator Devschuur®

Tactical Espionage Splatterer

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.

We're building self-driving cars, but we haven't even figured out how to make sure vacuum cleaners don't join botnets.


Acties:
  • 0Henk 'm!

  • EfBe
  • Registratie: januari 2000
  • Niet online
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%)

Lead developer of LLBLGen Pro.
https://fransbouma.com

Pagina: 1


Apple iPhone 11 Microsoft Xbox Series X LG OLED C9 Google Pixel 4 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True