Presentatie-volgorde DB-records beheren

[Erick T. Barkhuis]

AAN: niwss-s en niwo, want op snijvlak client/server

KORT: ik zoek naar meningen en documentatie over handige manieren om
functionaliteit op te zetten voor een webbeheerder, die graag zelf wil
kunnen bepalen in welke volgorde DB-records worden gepresenteerd,
afwijkend van 'standaard' sortering


UITGEBREID:
Ongetwijfeld komt het vaker voor: een website waar database-records in
een door de eigenaar gewenste volgorde moeten worden getoond, in plaats
van via een 'standaard' sortering. Ik ben benieuwd naar manieren waarop
zoiets wordt aangepakt.

Situatie: webwinkel met categorieen van producten. Er verschijnt een
overzicht van (10-20) categorienamen uit een MySQL-database, nu nog
alfamoeilijk oplopend gesorteerd. Pagina-eigenaar wil graag zelf kunnen
vastleggen in welke volgorde die categorienamen worden gepresenteerd, bij
voorkeur mbv zijn admin-systeem waar hij ook nieuwe categorieen en
producten kan toevoegen, en bestaande kan wijzigen.

Gedachte: het is waarschijnlijk wel te doen om die categorienamen in een
select-box van zo'n 8 regels hoog te plaatsen. Een mechanisme om er
eentje te selecteren en met knopjes omhoog en omlaag te bewegen (zodat de
volgorde in die selectbox wordt beinvloed) lukt wellicht ook. Maar dan?
Opslaan van het rijtje in een bestand (of volgnummer in DB opslaan)? Bij
presentatie die volgorde laten overeenkomen met het resultaat van de
query?

Ik ben blij met opvattingen over hoe zoiets op te zetten. Ook zou ik het
fijn vinden een verwijzing te krijgen naar 'design patterns' voor zoiets.
Alvast hartelijk dank.


--
Erick

"Hmrph, ik moet ook geen Engels schrijven als het woord
waarschuwfloepvenster me niet te binnen wil schieten...." - gr-hk in niwo

[William Schokkele]

Beste Erick,

Ooit ook dit probleem gehad voor een site die ik heb ontworpen. Ik heb
in de databasetabel heel eenvoudig een veldje volgorde toegevoegd met
daarin de volgorde waarin de elementen moeten getoond worden.

Moet de volgorde veranderen, dan verander ik de nrs in de tabel, ietwat
onorthodox, maar aangezien ik het onderhoud zelf doe, voor mij de
makkelijkste oplossing. Je kan natuurlijk een klein admin-paginaatje
maken waarin dit op een gebruiksvriendelijker wijze kan gebeuren. Voor
mij gaat het hier ook over heel weinig records, als dat er wat meer
worden zou ik ook opteren voor een andere aanpak dan het manuele
veranderen in de tabel.

Op http://www.ivosa.be/htl/graduaat/ worden de elementen onder "maak je
keuze" gelezen uit een tabel en dan volgens een eigen aangeduide
volgorde weergegeven. In de SQL van de Stored Procedure staat dus
uiteindelijk heel eenvoudig ORDER BY volgorde.

Dus eigenlijk een antwoord naast je vraag naar "design patterns" en
theoretisch onderbouwde oplossing, maar voor mij alvast werkbaar.

Nu goed, een voor de hand liggende oplossing waar je wellicht zelf ook
al was opgekomen :)

Groetjes,

William

[Erick T. Barkhuis]

William Schokkele:
> Beste Erick,

Hoi William. Dank voor je reactie.
>
> Ooit ook dit probleem gehad voor een site die ik heb ontworpen. Ik heb
> in de databasetabel heel eenvoudig een veldje volgorde toegevoegd met
> daarin de volgorde waarin de elementen moeten getoond worden.
>
> Moet de volgorde veranderen, dan verander ik de nrs in de tabel, ietwat
> onorthodox, maar aangezien ik het onderhoud zelf doe, voor mij de
> makkelijkste oplossing.

Tja, zo kan het, zolang je zelf in de database kunt gaan grutten. :-)

Zoals je zelf al aanvoelde, probeer ik iets op te zetten waarbij dat nou
net niet nodig is. Bij het toevoegen van een nieuw item zou een beheerder
'lekker makkelijk' moeten kunnen aanwijzen waar dat item in het volgorde-
rijtje tussengevoegd moet worden (zonder handmatig ruimte te moeten maken
door allerlei nummertjes op te schuiven), en al 'even makkelijk' een paar
items qua volgorde kunnen verwisselen.

--
Erick

[Ronin]

On Fri, 29 Sep 2006 09:15:59 +0200, Erick T. Barkhuis
<erick.usenet@ardane.c-o-m> wrote:

> AAN: niwss-s en niwo, want op snijvlak client/server

> KORT: ik zoek naar meningen en documentatie over handige manieren om
> functionaliteit op te zetten voor een webbeheerder, die graag zelf wil
> kunnen bepalen in welke volgorde DB-records worden gepresenteerd,
> afwijkend van 'standaard' sortering

In principe vraag je naar het indexeren van een relationele database
en de verschillende sleutels die je bij de presentatie van de records
wilt gebruiken. In SQL kan je dat doen door veschillende indexbestan-
den aan te maken met: CREATE [UNIQUE] INDEX. De theorie die je zoekt
is "Relationeel database ontwerp"

HTH

--
Constant change is here to stay.

[Rene Pijlman]

Erick T. Barkhuis:
>Gedachte: het is waarschijnlijk wel te doen om die categorienamen in een
>select-box van zo'n 8 regels hoog te plaatsen. Een mechanisme om er
>eentje te selecteren en met knopjes omhoog en omlaag te bewegen (zodat de
>volgorde in die selectbox wordt beinvloed) lukt wellicht ook.

Zo werkt het min of meer in Plone. Maar dan zonder select-box. Er staat
een rijtje items voor je in een soort Explorer-view en met pijltjes beweeg
je die omhoog en omlaag.

Bij een ander systeem dat ik in gebruik heb (vBulletin) staan
volgordenummertjes en is er een beheerscherm met een overzicht van alle
items en hun volgordenummers, zodat je in één formulier de volgordenummers
van alle items kunt wijzigen en dit met één handeling opslaan.

Ik vind beide user-interfaces alleszins werkbaar en aanvaardbaar.

>Maar dan?
>Opslaan van het rijtje in een bestand (of volgnummer in DB opslaan)? Bij
>presentatie die volgorde laten overeenkomen met het resultaat van de
>query?

In een relationele database zou ik een volgnummer in de db opslaan. Onder
Plone ligt een object-database waarin de kinderen een 'list of object
references' zijn in de container.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Rene Pijlman]

Erick T. Barkhuis:
>Bij het toevoegen van een nieuw item zou een beheerder
>'lekker makkelijk' moeten kunnen aanwijzen waar dat item in het volgorde-
>rijtje tussengevoegd moet worden (zonder handmatig ruimte te moeten maken
>door allerlei nummertjes op te schuiven)

Het zal wel komen doordat Basic mijn eerste programmeertaal was, maar ik
nummer de items 10, 20, 30...

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Rene Pijlman]

Ronin:
>Erick T. Barkhuis
>> in welke volgorde DB-records worden gepresenteerd,
>> afwijkend van 'standaard' sortering
>
>In principe vraag je naar het indexeren van een relationele database
>en de verschillende sleutels die je bij de presentatie van de records
>wilt gebruiken. In SQL kan je dat doen door veschillende indexbestan-
>den aan te maken met: CREATE [UNIQUE] INDEX. De theorie die je zoekt
>is "Relationeel database ontwerp"

Welnee. Het heeft niets met sleutels en indexen te maken - laat staan
indexbestanden - en het gaat natuurlijk om 'order by' in de query, maar
_dat_ weet Erick ook wel.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Erick T. Barkhuis]

Rene Pijlman:
> Erick T. Barkhuis:
> >Bij het toevoegen van een nieuw item zou een beheerder
> >'lekker makkelijk' moeten kunnen aanwijzen waar dat item in het volgorde-
> >rijtje tussengevoegd moet worden (zonder handmatig ruimte te moeten maken
> >door allerlei nummertjes op te schuiven)
>
> Het zal wel komen doordat Basic mijn eerste programmeertaal was, maar ik
> nummer de items 10, 20, 30...

Is dat: 10,10,20,30,50,.... ?

Anyway, ook het nummeren met tussenruimtes zal, na verloop van tijd,
leiden tot het moeten opschuiven van volgnummers. Bovendien heb je dan
nog wat algoritmes nodig voor het bepalen van het 'tussenliggende
nummer'. Welke kies je als er iets komt tussen 20 en 25?

Tja, gebruik van pointers, kettingen, of hoe je ze wilt noemen.
Verwijzingen van de ene naar de volgende. Geen verkeerd plan, ook in een
relationele database. Maar het nadeel daarvan is dat volgordewisselingen
alweer een stukje lastiger worden, dunkt me. Ga ik nog even verder naar
kijken.

--
Erick

[Ronin]

On Fri, 29 Sep 2006 13:13:38 +0200, Rene Pijlman
<reply.in.the.newsgroup@my.address.is.invalid> wrote:

>>> in welke volgorde DB-records worden gepresenteerd, afwijkend van
>>> 'standaard' sortering

>> In principe vraag je naar het indexeren van een relationele database
>> en de verschillende sleutels die je bij de presentatie van de records
>> wilt gebruiken. In SQL kan je dat doen door veschillende indexbestan-
>> den aan te maken met: CREATE [UNIQUE] INDEX. De theorie die je zoekt
>> is "Relationeel database ontwerp"

> Welnee. Het heeft niets met sleutels en indexen te maken - laat staan
> indexbestanden - en het gaat natuurlijk om 'order by' in de query, maar
> _dat_ weet Erick ook wel.

De 'order by' clause is geen indexering? Nou, weer wat geleerd :-)

--
Constant change is here to stay.

[Rene Pijlman]

Erick T. Barkhuis:
>Anyway, ook het nummeren met tussenruimtes zal, na verloop van tijd,
>leiden tot het moeten opschuiven van volgnummers.

Ja, als het om heel veel items gaat dan wordt dat een probleem. Maar
meestal willen mensen alleen kleine aantallen itens handmatig in een
bepaalde volgorde zetten. Zo'n probleem is het toch niet om eens in de
vijf jaar de volgordenummertjes van je twaalf categorieën weer op 10, 20,
30, ... 120 te zetten?

En anders is er nog de Basic-oplossing: RENUMBER :-)

>Tja, gebruik van pointers, kettingen, of hoe je ze wilt noemen.
>Verwijzingen van de ene naar de volgende.

Het model in Plone is conceptueel gezien geen ketting (linked list), maar
een array van object-id's in de container/parent:

[2612, 1235199, 53017663, 6720, 87474]

En een volgordewijziging bestaat uit het vervangen van die array door:

[1235199, 2612, 6720, 87474, 53017663]

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Rene Pijlman]

Ronin:
>De 'order by' clause is geen indexering?

Inderdaad. 'Order by' is de rijen in een resultaattabel in een bepaalde
volgorde zetten. De engine gebruikt daarbij indexen als dat kan en als dat
efficiënt is, maar sorteert ook zonder indexen.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Ronin]

On Fri, 29 Sep 2006 13:11:41 +0200, Rene Pijlman
<reply.in.the.newsgroup@my.address.is.invalid> wrote:

>> Bij het toevoegen van een nieuw item zou een beheerder
>> 'lekker makkelijk' moeten kunnen aanwijzen waar dat item in het volgorde-
>> rijtje tussengevoegd moet worden (zonder handmatig ruimte te moeten maken
>> door allerlei nummertjes op te schuiven)

> Het zal wel komen doordat Basic mijn eerste programmeertaal was, maar ik
> nummer de items 10, 20, 30...

Dat is een sequentiele database, geen relationele.

--
Constant change is here to stay.

[Ronin]

On Fri, 29 Sep 2006 13:27:26 +0200, Rene Pijlman
<reply.in.the.newsgroup@my.address.is.invalid> wrote:

>> De 'order by' clause is geen indexering?

> Inderdaad. 'Order by' is de rijen in een resultaattabel in een bepaalde
> volgorde zetten. De engine gebruikt daarbij indexen als dat kan en als dat
> efficiënt is, maar sorteert ook zonder indexen.

En de clausule die je bij de sortering gebruikt heet sleutel. Je hebt
het over virtueel indexeren. Want waar haal je het volgende record
vandaan als er geen index bestaat?

--
Constant change is here to stay.

[Erick T. Barkhuis]

Ronin:
> On Fri, 29 Sep 2006 13:27:26 +0200, Rene Pijlman
> <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>
> >> De 'order by' clause is geen indexering?
>
> > Inderdaad. 'Order by' is de rijen in een resultaattabel in een bepaalde
> > volgorde zetten. De engine gebruikt daarbij indexen als dat kan en als dat
> > efficiënt is, maar sorteert ook zonder indexen.
>
> En de clausule die je bij de sortering gebruikt heet sleutel. Je hebt
> het over virtueel indexeren. Want waar haal je het volgende record
> vandaan als er geen index bestaat?

Maar wat heeft die virtuele index nu te maken met CREATE INDEX?

--
Erick

"kleine letters maken subdomeinen mogelijk" - aljo in niwo

[Rene Pijlman]

Ronin:
>En de clausule die je bij de sortering gebruikt heet sleutel.

Sleutel slaat in de relationele terminologie op de kolommen die de rijen
in een tabel uniek identificeren. Na 'order by' kun je op een willekeurige
combinatie van kolommen sorteren, dat hoeft helemaal geen sleutel te zijn.

Het stuk na de 'order by' wordt in het boek "SQL-99 Complete" over de
SQL-standaard de 'sort specification list' genoemd.

Veel databases staan toe om na 'order by' vrije expressies op te nemen:

select col1
from table
order by col2 + col5

In dat geval is er geen index. De engine moet de expressie voor elke rij
evalueren en ad hoc sorteren.

>Want waar haal je het volgende record vandaan als er geen index bestaat?

De rijen worden gesorteerd aan de hand van de 'order by'-expressie, die
zonodig per rij geëvalueerd moet worden.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Ronin]

On Fri, 29 Sep 2006 13:38:49 +0200, Erick T. Barkhuis
<erick.usenet@ardane.c-o-m> wrote:

>>>> De 'order by' clause is geen indexering?

>>> Inderdaad. 'Order by' is de rijen in een resultaattabel in een bepaalde
>>> volgorde zetten. De engine gebruikt daarbij indexen als dat kan en als dat
>>> efficiënt is, maar sorteert ook zonder indexen.

>> En de clausule die je bij de sortering gebruikt heet sleutel. Je hebt
>> het over virtueel indexeren. Want waar haal je het volgende record
>> vandaan als er geen index bestaat?

> Maar wat heeft die virtuele index nu te maken met CREATE INDEX?

Ik weet niet wat efficienter is in het ontwerp. IMO is virueel index-
eren nogal een hog. Ik ben voorstander van lezen uit een index en
daarna deelverzamelingen virtueel indexeren. Dat is driedimensioneel
ontwerp en is in de meeste situaties het efficientst IMO. Zodoende..

--
Constant change is here to stay.

[Ronin]

On Fri, 29 Sep 2006 13:45:18 +0200, Rene Pijlman
<reply.in.the.newsgroup@my.address.is.invalid> wrote:


>> En de clausule die je bij de sortering gebruikt heet sleutel.

> Sleutel slaat in de relationele terminologie op de kolommen die de rijen
> in een tabel uniek identificeren. Na 'order by' kun je op een willekeurige
> combinatie van kolommen sorteren, dat hoeft helemaal geen sleutel te zijn.

Nee, 'sleutel' slaat op het algoritme dat die kolommen uniek
identificeert.

--
Constant change is here to stay.

[Ronin]

On Fri, 29 Sep 2006 13:49:11 +0200, Ronin <ronin@xs4all.invalid>
wrote:

>>> En de clausule die je bij de sortering gebruikt heet sleutel.

>> Sleutel slaat in de relationele terminologie op de kolommen die de rijen
>> in een tabel uniek identificeren. Na 'order by' kun je op een willekeurige
>> combinatie van kolommen sorteren, dat hoeft helemaal geen sleutel te zijn.

> Nee, 'sleutel' slaat op het algoritme dat

elementen in

> die kolommen uniek identificeert.

Excuus voor m'n slordigheid..

--
Constant change is here to stay.

[Rene Pijlman]

Ronin:
>Rene Pijlman
>> Sleutel slaat in de relationele terminologie op de kolommen die de rijen
>> in een tabel uniek identificeren. Na 'order by' kun je op een willekeurige
>> combinatie van kolommen sorteren, dat hoeft helemaal geen sleutel te zijn.
>
>Nee, 'sleutel' slaat op het algoritme dat die kolommen uniek
>identificeert.

Nee, dat is onjuist. Een sleutel is een verzameling kolommen.

"Definitie: Een (kandidaat)sleutel voor een relatie is een niet-lege
verzameling attributen waarvan de waardecombinaties, mits daarin geen
nulwaarden voorkomen, kunnen zorgen voor de unieke identificatie van de
tupels in iedere mogelijke extensie van de relatie, zonder dat de
verzameling overtollige attributen bevat."

Gegevensmodellering en gegevensbanken, K.A.M. Lemmen e.a., Open
Universiteit, 1988. Hoofdstuk 3 in deel 2: "Sleutels".

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Erick T. Barkhuis]

Rene Pijlman:

> Een sleutel is een verzameling kolommen.
>
> "Definitie: Een (kandidaat)sleutel voor een relatie is een niet-lege
> verzameling attributen waarvan de waardecombinaties, mits daarin geen
> nulwaarden voorkomen, kunnen zorgen voor de unieke identificatie van de
> tupels in iedere mogelijke extensie van de relatie, zonder dat de
> verzameling overtollige attributen bevat."
>
> Gegevensmodellering en gegevensbanken, K.A.M. Lemmen e.a., Open
> Universiteit, 1988.

Dat beschreven ze in de Teleac-cursus Database Management van 1992 toch
wat eenvoudiger, zodat ook simpele zielen het konden begrijpen:

"Een kandidaatsleutel van een relatie R is een minimale verzameling
attributen met de eigenschap dat zij tupels van R uniek identificeert."

Kun je bijna een Schlager van maken!

--
Erick
B&B Ardane - http://bed-and-breakfast.ardane.com/

[Ronin]

On Fri, 29 Sep 2006 14:29:35 +0200, Rene Pijlman
<reply.in.the.newsgroup@my.address.is.invalid> wrote:

>>> Sleutel slaat in de relationele terminologie op de kolommen die de rijen
>>> in een tabel uniek identificeren. Na 'order by' kun je op een willekeurige
>>> combinatie van kolommen sorteren, dat hoeft helemaal geen sleutel te zijn.

>> Nee, 'sleutel' slaat op het algoritme dat die kolommen uniek
>> identificeert.

> Nee, dat is onjuist. Een sleutel is een verzameling kolommen.

> "Definitie: Een (kandidaat)sleutel voor een relatie is een niet-lege
> verzameling attributen waarvan de waardecombinaties, mits daarin geen
> nulwaarden voorkomen, kunnen zorgen voor de unieke identificatie van de
> tupels in iedere mogelijke extensie van de relatie, zonder dat de
> verzameling overtollige attributen bevat."

> Gegevensmodellering en gegevensbanken, K.A.M. Lemmen e.a., Open
> Universiteit, 1988. Hoofdstuk 3 in deel 2: "Sleutels".

Uit "Informatiestructuren, bestandsorganisatie en bestandsontwerp" EIT
Dictatenserie, Academic service 1982. Hoofdstuk 2.3.

"De een bepaald verband hebbende items worden als regel verzameld tot
een bepaald recordtype, bijvoorbeeld omdat de gegevens betrekking
hebben op eenzelfde persoon of eenzelfde apparaat of eenzelfde complex
van activiteiten ('entity' of 'object') Is de naam van de entity
expliciet in het record opgenomen, dan heet dit centrale item meestal
sleutelitem of recordsleutel; de waarde van het sleutelitem heet de
sleutel (key) omdat dit gegeven als het ware de toegang geeft tot
andere bij dit item behorende gegevens."

Aangezien we inmiddels met complexe relaties werken, kan je het begrip
waarde vervangen door algoritme IMO. De sleutel is dan: "Een algoritme
dat de berekking beschrijft van entities of objects in de gegevens-
verzameling.

--
Constant change is here to stay.

[Erick T. Barkhuis]

Ronin:

> Is de naam van de entity
> expliciet in het record opgenomen, dan heet dit centrale item meestal
> sleutelitem of recordsleutel; de waarde van het sleutelitem heet de
> sleutel (key) omdat dit gegeven als het ware de toegang geeft tot
> andere bij dit item behorende gegevens."
>
> Aangezien we inmiddels met complexe relaties werken, kan je het begrip
> waarde vervangen door algoritme IMO.

Dit begrijp ik nog niet zo goed.
Zijn relaties tussen twee entiteiten complexer geworden in de afgelopen
20 jaar?


--
Erick

"A quick question is one that was formulated quickly, thus greatly
increasing the time needed for getting a useful answer" - Yukka Korpela

[Rene Pijlman]

Ronin:
>Aangezien we inmiddels met complexe relaties werken, kan je het begrip
>waarde vervangen door algoritme IMO.

Ik kan je niet volgen. Waarde en algoritme zijn twee totaal verschillende
dingen, in het normale spraakgebruik van informatici.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Ronin]

On Fri, 29 Sep 2006 15:30:46 +0200, Rene Pijlman
<reply.in.the.newsgroup@my.address.is.invalid> wrote:

>> Aangezien we inmiddels met complexe relaties werken, kan je het begrip
>> waarde vervangen door algoritme IMO.

> Ik kan je niet volgen. Waarde en algoritme zijn twee totaal verschillende
> dingen, in het normale spraakgebruik van informatici.

Ja.. ik extrapoleer 'waarde'. In de zin dat ik nu 'algoritme' gebruik
in plaats van 'waarde'. Een algoritme is IMO begrepen om de relatie
tussen waarden van items te beschrijven. Een 'sleutel' is in deze zin
een beschrijving van de relatie van de waarden van entiteiten.

--
Constant change is here to stay.

[Ronin]

On Fri, 29 Sep 2006 15:04:28 +0200, Erick T. Barkhuis
<erick.usenet@ardane.c-o-m> wrote:

>> Is de naam van de entity
>> expliciet in het record opgenomen, dan heet dit centrale item meestal
>> sleutelitem of recordsleutel; de waarde van het sleutelitem heet de
>> sleutel (key) omdat dit gegeven als het ware de toegang geeft tot
>> andere bij dit item behorende gegevens."

>> Aangezien we inmiddels met complexe relaties werken, kan je het begrip
>> waarde vervangen door algoritme IMO.

> Dit begrijp ik nog niet zo goed.
> Zijn relaties tussen twee entiteiten complexer geworden in de afgelopen
> 20 jaar?

Dit ging natuurlijk over een sequentiele relatie, inmiddels hanteren
we ook netwerkrelaties, bijvoorbeeld in een relationele database..

--
Constant change is here to stay.

[David Baakman]

Erick T. Barkhuis wrote...

> Tja, gebruik van pointers, kettingen, of hoe je ze wilt noemen.
> Verwijzingen van de ene naar de volgende. Geen verkeerd plan, ook in een
> relationele database. Maar het nadeel daarvan is dat volgordewisselingen
> alweer een stukje lastiger worden, dunkt me. Ga ik nog even verder naar
> kijken.

Wat imho een belangrijkere ontwerpbeslissing is is dat het gebruik van
pointers het ophalen moeilijker maken (recursieve queries in het ergste
geval :)). Het ophalen van de gegevens zal als het goed is vele malen
vaker voorkomen dan het aanpassen van de gegevens, dus ik zou uitgaan
van het makkelijk kunnen ophalen van de gegevens in de juiste volgorde.
Dus dat is gewoon een integer veld (voor het gemak verder: defaultOrder)
aan de tabel toevoegen.

Het ophalen van de gegevens kan dan gewoon met een simpele select met
een sort by clause.

Bij het wijzigen zou ik uitgaan van een interface waarin de beheerder
een lijst ziet van elementen en per regel een pijl omhoog en een pijl
naar beneden heeft (behalve op de eerste en de laatste regel) om het
element naar boven / beneden te verschuiven. Op het moment dat een
gebruiker op zo'n pijl klikt, voer je 2 update queries uit om de twee
gewijzigde elementen aan te passen (je verwisselt de default order van
de twee records).

Een rij verwijderen kan zonder problemen, hoef je nergens rekening mee
te houden.

Een rij toevoegen kan door de defaultOrder op max(defaultOrder)+1 te
zetten.

Mogelijke uitbreidingen (alleen nuttig indien gebruikers deze
informatiefuntie vaak gebruiken):
- Verspringingen per 10 mogelijk maken (11 update queries!).
- Handmatig defaultOrder invoeren.
- Mogelijkheid bieden om automatisch defaultOrders te normaliseren.
- Coole, hippe Web 2.0 AJAX technologie gebruiken om de elementen door
middel van sleur-en-pleur te wijzigen.

Groeten,
David

[Warden Dave]

"David Baakman" <davidbaakman@nl.invalid> wrote:
> Erick T. Barkhuis wrote...

>> Tja, gebruik van pointers, kettingen, of hoe je ze wilt noemen.
>> Verwijzingen van de ene naar de volgende. Geen verkeerd plan, ook in
>> een relationele database. Maar het nadeel daarvan is dat volgorde-
>> wisselingen alweer een stukje lastiger worden, dunkt me. Ga ik nog
>> even verder naar kijken.

> Wat imho een belangrijkere ontwerpbeslissing is is dat het gebruik
> van pointers het ophalen moeilijker maken (recursieve queries in het
> ergste geval :)).
<knip>
> Dus dat is gewoon een integer veld (voor het gemak verder:
> defaultOrder) aan de tabel toevoegen.
>
> Het ophalen van de gegevens kan dan gewoon met een simpele select met
> een sort by clause.

Dat lijkt 't simpelste, al bestaat er 't genoemde nadeel dat grotere
hoeveelheden records zullen moeten worden aangepast bij bijv. het in-
voegen van records. Bij een niet al te grote DB zal dat geen bezwaar
zijn.

> Bij het wijzigen zou ik uitgaan van een interface waarin de beheerder
> een lijst ziet van elementen en per regel een pijl omhoog en een pijl
> naar beneden heeft (behalve op de eerste en de laatste regel) om het
> element naar boven / beneden te verschuiven. Op het moment dat een
> gebruiker op zo'n pijl klikt, voer je 2 update queries uit om de twee
> gewijzigde elementen aan te passen (je verwisselt de default order van
> de twee records).

Dat is m.i. wat te 1-voudig & mogelijk traag. Als de gebruiker dan rap
pijlen wil drukken, of vrolijk verslepen, dan zal het allereerst
uitsluitend client-side afhandelen van die bewegingen al werk genoeg
zijn. Je kunt later alsnog de wijzigingen op de bus doen (met 'Bewaar'-
knop of bij 'unload').

WD

[Operator]

In article <ki8qh2l7g3560opd92fontsransimvsqun@4ax.com>,
Ronin <ronin@xs4all.invalid> writes:
> On Fri, 29 Sep 2006 15:04:28 +0200, Erick T. Barkhuis
> <erick.usenet@ardane.c-o-m> wrote:
>
>>> Is de naam van de entity
>>> expliciet in het record opgenomen, dan heet dit centrale item meestal
>>> sleutelitem of recordsleutel; de waarde van het sleutelitem heet de
>>> sleutel (key) omdat dit gegeven als het ware de toegang geeft tot
>>> andere bij dit item behorende gegevens."

Dat is slechts e1n voorbeeld. In een relationeel model kan het voorkomen
dat een sleutel gevormd wordt door meerdere attributen (items, kolommen).

>>> Aangezien we inmiddels met complexe relaties werken, kan je het begrip
>>> waarde vervangen door algoritme IMO.

Nou nee.

>> Dit begrijp ik nog niet zo goed.
>> Zijn relaties tussen twee entiteiten complexer geworden in de afgelopen
>> 20 jaar?
>
> Dit ging natuurlijk over een sequentiele relatie, inmiddels hanteren
> we ook netwerkrelaties, bijvoorbeeld in een relationele database..

Relationele databases zijn ontstaan uit het wiskundige begrip relatie.
Daar is de afgelopen 20 jaar niet zoveel aan veranderd en het heeft
niets van doen met "netwerkrelaties" enzo.

Wat er na een order by staat is _geen_ sleutel. De order by clause
is slechts een sorteer opdracht.

[Ronin]

On 29 Sep 2006 19:48:40 GMT, root@mier.doktercom.nl (Operator) wrote:


> Relationele databases zijn ontstaan uit het wiskundige begrip relatie.
> Daar is de afgelopen 20 jaar niet zoveel aan veranderd en het heeft
> niets van doen met "netwerkrelaties" enzo.

> Wat er na een order by staat is _geen_ sleutel. De order by clause
> is slechts een sorteer opdracht.

Ja hoor..

--
Constant change is here to stay.

[Erick T. Barkhuis]

Ronin:
> On 29 Sep 2006 19:48:40 GMT, root@mier.doktercom.nl (Operator) wrote:

> > Wat er na een order by staat is _geen_ sleutel. De order by clause
> > is slechts een sorteer opdracht.
>
> Ja hoor..

Jazeker.

--
Erick

"When a husband brings his wife flowers for no reason, there's a
reason."

[Martien van Wanrooij]

"Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> schreef in bericht
news:MPG.1f86e697e60bb83c98a1d5@news.individual.ne t...
> KORT: ik zoek naar meningen en documentatie over handige manieren om
> functionaliteit op te zetten voor een webbeheerder, die graag zelf wil
> kunnen bepalen in welke volgorde DB-records worden gepresenteerd,
> afwijkend van 'standaard' sortering
Erick,

Ik weet niet of dit je probleem oplost en ik ben ook nog niet zo geweldig
ervaren maar ik heb een keer een vergelijkbaar probleem gehad. De webmaster
van een orkestje wilde zijn songlist kunnen updaten en hij wilde daarbij ook
kunnen bepalen wáár nieuwe liedjes kwamen te staan, m.a.w. als het orkest
besluit voortaan een bepaald lied in het repertoire op te nemen dan hoeft
dat nog helemaal niet te betekenen dat het op de webpagina bovenaan of juist
onderaan staat. Ik heb ervoor gekozen om elk liedje in de database naast het
automatisch gegenereerde sleutelveld-id een extra veld mee te geven met de
naam "positie". In de beheerspagina verschijnt de songlist met na elk liedje
de opties "bewerken" , "verwijderen" en "hieronder een nieuwe song
invoegen".
Als hij, zeg maar bij liedje nummer 8 op die optie klikt, voegt hij het
nieuwe liedje in, de sql-opdrachten zorgen ervoor dat alle positienummers
hoger dan 9 met één verhoogd worden, en het nieuwe liedje krijgt nummer 9.
Ik moet er wel bij zeggen dat ik nog niet geimplementeerd heb dat hij
liedjes kan "verschuiven" - hij vond dat verder ook niet zo belangrijk -
maar misschien heb je wat aan dit idee.

Martien

[Erick T. Barkhuis]

Martien van Wanrooij:
>
> "Erick :
> > KORT: ik zoek naar meningen en documentatie over handige manieren om
> > functionaliteit op te zetten voor een webbeheerder, die graag zelf wil
> > kunnen bepalen in welke volgorde DB-records worden gepresenteerd,
> > afwijkend van 'standaard' sortering

> Ik heb ervoor gekozen om elk liedje in de database naast het
> automatisch gegenereerde sleutelveld-id een extra veld mee te geven met de
> naam "positie". In de beheerspagina verschijnt de songlist met na elk liedje
> de opties "bewerken" , "verwijderen" en "hieronder een nieuwe song
> invoegen".

Hoi Martien,
Dat lijkt me inderdaad een handige methode voor een beheerder die
voldoende heeft aan het eenmalig bepalen van de juiste plek.
Dankjewel voor je uitleg.

In mijn geval staat de beheerder er op ook achteraf de volgorde 'eventjes
makkelijk' te kunnen wijzigen. Daarom heb ik uiteindelijk, mede n.a.v.
suggesties hier, een combinatie gemaakt van:
- volgorde-veld in de tabel
- client-side javascriptfunctie voor het wijzigen van de plek van een
item
- bij presentatie sorteren op dat volgorde veld.

Het werkt naar behoren, al heb ik die beheerder er in productie-omgeving
nog geen gebruik van zien maken... :-)

--
Erick

[Martien van Wanrooij]

"Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> schreef in bericht
news:MPG.1f9212069f85ee5798a206@news.individual.ne t...
> Het werkt naar behoren, al heb ik die beheerder er in productie-omgeving
> nog geen gebruik van zien maken... :-)
Tja sommige mensen kopen schoenen om ze vervolgens nooit aan te trekken :)

[Erick T. Barkhuis]

Martien van Wanrooij:
>
> "Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> schreef in bericht
> news:MPG.1f9212069f85ee5798a206@news.individual.ne t...
> > Het werkt naar behoren, al heb ik die beheerder er in productie-omgeving
> > nog geen gebruik van zien maken... :-)

> Tja sommige mensen kopen schoenen om ze vervolgens nooit aan te trekken :)

Grrrr....breek me de bek niet los!

--
Erick
[die dit jaar bij zijn verhuizing werd geconfronteerd met de schoenenkast
van 'sommige mensen' in hetzelfde huishouden, en nu twintig paar schoenen
uit de jaren 70, 80 en 90 aanbiedt. Tweedehands maar ongebruikt]