---

Er det muligt at oprette et indeks der dækker flere tabeller ?
- eller er det nemmeste så at oprette en tabel der blot indeholder
de data indekset ellers skulle indeholde ?

F.eks. hvis man har to typer registreringer - personer og
virksomheder i hver sin tabel - og bruger CPR og CVR som nøgle. Så
kunne det jo være smart at kunne lave et indeks der dækker begge
tabeller så man hurtigt kan afgøre om et givent nummer allerede er
registreret eller lign.

--
..: Henrik Stidsen - http://hs235.dk/ - http://hs235.dk/blog/ ::...
"Alot of people may not know this but I happen to be quite famous"

---

On 27 Oct 2004 20:27:10 GMT, Henrik Stidsen <nospamforme@hs235.dk>
wrote:

>F.eks. hvis man har to typer registreringer - personer og
>virksomheder i hver sin tabel - og bruger CPR og CVR som nøgle. Så
>kunne det jo være smart at kunne lave et indeks der dækker begge
>tabeller så man hurtigt kan afgøre om et givent nummer allerede er
>registreret eller lign.

Hvis du laver to indexes - ét på hvert felt i hver tabel - så er det
vel fint nok?

Hvis det handler om at du blot vil lave én forespørgsel, så kig på
UNION.

--
- Peter Brodersen

Ugens sprogtip: pc (og ikke PC)

---

Peter Brodersen <usenet@ter.dk> wrote in
news:clp0nk$lnj$1@katie.ellegaard.dk

> Hvis det handler om at du blot vil lave én forespørgsel, så kig på
> UNION.

Det er lige præcis det det gør - jeg vil gerne med en enkelt
forespørgsel kunne se om en given bruger er oprettet i forvejen.

--
..: Henrik Stidsen - http://hs235.dk/ - http://hs235.dk/blog/ ::...
"Alot of people may not know this but I happen to be quite famous"

---

On Wed, 27 Oct 2004 21:14:36 +0000, Henrik Stidsen wrote:

>> Hvis det handler om at du blot vil lave én forespørgsel, så kig på
>> UNION.
>
> Det er lige præcis det det gør - jeg vil gerne med en enkelt
> forespørgsel kunne se om en given bruger er oprettet i forvejen.

Men med en UNION bliver det vel også til én forespørgsel (der så har
to subqueries). Det burde ikke være specielt krævende, synes jeg.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin <troels@arvin.dk> wrote in
news:pan.2004.10.27.21.16.26.492883@arvin.dk

>> Det er lige præcis det det gør - jeg vil gerne med en enkelt
>> forespørgsel kunne se om en given bruger er oprettet i
>> forvejen.

> Men med en UNION bliver det vel også til én forespørgsel (der så
> har to subqueries). Det burde ikke være specielt krævende, synes
> jeg.

Er der ikke noget med at MySQL ikke kan subqueries ? (er MySQL jeg
skal bruge, formentlig version 4.xxxx

--
..: Henrik Stidsen - http://hs235.dk/ - http://hs235.dk/blog/ ::...
"Alot of people may not know this but I happen to be quite famous"

---

On 27 Oct 2004 22:18:42 GMT, Henrik Stidsen <nospamforme@hs235.dk>
wrote:

>> Men med en UNION bliver det vel også til én forespørgsel (der så
>> har to subqueries). Det burde ikke være specielt krævende, synes
>> jeg.
>Er der ikke noget med at MySQL ikke kan subqueries ? (er MySQL jeg
>skal bruge, formentlig version 4.xxxx

MySQL 4.0 kan sagtens lave UNION (og UNION ALL, men ikke MINUS eller
INTERSECT), og den bruger selvfølgelig relevante indexes:

mysql> explain
-> select id from foo where id = 1
-> union all
-> select id from bar where id = 1
-> ;
+-------+-------+---------------+---------+---------+-------+------+-------+
| table | type | possible_keys | key | key_len | ref | rows | Extra |
+-------+-------+---------------+---------+---------+-------+------+-------+
| foo | const | PRIMARY | PRIMARY | 4 | const | 1 | |
| bar | const | PRIMARY | PRIMARY | 4 | const | 1 | |
+-------+-------+---------------+---------+---------+-------+------+-------+
2 rows in set (0.01 sec)

... og output for samme explain, fra en server, der kører 5.0.1-alpha:
+----+--------------+------------+-------+---------------+---------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------+------------+-------+---------------+---------+---------+-------+------+-------------+
| 1 | PRIMARY | aut | const | PRIMARY | PRIMARY | 4 | const | 1 | Using index |
| 2 | UNION | sce | const | PRIMARY | PRIMARY | 4 | const | 1 | Using index |
|NULL | UNION RESULT | <union1,2> | ALL | NULL | NULL | NULL | NULL | NULL | |
+----+--------------+------------+-------+---------------+---------+---------+-------+------+-------------+
3 rows in set (0.04 sec)

--
- Peter Brodersen

Ugens sprogtip: pc (og ikke PC)

---

On Thu, 28 Oct 2004 01:02:37 +0200, Peter Brodersen <usenet@ter.dk>
wrote:

>>Er der ikke noget med at MySQL ikke kan subqueries ? (er MySQL jeg
>>skal bruge, formentlig version 4.xxxx
>MySQL 4.0 kan sagtens lave UNION (og UNION ALL, men ikke MINUS eller
>INTERSECT), og den bruger selvfølgelig relevante indexes:

MySQL 4.1 er i øvrigt netop markeret som production-ready i disse
dage. Jeg har selvfølgelig forståelse for folk, der lige vil have
erfaringer fra folk, der rent faktisk har den i drift i
produktionsmiljøer.
http://www.mysql.com/news-and-events/press-release/release_2004_32.html

Jeg har ikke haft nogen nævneværdige problemer med den i
alpha-perioden.

I øvrigt har jeg noget, der tilsvarer løse håndnoter ifbm. 4.0 og 4.1,
som måske kunne interessere dig:
http://stock.ter.dk/mysql410.txt

--
- Peter Brodersen

Ugens sprogtip: pc (og ikke PC)

---

Peter Brodersen wrote:

> MySQL 4.1 er i øvrigt netop markeret som production-ready i disse
> dage. Jeg har selvfølgelig forståelse for folk, der lige vil have
> erfaringer fra folk, der rent faktisk har den i drift i
> produktionsmiljøer.
> http://www.mysql.com/news-and-events/press-release/release_2004_32.html

JUHUU.. Så er GROUP_CONCAT klar! *Så* skal der snart opdateres DB

---

On 27 Oct 2004 21:14:36 GMT, Henrik Stidsen <nospamforme@hs235.dk>
wrote:

>> Hvis det handler om at du blot vil lave én forespørgsel, så kig på
>> UNION.
>Det er lige præcis det det gør - jeg vil gerne med en enkelt
>forespørgsel kunne se om en given bruger er oprettet i forvejen.

Altså, du laver et opslag på tabeller, som så måske fører til et
opslag i relevante indexes. Men UNION-løsningen laver jo netop
index-opslag i hver af de to tabeller.

Hvis du vil have datastrukturen til at sikre, at en nøgle ikke findes
i forvejen, så kan du for eksempel lave én fælles tabel, der både
indeholder CVR og CPR i samme felt, og så fx have et typeflag.

Hvis du er bekymret for om CVR en dag udvider antallet af cifre til
10, så må du jo blot lave et unique index, der både dækker key og
type.

--
- Peter Brodersen

Ugens sprogtip: pc (og ikke PC)

---

Peter Brodersen <usenet@ter.dk> wrote in
news:clp3ec$nsv$1@katie.ellegaard.dk

> Hvis du vil have datastrukturen til at sikre, at en nøgle ikke
> findes i forvejen, så kan du for eksempel lave én fælles tabel,
> der både indeholder CVR og CPR i samme felt, og så fx have et
> typeflag.

Tror det bliver den jeg vælger.

> Hvis du er bekymret for om CVR en dag udvider antallet af cifre
> til 10, så må du jo blot lave et unique index, der både dækker
> key og type.

Det er ikke lige der skoen trykker :)

--
..: Henrik Stidsen - http://hs235.dk/ - http://hs235.dk/blog/ ::...
"Alot of people may not know this but I happen to be quite famous"

---

On Wed, 27 Oct 2004 22:33:47 +0200, Peter Brodersen wrote:

> On 27 Oct 2004 20:27:10 GMT, Henrik Stidsen <nospamforme@hs235.dk>
> wrote:
>
>>F.eks. hvis man har to typer registreringer - personer og
>>virksomheder i hver sin tabel - og bruger CPR og CVR som nøgle. Så
>>kunne det jo være smart at kunne lave et indeks der dækker begge
>>tabeller så man hurtigt kan afgøre om et givent nummer allerede er
>>registreret eller lign.
>
> Hvis du laver to indexes - ét på hvert felt i hver tabel - så er det
> vel fint nok?
Det vil jeg også mene, og så kan du lave et view ovenpå så har du hvad
du skal bruge.
>
> Hvis det handler om at du blot vil lave én forespørgsel, så kig på
> UNION.
Da CPR og CVR ikke har fælles værdier så skal det være UNION ALL (dvs.
uden sortering og sletning af dubletter).

Michael.

---

Henrik Stidsen wrote:
> Er det muligt at oprette et indeks der dækker flere tabeller ?
> - eller er det nemmeste så at oprette en tabel der blot indeholder
> de data indekset ellers skulle indeholde ?
>
> F.eks. hvis man har to typer registreringer - personer og
> virksomheder i hver sin tabel - og bruger CPR og CVR som nøgle. Så
> kunne det jo være smart at kunne lave et indeks der dækker begge
> tabeller så man hurtigt kan afgøre om et givent nummer allerede er
> registreret eller lign.
>

Jeg ved ikke noget om CVR-numre. Men er man sikker på, at et CVR nummer
ikke kan være identisk med et CPR nummer ?

Hvis ja, så kan man vel på en nem måde først afgøre om, det er et CPR
nummer eller CVR nummer man skal kontrollere ?

Hvis nej, så er man vel nødt til på anden vis at vide, hvad man skal
kontrollere ?

Mvh. Torben

---

torben skrev:

> Jeg ved ikke noget om CVR-numre. Men er man sikker på, at et CVR nummer
> ikke kan være identisk med et CPR nummer ?

Et cvr-nummer er ifølge www.cvr.dk på otte cifre, og det kan derfor ikke
falde sammen med et cpr-nummer (der jo er på ti cifre).

Men der er så vidt jeg kan se ingen garanti for at det også vil holde i
fremtiden. Jeg kan i hvert fald ikke finde noget officielt om at cpr- og
cvr-numre bevidst laves så de kan kendes fra hinanden.

Hvis man gemmer bindestregen med i et cpr-nummer, skulle det dog være en
rimelig fremtidssikret måde at skelne mellem cpr og cvr.

--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

torben <torben@frojonck.dk> wrote in
news:41811807$0$33744$14726298@news.sunsite.dk

> Jeg ved ikke noget om CVR-numre. Men er man sikker på, at et CVR
> nummer ikke kan være identisk med et CPR nummer ?

Well, CPR/CVR er kun et eksempel - i virkeligheden er det
emailadresser.

De to forskellige typer der skal gemmes (privat og erhverv) er dog så
forskellige at det ville give en voldsom mængde null værdier hvis man
skulle gemme dem i samme tabel - og det er derfor jeg gerne vil have
det opdelt.

--
..: Henrik Stidsen - http://hs235.dk/ - http://hs235.dk/blog/ ::...
Hvis du engang føler ingen hører dig.. Elsker dig... Holder af dig..
ser dig.. Ingen vil snakke med dig.. Så husk blot på.. FALCK ER DER
ALTID!

---

Hejsa !

Hmm. for mig at se, lyder det lidt som et normaliseringsproblem.

Jeg forestiller mig at du har en nøgle til at identificere dine brugere.
Derfor en brugertabel, med en primærnøgle (CVR/CPR eller mailadresse) og de
attributter (læs: felter) der er ens for de to forskellige typer
(Primærgnølen er naturligvis unik for den enkelte bruger, hvorfor
mailadresse måske ikke er dit bedste bud). Her udover to tabeller... én med
de attributter der måtte være specifikke for CVR-kunder og én med
CPR-kunder. På disse to en fremmednøgle indeholdende enten CPR eller CVR,
alt efter typen, naturligvis. Du kan med fordel lægge et type felt på din
"hoved-tabel", der fortæller dig, i hvilken tabel du skal søge efter
detaljerne.

Men udover det... Ja, byg et index på nøglefelterne på hver af de to
tabeller og vælg et UNOIN-statement til din forespørgsel. Det vil automatisk
ramme de to indexes.

Fik jeg formuleret mig på dansk, eller var det helt håbløst ?

/Jan



"Henrik Stidsen" <nospamforme@hs235.dk> wrote in message
news:Xns9590F2B031E3FHS235dk@130.225.247.90...
> torben <torben@frojonck.dk> wrote in
> news:41811807$0$33744$14726298@news.sunsite.dk
>
>> Jeg ved ikke noget om CVR-numre. Men er man sikker på, at et CVR
>> nummer ikke kan være identisk med et CPR nummer ?
>
> Well, CPR/CVR er kun et eksempel - i virkeligheden er det
> emailadresser.
>
> De to forskellige typer der skal gemmes (privat og erhverv) er dog så
> forskellige at det ville give en voldsom mængde null værdier hvis man
> skulle gemme dem i samme tabel - og det er derfor jeg gerne vil have
> det opdelt.
>
> --
> .: Henrik Stidsen - http://hs235.dk/ - http://hs235.dk/blog/ ::...
> Hvis du engang føler ingen hører dig.. Elsker dig... Holder af dig..
> ser dig.. Ingen vil snakke med dig.. Så husk blot på.. FALCK ER DER
> ALTID!

---

"Jan Pedersbæk" <Peders*at*stofanet.dk> wrote in
news:4182cb6f$0$17615$ba624c82@nntp06.dk.telia.net

> Hmm. for mig at se, lyder det lidt som et normaliseringsproblem.

Det er jeg ikke sikker på det er.
Sagen er den at jeg skal have en database til at registrere to typer
brugere. Email er imho den bedste nøgle - alternativet er
telefonnummer, navn eller adresse...
Da den type bruger der er flest af (mit gæt er omkring 90%) er den
med færrest data vil det alt andet lige give en masse null værdier at
samle det hele i en tabel.
Man kunne jo så smide de ekstra data for den "udvidede bruger" i en
anden tabel og kæde dem sammen med nøglen - men det syns jeg ikke er
nogen god ide da det kun drejer sig om to-tre attributter.

> Fik jeg formuleret mig på dansk, eller var det helt håbløst ?
>

Tror jeg forstod det meste :)

--
Henrik Stidsen - http://såkadulæredet.dk/
'Veni, Vidi, Velcro' - I came, I saw, I stuck around.

---

"Henrik Stidsen" wrote

>> Hmm. for mig at se, lyder det lidt som et normaliseringsproblem.
> Det er jeg ikke sikker på det er.

Johh

> Sagen er den at jeg skal have en database til at registrere to typer
> brugere. Email er imho den bedste nøgle - alternativet er
> telefonnummer, navn eller adresse...

Email er da udmærket til at søge en person frem
Men ikke som nøgle
Lur mig ikke om du på et tidspunkt render ind i at flere personer har den
samme mailadresse
Du kan så have en forretningsregel der siger at det ikke må forekomme

Emailadresser har det med at skifte over tid
Nyt job, ny udbyder, ny kontaktperson etc

I større systemer er emailadresser sekundære, hvor man kan tilknytte flere
adresser til samme person inkl passende attributter

> Man kunne jo så smide de ekstra data for den "udvidede bruger" i en
> anden tabel og kæde dem sammen med nøglen - men det syns jeg ikke er
> nogen god ide da det kun drejer sig om to-tre attributter.
>
Det står egentllig med valgmuligheden mellem den relationelle database eller
den objektorienterede database
Eller evt en sammenblanding

Der er ikke noget i vejen for at implementere emailadresser i en tabel
forsig selv med passende sæt attributter og have firmaer, kontaktpersoner,
privatpersoner i deres egne tabeller
Eller en endnu større opsplitning

En anden overvejelse
Hvordan kan database understøtte brugergrænsefladen?

- Peter

---

"Peter Lykkegaard" <polonline@hotmail.com> wrote in
news:2uh2mvF2b63kaU1@uni-berlin.de

>> Sagen er den at jeg skal have en database til at registrere to
>> typer brugere. Email er imho den bedste nøgle - alternativet er
>> telefonnummer, navn eller adresse...
>
> Email er da udmærket til at søge en person frem
> Men ikke som nøgle
> Lur mig ikke om du på et tidspunkt render ind i at flere
> personer har den samme mailadresse
> Du kan så have en forretningsregel der siger at det ikke må
> forekomme

Nemlig - at det ikke *må* forekomme er nok mere korrekt :)

> Emailadresser har det med at skifte over tid
> Nyt job, ny udbyder, ny kontaktperson etc

> I større systemer er emailadresser sekundære, hvor man kan
> tilknytte flere adresser til samme person inkl passende
> attributter

Ja det kan da nok være jeg skal finde mig en anden nøgle. Man kan jo
altid bruge et unikt brugernavn.

> Det står egentllig med valgmuligheden mellem den relationelle
> database eller den objektorienterede database
> Eller evt en sammenblanding

Jeg er ikke helt klar over hvad en objektorienteret database dækker
over.

--
..: Henrik Stidsen - HS235.dk - http://hs235.dk ::...
"You know the world is going crazy when the best rapper is a white
guy, the best golfer is a black guy, France is accusing the US of
arrogance and Germany doesn't want to go to war."

---

"Henrik Stidsen" wrote

> Jeg er ikke helt klar over hvad en objektorienteret database dækker
> over.
>
Jeg har ikke selv arbejdet med implementering af OODBMS
Jeg har leget lidt mht at lave faste objekter i mssql, hvor jeg sammen med
de egentlige data angiver objecttyper og derigennem styrer linkning til
øvrige støttetabeller, samt styring af GUI
Men det bliver hurtigt komplekts og langsommeligt at udvikle og vedligeholde

Prøv at søge på Google efter "object oriented database"

I store træk går det ud på at de business objekter der skal bruges bliver
afspejlet i databaseopbygningen
Fx en adresse eller en emailadresse og objekter i sig selv og uafhængig af
bruger/kunde/leverandør
Leverandør/kunde kan være nedarvet fra bruger etc

- Peter

---

"Peter Lykkegaard" <polonline@hotmail.com> wrote in
news:2ul2mnF2bhpqnU1@uni-berlin.de

>> Jeg er ikke helt klar over hvad en objektorienteret database
>> dækker over.

> Jeg har ikke selv arbejdet med implementering af OODBMS
> Jeg har leget lidt mht at lave faste objekter i mssql, hvor jeg
> sammen med de egentlige data angiver objecttyper og derigennem
> styrer linkning til øvrige støttetabeller, samt styring af GUI
> Men det bliver hurtigt komplekts og langsommeligt at udvikle og
> vedligeholde

Det lyder som totalt overkill i forhold til styring af en brugerDB på
en webside :)

--
Henrik Stidsen - http://hs235.dk/ - http://såkadulæredet.dk/
"Is everyone else in the world a moron, or is it just me?"
(Dilbert Newsletter)

---

"Henrik Stidsen" wrote

> Det lyder som totalt overkill i forhold til styring af en brugerDB på
> en webside :)

Det kommer jo an på det overordnede formål

- Peter