Tabelstructuur aanpasbare lay-out profielpagina*

[Verwijderd]

hallo,

ik vraag mij af hoe jullie dit zouden doen.
Je hebt een profiel. Mensen kunnen hun eigen achtergrond, kleuren en text etc wijzigen..Dit ga je niet in 1 tabel stoppen.

Hoe is de db structuur hiervan? Ik twijfel of het dit is
maar ja als je alleen een bg instelt zijn de andere veldje leeg

id | bg | textkleur | linkkleur | fontgrootte |
------------------------------------------------
1 |x.gif| 000 | 09F | 14


of moet je iets doen dat je alle aanpassingen ine en tabel zet en je zon soort tabel krijgt:

id | titel
----------
1 | bg
2 | textkleur
3 | linkleur
4 | fontgroote


user_id | layout_id | waarde

1 | 2 | 099
1 | 1 | x.gif


het enige is dan dat volgens mij het pvragen in het tweede vb langer duurt, maar minder ruimte kost?

wat denken jullie? een soort hyves dus

[ Voor 4% gewijzigd door Verwijderd op 09-12-2007 12:32 ]

[NMe]

Ik pas je titel even aan en verplaats je topic naar Software Engineering & Architecture, waar het thuishoort zoals je kan lezen in Waar hoort mijn topic?

PRG>>SEA

Over je vraag: Als het aantal aanpasbare dingen vaststaat en niet waarschijnlijk is dat er wat bij komt, dan zou ik persoonlijk voor het gemak eerder gaan voor de eerste optie, puur om het gebruiksgemak.

[cspare]

Ik zie geen (niet genoeg) voordelen voor de tweede optie. Performance en opslag ruimte verschil is nihil. Generieke opzetten zijn overrated.
Optie 1 is makkelijker, beter te begrijpen(= beter onderhoudbaar) en ook prima uitbreidbaar,

[NMe]

cspare schreef op zondag 09 december 2007 @ 12:59:
Ik zie geen (niet genoeg) voordelen voor de tweede optie. Performance en opslag ruimte verschil is nihil.

Dat zou ik niet zomaar zeggen. Bij erg veel profielen ga je het verschil, zeker in opslagruimte, toch wel merken. Opslag is dan wel weer de goedkoopste bottleneck, dus dat zou niet zo'n probleem moeten zijn.

[Verwijderd]

hmm..ok maar optie 1 is toch niet geoptimaliseerd? en je hebt veel lege ruimte als er niks wordt ingevuld...of zie ik het verkeerd?

optie twee is toch ook makkelijk uit te breiden??

[Xcalibur]

Ik heb me hier ook al vaker het hoofd over zitten breken. Afhankelijk van het aantal velden en de kans of er velden bij moeten kies is meestal toch voor optie 2, hoewel die wel lastiger te bouwen is....

Ben benieuwd of iemand betere ideeen / structuren heeft

[Verwijderd]

hoever ben je al?

[Boss]

Hoe ga je nu (bij optie 2) optie-waarden van verschillende types (blob, string, integer, float, ...) in 1 tabel zetten? Of doe je alles lekker ruim?
Daar gaat dan je voordeel van minder opslagruimte...

Ik zou ook voor optie 1 gaan.

[Kettrick]

Je kan de waarde ook nog normaliseren naar een eigen tabel, daar win je hier en daar ook nog een bitje mee

[cspare]

Hoeveel users denk je te gaan krijgen? En hoe belangrijk is de hoeveelheid opslag ruimte die je DB gaat gebruiken?

Als je je site nog moet lanceren zou ik voorlopig voor de makkelijke weg kiezen. eventuele performance problemen kan je relatief makkelijk oplossen dmv. cachen. mocht het echt uit de hand lopen kan je alsnog zonder heel veel moeite refactoren.

[Verwijderd]

refactoren??

maar even kijken ...als je voor methode 1 gaat moet je dus eerst een count doen om te kijken of de user wel een eigen layout heeft.. en stel je hebt 20 dingen die je aan je profiel kunt aanpassen en iemand doet alleen een bg...dan heb je 19 velden onbenut (in optie 2 heb je dat niet)

trouwens wat ik me ook afvraag hoe doe je dit met css..ik bedoel hoe ga je dit inladen...met een if elsje of met alternate?

[Boss]

Je moet dus voor alle opties een default hebben, en die overschrijven met eventuele zelf gekozen opties van de gebruiker.

Ik denk persoonlijk ook dat het hier compleet zinloos is om te gaan kijken naar de hoeveelheid ruimte die dit gaat innemen in de database. Pas bij enkele miljoenen gebruikers zou ik me daar zorgen over maken.

En dan blijft de eerste optie gewoon het makkelijkste te implementeren. Maar er was al eerder iets geschreven over over-normaliseren

[rvrbtcpt]

Ik zou met die algemene tabel werken

Tabel: userstyle
userid | propertyid | value

Het propertyid wordt dan: textkleur | linkkleur | fontgrootte
Deze lijst kun je vast bijhouden in een configuratie bestand of in een aparte tabel, dan krijg je twee tabellen.
Krijg je er een property bij, dan kun je die simpel toevoegen en een default waarde gegeven.
Je hebt dan flexibiliteit en toch maar twee tabellen.

Per user kun je alle gegevens uitlezen en ze dan, als je Java gebruikt, in een HashMap zetten waarbij het propertyid de key wordt.
Zo kun je gemakkelijk bij je gegevens zonder dat je moet gaan loopen.

[ Voor 12% gewijzigd door rvrbtcpt op 18-12-2007 12:34 ]

[Boss]

Zit je alleen nog met het probleem dat je nu gedwongen bent alle soorten properties in hetzelfde type veld onder te brengen...

[Verwijderd]

hmm das waar...maar hoe dan ...

en die count dan die je nu moet toepassen om t ekijken of iemand een eigen layout heeft?

[YopY]

Gewoon de eerste doen, de tweede is qua onderhoudbaarheid vanuit een webapplicatie misschien makkelijker, maar niet qua performance en dergelijke. Lege velden in een database zijn niet erg en hebben ook (lees: horen geen) negatieve invloed op de performance te hebben.

Voor de tweede oplossing kun je alles gewoon in (var)chars zetten lijkt mij, aangezien het lijkt alsof die gegevens direct in de html output gezet worden zonder dat er nog berekeningen en dergelijke op losgelaten worden.

[Verwijderd]

ok maar mijn vraag..

je moet ook een soort standaard values hebben...

je komt op een id..de querykijkt (waarschijnlijk met left join ipv count) of de user een layout hebt ...zo niet doe de standaard..en hier is het probleem...hoe zorg je voor d estandaard? doe je dat in je tabel of met een if elseje in je php?

[Boss]

Je hebt natuurlijk helemaal geen join nodig om te kijken of een user een eigen layout heeft. Er vanuitgaande dat je in de layout-tabel ook een kolom met UserID hebt opgenomen, en dat die ID gelijk is aan het UserID in de tabel met users.

Daarnaast zou je bijvoorbeeld 1 user kunnen toevoegen met als naam Default. Die kan niet inloggen, maar dat UserID gebruik je wel in de tabel met layout settings voor de default user.

Als je nu de gegevens nodig hebt: eerst een select op het UserID, en als die geen resultaten geeft doe je een nieuwe select met de UserID van de default user.

Wil een gebruiker nu ook een eigen layou maken, dan kopieer je de default regel en pas je de UserID aan.

[Verwijderd]

"Als je nu de gegevens nodig hebt: eerst een select op het UserID, en als die geen resultaten geeft doe je een nieuwe select met de UserID van de default user."

met mysql_num rows dus? hoe kun je anders zien of er geen rij is met die userid?