---

Jeg bruger MySQL 4.0.26

Tabel Boger
Idkode : INT
Forfatter : INT

Tabel Forfatter
Idkode : INT
Navn : varchar

Boger.Forfatter henviser til Forfatter.Idkode.
Det jeg ønsker er at finde er de poster i Forfatter som der ikke er
henvisninger til fra nogle poster i Boger. Jeg har prøvet med:

SELECT *
FROM `forfatter`
left join boger on boger.forfatter=forfatter.idkode
where boger.idkode is null

det ser ud til at virke men det er utrolig langsom (tager over 1 minut på en
3Ghz) så nogle forslag?

/HK

---

Harald wrote:
> Jeg bruger MySQL 4.0.26
>
> Tabel Boger
> Idkode : INT
> Forfatter : INT
>
> Tabel Forfatter
> Idkode : INT
> Navn : varchar
>
> Boger.Forfatter henviser til Forfatter.Idkode.
> Det jeg ønsker er at finde er de poster i Forfatter som der ikke er
> henvisninger til fra nogle poster i Boger. Jeg har prøvet med:
>
> SELECT *
> FROM `forfatter`
> left join boger on boger.forfatter=forfatter.idkode
> where boger.idkode is null
>
> det ser ud til at virke men det er utrolig langsom (tager over 1
> minut på en 3Ghz) så nogle forslag?

Har du en fornuftig indexering på dine tabeller ? Hvor store er de?

Du kan også prøve

select *
from forfatter
where not exists (select * from boger where boger.forfatter =
forfatter.idkode)


--
Kristian Damm Jensen

---

"Kristian Damm Jensen" <dNOamSPmAM.usenet@kristiandamm.dk> skrev i en
meddelelse news:44412b9f$0$27562$edfadb0f@dread11.news.tele.dk...
> Harald wrote:
>> Jeg bruger MySQL 4.0.26
>>
>> Tabel Boger
>> Idkode : INT
>> Forfatter : INT
>>
>> Tabel Forfatter
>> Idkode : INT
>> Navn : varchar
>>
>> Boger.Forfatter henviser til Forfatter.Idkode.
>> Det jeg ønsker er at finde er de poster i Forfatter som der ikke er
>> henvisninger til fra nogle poster i Boger. Jeg har prøvet med:
>>
>> SELECT *
>> FROM `forfatter`
>> left join boger on boger.forfatter=forfatter.idkode
>> where boger.idkode is null
>>
>> det ser ud til at virke men det er utrolig langsom (tager over 1
>> minut på en 3Ghz) så nogle forslag?
>
> Har du en fornuftig indexering på dine tabeller ? Hvor store er de?

Kun er Idkode i begge tabeller er index. Der er 7500 poster i Boger og 3500
poster i Forfatter. Jeg kan lave alle mulige andre forespørgelser med flere
JOIN på felter der ikke er indexeret og ingen af dem tager over 1 sekund, så
hvorfor lige denne tager så lang tid undre mig?

> Du kan også prøve
>
> select *
> from forfatter
> where not exists (select * from boger where boger.forfatter =
> forfatter.idkode)

Det giver en syntax fejl
You have an error in your SQL syntax. Check the manual that corresponds to
your MySQL server version for the right syntax to use near 'exists (select *
from boger where boger.forfatter =forfatter.id

/HK

---

"Harald" <nomail@noname.dk> skrev i en meddelelse
news:44412e55$0$84030$edfadb0f@dtext01.news.tele.dk...
> "Kristian Damm Jensen" <dNOamSPmAM.usenet@kristiandamm.dk> skrev i en
> meddelelse news:44412b9f$0$27562$edfadb0f@dread11.news.tele.dk...
>> Harald wrote:
>>> Jeg bruger MySQL 4.0.26
>>>
>>> Tabel Boger
>>> Idkode : INT
>>> Forfatter : INT
>>>
>>> Tabel Forfatter
>>> Idkode : INT
>>> Navn : varchar
>>>
>>> Boger.Forfatter henviser til Forfatter.Idkode.
>>> Det jeg ønsker er at finde er de poster i Forfatter som der ikke er
>>> henvisninger til fra nogle poster i Boger. Jeg har prøvet med:
>>>
>>> SELECT *
>>> FROM `forfatter`
>>> left join boger on boger.forfatter=forfatter.idkode
>>> where boger.idkode is null
>>>
>>> det ser ud til at virke men det er utrolig langsom (tager over 1
>>> minut på en 3Ghz) så nogle forslag?
>>
>> Har du en fornuftig indexering på dine tabeller ? Hvor store er de?
>
> Kun er Idkode i begge tabeller er index. Der er 7500 poster i Boger og
> 3500 poster i Forfatter. Jeg kan lave alle mulige andre forespørgelser med
> flere JOIN på felter der ikke er indexeret og ingen af dem tager over 1
> sekund, så hvorfor lige denne tager så lang tid undre mig?
>
>> Du kan også prøve
>>
>> select *
>> from forfatter
>> where not exists (select * from boger where boger.forfatter =
>> forfatter.idkode)
>
> Det giver en syntax fejl
> You have an error in your SQL syntax. Check the manual that corresponds
> to your MySQL server version for the right syntax to use near 'exists
> (select * from boger where boger.forfatter =forfatter.id

Denne syntaks burde virke:

select *
from forfatter
where Idkode not in (select forfatter from Boger)


Mvh


C@rsten

---

"Carsten Pedersen" <Carsten.Pedersen@invalid.invalid> skrev i en meddelelse
news:44413b8a$0$27582$edfadb0f@dread11.news.tele.dk...
>
> "Harald" <nomail@noname.dk> skrev i en meddelelse
> news:44412e55$0$84030$edfadb0f@dtext01.news.tele.dk...
>> "Kristian Damm Jensen" <dNOamSPmAM.usenet@kristiandamm.dk> skrev i en
>> meddelelse news:44412b9f$0$27562$edfadb0f@dread11.news.tele.dk...
>>> Harald wrote:
>>>> Jeg bruger MySQL 4.0.26
>>>>
>>>> Tabel Boger
>>>> Idkode : INT
>>>> Forfatter : INT
>>>>
>>>> Tabel Forfatter
>>>> Idkode : INT
>>>> Navn : varchar
>>>>
>>>> Boger.Forfatter henviser til Forfatter.Idkode.
>>>> Det jeg ønsker er at finde er de poster i Forfatter som der ikke er
>>>> henvisninger til fra nogle poster i Boger. Jeg har prøvet med:
>>>>
>>>> SELECT *
>>>> FROM `forfatter`
>>>> left join boger on boger.forfatter=forfatter.idkode
>>>> where boger.idkode is null
>>>>
>>>> det ser ud til at virke men det er utrolig langsom (tager over 1
>>>> minut på en 3Ghz) så nogle forslag?
>>>
>>> Har du en fornuftig indexering på dine tabeller ? Hvor store er de?
>>
>> Kun er Idkode i begge tabeller er index. Der er 7500 poster i Boger og
>> 3500 poster i Forfatter. Jeg kan lave alle mulige andre forespørgelser
>> med flere JOIN på felter der ikke er indexeret og ingen af dem tager over
>> 1 sekund, så hvorfor lige denne tager så lang tid undre mig?
>>
>>> Du kan også prøve
>>>
>>> select *
>>> from forfatter
>>> where not exists (select * from boger where boger.forfatter =
>>> forfatter.idkode)
>>
>> Det giver en syntax fejl
>> You have an error in your SQL syntax. Check the manual that corresponds
>> to your MySQL server version for the right syntax to use near 'exists
>> (select * from boger where boger.forfatter =forfatter.id
>
> Denne syntaks burde virke:
>
> select *
> from forfatter
> where Idkode not in (select forfatter from Boger)

Syntax fejl igen:
You have an error in your SQL syntax. Check the manual that corresponds to
your MySQL server version for the right syntax to use near 'select forfatter
from Boger)' at line 3

/HK

---

Harald wrote:
> "Kristian Damm Jensen" <dNOamSPmAM.usenet@kristiandamm.dk> skrev i en
> meddelelse news:44412b9f$0$27562$edfadb0f@dread11.news.tele.dk...
>> Harald wrote:
>>> Jeg bruger MySQL 4.0.26
>>>
>>> Tabel Boger
>>> Idkode : INT
>>> Forfatter : INT
>>>
>>> Tabel Forfatter
>>> Idkode : INT
>>> Navn : varchar
>>>
>>> Boger.Forfatter henviser til Forfatter.Idkode.
>>> Det jeg ønsker er at finde er de poster i Forfatter som der ikke er
>>> henvisninger til fra nogle poster i Boger. Jeg har prøvet med:
>>>
>>> SELECT *
>>> FROM `forfatter`
>>> left join boger on boger.forfatter=forfatter.idkode
>>> where boger.idkode is null
>>>
>>> det ser ud til at virke men det er utrolig langsom (tager over 1
>>> minut på en 3Ghz) så nogle forslag?
>>
>> Har du en fornuftig indexering på dine tabeller ? Hvor store er de?
>
> Kun er Idkode i begge tabeller er index. Der er 7500 poster i Boger
> og 3500 poster i Forfatter. Jeg kan lave alle mulige andre
> forespørgelser med flere JOIN på felter der ikke er indexeret og
> ingen af dem tager over 1 sekund, så hvorfor lige denne tager så lang
> tid undre mig?
>> Du kan også prøve
>>
>> select *
>> from forfatter
>> where not exists (select * from boger where boger.forfatter =
>> forfatter.idkode)
>
> Det giver en syntax fejl
> You have an error in your SQL syntax. Check the manual that
> corresponds to your MySQL server version for the right syntax to use
> near 'exists (select * from boger where boger.forfatter =forfatter.id


Og gjorde du så det (checkede manualen)? Tilsyneladende ikke, hvilket du
burde skamme dig over.

Til gengæld kan jeg så glæde mig over, at jeg kan få lov til selv at rette
fejlen fremfor at få den stukket i næsen..

Jeg huskede forkert. Subselects er først tilladt fra version 4.1 og ikke -
som jeg troede - fra version 4. Dermed er hverken min ellers Carstens
løsnings korrekt for dette DBMS. Beklager.

Jeg vil foreslå at du opgraderer til en nyere version af MySQL. Der er så
mange ting der er nemmere, når man har en fuld SQL, fremfor den amputerede
version MySQL kørte med tidligere.

Desuden vil jeg anbefale et indeks på boger.forfatter. I mangel heraf skal
hele tabellen løbes igennem fra en ende af 3500 gange. 7500 * 3500 ; det
lyder ikke urimeligt i mine ører at det skal tage et minut.
--
Kristian Damm Jensen

---

"Kristian Damm Jensen" <dNOamSPmAM.usenet@kristiandamm.dk> skrev i en
meddelelse news:44416d0e$0$27577$edfadb0f@dread11.news.tele.dk...
> Harald wrote:
>> "Kristian Damm Jensen" <dNOamSPmAM.usenet@kristiandamm.dk> skrev i en
>> meddelelse news:44412b9f$0$27562$edfadb0f@dread11.news.tele.dk...
>>> Harald wrote:

<klip>

>>> select *
>>> from forfatter
>>> where not exists (select * from boger where boger.forfatter =
>>> forfatter.idkode)
>>
>> Det giver en syntax fejl
>> You have an error in your SQL syntax. Check the manual that
>> corresponds to your MySQL server version for the right syntax to use
>> near 'exists (select * from boger where boger.forfatter =forfatter.id
>
>
> Og gjorde du så det (checkede manualen)? Tilsyneladende ikke, hvilket du
> burde skamme dig over.
>
> Til gengæld kan jeg så glæde mig over, at jeg kan få lov til selv at rette
> fejlen fremfor at få den stukket i næsen..
>
> Jeg huskede forkert. Subselects er først tilladt fra version 4.1 og ikke -
> som jeg troede - fra version 4. Dermed er hverken min ellers Carstens
> løsnings korrekt for dette DBMS. Beklager.
>
> Jeg vil foreslå at du opgraderer til en nyere version af MySQL. Der er så
> mange ting der er nemmere, når man har en fuld SQL, fremfor den amputerede
> version MySQL kørte med tidligere.
>
> Desuden vil jeg anbefale et indeks på boger.forfatter. I mangel heraf skal
> hele tabellen løbes igennem fra en ende af 3500 gange. 7500 * 3500 ; det
> lyder ikke urimeligt i mine ører at det skal tage et minut.

Jo jeg havde kikket i manualen lige her:
http://dev.mysql.com/doc/refman/4.1/en/exists-and-not-exists-subqueries.html
men så ikke at der står noget om at det ikke er understøttet i 4.0. Jeg har
desværre ikke mulighed for at opgradere da nogle af de programmer jeg bruger
kun understøtter 4.0. Men hvis der ikke kommer flere gode forslag så vil jeg
prøve med et index.
Tak for hjælpen.

/HK

---

On Fri, 14 Apr 2006 21:43:58 +0200, "Harald" <nomail@noname.dk> wrote:

>SELECT *
>FROM `forfatter`
>left join boger on boger.forfatter=forfatter.idkode
>where boger.idkode is null
>
>det ser ud til at virke men det er utrolig langsom (tager over 1 minut på en
>3Ghz) så nogle forslag?

LEFT JOIN-stuntet plejer nu at være hurtigere end subselect-stuntet
(som rigtigt nok kun er tilgængeligt i MySQL 4.1+). Har du relevante
indexes på plads?

Du kan prøve med en explain:

EXPLAIN SELECT *
FROM `forfatter`
left join boger on boger.forfatter=forfatter.idkode
where boger.idkode is null



Ud fra hvad du senere beskriver, lyder det i allerhøjeste grad som om,
du godt kunne bruge et index på boger.forfatter.

--
- Peter Brodersen
Find dig selv: http://map.ter.dk/

---

"Peter Brodersen" <usenet2006@ter.dk> skrev i en meddelelse
news:e20lfe$1n9$1@news.klen.dk...
> On Fri, 14 Apr 2006 21:43:58 +0200, "Harald" <nomail@noname.dk> wrote:
>
>>SELECT *
>>FROM `forfatter`
>>left join boger on boger.forfatter=forfatter.idkode
>>where boger.idkode is null
>>
>>det ser ud til at virke men det er utrolig langsom (tager over 1 minut på
>>en
>>3Ghz) så nogle forslag?
>
> LEFT JOIN-stuntet plejer nu at være hurtigere end subselect-stuntet
> (som rigtigt nok kun er tilgængeligt i MySQL 4.1+). Har du relevante
> indexes på plads?
>
> Du kan prøve med en explain:
>
> EXPLAIN SELECT *
> FROM `forfatter`
> left join boger on boger.forfatter=forfatter.idkode
> where boger.idkode is null
>
> Ud fra hvad du senere beskriver, lyder det i allerhøjeste grad som om,
> du godt kunne bruge et index på boger.forfatter.

Jeg har ikke et index på boger.forfatter, jeg forsøger at holde antal index
på et minimum da jeg har en ide om at jo flere index jo større chance er der
for at noget kan gå galt i tabellen, men der tager jeg måske helt fejl?

/HK

---

On Mon, 17 Apr 2006 22:59:09 +0200, "Harald" <nomail@noname.dk> wrote:

>> Ud fra hvad du senere beskriver, lyder det i allerhøjeste grad som om,
>> du godt kunne bruge et index på boger.forfatter.
>Jeg har ikke et index på boger.forfatter, jeg forsøger at holde antal index
>på et minimum da jeg har en ide om at jo flere index jo større chance er der
>for at noget kan gå galt i tabellen, men der tager jeg måske helt fejl?

Ja, det er meget ved siden af

Hvis du ikke har et index på boger.forfatter, og du laver et opslag på
en bestemt værdi for boger.forfatter, skal alle rækker kigges igennem
for at finde rækker med den korrekte værdi.

Det skal der så gøres for samtlige rækker i Forfatter.

Hvis du laver en EXPLAIN, vil du sandsynligvis kunne se, at for hver
af de 3.500 rækker i Forfatter, skal der kigges 7.500 rækker igennem i
Boger. Det giver rigtigt, rigtigt mange rækker, når man ganger de to
tal op mod hinanden.

Du kan prøve at tilføje det index, og så lave dit opslag (som så vil
være yderst hurtigt). Og evt. også lave en EXPLAIN bagefter for at få
bekræftet, at antallet af rækker, der skal kigges på, er faldet
tilsvarende.

At tilføje et index vil tilføje en lille smule ekstra behandlingstid,
når der skal tilføjes/rettes/slettes rækker, men for de tilfælde, hvor
man skal lave et opslag for en bestemt værdi direkte på et felt, vil
det stort set altid kunne betale sig at have et index.

Der er ikke noget specielt magisk over indexes. Sammenlign med
forfatter-kartoteket på et bibliotek, hvor bøgerne primært er sorteret
efter kategorier/numre. Hvis du ikke gør brug af dette kartotek (eller
det ikke findes), og skal finde alle bøger af en bestemt forfatter, så
skal du kigge alle bogrygge igennem på hele biblioteket. Hvis du
derimod starter med at slå op i forfatter-kartoteket, kan du let finde
alle bøger skrevet af en bestemt forfatter - også selv om de er i vidt
forskellige kategorier.

"Ulempen" er, at biblioteket, når de får en ny bog, ikke blot skal
sætte den på hylden, men skal også tilføje et kort i kartoteket
(indexet). Dette er dog et minimum af arbejde.

Arbejdet med at gøre brug af indexet er noget, database-serveren selv
håndterer. Du skal ikke ændre din forespørgsel (SQL) på nogen måde,
hverken når du henter data eller retter data.


Vi kan også skære dit eksempel helt ned, så det måske bliver endnu
mere klart:

SELECT * FROM Boger WHERE Forfatter = 1234;

Denne forespørgsel kræver, at alle rækker i Boger kigges igennem. Det
er udelukkende for at finde én forfatter. Med et indeks på det
pågældende felt, er rækken så sorteret på forhånd, så det er hurtigere
at finde frem og se om dette forfatter-id optræder.

--
- Peter Brodersen
Find dig selv: http://map.ter.dk/

---

"Peter Brodersen" <usenet2006@ter.dk> skrev i en meddelelse
news:e214e2$dsh$1@news.klen.dk...
> On Mon, 17 Apr 2006 22:59:09 +0200, "Harald" <nomail@noname.dk> wrote:
>
>>> Ud fra hvad du senere beskriver, lyder det i allerhøjeste grad som om,
>>> du godt kunne bruge et index på boger.forfatter.
>>Jeg har ikke et index på boger.forfatter, jeg forsøger at holde antal
>>index
>>på et minimum da jeg har en ide om at jo flere index jo større chance er
>>der
>>for at noget kan gå galt i tabellen, men der tager jeg måske helt fejl?
>
> Ja, det er meget ved siden af
>
> Hvis du ikke har et index på boger.forfatter, og du laver et opslag på
> en bestemt værdi for boger.forfatter, skal alle rækker kigges igennem
> for at finde rækker med den korrekte værdi.
>
> Det skal der så gøres for samtlige rækker i Forfatter.
>
> Hvis du laver en EXPLAIN, vil du sandsynligvis kunne se, at for hver
> af de 3.500 rækker i Forfatter, skal der kigges 7.500 rækker igennem i
> Boger. Det giver rigtigt, rigtigt mange rækker, når man ganger de to
> tal op mod hinanden.
>
> Du kan prøve at tilføje det index, og så lave dit opslag (som så vil
> være yderst hurtigt). Og evt. også lave en EXPLAIN bagefter for at få
> bekræftet, at antallet af rækker, der skal kigges på, er faldet
> tilsvarende.
>
> At tilføje et index vil tilføje en lille smule ekstra behandlingstid,
> når der skal tilføjes/rettes/slettes rækker, men for de tilfælde, hvor
> man skal lave et opslag for en bestemt værdi direkte på et felt, vil
> det stort set altid kunne betale sig at have et index.
>
> Der er ikke noget specielt magisk over indexes. Sammenlign med
> forfatter-kartoteket på et bibliotek, hvor bøgerne primært er sorteret
> efter kategorier/numre. Hvis du ikke gør brug af dette kartotek (eller
> det ikke findes), og skal finde alle bøger af en bestemt forfatter, så
> skal du kigge alle bogrygge igennem på hele biblioteket. Hvis du
> derimod starter med at slå op i forfatter-kartoteket, kan du let finde
> alle bøger skrevet af en bestemt forfatter - også selv om de er i vidt
> forskellige kategorier.
>
> "Ulempen" er, at biblioteket, når de får en ny bog, ikke blot skal
> sætte den på hylden, men skal også tilføje et kort i kartoteket
> (indexet). Dette er dog et minimum af arbejde.
>
> Arbejdet med at gøre brug af indexet er noget, database-serveren selv
> håndterer. Du skal ikke ændre din forespørgsel (SQL) på nogen måde,
> hverken når du henter data eller retter data.
>
> Vi kan også skære dit eksempel helt ned, så det måske bliver endnu
> mere klart:
>
> SELECT * FROM Boger WHERE Forfatter = 1234;
>
> Denne forespørgsel kræver, at alle rækker i Boger kigges igennem. Det
> er udelukkende for at finde én forfatter. Med et indeks på det
> pågældende felt, er rækken så sorteret på forhånd, så det er hurtigere
> at finde frem og se om dette forfatter-id optræder.

Jeg har nu prøvet at oprette et index på boger.forfatter og det nedsatte
tiden for at finde 40 poster fra 47 sek. til 0,06 sek. så det kan man jo
sige var en forbedring. Mange tak for svaret.

/HK

---

Harald wrote:

<snip>

> Jeg har ikke et index på boger.forfatter, jeg forsøger at holde antal
> index på et minimum da jeg har en ide om at jo flere index jo større
> chance er der for at noget kan gå galt i tabellen, men der tager jeg
> måske helt fejl?

Med fare for at virke nedladende (det er bestemt ikke min mening): Hvor har
du den idé fra? Jeg er oprigtigt nysgerrig. Hvad skulle kunne gå galt?

(Peter Brodersen har allerede forklaret den rette sammenhæng. Det vil jeg
ikke give mig i kast med at gøre bedre.)


--
Kristian Damm Jensen

---

"Kristian Damm Jensen" <dNOamSPmAM.usenet@kristiandamm.dk> skrev i en
meddelelse news:444542d5$0$27609$edfadb0f@dread11.news.tele.dk...
> Harald wrote:
>
> <snip>
>
>> Jeg har ikke et index på boger.forfatter, jeg forsøger at holde antal
>> index på et minimum da jeg har en ide om at jo flere index jo større
>> chance er der for at noget kan gå galt i tabellen, men der tager jeg
>> måske helt fejl?
>
> Med fare for at virke nedladende (det er bestemt ikke min mening): Hvor
> har du den idé fra? Jeg er oprigtigt nysgerrig. Hvad skulle kunne gå galt?

Det stammer nok fra den tid hvor jeg brugte paradox tabeller hvor jeg flere
gange oplevede at kunder ringede og sagde at programmet melde om index fejl
i databasen hvorefter jeg skulle foretage en reindexering af databasen før
det virkede igen, de fleste gange mente kunden nok at det kom efter at deres
computer var gået død eller efter de havde haft strømsvigt.
Men index i MySQL er måske ikke så følsom? Eller kan man gøre noget for at
undgå den slags fejl, hvis de da overhovedet opstår i MySQL?

/HK

---

Harald wrote:
> "Kristian Damm Jensen" <dNOamSPmAM.usenet@kristiandamm.dk> skrev i en
> meddelelse news:444542d5$0$27609$edfadb0f@dread11.news.tele.dk...
>> Harald wrote:
>>
>> <snip>
>>
>>> Jeg har ikke et index på boger.forfatter, jeg forsøger at holde
>>> antal index på et minimum da jeg har en ide om at jo flere index jo
>>> større chance er der for at noget kan gå galt i tabellen, men der
>>> tager jeg måske helt fejl?
>>
>> Med fare for at virke nedladende (det er bestemt ikke min mening):
>> Hvor har du den idé fra? Jeg er oprigtigt nysgerrig. Hvad skulle
>> kunne gå galt?
>
> Det stammer nok fra den tid hvor jeg brugte paradox tabeller hvor jeg
> flere gange oplevede at kunder ringede og sagde at programmet melde
> om index fejl i databasen hvorefter jeg skulle foretage en
> reindexering af databasen før det virkede igen, de fleste gange mente
> kunden nok at det kom efter at deres computer var gået død eller
> efter de havde haft strømsvigt. Men index i MySQL er måske ikke så følsom?
> Eller kan man gøre noget
> for at undgå den slags fejl, hvis de da overhovedet opstår i MySQL?

Okay.

Nu er vi nede på et meget basalt niveau. Ethvert system kan gå fuldstændig i
stykker, hvis man klipper ledningen over på det forkerte tidspunkt. Det
gælder naturligvis også MySQL.

Jeg kender ikke noget til de tekniske detaljer i hverken Paradox eller
MySQL, så det vil jeg helst ikke udtale mig om følsomheden. Men til en start
vil jeg tro, at MySQL er mindre skarpt koblet til applikationen og derfor
nok skulle kunne bevare sin konsistens selvom applikationen går ned. Det
burde kun være hvis MySQL-serveren selv går ned, at der skulle kunne opstå
problemer.

Men jeg kunne aldrig finde på at lade den slags stå i vejen for at skrue mit
system sammen på den rigtige måde. Så må man altså investere det nødvendige
i at have et sikkert system, der ikke går ned. Og have en backup klar når
det alligevel går galt.

--
Kristian Damm Jensen

---

Kristian Damm Jensen wrote:
> Harald wrote:
>
>>Det stammer nok fra den tid hvor jeg brugte paradox tabeller hvor jeg
>>flere gange oplevede at kunder ringede og sagde at programmet melde
>>om index fejl i databasen hvorefter jeg skulle foretage en
>>reindexering af databasen før det virkede igen, de fleste gange mente
>>kunden nok at det kom efter at deres computer var gået død eller
>>efter de havde haft strømsvigt. Men index i MySQL er måske ikke så følsom?
>>Eller kan man gøre noget
>>for at undgå den slags fejl, hvis de da overhovedet opstår i MySQL?
>
> Nu er vi nede på et meget basalt niveau. Ethvert system kan gå fuldstændig i
> stykker, hvis man klipper ledningen over på det forkerte tidspunkt. Det
> gælder naturligvis også MySQL.

Hvis man bruger en transaktions-log og tager backup hver gang man
committer den, er man så godt som 100% sikker.

Nu har jeg erfaret at mysql er notorisk feature-incomplete, så jeg ved
ikke om lige netop mysql understøtter dette, men Postgres, som er en
anden Open Source database, understøtter det.

Problemet med Paradox er nok snarere at det er en enkeltbrugerdatabase,
som slet ikke bygger på ACID-paradigmet.

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