Onderwerp: Presentatie-volgorde DB-records beheren

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.

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.

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.

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

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/

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.

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

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

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.

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.

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

"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

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.

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.

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."