Archief - DISCUSSIE: values van dropdownmenus ook in databank of hard coderen?

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
k

keybern

Legacy Member
is het wijs om de ids en values van dropdownmenu's/ selectionlists (ook als het weinig waarschijnlijk is dat ze gaan wijzigen) op te nemen in de databank ipv hard te coderen? Ik denk dan aan bv. languages, countries, etc.

Het brengt wel wat overhead en vooral vertraging met zich mee, maar langs de andere kant vind ik het wel netjes om de data zo goed mogelijk te centraliseren in een databank.

Hoe denken jullie hierover? Bestaat er een bepaalde vuistregel hiervoor?
E

Erlend

Legacy Member
Zaken als landen zou ik niet in een databank(mysql, ...) stoppen.
Wat je wel kan doen: xml.
p

passero

Legacy Member
maak idd een xml en dan via een xslt kan je er eventueel een <select> van maken
N

NeoNeke

Legacy Member
één simpel antwoord:

indien je data veel aangepast moet worden steek je het best in database zodat je snel landen en talen gaat kunnen bijvoegen indien dat later nodig blijkt... En dit is dus niet het geval.

Maak idd een xml bestand aan voor dat of doe het nog simpelere maak een textbestandje aan met alle landen onder elkaar (die zijn trouwens te vinden op het internet) en gebruik die om uw dropdownlijst uit te lezen... (voor de id ofzo van een land/taal laat je gewoon via php/asp een teller meerunnen hé)
K

KoenDK

Legacy Member
NeoNeke zei:
één simpel antwoord:

indien je data veel aangepast moet worden steek je het best in database zodat je snel landen en talen gaat kunnen bijvoegen indien dat later nodig blijkt...
Klik om te vergroten...

de vraag is natuurlijk
hoe lang duurt het om de hardgecodeerde html aan te passen
om zo landen toe te voegen :p

en ik denk qua snelheid dat beide even lang duren :D



<option>BE</option>
dit kopieer ik 5 maal
en wijzig gewoon het land, control S en uploaden die handel


15seconden werk schat ik :D



of ben ik verkeerd aan het redeneren :x
k

keybern

Legacy Member
nee idd, daar heb je ook een punt.

Het zal dan alleen een pak moeilijker worden om ze dynamisch aan te passen. Dus via een form extra landen toevoegen ofzo... (wat meestal niet de bedoeling is natuurlijk)

Wat me stoort aan de xml of de hard coded manier is dat je dan in je databank met verwijzigen zit (ID's naar landen) terwijl die landen zelf niet in je databank staan. Iemand (persoon of applicatie) die je databank inspecteert zal er niets uit kunnen opmaken.

edit: een oplossing zou kunnen zijn: je ID's vervangen door iets wat toch van betekenis zou kunnen zijn voor een mens. In het geval van landen: landcodes (BE, NL, ...). Deze oplossing is echter voor lang niet alle zaken toepasbaar (talen, platforms, ... ?) en je databank wordt er een stukje groter op.
i

iamdesign

Legacy Member
als het maar 5 landen zijn en je hoeft deze nooit aan te passen kun je het idd hard coderen en zijn dat 15 goed benutte seconden, maar als je echter zoals op veel registratiepagina's alle landen van de wereld in cbobox steekt, dan is het beter deze via xml in te lezen (simpleXML om alleen maar te lezen).

Wil je ze echter nog vaak aanpasse (wat ik denk dat niet echt nodig is als je cbobox van alle landen bijhoudt kunde ze in DB steke)
R

Radiance

Legacy Member
Ik ben het niet echt eens met de meerderheid. Vooral hard-coded data vind ik bijna niet kunnen. Als je een applicatie van enige grootte ontwikkelt ga je al gauw merken dat elementen op verschillende plaatsen terugkomen en dat wanneer je bv. een jaar later wijzigingen moet maken dat het verdorie moeilijk is om op "15 seconden" je eigen code te doorgronden en te vinden waar dat ook weer stond.

Om nog maar te zwijgen van applicaties waar later (mogelijk) anderen verantwoordelijk voor zouden zijn. Steek alles toch gewoon in die database, tenzij je super high load toepassingen maakt (en daarvoor is er dan weer caching) zie ik weinig reden om zoiets te hardcoden.

XML opslag van gegevens is voor mij wel een optie, zeker als die XML feed bv. automatisch wordt aangeleverd door een externe bron.
e

el73

Legacy Member
Dingen als steden en landen stop ik in de database. De kans dat hier iets aan veranderd is klein, dus ik genereer een cached versie. Links in de database blijven dus bestaan, maar ik krijg niet te maken met de overhead die ontstaat als ik telkens een query zou moeten uitvoeren.

Een vraag voor de mensen die PHP gebruiken en dit type opties in XML willen stoppen: waarom? Je kan het net zo goed in een array stoppen en de PHP file includen.
N

NeoNeke

Legacy Member
je kan idd even goed een array gebruiker, maar een xml bestand gebruiken zou op de lange duur voordeel kunnen halen omdat je zo sneller semantieke linken aan het geheel kan toevoegen of zou je ergens een extern vrijgegeven xml bestand kunnen gebruiken dat volledig semantisch gemaakt is. Ik geef wel toe voor de moment zou ik het met een array doen, maar in het licht van Web2.0 is dit de discussie of we voor semantische content gaan of niet.

Anders is alles gezegd, meestal hangt het ook af hoeveel landen je wil tonen en op hoeveel pagina's. Ook of je de landen alfabetisch wil of niet...
e

el73

Legacy Member
NeoNeke zei:
... maar een xml bestand gebruiken zou op de lange duur voordeel kunnen halen ...
Klik om te vergroten...
Inderdaad. Zou. Misschien. In de toekomst. Zo ben je snel uren bezig met iets op poten te zetten dat niet nodig is en dat waarschijnlijk ook niet zal worden :)

Alles dat hier aan bod is gekomen heeft zijn nut. Het hangt van de situatie af welke methode je verkiest.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan