---

Vil der være noget i vejen med at lave en kolonne der indeholder en URL til
den primære nøgle med index på ? De aktuelle URLs kan vel i princippet være
op til 100+ tegn lange, men hvis kolonnen indexeres, så er det vel ikke
betydningsfuldt ?

Kan man som regel sige, at performance forbedres ved at holde de primære
nøglekolonner så "simple" som muligt - dvs integer, tinyint etc ... eller
er det hip som hap ?

--
Jesper Stocholm - http://stocholm.dk

Synes du også, at Britney trods alt er meget lækker - men dog
på grænsen til det kvalmende ? http://stocholm.dk/britney.txt

---

Jesper Stocholm wrote:

> Vil der være noget i vejen med at lave en kolonne der indeholder en URL
> til den primære nøgle med index på ? De aktuelle URLs kan vel i princippet
> være op til 100+ tegn lange, men hvis kolonnen indexeres, så er det vel
> ikke betydningsfuldt ?

Både ja og nej. Det kommer lidt an på hvilken metode, der er brugt til at
gemme indexeringer på i det givne tilfælde (DBMS?). I de fleste tilfælde,
betyder det ikke så meget performancemæssigt, men det kræver noget mere
plads at gemme nøgler, der fylder meget. BTW 100+, er grænsen ikke på
2048?

> Kan man som regel sige, at performance forbedres ved at holde de primære
> nøglekolonner så "simple" som muligt - dvs integer, tinyint etc ... eller
> er det hip som hap ?

Hvis du dermed mener, at der skal laves et ekstra opslag ud fra din nøgle,
for at finde en given URL, er det på ingen måde en fordel.

--
Med venlig hilsen / Best regards
Stig Johansen

---

Stig Johansen wrote in news:a1er12$ai1$1@sunsite.dk:

> Jesper Stocholm wrote:
>
>> Vil der være noget i vejen med at lave en kolonne der indeholder en
>> URL til den primære nøgle med index på ? De aktuelle URLs kan vel i
>> princippet være op til 100+ tegn lange, men hvis kolonnen indexeres,
>> så er det vel ikke betydningsfuldt ?
>
> Både ja og nej. Det kommer lidt an på hvilken metode, der er brugt til
> at gemme indexeringer på i det givne tilfælde (DBMS?). I de fleste
> tilfælde, betyder det ikke så meget performancemæssigt, men det kræver
> noget mere plads at gemme nøgler, der fylder meget. BTW 100+, er
> grænsen ikke på 2048?
>

jo ... det mener jeg - eller er det 4096 ? - men det var mere et bud på
en mere praktisk øvre grænse for, hvor lange URLs jeg regner med, at mine
brugere vil give mig.

>> Kan man som regel sige, at performance forbedres ved at holde de
>> primære nøglekolonner så "simple" som muligt - dvs integer, tinyint
>> etc ... eller er det hip som hap ?
>
> Hvis du dermed mener, at der skal laves et ekstra opslag ud fra din
> nøgle, for at finde en given URL, er det på ingen måde en fordel.
>

Nej ... det var mere spørgsmålet om det kunne betale sig at lave endnu en
kolonne (int, auto_increment, not null) til håndtering af den primære
nøgle - eller om det lissågodt kunne give sig at bruge noget i forvejen
unikt i tabellen - nemlig URL.


--
Jesper Stocholm - http://stocholm.dk

Synes du også, at Britney trods alt er meget lækker - men dog
på grænsen til det kvalmende ? http://stocholm.dk/britney.txt

---

"Jesper Stocholm" <spam200201@stocholm.dk> skrev i en meddelelse
news:Xns91909652D4909spamstocholmdk@130.226.1.34...
> Stig Johansen wrote in news:a1er12$ai1$1@sunsite.dk:
>

> >> Kan man som regel sige, at performance forbedres ved at holde de
> >> primære nøglekolonner så "simple" som muligt - dvs integer, tinyint
> >> etc ... eller er det hip som hap ?
> >
> > Hvis du dermed mener, at der skal laves et ekstra opslag ud fra din
> > nøgle, for at finde en given URL, er det på ingen måde en fordel.
> >
>
> Nej ... det var mere spørgsmålet om det kunne betale sig at lave endnu en
> kolonne (int, auto_increment, not null) til håndtering af den primære
> nøgle - eller om det lissågodt kunne give sig at bruge noget i forvejen
> unikt i tabellen - nemlig URL.

Den primære nøgle bør være noget ikke informationsbærende, så jeg vil
fraråde dig at bruge URL-kolonnen i din primær nøgle.

Martin

---

Martin Elkjær Nielsen wrote in news:rhD_7.101$t17.3497@news.get2net.dk:

>
> "Jesper Stocholm" <spam200201@stocholm.dk> skrev i en meddelelse
> news:Xns91909652D4909spamstocholmdk@130.226.1.34...
>>
>> Nej ... det var mere spørgsmålet om det kunne betale sig at lave
>> endnu en kolonne (int, auto_increment, not null) til håndtering af
>> den primære nøgle - eller om det lissågodt kunne give sig at bruge
>> noget i forvejen unikt i tabellen - nemlig URL.
>
> Den primære nøgle bør være noget ikke informationsbærende

med fare for at virke ignorant:
Hvorfor ikke det ?

--
Jesper Stocholm - http://stocholm.dk

Synes du også, at Britney trods alt er meget lækker - men dog
på grænsen til det kvalmende ? http://stocholm.dk/britney.txt

---

"Jesper Stocholm" <spam200201@stocholm.dk> skrev i en meddelelse
news:Xns91909D0C18F58spamstocholmdk@130.226.1.34...
> Martin Elkjær Nielsen wrote in news:rhD_7.101$t17.3497@news.get2net.dk:
>
> >
> > "Jesper Stocholm" <spam200201@stocholm.dk> skrev i en meddelelse
> > news:Xns91909652D4909spamstocholmdk@130.226.1.34...
> >>
> >> Nej ... det var mere spørgsmålet om det kunne betale sig at lave
> >> endnu en kolonne (int, auto_increment, not null) til håndtering af
> >> den primære nøgle - eller om det lissågodt kunne give sig at bruge
> >> noget i forvejen unikt i tabellen - nemlig URL.
> >
> > Den primære nøgle bør være noget ikke informationsbærende
>
> med fare for at virke ignorant:
> Hvorfor ikke det ?

Nu kender jeg selvfølgelig ikke til dit specifikke db-design, så det er
muligt at det ikke er noget problem.
Men normalt bruger man primær nøgler (/fremmednøgler) til at binde/relatere
data imellem forskellige tabeller, og indeholder den primære nøgle
information vil man når der ændres i dataen ikke længere have en valid
relation.
Så derfor.

mvh
Martin

---

Stig Johansen <linux@w3data.dk> writes:

[ Længden af en URL ]

> BTW 100+, er grænsen ikke på 2048?

I RFC 2616 (HTTP 1.1) står der i afsnit 3.2.1 på side 19:

| The HTTP protocol does not place any a priori limit on the length of
| a URI. Servers MUST be able to handle the URI of any resource they
| serve, and SHOULD be able to handle URIs of unbounded length if they
| provide GET-based forms that could generate such URIs. A server
| SHOULD return 414 (Request-URI Too Long) status if a URI is longer
| than the server can handle (see section 10.4.15).
|
| Note: Servers ought to be cautious about depending on URI lengths
| above 255 bytes, because some older client or proxy
| implementations might not properly support these lengths.

Så der er altså ingen grænse.

--
Jacob - www.bunk.cc
grep me no patterns and I'll tell you no lines.

---

Jacob Bunk Nielsen wrote in news:spamdrop+m3g05h3oxw.fsf@paven.bunk.cc:

> Stig Johansen <linux@w3data.dk> writes:
>
> [ Længden af en URL ]
>
>> BTW 100+, er grænsen ikke på 2048?
>
> I RFC 2616 (HTTP 1.1) står der i afsnit 3.2.1 på side 19:
>
>| The HTTP protocol does not place any a priori limit on the length of
>| a URI. Servers MUST be able to handle the URI of any resource they
>| serve, and SHOULD be able to handle URIs of unbounded length if they
>| provide GET-based forms that could generate such URIs. A server
>| SHOULD return 414 (Request-URI Too Long) status if a URI is longer
>| than the server can handle (see section 10.4.15).
>|
>| Note: Servers ought to be cautious about depending on URI lengths
>| above 255 bytes, because some older client or proxy
>| implementations might not properly support these lengths.
>
> Så der er altså ingen grænse.
>

næeh ... det ville også være mæærkeligt, hvis der var en begrænsning i
RFCen, men derfor kan der jo godt være en applikationsafhængig
begrænsning - og her mener jeg faktisk, at IE har (haft) en begrænsning
på 4095 tegn.

:)

--
Jesper Stocholm - http://stocholm.dk

Synes du også, at Britney trods alt er meget lækker - men dog
på grænsen til det kvalmende ? http://stocholm.dk/britney.txt

---

Jesper Stocholm <spam200201@stocholm.dk> writes:

>> I RFC 2616 (HTTP 1.1) står der i afsnit 3.2.1 på side 19:
>> [ ... ]
>> Så der er altså ingen grænse.
>
> næeh ... det ville også være mæærkeligt, hvis der var en begrænsning i
> RFCen, men derfor kan der jo godt være en applikationsafhængig
> begrænsning - og her mener jeg faktisk, at IE har (haft) en begrænsning
> på 4095 tegn.

Men så er det jo bare en begrænsning/"fejl" i en specifik
applikation. Det kan man jo ikke basere sine beslutninger på, jo
mindre man ved at det er den eneste applikation af dens art der skal
benyttes. IE findes fx ikke til mit foretrukne operativsystem

--
Jacob - www.bunk.cc
If you don't drink it, someone else will.

---

On Tue, 8 Jan 2002 15:51:03 +0100, Martin Elkjær Nielsen wrote:

> Nu kender jeg selvfølgelig ikke til dit specifikke db-design, så det
> er muligt at det ikke er noget problem. Men normalt bruger man
> primær nøgler (/fremmednøgler) til at binde/relatere data imellem
> forskellige tabeller, og indeholder den primære nøgle information
> vil man når der ændres i dataen ikke længere have en valid relation.
> Så derfor.

Hvis primærnøglen ændres er det jo en anden post.


Mvh.

--
"Well, I'm a moon around you" Adam Sjøgren
asjo@koldfront.dk

---

"Adam Sjøgren" <asjo@koldfront.dk> skrev i en meddelelse
news:87bsg4yaa8.fsf@virgil.koldfront.dk...
> On Tue, 8 Jan 2002 15:51:03 +0100, Martin Elkjær Nielsen wrote:
>
> > Nu kender jeg selvfølgelig ikke til dit specifikke db-design, så det
> > er muligt at det ikke er noget problem. Men normalt bruger man
> > primær nøgler (/fremmednøgler) til at binde/relatere data imellem
> > forskellige tabeller, og indeholder den primære nøgle information
> > vil man når der ændres i dataen ikke længere have en valid relation.
> > Så derfor.
>
> Hvis primærnøglen ændres er det jo en anden post.
>

Netop og netop derfor er det dumt af gemme informationer i denne!

Martin

---

On Tue, 8 Jan 2002 19:48:11 +0100, Martin Elkjær Nielsen wrote:

>> Hvis primærnøglen ændres er det jo en anden post.

> Netop og netop derfor er det dumt af gemme informationer i denne!

Nej, vi går fejl af hinanden. Jeg går ud fra at primærnøglen, her
url'en, identificerer posten. Du går ud fra at den ikke gør (og at den
således er information der kan ændres. At den ikke entydigt
identificerer posten).

Men hvis den ikke gjorde det, var den jo ikke primærnøgle


Mvh.

--
"Well, I'm a moon around you" Adam Sjøgren
asjo@koldfront.dk

---

"Adam Sjøgren" <asjo@koldfront.dk> wrote in message
news:87zo3ovfaz.fsf@virgil.koldfront.dk...
> On Tue, 8 Jan 2002 19:48:11 +0100, Martin Elkjær Nielsen wrote:
>
> >> Hvis primærnøglen ændres er det jo en anden post.
>
> > Netop og netop derfor er det dumt af gemme informationer i denne!
>
> Nej, vi går fejl af hinanden. Jeg går ud fra at primærnøglen, her
> url'en, identificerer posten. Du går ud fra at den ikke gør (og at den
> således er information der kan ændres. At den ikke entydigt
> identificerer posten).
>
> Men hvis den ikke gjorde det, var den jo ikke primærnøgle
>
Bruger man url som primærnøgle følger man _ikke_ de gængse principper for
opbygning af RDBMS - der kan dog være gode grunde til at fravige disse
principper

Der har for år tilbage være en gængs en praksis med at bruge telefonnummer
som primærnøgle for kundenummer - men....
Dette gav store problemer i takt med at TDC udbyggede og ændrede
telefonnumrene, specielt i det københavnske område

Derfor er det særdeles fornuftigt at bruge en "ikke informationsbærende"
nøgle som der blev skrevet tidligere - og det vil da også følge den gængse
principper

Søg evt efter "normalformer" på google

mvh/Peter Lykkegaard

---

On Tue, 8 Jan 2002 20:02:36 +0100, Peter Lykkegaard wrote:

> Bruger man url som primærnøgle følger man _ikke_ de gængse
> principper for opbygning af RDBMS - der kan dog være gode grunde til
> at fravige disse principper

Det gør man da absolut, hvis url'en altså entydigt bestemmer posten.

Man følger muligvis ikke den gængse _praksis_, men det er jo som
oftest også noget andet en principper

> Der har for år tilbage være en gængs en praksis med at bruge
> telefonnummer som primærnøgle for kundenummer - men.... Dette gav
> store problemer i takt med at TDC udbyggede og ændrede
> telefonnumrene, specielt i det københavnske område

Ja. Dårligt valg af primærnøgle (hvilket url også sagtens kunne være,
det afviser jeg bestemt ikke .

> Søg evt efter "normalformer" på google

Hvordan er det relevant hér?


Mvh.

--
"Well, I'm a moon around you" Adam Sjøgren
asjo@koldfront.dk

---

Hej Adam,

"Adam Sjøgren" <asjo@koldfront.dk> skrev i en meddelelse
news:87r8p0vd9f.fsf@virgil.koldfront.dk...
> On Tue, 8 Jan 2002 20:02:36 +0100, Peter Lykkegaard wrote:
>
> > Bruger man url som primærnøgle følger man _ikke_ de gængse
> > principper for opbygning af RDBMS - der kan dog være gode grunde til
> > at fravige disse principper
>
> Det gør man da absolut, hvis url'en altså entydigt bestemmer posten.
>
> Man følger muligvis ikke den gængse _praksis_, men det er jo som
> oftest også noget andet en principper
>
> > Der har for år tilbage være en gængs en praksis med at bruge
> > telefonnummer som primærnøgle for kundenummer - men.... Dette gav
> > store problemer i takt med at TDC udbyggede og ændrede
> > telefonnumrene, specielt i det københavnske område
>
> Ja. Dårligt valg af primærnøgle (hvilket url også sagtens kunne være,
> det afviser jeg bestemt ikke .

Ved at vælge primærnøgle som ikke informationsbærende vil du aldrig opleve
at have valgt en dårlig primærnøgle. Uanset hvor statisk data kan se ud
siger Murphey's lov at det vil gå galt (selv TDC har oplevet dette).
Jeg kan heller ikke se ulemperne ved at lave sin primærnøgle på denne måde ?
Måske du kan hjælpe mig ?? Eller måske du kan fortælle mig om fordelen ved
at have informationer i primærnøglen ??

mvh
Martin

---

"Adam Sjøgren" <asjo@koldfront.dk> wrote in message
news:87r8p0vd9f.fsf@virgil.koldfront.dk...
> On Tue, 8 Jan 2002 20:02:36 +0100, Peter Lykkegaard wrote:
>
> > Bruger man url som primærnøgle følger man _ikke_ de gængse
> > principper for opbygning af RDBMS - der kan dog være gode grunde til
> > at fravige disse principper
>
> Det gør man da absolut, hvis url'en altså entydigt bestemmer posten.
>
> > Søg evt efter "normalformer" på google
>
> Hvordan er det relevant hér?

At gemme en hel url er et brud på 1NF efter min bedste overbevisning
Url er jo som bekendt sammensat af domainnavn samt en sti + evt filnavn
derudover en større samling parametre alt efter kompleksitet på websitet
At gemme forsk link til fx jubii ca 1000 er jo endvidere redundant
information i forhold til domainnavnet jubii.dk

Men som sagt er der en ganske god grund til at gøre det

mvh/Peter Lykkegaard

---

In article <a1i2mf$eq8$1@news.net.uni-c.dk>, Peter Lykkegaard wrote:
> At gemme en hel url er et brud på 1NF efter min bedste overbevisning
> Url er jo som bekendt sammensat af domainnavn samt en sti + evt filnavn
> derudover en større samling parametre alt efter kompleksitet på websitet
> At gemme forsk link til fx jubii ca 1000 er jo endvidere redundant
> information i forhold til domainnavnet jubii.dk

Ok.
Her er URL primær nøgle og dette overholder da BCNF ikk?

+------+----------------+-----------+-------------------------+
|url | Sidstopdateret | Størrelse | Antal billeder på siden |
+------+----------------+-----------+-------------------------+


--
../Jesper Krogh, jesper@linuxpusher.dk
webshop: http://www.linuxpusher.dk

---

"Jesper Krogh" <jesper@linuxpusher.dk> wrote in message
news:slrna3ql9t.q2l.jesper@luke.kollegiet...
> In article <a1i2mf$eq8$1@news.net.uni-c.dk>, Peter Lykkegaard wrote:
> > At gemme en hel url er et brud på 1NF efter min bedste overbevisning
> > Url er jo som bekendt sammensat af domainnavn samt en sti + evt filnavn
> > derudover en større samling parametre alt efter kompleksitet på
websitet
> > At gemme forsk link til fx jubii ca 1000 er jo endvidere redundant
> > information i forhold til domainnavnet jubii.dk
>

> Ok.
> Her er URL primær nøgle og dette overholder da BCNF ikk?
>
> +------+----------------+-----------+-------------------------+
> |url | Sidstopdateret | Størrelse | Antal billeder på siden |
> +------+----------------+-----------+-------------------------+
>
Da URL er sammensat af forskellige oplysninger som beskrevet ovenfor
overholder det ikke 1NF og derved heller ikke BCNF

Du ville jo heller ikke bruger polonline@hotmail.com sim primærnøgle?
For ikke at nævne en komplet snailmail adresse?

Derudover kan man diskutere om de angivne attributter, der kan være endog
meget dynamiske, overhovedet skal med i den relation

Der _kan_ være og typisk _er_ en god grund til at gemme en komplet URL i
databasen

mvh/Peter Lykkegaard

---

On Tue, 8 Jan 2002 21:37:53 +0100, Martin Elkjær Nielsen wrote:

> Ved at vælge primærnøgle som ikke informationsbærende vil du aldrig
> opleve at have valgt en dårlig primærnøgle.

Det har du ret i, det er en stor praktisk fordel.

> Jeg kan heller ikke se ulemperne ved at lave sin primærnøgle på
> denne måde ?

Næh, ikke udover at det ikke er "pænt", for nogle værdier af pænt.

> Eller måske du kan fortælle mig om fordelen ved at have
> informationer i primærnøglen ??

I det jeg kommenterede _indeholdt__ primærnøglen information (hvilket
er lidt misvisende sprogbrug, synes jeg - selvfølgelig er der
information), hvorfor at ændre denne information er at ændre
post. Hvilket var den pointe jeg var ude efter at gøre.


Mvh.

--
"Well, I'm a moon around you" Adam Sjøgren
asjo@koldfront.dk

---

On Wed, 9 Jan 2002 19:32:36 +0100, Peter Lykkegaard wrote:

> At gemme en hel url er et brud på 1NF efter min bedste overbevisning

Godt så.


Mvh.

--
"Well, I'm a moon around you" Adam Sjøgren
asjo@koldfront.dk

---

On Fri, 11 Jan 2002 10:51:07 +0100, Peter Lykkegaard wrote:

>> +------+----------------+-----------+-------------------------+
>> |url | Sidstopdateret | Størrelse | Antal billeder på siden |
>> +------+----------------+-----------+-------------------------+

> Da URL er sammensat af forskellige oplysninger som beskrevet ovenfor
> overholder det ikke 1NF og derved heller ikke BCNF

Et flercifret tal er også sammensat af flere enkelte cifre, derfor kan
det sagtens være entydigt bestemmende for en post.

Det kommer an på sammenhængen.

(Det behøver f.ex. ikke være det).

> Du ville jo heller ikke bruger polonline@hotmail.com sim
> primærnøgle? For ikke at nævne en komplet snailmail adresse?

Hvis man ved at det entydigt udpeger hvilken post der er tale om _i
den givne sammenhæng_ (univers om du vil): jo.


Mvh.

--
"Well, I'm a moon around you" Adam Sjøgren
asjo@koldfront.dk