---

Jeg skal igang med et projekt som over tid kommer til at omfatte et par
millioner poster, hver med ca. 20 felter. Materialet omfatter en 15 - 20
hovedgrupper, hver med et antal undergrupper.

Det skal kun være muligt at søge i een hovedgruppe ad gangen.
Men der skal til gengæld kunne søges på en lang række af kriterier
omfattende både undergrupper og enkeltposter.

Vil det være mest hensigtsmæsigt at oprette en tabel til hver
hovedgruppe (evt. en database til hver hovedgruppe og derunder en tabel
til hvert af de prinære undergrupper), eller kan man lige så godt lægge
det hele i een enkelt tabel.?

Jeg tænker i den sammenhæng udelukkende på performance (søge- og
svartider mv.).

Databasen skal tilgåes via PHP, hvis det skulle have nogen betydning.


--
mvh, A:\Feldborg

Folketælllinger Hammerum og Bøling herreder, kirkebøger Hammerum herred
http://www.haunstrup.dk/feldborg/genealogi/download/

---

Arne Feldborg skrev:
> Jeg skal igang med et projekt som over tid kommer til at omfatte et par
> millioner poster, hver med ca. 20 felter. Materialet omfatter en 15 - 20
> hovedgrupper, hver med et antal undergrupper.
....
> Vil det være mest hensigtsmæsigt at oprette en tabel til hver
> hovedgruppe... eller kan man lige så godt lægge det hele i een
> enkelt tabel.?

Det afhænger formentlig meget af hvilken database du vil køre med, og også i
nogen grad hvad, du ønsker at kunne gøre med dine data.

Mindre fil-baserede database-systemer, vil nok kunne få problemer med at
søge i meget store tabeller, men rigtig "store" database-servere burde ikke
kløjes i det.

Hvis du ofte skal foretage store opdateringer på _mange_ poster, vil der i
visse tifælde kunne være fornuft i at opdele i mindre tabeller, men hvis
hvis dine data hovedsaglig er statiske, og du har lagt dine indekser
rigtigt, kan jeg ikke se nogen fordel i at opdele i (så mange) mindre
tabeller.

-------
Tomas

---

"Tomas Christiansen" <toc-01-nospam@blikroer.dk> skrev Sat, 28 Jun 2003
00:04:15 +0200

>Det afhænger formentlig meget af hvilken database du vil køre med, og også i
>nogen grad hvad, du ønsker at kunne gøre med dine data.
>
Ah, ja. Nu glemte jeg det igen(!).

Det er MySql / Apache / PHP / Win98SE på en 2GHZ maskine.
Og hovedsageligt til eget brug, men også med besøgende (men ikke i stort
antal) over internet.

>Hvis du ofte skal foretage store opdateringer på _mange_ poster, vil der i
>visse tifælde kunne være fornuft i at opdele i mindre tabeller, men hvis
>hvis dine data hovedsaglig er statiske,
>
Det er rimeligt statisk. Opdatering måske een eller to gange årligt.

> og du har lagt dine indekser
>rigtigt, kan jeg ikke se nogen fordel i at opdele i (så mange) mindre
>tabeller.
>
Er det rigtig forstået, at en indeksering på de tidligere nævnte
hovedgrupper vil give ca. samme fordel som en opdeling i et tilsvarende
antal mindre tabeller.?

Derudover skal der naturligvis indekseres også på andre kriterier, men
det vil jo være ens i begge tilfælde.

Lige et tillægsspørgsmål:
Hvis man ser bort fra pladsforbruget, bør man så indexsere på alle de
felter det er muligt at søge i, eller kan det også have negative
effekter - om man så at sige også kan indexere for meget.?


--
mvh, A:\Feldborg

Folketælllinger Hammerum og Bøling herreder, kirkebøger Hammerum herred
http://www.haunstrup.dk/feldborg/genealogi/download/

---

Arne Feldborg skrev:
> Det er MySql / Apache / PHP / Win98SE på en 2GHZ maskine.
> Og hovedsageligt til eget brug, men også med besøgende (men ikke i stort
> antal) over internet.
> Det er rimeligt statisk. Opdatering måske een eller to gange årligt.

Det lyder umiddelbart som at du skal gå efter en enkelt tabel.

> Er det rigtig forstået, at en indeksering på de tidligere nævnte
> hovedgrupper vil give ca. samme fordel som en opdeling i et tilsvarende
> antal mindre tabeller.?

Som Lars Dybdahl har beskrevet for dig, er søgetiden i indekser faktisk ikke
særlig følsom over for antallet af poster.
Om du har 1 million eller 10 millioner poster betyder ikke ret meget, hvis
der i _begge_ tilfælde er 50.000 poster med den værdi du ønsker, og værdien
kan findes i et indeks.

Alpha og omega er altså at du har lagt indekser på det, som du søger efter.
Hvis du _ikke_ har indekseret et felt, hvor du søger efter en bestemt værdi,
vil du kunne mærke betydelig forskel på hvor mange poster du har i din(e)
tabel(ler). En sekventiel søgning gennem en database kan være en _meget_
tidskrævende operation.

Om dit database-system så kan finde ud af at bruge indekserne er så en anden
sag. Jeg har ladet mig fortælle at der er situationer, hvor Oracle kan være
30-40 gange hurtigere til at udføre en søging end MySql. Det _kan_ bero på
et tilfælde hvor database-systemet ikke kan finde ud af at bruge et indeks
rigtigt, men der kommer hele tiden nye versioner (med nye features og nye
FEJL), så i morgen kan bøtten vende.

> Hvis man ser bort fra pladsforbruget, bør man så indexsere på alle de
> felter det er muligt at søge i, eller kan det også have negative
> effekter - om man så at sige også kan indexere for meget.?

Tja. Jo flere indekser des længere tid tager en opdatering. Ellers kan jeg
ikke se det store problem.

Jo, forresten: En Oracle-database kan faktisk godt blive "forvirret", og
vælge et ret dårligt indeks til en given søgning, hvis der er flere indekser
at vælge mellem. Oftest kan det dog løses ved at oprette et mere "oplagt"
indeks at bruge til den specifikke søgning - eller at bruge "hints" i sin
SQL (hvilket jeg stort set _aldrig_ bevæger mig ud i).

-------
Tomas

---

Tomas Christiansen wrote:
> at vælge mellem. Oftest kan det dog løses ved at oprette et mere "oplagt"
> indeks at bruge til den specifikke søgning - eller at bruge "hints" i sin
> SQL (hvilket jeg stort set _aldrig_ bevæger mig ud i).

Det gør man næsten altid i Interbase/Firebird, da denne er ret dårlig til at
gætte - her hedder det "plan". Bruger man til gengæld "plan" i sine SQL
statements, kan man være 100% sikker på, at dette SQL statement kører
optimalt uanset hvilken Firebird version det er.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

---

Lars Dybdahl skrev:
> Det gør man næsten altid i Interbase/Firebird, da denne er ret dårlig til
at
> gætte - her hedder det "plan". Bruger man til gengæld "plan" i sine SQL
> statements, kan man være 100% sikker på, at dette SQL statement kører
> optimalt uanset hvilken Firebird version det er.

Afhængig af opsætningen _kan_ Oracle også været dårlig (men behøver ikke at
være det).

Det "sjove" er at hint kun er hints. Man er ikke 100% sikker på at de vil
blive brugt ("alt hvad du siger vil eller vil ikke blive brugt imod dig").
Der kan dog være forskel på de forskellige Oracle-versioner (der sker trods
alt en udvikling).

-------
Tomas

---

"Arne Feldborg" <feldborg@haunstrup.dk> wrote in message
news:2hbofv01lq1tfhlnkpp21rfhonhefl6uui@news2.tele.dk...
>
> Jeg skal igang med et projekt som over tid kommer til at omfatte et
par
> millioner poster, hver med ca. 20 felter. Materialet omfatter en
15 - 20
> hovedgrupper, hver med et antal undergrupper.
>
> Det skal kun være muligt at søge i een hovedgruppe ad gangen.
> Men der skal til gengæld kunne søges på en lang række af kriterier
> omfattende både undergrupper og enkeltposter.
>
> Vil det være mest hensigtsmæsigt at oprette en tabel til hver
> hovedgruppe (evt. en database til hver hovedgruppe og derunder en
tabel
> til hvert af de prinære undergrupper), eller kan man lige så godt
lægge
> det hele i een enkelt tabel.?
>
> Jeg tænker i den sammenhæng udelukkende på performance (søge- og
> svartider mv.).
>

1) Lav et par testdesigns og hæld 20 millioner rækker i databasen og
udfør nogle typiske select, update, delete, inserts osv. Brug dine
testdatabaser mens du udvikler systemet til at teste performence
undervejs.

2) Normalisering sikrer nem vedligeholdelse og i de fleste tilfælde
god performence. Hvis dataene hovedsaglig skal bruges til rapport
(lignende) forespørgsler, så kan man ofte opnå bedre performence ved
at denormalisere. Denormalisering kan opfattes som optimering til
nogle specielle formål, mens der tabes performence ved andre formål.
Findes der ikke et af de der hæfter der hedder "Normalisering for
dummies" eller eller sådan noget? Det kunne sikkert give et hurtigt
indblik i normalisering.

/Peter

---

"Peter Laursen" <pl@mail1.remove.this.stofanet.dk> skrev Sat, 28 Jun
2003 00:24:02 +0200


>1) Lav et par testdesigns og hæld 20 millioner rækker i databasen og
>udfør nogle typiske select, update, delete, inserts osv. Brug dine
>testdatabaser mens du udvikler systemet til at teste performence
>undervejs.
>
Det var selvfølgelig en mulighed. Men det er nu hovedsageligt svartider
jeg interesserer mig for i den her sammenhæng. Opdatering vil komme til
at foregå som en batch-kørsel nogle få gange årligt.

>2) Normalisering sikrer nem vedligeholdelse og i de fleste tilfælde
>god performence. Hvis dataene hovedsaglig skal bruges til rapport
>(lignende) forespørgsler, så kan man ofte opnå bedre performence ved
>at denormalisere.
>
Jeg er vist ikke helt klar over hvad du mener her.?

Den typiske brug vil være at der søges på en 6 - 10 kriterier, men at
samtlige felter skal udlæses for de poster der hitter.


--
mvh, A:\Feldborg

Folketælllinger Hammerum og Bøling herreder, kirkebøger Hammerum herred
http://www.haunstrup.dk/feldborg/genealogi/download/

---

Arne Feldborg wrote:
> Det skal kun være muligt at søge i een hovedgruppe ad gangen.

Det betyder, at hovedgruppen skal være første felt i alle indexer.

> Vil det være mest hensigtsmæsigt at oprette en tabel til hver
> hovedgruppe (evt. en database til hver hovedgruppe og derunder en tabel
> til hvert af de prinære undergrupper), eller kan man lige så godt lægge
> det hele i een enkelt tabel.?

Der er enkelte fordele ved begge dele. Hvis du er 100% sikker på, at du
aldrig nogensinde kommer til at lave bare en enkelt forespørgsel på tværs
af hovedgrupperne, og du er 100% sikker på, at du altid vil tilgå dine data
fra PHP, og ikke fra et andet program, så mener jeg godt at du kan splitte
det op og få enkelte administrative fordele. Jeg tror ikke på
performancefordele, især fordi du siger, at du sjældent skriver i
databasen.

Men databaser er nu beregnet på at man har det i samme tabel, så hvis du på
nogen måde på et tidspunkt får brug for, at det ligger i samme tabel, så
vil du fortryde, at du delte det op.

Mht. søge- og svartider, så laver alle databaser en binær søgning på et
indeks. Hvis du siger 2 millioner poster, så svarer det til 21 opslag før
en record er fundet. Hvis du deler dette op i 20 lige store tabeller, så
får du reduceret antal poster til 100.000, svarende til ca. 17 opslag,
altså en nedsættelse af tidsforbruget med 19%. I praksis betyder det
ingenting.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

---

Lars Dybdahl <lars@dybdahl.net> skrev:

> Men databaser er nu beregnet på at man har det i samme
> tabel, så hvis du på nogen måde på et tidspunkt får brug
> for, at det ligger i samme tabel, så vil du fortryde, at du
> delte det op.

Hvis der bruges en database med views - dvs en af de allernyeste
versioner hvis du bruger MySQL - og applikationen laver sine
søgninger gennem views, kan man ændre på designet af de
underliggende tabeller uden at ændre applikationen - og på
den måde eksperimentere sig til hvad der performer bedst.

ON

---

Arne Feldborg <feldborg@haunstrup.dk> skrev Fri, 27 Jun 2003 14:09:29
+0200

>Vil det være mest hensigtsmæsigt at oprette en tabel til hver
>hovedgruppe (evt. en database til hver hovedgruppe og derunder en tabel
>til hvert af de prinære undergrupper), eller kan man lige så godt lægge
>det hele i een enkelt tabel.?
>
Tak for de konkrete svar på mit spørgsmål, og for de mange andre gode
råd der faldt af undervejs.


--
mvh, A:\Feldborg

Folketælllinger Hammerum og Bøling herreder, kirkebøger Hammerum herred
http://www.haunstrup.dk/feldborg/genealogi/download/