---

Goddag.

Jeg har brug for lidt erfaring med MSQL 2000. I mit nuværnde db design har
jeg (i en del af det) 3 tabeller som hver er koblet sammen med en
fremmednøgle. Alle 3 tabeller vil med tiden løb have ca. 100.000 rækker

Vil jeres vurdering være at alle 3 tabeller uden store hastighedsproblmer
kan joines naturligvis med indexere på nøglerne?

Har ikke erfaringer med så mange data i tabeller samtidig med at alle 3 skal
joines.

Ser frem til erfaringer
Anders

---

On Thu, 30 Dec 2004 01:34:17 +0100, Anders K. Jacobsen wrote:

> Alle 3 tabeller vil med tiden løb have ca. 100.000 rækker
>
> Vil jeres vurdering være at alle 3 tabeller uden store hastighedsproblmer
> kan joines naturligvis med indexere på nøglerne?

Der er mange måder at join'e på.

Et betingelsesløst join (kartesisk produkt / CROSS JOIN) vil være grimt
at håndtere (100000^3 rækker), men den slags joins er normalt aldrig
interessante:

SELECT * FROM tab1 CROSS JOIN tab2 CROSS JOIN tab3;
- alternativt:
SELECT * FROM tab1 JOIN tab2 ON (1=1) JOIN tab3 ON (1=1)

I praksis vil man join'e med nogle betingelser, der gør, at
resultatsættene får et håndtërbart antal rækker - og man vil normalt
også kun bede om at få returneret visse af kolonnerne:

SELECT foo,bar,baz
FROM tab1
JOIN tab2 ON (tab1.col1=tab2.col2)
JOIN tab3 ON (tab2.col2=tab3.col3)

Svaret på dit spørgsmål er efter min mening: "Ja, du kan sagtens join'e
tre tabeller i den størrelse, når blot du ikke gør stupide ting".

> Har ikke erfaringer med så mange data i tabeller samtidig med at alle 3 skal
> joines.

Tabeller med 100000 rækker være barnemad for ethvert databasesystem med
respekt for sig selv. Men hvis du skriver dårlige forespørgsler, kan
selv endnu mindre tabeller rækker give problemer.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Fuldstændig enig. Lyt til Troels i denne sammenhæng. 100K records er
småting. Faktisk er 1 mio. records at betragte som småting for en
moderne database server, selv på en forholdvis lille maskine rent
hardware mæssigt.



- Jesper



Troels Arvin wrote:
> On Thu, 30 Dec 2004 01:34:17 +0100, Anders K. Jacobsen wrote:
>
>
>>Alle 3 tabeller vil med tiden løb have ca. 100.000 rækker
>>
>>Vil jeres vurdering være at alle 3 tabeller uden store hastighedsproblmer
>>kan joines naturligvis med indexere på nøglerne?
>
>
> Der er mange måder at join'e på.
>
> Et betingelsesløst join (kartesisk produkt / CROSS JOIN) vil være grimt
> at håndtere (100000^3 rækker), men den slags joins er normalt aldrig
> interessante:
>
> SELECT * FROM tab1 CROSS JOIN tab2 CROSS JOIN tab3;
> - alternativt:
> SELECT * FROM tab1 JOIN tab2 ON (1=1) JOIN tab3 ON (1=1)
>
> I praksis vil man join'e med nogle betingelser, der gør, at
> resultatsættene får et håndtërbart antal rækker - og man vil normalt
> også kun bede om at få returneret visse af kolonnerne:
>
> SELECT foo,bar,baz
> FROM tab1
> JOIN tab2 ON (tab1.col1=tab2.col2)
> JOIN tab3 ON (tab2.col2=tab3.col3)
>
> Svaret på dit spørgsmål er efter min mening: "Ja, du kan sagtens join'e
> tre tabeller i den størrelse, når blot du ikke gør stupide ting".
>
>
>>Har ikke erfaringer med så mange data i tabeller samtidig med at alle 3 skal
>>joines.
>
>
> Tabeller med 100000 rækker være barnemad for ethvert databasesystem med
> respekt for sig selv. Men hvis du skriver dårlige forespørgsler, kan
> selv endnu mindre tabeller rækker give problemer.
>

---

"Jesper Sommer" <dknewsgroups4js@conceptfactory.dk> skrev :

> Fuldstændig enig. Lyt til Troels i denne sammenhæng. 100K records er
> småting. Faktisk er 1 mio. records at betragte som småting for en moderne
> database server, selv på en forholdvis lille maskine rent hardware
> mæssigt.
>
>
>
> - Jesper
>
Og jeg vil tilføje: Når DB-maskinen skal joine er det en fordel hvis du kan
få den til at finde den mindste mængde først. Hvis du skal joine 500 i den
ene med 50000 i den anden, er det hurtigere at finde sættet med 500 og
derefter gå den anden tabel igennem - end den anden vej rundt. I Oracle,
hvor jeg havde stort behov for at joine korrekt (for 10+ år siden), var det
venstre led i en outer join. Jeg kender ikke "MSQL 2000", men mon ikke du
kan finde noget i DOK'en? Ellers er det ikke noget problem, når du når op på
de store mængder, at lave en testbænk. Minimalt med kørende processer osv.

Vagn Kofoed

---

On Fri, 31 Dec 2004 06:17:08 +0100, Vagn Kofoed wrote:

> Og jeg vil tilføje: Når DB-maskinen skal joine er det en fordel hvis du kan
> få den til at finde den mindste mængde først. Hvis du skal joine 500 i den
> ene med 50000 i den anden, er det hurtigere at finde sættet med 500 og
> derefter gå den anden tabel igennem - end den anden vej rundt.

Den slags _burde_ et godt DBMS kunne hitte ud af automatisk, hvis man
giver det chancen (sørger for, at dets statistikker holdes up-to-date).

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

> Den slags _burde_ et godt DBMS kunne hitte ud af automatisk, hvis man
> giver det chancen (sørger for, at dets statistikker holdes up-to-date).

Enig - optimizeren bør have styr på den slags i vore dage. Hvis man er i
tvivl kan man altid bede om at se optimizer planen.

På Oracle kan man i øvrigte give optimizeren hints - sikkert et lævn fra
akkurat de problemer med tidligere versioner som Vagn nævner

- Jesper