database structuur profielopties

[ZeroXT]

Beste Tweakers,

Voor een website moet ik profielgegevens opslaan in de database. Normaal gesproken is dat geen probleem alleen zijn het dit keer erg veel opties die opgeslagen moeten worden. Opties zoals geboortedatum en nickname maar ook opties zoals of die gene rookt, haarkleur, profielomschrijving ect. Deze opties zijn bij elkaar ong. 100 stuks, dus per profiel zijn er 100 opties die opgeslagen moeten worden in de database.

Zoals ik het nu heb is dat de opties in de database beschreven staat in een tabel en er een ander tabel is waar die opties samen met de gebruiker id gekoppeld worden. Dus voor elk gebruiker zijn er dan 100 records.

Nu was mijn vraag, is dit wel handig? Want dat betekend dat als er 200.000 gebruikers zijn er 20.000.000 records zijn wat ik wel erg veel vind voor het aantal gebruikers.

Weet iemand een efficiënte manier van opslaan?

[Gomez12]

Wat is het probleem van 20.000.000 records?

Als je het echt te veel vind zou je de tabel nog kunnen splitsen op 2 of 3 soorten records (yes/no antwoorden / numerieke antwoorden en string-antwoorden bijv )

Maar je aanpak is in principe goed (zolang je maar niet alles als string behandelt, een profielomschrijving (string/text) is iets anders als of een gebruiker rookt (j/n), dat krijg je niet in 1 optieveld gepropt)

Maar zoals zo vaak opgaat : Krijg eerst maar eens die 200.000 gebruikers en ga je dan halverwege dat traject eens druk maken om dit soort dingen. 20.000.000 records is geen probleem voor een dbase maak je daar geen zorgen over zonder dat je 1 gebruiker hebt.
In de aanloop naar 200.000 gebruikers ga je nog genoeg veranderingen krijgen / dingen vergeten zijn.

[ Voor 30% gewijzigd door Gomez12 op 09-10-2011 15:06 ]

[djluc]

Want dat betekend dat als er 200.000 gebruikers zijn er 20.000.000 records zijn wat ik wel erg veel vind voor het aantal gebruikers.

Als je 100% alle opties in gaat voeren wel ja, hoe groot is die kans? Lijkt me niet dat dat gaat gebeuren? Dus kan je constateren dat het er een stuk minder zijn. Als iedereen alles wel invult kan je beter het gewoon in de tabel zetten, dan hoef je geen relaties meer op te zetten die je anders iedere keer alsnog gaat maken.

[cariolive23]

djluc schreef op zondag 09 oktober 2011 @ 16:46:
[...]
Als je 100% alle opties in gaat voeren wel ja,

Dan is het nog steeds niet overdreven veel. Het gaat om 20 miljoen records, hier druk ik dit dagelijks in een PostgreSQL database. Dat is de dagelijkse groei, naast de reeds aanwezige x-miljard records.

20 miljoen records is geen enkel probleem voor een database, het gaat erom wat je er in stopt (datatypes en datamodel) ben hoe je het weer opvraagt. Dat moet je slim doen om goede performance te krijgen.

[Wolfboy]

Als de eigenschappen vast zijn (nooit veranderen dus) dan is de beste optie (imho) om het gewoon in 1 tabel te stoppen.

Maar zoals je het beschrijft klinkt het meer als een systeem waar het aantal eigenschappen per gebruiker verschillen en waar extra eigenschappen bij komen.


In dat geval zou je eens moeten kijken naar een document storage oplossing zoals CouchDB

[Gomez12]

Wolfboy schreef op zondag 09 oktober 2011 @ 19:24:
Als de eigenschappen vast zijn (nooit veranderen dus) dan is de beste optie (imho) om het gewoon in 1 tabel te stoppen.

Daar zijn nog wel wat meer afwegingen voor nodig hoor. Je wilt ook weer geen grote rows hebben...

In dat geval zou je eens moeten kijken naar een document storage oplossing zoals CouchDB

Geef er dan aub eens wat argumentatie bij...
Waarom niet alles in 1 dbms houden en als je het al zou scheiden, waarom dan specifiek een document storage oplossing itt tot de 10.000'en andere key-value implementaties die er bestaan.

[ZeroXT]

Hartelijk bedankt voor de reacties maar ik denk dat mijn vraag verkeerd begrepen is. Ik zie namelijk een hoop mensen zeggen dat 20mil geen probleem is voor een database maar dat wist ik al

Het gaat mij erom dat 20mil in verhouding met het aantal gebruikers veel is. Ik snap dat als je 100 opties wilt opslaan je in het 'ergste' geval, zoals nu ook het geval is 20mil records opslaat wanneer iedereen alles invult maar ik hoopte op een beter en efficiënte manier van opslaan in de database.

[R4gnax]

ZeroXT schreef op zondag 09 oktober 2011 @ 20:40:
Hartelijk bedankt voor de reacties maar ik denk dat mijn vraag verkeerd begrepen is. Ik zie namelijk een hoop mensen zeggen dat 20mil geen probleem is voor een database maar dat wist ik al

Het gaat mij erom dat 20mil in verhouding met het aantal gebruikers veel is. Ik snap dat als je 100 opties wilt opslaan je in het 'ergste' geval, zoals nu ook het geval is 20mil records opslaat wanneer iedereen alles invult maar ik hoopte op een beter en efficiënte manier van opslaan in de database.

Als profielen voornamelijk als geheel opgehaald en getoond worden en slechts doorzocht hoeven worden, dan kun je er natuurlijk nog voor kiezen om per gebruiker het complete profiel in een XML veld op te slaan en alleen de doorzoekbare properties als losse velden. (O.a. de standaard implementatie van gebruikersprofielen in ASP.NET slaat profielen op als XML; het hoeft zeker niet langzaam te zijn.)

[Gomez12]

R4gnax schreef op maandag 10 oktober 2011 @ 09:11:
[...]


Als profielen voornamelijk als geheel opgehaald en getoond worden en slechts doorzocht hoeven worden, dan kun je er natuurlijk nog voor kiezen om per gebruiker het complete profiel in een XML veld op te slaan en alleen de doorzoekbare properties als losse velden. (O.a. de standaard implementatie van gebruikersprofielen in ASP.NET slaat profielen op als XML; het hoeft zeker niet langzaam te zijn.)

Yep, dbase in dbase is echt de meest efficiënte vorm...

[YopY]

R4gnax schreef op maandag 10 oktober 2011 @ 09:11:
[...]


Als profielen voornamelijk als geheel opgehaald en getoond worden en slechts doorzocht hoeven worden, dan kun je er natuurlijk nog voor kiezen om per gebruiker het complete profiel in een XML veld op te slaan en alleen de doorzoekbare properties als losse velden. (O.a. de standaard implementatie van gebruikersprofielen in ASP.NET slaat profielen op als XML; het hoeft zeker niet langzaam te zijn.)

^ Niet doen dus, . Hoe doorzoek je een tabel waar een deel van de data in XML zit? Stel iemand z'n haarkleur zit in die XML, hoe zoek je dan iedereen op die een bepaalde kleur haar heeft?

Juist, alle XML in alle records parsen en doorzoeken. Lekker efficient.

@thread, oplossing is niks mis mee. Alternatief is een schema-less storage (key/value store), MongoDB, CouchDB, etc. Hoef je ook geen databasestructuur te bedenken en bij te houden, of in je code een ORM laag te bouwen.

[Guillome]

Je moet wel lezen, hij heeft het over items die niet op gezocht hoeft te worden, die stop je in XML. Bijv uitgebreid profiel of achtergrond info van iemand ofzo

[Wolfboy]

Gomez12 schreef op zondag 09 oktober 2011 @ 19:38:
[...]

Daar zijn nog wel wat meer afwegingen voor nodig hoor. Je wilt ook weer geen grote rows hebben...

Verschilt uiteraard nogal per database wat daar zinnig is, aangezien de TS niet verteld welke database server hij gebruikt kunnen we daar geen aannames over doen.

Geef er dan aub eens wat argumentatie bij...
Waarom niet alles in 1 dbms houden en als je het al zou scheiden, waarom dan specifiek een document storage oplossing itt tot de 10.000'en andere key-value implementaties die er bestaan.

Wie zegt dat het niet in 1 dbms zou komen? Ik zeg alleen dat je voor document storage beter een dbms kan gebruiken wat specifiek ontworpen is voor document storage.

Een key-value systeem (EAV) wat de TS nu voorstelt is kwa performance en efficientie (zeker bij veel velden) niet bijzonder handig. Het _kan_ uiteraard prima met een rdbms, het is alleen een lastigere oplossing.

[ZeroXT]

Nogmaals bedankt voor de antwoorden. Ik zal even wat meer informatie geven. Het betreft een Mysql database die met het programmeer/script-taal PHP wordt benaderd.

Alle profielopties moeten ook doorzocht worden.

[JaQ]

YopY schreef op maandag 10 oktober 2011 @ 10:08:
^ Niet doen dus, . Hoe doorzoek je een tabel waar een deel van de data in XML zit? Stel iemand z'n haarkleur zit in die XML, hoe zoek je dan iedereen op die een bepaalde kleur haar heeft?

Nou, gewoon door de kolom als xmltype te typeren.