---

Hej gruppe

Jeg skal have skrevet et script der kan hjælpe med at finde dubletter i en
ret stor (140k rækker) tabel.
Idéen er at rækkerne skal sammenlignes på, lad os sige, ét eller flere af
følgende felter: email, username, first_name, last_name. De rækker som har
ens værdier i de felter, skal så listes og brugeren kan afgøre hvilke der
skal beholdes og hvilke der skal slettes (groft sagt).
Det kan man jo løse på flere forskellige måder, og min første tanke var at
lave en SELECT DISTINCT email, COUNT(email) FROM foo GROUP BY email (virker
naturligvis kun for ét felt) og på den måde få alle forskellige
email-addresser samt en COUNT på den værdi i hele tabellen. For de værdier
med count > 1 henter jeg så alle rækker med matchende felt (her email). Det
virker somend også fint nok, men går _alt_ for langsomt i det jeg først skal
hente de næsten 140k forskellige værdier og derefter loope dem alle sammen
igennem og hente et par rækker for hver værdi.

Er der nogen der har en brandgod idé til hvordan dette gøres bedst (bedre!)
rent performance mæssigt, og måske samtidigt lidt mere elegant?:)

På forhånd tak!

Mvh. Jonas

---

"Jonas Delfs" <jonas@NOSPAMdelfs.dk> writes:

> Er der nogen der har en brandgod idé til hvordan dette gøres bedst (bedre!)
> rent performance mæssigt, og måske samtidigt lidt mere elegant?:)

Er det du er ude efter ikke "GROUP BY"?

--
Thorbjørn Ravn Andersen

---

Jonas Delfs wrote:
> Jeg skal have skrevet et script der kan hjælpe med at finde dubletter i en
> ret stor (140k rækker) tabel.
> Idéen er at rækkerne skal sammenlignes på, lad os sige, ét eller flere af
> følgende felter: email, username, first_name, last_name. De rækker som har
> ens værdier i de felter, skal så listes og brugeren kan afgøre hvilke der
> skal beholdes og hvilke der skal slettes (groft sagt).
> Det kan man jo løse på flere forskellige måder, og min første tanke var at
> lave en SELECT DISTINCT email, COUNT(email) FROM foo GROUP BY email (virker
> naturligvis kun for ét felt) og på den måde få alle forskellige
> email-addresser samt en COUNT på den værdi i hele tabellen. For de værdier
> med count > 1 henter jeg så alle rækker med matchende felt (her email). Det
> virker somend også fint nok, men går _alt_ for langsomt i det jeg først skal
> hente de næsten 140k forskellige værdier og derefter loope dem alle sammen
> igennem og hente et par rækker for hver værdi.

Prøv denne her:

SELECT COUNT(email) AS Antal
FROM mintabel
HAVING Antal > 1

En mere generel version er

SELECT COUNT(email) AS Antal, felt1, felt2, ...
FROM mintabel
GROUP BY felt1, felt2, ...
HAVING Antal > 1

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

> Prøv denne her:
>
> SELECT COUNT(email) AS Antal
> FROM mintabel
> HAVING Antal > 1

Takker! Det var HAVING klausulen jeg havde overset - jeg prøvede noget
lignede med WHERE, men uden held.

> En mere generel version er

> SELECT COUNT(email) AS Antal, felt1, felt2, ...
> FROM mintabel
> GROUP BY felt1, felt2, ...
> HAVING Antal > 1

Det ser ud til at følgende gør jobbet for mig:

SELECT email, forename, surname
FROM table
WHERE email != ''
GROUP BY email, forename, surname
HAVING COUNT(email) > 1

Et tillægsspørgsmål: hvordan finder jeg ud af hvor mange rækker
ovenstående forespørgsel giver mig? Jeg kan umiddelbart ikke SELECT'e
en COUNT() da resultatet er grupperet som det er - nogen forslag?

Mvh. Jonas

---

On 24 May 2006 03:52:45 -0700, jonas@delfs.dk wrote:

>SELECT email, forename, surname
>FROM table
>WHERE email != ''
>GROUP BY email, forename, surname
>HAVING COUNT(email) > 1
>
>Et tillægsspørgsmål: hvordan finder jeg ud af hvor mange rækker
>ovenstående forespørgsel giver mig? Jeg kan umiddelbart ikke SELECT'e
>en COUNT() da resultatet er grupperet som det er - nogen forslag?

Hvis du vil have det som et SQL-resultat, så kan du lave en subquery,
fx:

SELECT COUNT(*) FROM (
SELECT email, forename, surname
FROM table
WHERE email != ''
GROUP BY email, forename, surname
HAVING COUNT(email) > 1
) a

--
- Peter Brodersen
Ugens værktøj - Find vej: www.findvej.dk

---

jonas@delfs.dk wrote:
> Det ser ud til at følgende gør jobbet for mig:
>
> SELECT email, forename, surname
> FROM table
> WHERE email != ''
> GROUP BY email, forename, surname
> HAVING COUNT(email) > 1
>
> Et tillægsspørgsmål: hvordan finder jeg ud af hvor mange rækker
> ovenstående forespørgsel giver mig? Jeg kan umiddelbart ikke SELECT'e
> en COUNT() da resultatet er grupperet som det er - nogen forslag?

Nu ved jeg ikke lige hvilket miljø du bruger, men de fleste steder kan
man få at vide hvor mange rækker, der er i resultatet.

I PHP er der f. eks. mysql_num_rows.

http://dk.php.net/manual/en/function.mysql-num-rows.php

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

"Michael Zedeler" <michael@zedeler.dk> wrote in message
news:N_4dg.19657$uk.19434@news.get2net.dk...
> jonas@delfs.dk wrote:
>> Det ser ud til at følgende gør jobbet for mig:
>>
>> SELECT email, forename, surname
>> FROM table
>> WHERE email != ''
>> GROUP BY email, forename, surname
>> HAVING COUNT(email) > 1
>>
>> Et tillægsspørgsmål: hvordan finder jeg ud af hvor mange rækker
>> ovenstående forespørgsel giver mig? Jeg kan umiddelbart ikke SELECT'e
>> en COUNT() da resultatet er grupperet som det er - nogen forslag?
>
> Nu ved jeg ikke lige hvilket miljø du bruger, men de fleste steder kan man
> få at vide hvor mange rækker, der er i resultatet.
>
> I PHP er der f. eks. mysql_num_rows.

Ja, men problemet er, som nævnt andetsteds, at jeg sætter en LIMIT på
ovenstående men stadig gerne vil kende størrelsen på det fulde resultatsæt.

Mvh. Jonas

---

Jonas Delfs wrote:
> "Michael Zedeler" <michael@zedeler.dk> wrote in message
> news:N_4dg.19657$uk.19434@news.get2net.dk...
>
>>jonas@delfs.dk wrote:
>>
>>>Det ser ud til at følgende gør jobbet for mig:
>>>
>>>SELECT email, forename, surname
>>>FROM table
>>>WHERE email != ''
>>>GROUP BY email, forename, surname
>>>HAVING COUNT(email) > 1
>>>
>>>Et tillægsspørgsmål: hvordan finder jeg ud af hvor mange rækker
>>>ovenstående forespørgsel giver mig? Jeg kan umiddelbart ikke SELECT'e
>>>en COUNT() da resultatet er grupperet som det er - nogen forslag?
>>
>>Nu ved jeg ikke lige hvilket miljø du bruger, men de fleste steder kan man
>>få at vide hvor mange rækker, der er i resultatet.
>>
>>I PHP er der f. eks. mysql_num_rows.
>
> Ja, men problemet er, som nævnt andetsteds, at jeg sætter en LIMIT på
> ovenstående men stadig gerne vil kende størrelsen på det fulde resultatsæt.

Ok. Så får du ikke meget ud af den funktion.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

Hej Peter

Tak for svar!

> Hvis du vil have det som et SQL-resultat, så
> kan du lave en subquery, fx:

> [snip]

Jeg havde håbet jeg kunne slippe for at lave et subquery af
performance-grunde. Som nogen måske har gættet er det fordi jeg i
første omgang sætter en limit på 100 på min query, og derefter skal
bruge det fulde antal for at kunne generere en " < forrige 1 2 3 næste
>" type navigation. MySQL's caching af resultatsæt (eller hvad den nu gør - 2. udførsel af en halvtung forespørgsel er i hvert fald altid meget hurtigere end første) kan vel kun bruges ved identiske forespørgsler? Det ville irritere mig lidt hvis navigations-genereringen skulle tilføre overhead til systemet når du den egentlige forespørgsel fungerer glimrende.

Nogen forslag?

Mvh. Jonas

---

jonas@delfs.dk writes:

> Jeg havde håbet jeg kunne slippe for at lave et subquery af
> performance-grunde. Som nogen måske har gættet er det fordi jeg i

Jeg kender ikke nogen måde at få antallet at vide på uden at spørge
udtrykkeligt med count() eller ved at hive hele resultatsættet ind.

Sagt på en anden måde, du er nødt til at spørge en gang for at få
antallet og en gang for hver klump du hiver ud.

Måske tillader MySQL en svartype som tillader dig at beholde svaret
aktivt, og så bladre frem og tilbage efter behov? LIdt a la
faciliteterne i JDBC 3.0
--
Thorbjørn Ravn Andersen

---

On 24 May 2006 06:57:50 -0700, jonas@delfs.dk wrote:

>Jeg havde håbet jeg kunne slippe for at lave et subquery af
>performance-grunde. Som nogen måske har gættet er det fordi jeg i
>første omgang sætter en limit på 100 på min query, og derefter skal
>bruge det fulde antal for at kunne generere en " < forrige 1 2 3 næste >
> " type navigation. MySQL's caching af resultatsæt (eller hvad den nu gør
>- 2. udførsel af en halvtung forespørgsel er i hvert fald altid meget hurtigere end første)
>kan vel kun bruges ved identiske forespørgsler?

Hvis det bare handler om at du gerne vil kende det samlede antal
rækker, selv om du bruger limit, kan du tilføje SQL_CALC_FOUND_ROWS
til begyndelsen af din forespørgsel, og så efterfølgende afvikle
SELECT FOUND_ROWS()

Fx:

SELECT SQL_CALC_FOUND_ROWS COUNT(*) AS antal, ... LIMIT 0,100
(giver fx 100 rækker)
SELECT FOUND_ROWS()
(giver én række med ét felt med det samlede antal rækker fra
foregående forespørgsel)

--
- Peter Brodersen
Ugens værktøj - Find vej: www.findvej.dk

---

On Wed, 24 May 2006 18:51:22 +0200, Peter Brodersen
<usenet2006@ter.dk> wrote:

>Hvis det bare handler om at du gerne vil kende det samlede antal
>rækker, selv om du bruger limit, kan du tilføje SQL_CALC_FOUND_ROWS
>til begyndelsen af din forespørgsel, og så efterfølgende afvikle
>SELECT FOUND_ROWS()

I øvrigt, hvis selve datamængden ikke er så vildt stor, men det blot
er beregningen, der er tung, kan du overveje at hente al data ud, og
så blot gå til et bestemt sted i resultatet i applikations-delen.

Det vil sige, at du sender præcis den samme forespørgsel (og får samme
resultat), og så ud fra en værdi i applikationen kun viser en
begrænset del af resultatet. Fordelen her er, at du udnytter, at mysql
cache'r resultatet fra forespørgslen, så at du skal lave det samme
opslag på "næste side", kræver vitterligt intet af serveren.

--
- Peter Brodersen
Ugens værktøj - Find vej: www.findvej.dk

---

"Peter Brodersen" <usenet2006@ter.dk> wrote in message
news:e522us$ve$1@news.klen.dk...
> On 24 May 2006 06:57:50 -0700, jonas@delfs.dk wrote:
>
>>Jeg havde håbet jeg kunne slippe for at lave et subquery af
>>performance-grunde. Som nogen måske har gættet er det fordi jeg i
>>første omgang sætter en limit på 100 på min query, og derefter skal
>>bruge det fulde antal for at kunne generere en " < forrige 1 2 3 næste >
>> " type navigation. MySQL's caching af resultatsæt (eller hvad den nu gør
>>- 2. udførsel af en halvtung forespørgsel er i hvert fald altid meget
>>hurtigere end første)
>>kan vel kun bruges ved identiske forespørgsler?
>
> Hvis det bare handler om at du gerne vil kende det samlede antal
> rækker, selv om du bruger limit, kan du tilføje SQL_CALC_FOUND_ROWS
> til begyndelsen af din forespørgsel, og så efterfølgende afvikle
> SELECT FOUND_ROWS()

Smart! Mon SQL_CALC_FOUND_ROWS returnerer en værdi? - jeg prøver det af så
snart jeg får mulighed for det!
Tak for svar!

Mvh. Jonas

---

Jonas Delfs <jonas@NOSPAMdelfs.dk> wrote:

> Jeg skal have skrevet et script der kan hjælpe med at finde dubletter i en
> ret stor (140k rækker) tabel.

Der burde aldrig optræde dubletter i en tabel i en relationsdatabase, da
disse naturligvis skal forsynes med en primær nøgle.

På:

<http://dev.mysql.com/doc/refman/5.0/en/create-table.html>

kan ses hvordan:

=
create_definition:
column_definition
| [CONSTRAINT [symbol]] PRIMARY KEY [index_type] (index_col_name,...)
| {INDEX|KEY} [index_name] [index_type] (index_col_name,...)
| [CONSTRAINT [symbol]] UNIQUE [INDEX|KEY]
[index_name] [index_type] (index_col_name,...)
| {FULLTEXT|SPATIAL} [INDEX|KEY] [index_name] (index_col_name,...)
| [CONSTRAINT [symbol]] FOREIGN KEY
[index_name] (index_col_name,...) [reference_definition]
| CHECK (expr)
=

Den findes også på den 4.1.15 jeg er nødt til at anvende på min Synology
diskstation 101g+:

<http://dev.mysql.com/doc/refman/4.1/en/create-table.html>

create_definition:
column_definition
| [CONSTRAINT [symbol]] PRIMARY KEY [index_type] (index_col_name,...)
| {INDEX|KEY} [index_name] [index_type] (index_col_name,...)
| [CONSTRAINT [symbol]] UNIQUE [INDEX|KEY]
[index_name] [index_type] (index_col_name,...)
| {FULLTEXT|SPATIAL} [INDEX|KEY] [index_name] (index_col_name,...)
| [CONSTRAINT [symbol]] FOREIGN KEY
[index_name] (index_col_name,...) [reference_definition]
| CHECK (expr)

--
Per Erik Rønne
http://www.RQNNE.dk

---

""Per Rønne"" <per@RQNNE.invalid> wrote in message
news:1hfza21.1f1qe97x6h3zvN%per@RQNNE.invalid...
> Jonas Delfs <jonas@NOSPAMdelfs.dk> wrote:
>
>> Jeg skal have skrevet et script der kan hjælpe med at finde dubletter i
>> en
>> ret stor (140k rækker) tabel.
>
> Der burde aldrig optræde dubletter i en tabel i en relationsdatabase, da
> disse naturligvis skal forsynes med en primær nøgle.

Enig, men det tænkte dem der oprindeligt designede databasen for 10 år siden
ikke rigtigt over, så nu skal der ryddes op...

Mvh. Jonas

---

Jonas Delfs <jonas@NOSPAMdelfs.dk> wrote:

> ""Per Rønne"" <per@RQNNE.invalid> wrote in message
> news:1hfza21.1f1qe97x6h3zvN%per@RQNNE.invalid...
> > Jonas Delfs <jonas@NOSPAMdelfs.dk> wrote:
> >
> >> Jeg skal have skrevet et script der kan hjælpe med at finde dubletter i
> >> en ret stor (140k rækker) tabel.
> >
> > Der burde aldrig optræde dubletter i en tabel i en relationsdatabase, da
> > disse naturligvis skal forsynes med en primær nøgle.
>
> Enig, men det tænkte dem der oprindeligt designede databasen for 10 år siden
> ikke rigtigt over, så nu skal der ryddes op...

Tænk, det blev der ellers gjort meget ud af på det første kursus jeg
fulgte i relationsdatabaser. På DTU, forårssemesteret 1981, som senere
blev meritoverført til datalogistudiet.

Vi brugte C.J. Dates »An Introduction to Database Systems«, Second
Edition.

--
Per Erik Rønne
http://www.RQNNE.dk

---

Per Rønne wrote:
> Jonas Delfs <jonas@NOSPAMdelfs.dk> wrote:

>>Jeg skal have skrevet et script der kan hjælpe med at finde dubletter i en
>>ret stor (140k rækker) tabel.
>
> Der burde aldrig optræde dubletter i en tabel i en relationsdatabase, da
> disse naturligvis skal forsynes med en primær nøgle.

Selv uden primær nøgle er der ingen dubletter i en relationsdatabase.
Mon ikke vi heraf kan udledes at MySQL ikke er en relationsdatabase.

--
Jens Axel Søgaard

---

Jens Axel Søgaard <usenet@soegaard.net> wrote:

> Per Rønne wrote:
> > Jonas Delfs <jonas@NOSPAMdelfs.dk> wrote:
>
> >>Jeg skal have skrevet et script der kan hjælpe med at finde dubletter i en
> >>ret stor (140k rækker) tabel.
> >
> > Der burde aldrig optræde dubletter i en tabel i en relationsdatabase, da
> > disse naturligvis skal forsynes med en primær nøgle.
>
> Selv uden primær nøgle er der ingen dubletter i en relationsdatabase.

Korrekt.

> Mon ikke vi heraf kan udledes at MySQL ikke er en relationsdatabase.

Jov det kan vi faktisk. Det samme gælder i øvrigt for Oracle; vi skal
nemlig først tvinge dem til at opføre sig som relationsdatabaser ved
omhyggeligt altid at sørge for at alle tabeller har en primær nøgle.
--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> Jov det kan vi faktisk. Det samme gælder i øvrigt for Oracle; vi skal
> nemlig først tvinge dem til at opføre sig som relationsdatabaser ved
> omhyggeligt altid at sørge for at alle tabeller har en primær nøgle.

Den laver Oracle da sæl. Hver række har sin egen id.

--
Thorbjørn Ravn Andersen

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > Jov det kan vi faktisk. Det samme gælder i øvrigt for Oracle; vi skal
> > nemlig først tvinge dem til at opføre sig som relationsdatabaser ved
> > omhyggeligt altid at sørge for at alle tabeller har en primær nøgle.
>
> Den laver Oracle da sæl. Hver række har sin egen id.

Der er nu ikke tale om primær nøgle, og i øvrigt har jeg været ude for
at disse er blevet ændret automatisk.
--
Per Erik Rønne
http://www.RQNNE.dk

---

Jens Axel Søgaard skrev:

> Selv uden primær nøgle er der ingen dubletter i en
> relationsdatabase. Mon ikke vi heraf kan udledes at MySQL ikke
> er en relationsdatabase.

Nej - jeg kender ingen database der ikke tillader tabeller med
dubletter, uanset at det ikke er tilladt i den relationelle model.

Det er op til brugeren at lave relationelle databaser - det er ikke
noget systemet sikrer.
--
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

---

Jens Gyldenkærne Clausen wrote:
> Jens Axel Søgaard skrev:
>
>>Selv uden primær nøgle er der ingen dubletter i en
>>relationsdatabase. Mon ikke vi heraf kan udledes at MySQL ikke
>>er en relationsdatabase.
>
> Nej - jeg kender ingen database der ikke tillader tabeller med
> dubletter, uanset at det ikke er tilladt i den relationelle model.

Hvis der forefindes dubletter kan vel højst kalde databasen en
tupel-database.

> Det er op til brugeren at lave relationelle databaser - det er ikke
> noget systemet sikrer.

Hvis databasen ikke følger den relationelle model, er den vel
ikke relationel

Konkrete relationelle databaser: Rasmus [for Daimi-folk], Dataphor
og Rel.

<http://dbappbuilder.sourceforge.net/Rel.html>
<http://www.alphora.com/tiern.asp?ID=DATAPHOR>

--
Jens Axel Søgaard

---

Jens Axel Søgaard <usenet@soegaard.net> wrote:

> Jens Gyldenkærne Clausen wrote:
> > Jens Axel Søgaard skrev:
> >
> >>Selv uden primær nøgle er der ingen dubletter i en
> >>relationsdatabase. Mon ikke vi heraf kan udledes at MySQL ikke
> >>er en relationsdatabase.
> >
> > Nej - jeg kender ingen database der ikke tillader tabeller med
> > dubletter, uanset at det ikke er tilladt i den relationelle model.
>
> Hvis der forefindes dubletter kan vel højst kalde databasen en
> tupel-database.

En kuffert-database? Engelsk: /bag database/.

En mængde er en dubletløs kuffert. En relation {i almindelig tale i
relationssammenhæng: tabel} er en mængde af tupler {eller poster}. I
gode gamle pascal ville jeg have skrevet det som: /set of record .../.

En kuffert er et uordnet sæt af elementer, hvor der kan forekomme
dubletter. Som min gamle klasse i gymnasiet:

{dreng, dreng, pige , dreng, dreng, dreng, pige , dreng, dreng, dreng,
dreng, dreng, dreng, pige , dreng, dreng, dreng, dreng, dreng, dreng,
dreng, pige , dreng, dreng}.

Ja, dengang var der minsandten kraftig forskel mellem matematisk og
sprogligt gymnasium ...
--
Per Erik Rønne
http://www.RQNNE.dk

---

Per Rønne wrote:
> Jens Axel Søgaard <usenet@soegaard.net> wrote:
>
>>Jens Gyldenkærne Clausen wrote:
>>
>>>Jens Axel Søgaard skrev:
>>>
>>>>Selv uden primær nøgle er der ingen dubletter i en
>>>>relationsdatabase. Mon ikke vi heraf kan udledes at MySQL ikke
>>>>er en relationsdatabase.
>>>
>>>Nej - jeg kender ingen database der ikke tillader tabeller med
>>>dubletter, uanset at det ikke er tilladt i den relationelle model.
>>
>>Hvis der forefindes dubletter kan vel højst kalde databasen en
>>tupel-database.
>
> En kuffert-database? Engelsk: /bag database/.

Så hedder det en pose. Sådan siger de i hvert fald på IMFUFA, når de
underviser i matematik.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Michael Zedeler <michael@zedeler.dk> wrote:

> Per Rønne wrote:
> > Jens Axel Søgaard <usenet@soegaard.net> wrote:

> >>Jens Gyldenkærne Clausen wrote:

> >>>Jens Axel Søgaard skrev:

> >>>>Selv uden primær nøgle er der ingen dubletter i en relationsdatabase.
> >>>>Mon ikke vi heraf kan udledes at MySQL ikke er en relationsdatabase.

> >>>Nej - jeg kender ingen database der ikke tillader tabeller med
> >>>dubletter, uanset at det ikke er tilladt i den relationelle model.

> >>Hvis der forefindes dubletter kan vel højst kalde databasen en
> >>tupel-database.

> > En kuffert-database? Engelsk: /bag database/.

> Så hedder det en pose. Sådan siger de i hvert fald på IMFUFA, når de
> underviser i matematik.

Jeg har set det kaldt en kuffert, men sådanne ting var ikke med i
Kristensen & Rindung da vi havde matematik med mængdelære en masse i 1g.
Jeg havde det først på datalogistudiet, hvor lærebogen /Elements of
Discrete Mathematics/ var på engelsk. Eller gælder pose-begrebet kun i
forhold til kufferter af tupler?

Ja, der er altid problemer med oversættelser til dansk af veldefinerede,
engelske termer ...
--
Per Erik Rønne
http://www.RQNNE.dk

---

Per Rønne wrote:
> Jeg har set det kaldt en kuffert, men sådanne ting var ikke med i
> Kristensen & Rindung da vi havde matematik med mængdelære en masse i 1g.
> Jeg havde det først på datalogistudiet, hvor lærebogen /Elements of
> Discrete Mathematics/ var på engelsk. Eller gælder pose-begrebet kun i
> forhold til kufferter af tupler?

En pose er en ordnet mængde som tillader dubletter. Hvad elementer man
så stopper i den, er der ingen krav om.

> Ja, der er altid problemer med oversættelser til dansk af veldefinerede,
> engelske termer ...

Det kan roligt siges. Fastpladelager... suk!

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Michael Zedeler <michael@zedeler.dk> wrote:

> Per Rønne wrote:
> > Jeg har set det kaldt en kuffert, men sådanne ting var ikke med i
> > Kristensen & Rindung da vi havde matematik med mængdelære en masse i 1g.
> > Jeg havde det først på datalogistudiet, hvor lærebogen /Elements of
> > Discrete Mathematics/ var på engelsk. Eller gælder pose-begrebet kun i
> > forhold til kufferter af tupler?
>
> En pose er en ordnet mængde som tillader dubletter. Hvad elementer man
> så stopper i den, er der ingen krav om.

OK, en kuffert er /ikke/ ordnet.

> > Ja, der er altid problemer med oversættelser til dansk af veldefinerede,
> > engelske termer ...
>
> Det kan roligt siges. Fastpladelager... suk!

Ja, selv 'datamat' er forsvundet fra brugen ...
--
Per Erik Rønne
http://www.RQNNE.dk

---

Jens Axel Søgaard skrev:

>> Det er op til brugeren at lave relationelle databaser - det
>> er ikke noget systemet sikrer.

> Hvis databasen ikke følger den relationelle model, er den vel
> ikke relationel

Korrekt - men spørgsmålet er hvad man kan/skal/bør kalde
databaseprogrammet (DBMS'et).

Det er gængs sprogbrug at kalde systemer som Oracle, MSSQL og DB2
for RDBMS - altså relationelle databaseprogrammer - uanset at man
kan lave ikke-relationelle databaser med dem alle.

Se evt. <http://en.wikipedia.org/wiki/RDBMS#Current_usage>.
--
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