[Database] Een grote of veel kleintjes

[IJsbeer]

Momenteel ben ik bezig met een generieke website, zodat ik vanuit één webapplicatie meerdere sites heb. Iedere klant krijgt een aparte interface en eigen gebruikers.

Nu vraag ik me af wat de beste optie is:

Optie 1: Één grote database
Optie 2: Iedere klant een aparte DB

Beheer en Performance vind ik hierbij best wel belangrijk. Security speelt natuurlijk ook een rol.. maar wat kan ik he beste doen???

[Rotjeknor]

Lijkt mij dat het compleet van de structuur van de database afhangt, vertel daar eens wat meer over, dan kunnen we misschien wat meer advies geven...?!

[Verwijderd]

ik zou voor optie 1 gaan, als je server een beetje de load aankan

en anders blijft er alleen de 2e over

[IJsbeer]

Ik weet niet wat je precies met de structuur wil horen, maar het wordt een soort site waarin je als gebruiker zelf de inhoudt kan bepalen. Deze inhoud zullen Word documenten zijn die opgeslagen worden als XML bestanden. Daarnaast zitten er dingen in als een forum, smoelenboek, webmail en dat soort gein....

Heb je hier voldoende aan om me verder te kunnen helpen???

[Verwijderd]

Verwijderd schreef op 13 december 2002 @ 14:40:
ik zou voor optie 1 gaan, als je server een beetje de load aankan

en anders blijft er alleen de 2e over

Jij wilt de users van verschillende websites in dezelfde tabel zetten? En dat, gegeven het feit dat het veilig moet zijn.

De klanten krijgen dus een soort query met WHERE site_id=16 of iets dergelijks. Lekker makkelijk om aan te passen, en gegevens van de andere sites in dezelfde database te rippen.

Nee je zou aparte tabellen moeten aanmaken voor afzonderlijke klanten, maar dan kun je net zo goed compleet aparte databases en database-users aanmaken.

Ik zou dus voor elke klant een database maken.

[Defspace]

Beheer en Performance vind ik hierbij best wel belangrijk. Security speelt natuurlijk ook een rol.. maar wat kan ik he beste doen???

Ik ben het met Cheatah eens.

Je zegt beheer/performance/security zijn mijn aandachtspunten.
Optie 1: Voordeel: Beheer
Optie 2: Voordeel: Security en Performance.

[IJsbeer]

Defspace schreef op 13 December 2002 @ 14:55:

Optie 1: Voordeel: Beheer

Alles in aparte databases maakt het geel juist moeilijk beheerbaar... tenminste dat zie ik als groot nadeel, of zijn hier mogelijkheden voor om eventuele aanpassing in de DB structuur in iedere DB door te voeren??

[Defspace]

IJsbeer79 schreef op 13 december 2002 @ 14:57:
[...]


Alles in aparte databases maakt het geel juist moeilijk beheerbaar... tenminste dat zie ik als groot nadeel, of zijn hier mogelijkheden voor om eventuele aanpassing in de DB structuur in iedere DB door te voeren??

Optie 1 is ook Eén grote database

[justmental]

Verwijderd schreef op 13 December 2002 @ 14:45:
Jij wilt de users van verschillende websites in dezelfde tabel zetten? En dat, gegeven het feit dat het veilig moet zijn.

De klanten krijgen dus een soort query met WHERE site_id=16 of iets dergelijks. Lekker makkelijk om aan te passen, en gegevens van de andere sites in dezelfde database te rippen.

Niet als de data in verschillende schema's zit.

[IJsbeer]

Heeft er iemand ook meer ervaring met de performance:

Er zullen zo'n 20 klanten komen, die gemiddeld zo'n 500 gebruikers hebben (we verwachten niet dat de site door meer dan 15 mensen tegelijkertijd bezocht wordt). Kan SQLServer 2000 het dan makkelijk aan om met huge tabellen te werken?

Dus als we voor optie 1 gaan, is dan de performance er nog een beetje? Of zegt SQLserver: Zoek het lekker zelf uit???

[Verwijderd]

Misschien moet je dit bij een "echte databaas" neerleggen ?

[Verwijderd]

SQL Server is een hele robuuste database, die best wel wat kan hebben. Dat neemt niet weg dat zoeken dor grotere tabellen meer tijd kost, en dat er meer aandacht aan DB tuning besteed moet gaan worden als er specifieke knelpunten zijn.

Eerlijk gezegd zou ik, als je verwacht of vreest dat performance een issue kan worden, de database opsplitsen in verschilllende schema's op 1 server. Daarmee beperk je de records per tabel, en kun later makkelijk de database opdelen over meerdere servers, als extra performance nodig mocht zijn. Zolang de schema's op 1 server staan is het beheer echter niet zo'n groot probleem.

HTH

[jochemd]

IJsbeer79 schreef op 13 december 2002 @ 14:38:

Beheer en Performance vind ik hierbij best wel belangrijk. Security speelt natuurlijk ook een rol.. maar wat kan ik he beste doen???

Beheer: in het ergste geval is het meer werk
Performance: in het ergste geval heb je een zwaardere database server nodig
Security: in het ergste geval zijn al je klanten al hun data kwijt

Weet je zeker dat je je prioriteiten goed hebt?

[Verwijderd]

Misschien niet onbelangrijk:

Waarmee ga je werken ? (dus niet de database)

Wordt het een ASP.NET oplossing, of een J2EE oplossing ?
Of wellicht iets anders ?

Heb je de juiste mensen om dit te bouwen / op te zetten / te beheren ?

[Verwijderd]

Ik zou zelf kiezen voor de tweede optie, enige nadeel is dan wel dat je voor het beheer iets moet verzinnen, maar een grote database lijkt mij erg lastig...

[IJsbeer]

Verwijderd schreef op 13 december 2002 @ 15:43:
Misschien niet onbelangrijk:

Waarmee ga je werken ? (dus niet de database)

Wordt het een ASP.NET oplossing, of een J2EE oplossing ?
Of wellicht iets anders ?

Het wordt gebouwd in .NET.

[EfBe]

maak je 1 database, dan moet je bij alle acties rekening houden met de ID van de site. Dit maakt de programmatuur nodeloos ingewikkeld. Het voordeel is wel dat je via wat recordjes aanmaken een nieuwe site kunt opzetten.

Echter, je kunt ook een nieuwe SQLServer DB aanmaken vanuit een webpage (je beheersite bv) mbv SQL-DMO. Je kunt dan iedere site in zn eigen database laten staan en de programmatuur is sterk versimpeld, want je hoeft binnen een database (en binnen een webapplicatie(!) geen rekening te houden met siteid en aanverwante zaken, je kunt doen alsof je de enige bent op de database en binnen de programmatuur. Echt, scheelt in tijd en complexiteit, wat weer scheelt in de hoeveelheid bugs, want gesharede code en data binnen verschillende applicaties levert een groep potentiele bugs op (bv cross-site ellende)

[curry684]

IJsbeer79 schreef op 13 December 2002 @ 15:11:
Heeft er iemand ook meer ervaring met de performance:

Er zullen zo'n 20 klanten komen, die gemiddeld zo'n 500 gebruikers hebben (we verwachten niet dat de site door meer dan 15 mensen tegelijkertijd bezocht wordt). Kan SQLServer 2000 het dan makkelijk aan om met huge tabellen te werken?

Dus als we voor optie 1 gaan, is dan de performance er nog een beetje? Of zegt SQLserver: Zoek het lekker zelf uit???

Da's peanuts voor SQL Server (tenzij je entiteiten met 100 attributen gaat maken of zo). En anders cluster je er toch gewoon een server aan vast?

[sebastius]

Verwijderd schreef op 13 december 2002 @ 14:45:

[...]

Jij wilt de users van verschillende websites in dezelfde tabel zetten? En dat, gegeven het feit dat het veilig moet zijn.

De klanten krijgen dus een soort query met WHERE site_id=16 of iets dergelijks. Lekker makkelijk om aan te passen, en gegevens van de andere sites in dezelfde database te rippen.

Nee je zou aparte tabellen moeten aanmaken voor afzonderlijke klanten, maar dan kun je net zo goed compleet aparte databases en database-users aanmaken.

Ik zou dus voor elke klant een database maken.

Dit idee ziet er uit als een soort clubs.nl-achtig systeem; zelf geen serverside code invoeren dus, alleen standaardpages met wat content. Dan vervalt die veiligheidskwestie en wordt het geheel beheersbaarder als alles in één db staat.

edit:
dit had onder user |HunterPro| gepost moeten worden

[ Voor 6% gewijzigd door sebastius op 13-12-2002 16:17 . Reden: procentuele kans dat U dit bericht begreep: ]

[Creepy]

Verwijderd schreef op 13 december 2002 @ 15:43:
Misschien niet onbelangrijk:

Waarmee ga je werken ? (dus niet de database)

Wordt het een ASP.NET oplossing, of een J2EE oplossing ?
Of wellicht iets anders ?

Heb je de juiste mensen om dit te bouwen / op te zetten / te beheren ?

Dat laatste is belangrijk ja. Waarmee je gaat werken is echt een bijzaak. Net alsof het uitmaakt dat je zoiets opzet in ASP.NET, ASP, J2EE, PHP, C, C++, Delphi, PERL etc. Zolang de mensen die het bouwen de ontwikkel omgeving maar kennen.

Alleen al uit security oogpunt zou ik per klant een database doen. Mocht het eens echt groot worden dan kan je zelfs meerdere (R)DMS'en gebruiken zonder enige aanpassingen in de code.

[mulder]

De klanten krijgen dus een soort query met WHERE site_id=16 of iets dergelijks. Lekker makkelijk om aan te passen, en gegevens van de andere sites in dezelfde database te rippen.

Op het moment dat je die query kan aanpassen is mijn inziens al te laat. Als je security goed in voorelkaar is, moet het geen enkel probleem zijn meerdere 'sites' in 1 database te proppen.

Zelf prefereer ik meerdere db's, vooral bij het ontwikkelen

[Verwijderd]

Ik zou absoluut voor meerdere databases gaan ... het is makkelijk te backuppen en te restoren .. is vanuit security beter.... de tabellen blijven kleiner (minder last van table locks en voor sql veel sneller te doorzoeken) voorst wat wil je doen als een klant weggaat... alle data van die klant uit een database peuteren?

[Solopher]

Ik zou, voor 1 database gaan zodat je 1 permante verbinding met Database hebt, anders steeds andere database openen (En dat gaat tijd kosten) Vooral mensen met geen breedband, zullen lang bezig zijn met de site te openen.

[EfBe]

solopher schreef op 13 December 2002 @ 20:23:
Ik zou, voor 1 database gaan zodat je 1 permante verbinding met Database hebt, anders steeds andere database openen (En dat gaat tijd kosten) Vooral mensen met geen breedband, zullen lang bezig zijn met de site te openen.

Dit lijkt me onzin, omdat de applicaties zelf database connecties maken en of je nu 1 database hebt en 20 sites die daar verbinding mee maken of 20 databases waar die 20 sites verbinding mee maken, die 20 sites moeten verbinding maken. Ook die client connectie heeft volgens mij niet zoveel invloed op het geheel De optie van het backuppen en vooral het restoren van tijnbraun is een goed punt. Als je voor meerdere databases gaat houdt je het per applicatie atomair en loop je nooit het risico andere applicaties en de daarbij horende data schade aan te doen.

[Creepy]

solopher schreef op 13 december 2002 @ 20:23:
Ik zou, voor 1 database gaan zodat je 1 permante verbinding met Database hebt, anders steeds andere database openen (En dat gaat tijd kosten) Vooral mensen met geen breedband, zullen lang bezig zijn met de site te openen.

Ja, en 6 sites tegelijk over 1 verbinding gaat sneller dan 6 sites over 6 verbindingen???

En wat heeft het aantal connecties tussen webserver en database (die vaak ook nog eens op de zelfde machine draaien) te maken met de verbinding van iemand die een website opvraagt?

edit:
En Efbe was wat sneller dan mij

[ Voor 5% gewijzigd door Creepy op 13-12-2002 20:30 ]

[hobbit_be]

voor eenzelfde sort CMS systeem gebruik ik 1 database met vele tabellen (PHP en MySQL). Per site foobar beginnen de tabellen gewoon met foobar_user, foobar_group, etc.
Redenen hiervoor heel simpel: Bij de meeste Hosts krijg je niet meer dan 1 MySQL database. Als alles in 1 steekt is ie net iets makkelijker te onderhouden. Maar aangezien de tabellen allemaal gescheiden zijn heb je de voordelen van snelheid/compactheid/etc. Bovendien kun je als admin dan nog heel eenvoudig volledige site statistics maken. (Union, etc). Natuurlijk het gebruik van tabelnamen maakt het noodzakelijk om een beetje scripting te doen voor het creeren van je queries. Voor het opvragen heb ik een XML/Xpath parser gebouwd zodat dit triviaal voor het creeren wordt. Nu bezig aan een XML file die de pagina's opbouwst (ssort van XSL maar dan met database queries)... Door gebruik te maken van cached paginas is de performance zeker in par met gebuiks vriendelijkheid...

[Mart!]

Tja, de meningen zijn hierover verdeeld. Het heeft dan ook veel te maken met persoonlijke voorkeur. Je hebt 3 keuzes:

- 1 database, data van alle klanten in zelfde tabel(len)
- 1 database, data van klanten in apparte tabel(len)
- meer databases, data van klanten in apparte databases

Ik heb zelf de voorkeur voor de eerste.

Development: Ik ga ervanuit dat het systeem initieel wordt neergezet voor klanten en dat er vervolgens uitbreidingen worden gemaakt. Wanneer je voor de andere opties gaat betekent het bij tabelaanpassingen dat je deze in alle tabellen moet doorvoeren. Bij de eerste oplossing slechts in 1. Dat vindt ik een heel groot voordeel, aangezien CMS- en documentbeheersystemen nooit af zijn en altijd uitgebreid worden.

Onderhoud: Het appart backuppen van de databases vindt ik niet echt noodzakelijk. Het restoren van een backup doe je alleen in noodgevallen. Houd er bijvoorbeeld bij het ontwerpen van je site rekening mee dat records niet echt worden verwijderd, maar worden 'gevlagd'. Belt er iemand op dat hij perongeluk iets heel belangrijks heeft verwijderd, dan is het voor jullie een fluitje van een cent dat weer te herstellen.

Performance: lijkt me geen issue. Databases zijn prima in staat om grote hoeveelheden data door te worstelen, daar zijn ze namelijk voor gemaakt. Een index op de siteID kolom zal select-statements al zeer snel maken voor een bepaalde site.

Security: Het is natuurlijk mogelijk om met een andere siteID gegevens van een andere klant op je scherm te krijgen, maar dit hangt allemaal samen met hoe netjes er wordt geprogrameerd. Denk hierbij aan het voorkomen van sql-injection en cross-site scripting. Het maken van stored procedures waarin een siteID moet worden opgegeven kan bovendien de data nog verder afschermen. Fouten in query's zijn dan nog zeldzamer.

[Annie]

Mart! schreef op 14 December 2002 @ 15:40:
Development: Ik ga ervanuit dat het systeem initieel wordt neergezet voor klanten en dat er vervolgens uitbreidingen worden gemaakt. Wanneer je voor de andere opties gaat betekent het bij tabelaanpassingen dat je deze in alle tabellen moet doorvoeren. Bij de eerste oplossing slechts in 1. Dat vindt ik een heel groot voordeel, aangezien CMS- en documentbeheersystemen nooit af zijn en altijd uitgebreid worden.

Of je een update nu op 1 table moet doen of op 3 tables maakt mij niet zoveel uit. Evt is dat natuurlijk ook te automatiseren (een batch is zo gemaakt). Je moet alleen wel goed je versies en installaties bijhouden.

Mart! schreef op 14 December 2002 @ 15:40:
Onderhoud: Het appart backuppen van de databases vindt ik niet echt noodzakelijk. Het restoren van een backup doe je alleen in noodgevallen.

Jij vindt het misschien niet noodzakelijk, maar klanten wel. Als klant A een backup terug wil zetten, dan heeft klant B ook meteen oude data.

Mart! schreef op 14 December 2002 @ 15:40:
Houd er bijvoorbeeld bij het ontwerpen van je site rekening mee dat records niet echt worden verwijderd, maar worden 'gevlagd'. Belt er iemand op dat hij perongeluk iets heel belangrijks heeft verwijderd, dan is het voor jullie een fluitje van een cent dat weer te herstellen.

En wat als iemand belt dat deze per ongeluk iets heeft gewijzigd? Ga je daar dan ook wat voor verzinnen? Of per ongeluk iets heeft toegevoegd? Of iets toegevoegd en daarna gewijzigd? Of ...? Of ...? En hoe ga je om met referentiele integriteit?
Mooie functionaliteit natuurlijk, maar verder imho niet zo van belang in de afweging van de TS.

offtopic:
Ik neig er overigens naar om een klant verantwoordelijk te laten voor zijn/haar data (maar laten we dat maar even buiten deze discussie houden, dat zit meer in de functionele sfeer van de uiteindelijke applicatie). Met transaction log restores kan je overigens ook al een boel tergdraaien.