---

Hej

Hvilke produkter har Microsoft der tilsvarer PostgreSQL eller MySQL eller
f.eks. Oracle - jeg tænker på store serverbaserede databaseløsninger.
Jeg kender kun Access og det er vist ikke lige sagen.

På forhånd tak.

Venlig hilsen

Jes

---

JP <davinci@mail.tele.dk> skrev i en
nyhedsmeddelelse:3dfce7a7$0$209$edfadb0f@dread12.news.tele.dk...
>
> Hvilke produkter har Microsoft der tilsvarer PostgreSQL eller MySQL eller
> f.eks. Oracle - jeg tænker på store serverbaserede databaseløsninger.
> Jeg kender kun Access og det er vist ikke lige sagen.
>
MSSQL
http://www.microsoft.com/sql/default.asp

mvh/Peter Lykkegaard

---

JP wrote:
> Hvilke produkter har Microsoft der tilsvarer PostgreSQL eller MySQL eller
> f.eks. Oracle - jeg tænker på store serverbaserede databaseløsninger.
> Jeg kender kun Access og det er vist ikke lige sagen.

Jeg ved godt at jeg ikke svarer specifikt på dit spørgsmål, men hvad er
problemet med mysql, det er da let at installere på win...

mvh

Jesper Brunholm

---

Jesper Brunholm wrote:
>
> Jeg ved godt at jeg ikke svarer specifikt på dit spørgsmål, men hvad
> er problemet med mysql, det er da let at installere på win...
>

MySQL er ganske udmærket, men det er altså stadig ikke godt nok, når det
drejer sig om virkeligt store databaseløsninger. Nu ved jeg jo ikke, hvad
formålet er i denne situation, men når det drejer sig om kritiske løsninger
er SQL Server et langt bedre alternativ, selvom der naturligvis findes bedre
(og dyrere og mere komplekse) løsninger som Oracle og DB2.

--
Michael Barrett

---

"> MySQL er ganske udmærket, men det er altså stadig ikke godt nok, når det
> drejer sig om virkeligt store databaseløsninger. Nu ved jeg jo ikke, hvad
> formålet er i denne situation, men når det drejer sig om kritiske
løsninger
> er SQL Server et langt bedre alternativ, selvom der naturligvis findes
bedre
> (og dyrere og mere komplekse) løsninger som Oracle og DB2.

Jeg er lidt tændt på PostgreSQL - men den kører vist bedst på Linux
maskiner.

Jeg tænkte også på økonomien i det. Microsoft plejer at ta' sig godt betalt.
Men jeg kender ikke prisen på MSSQL programmet.

Vh. Jes

---

> "> MySQL er ganske udmærket, men det er altså stadig ikke godt nok, når
det
> > drejer sig om virkeligt store databaseløsninger. Nu ved jeg jo ikke,
hvad
> > formålet er i denne situation, men når det drejer sig om kritiske
> løsninger
> > er SQL Server et langt bedre alternativ, selvom der naturligvis findes
> bedre
> > (og dyrere og mere komplekse) løsninger som Oracle og DB2.
> Jeg er lidt tændt på PostgreSQL - men den kører vist bedst på Linux
> maskiner.
> Jeg tænkte også på økonomien i det. Microsoft plejer at ta' sig godt
betalt.
> Men jeg kender ikke prisen på MSSQL programmet.

Hvem herinde har lavet en database som mySQL *IKKE* vil kunne
trække/køre/håndtere? Med andre ord, hvor mange er teoretikere og hvor mange
har praktiske erfaringer? Det er egenlig ikke fordi jeg er fanatisk i mit
valg af database, men mere fordi jeg synes det kunne være interssant at få
skildt teoretikerne fra. De har ofte med at lyde som en længere salgstale
for et dyrt Microsoft produkt -Gerne før folks behov er klarlagt!

Hvem tør stå frem?

---

Thomas Lesvang wrote:
>> MySQL er ganske udmærket, men det er altså stadig ikke godt nok, når
>> det drejer sig om virkeligt store databaseløsninger. Nu ved jeg jo ikke,
>> hvad formålet er i denne situation, men når det drejer sig om kritiske
>>løsninger er SQL Server et langt bedre alternativ, selvom der naturligvis findes
>>bedre (og dyrere og mere komplekse) løsninger som Oracle og DB2.

> Hvem herinde har lavet en database som mySQL *IKKE* vil kunne
> trække/køre/håndtere?

Nu handler det vel ikke kun om at _kunne_ trække databasen, men også om
at kunne det i fuldt tempo.

Næste afdeling kunne let være at man ønsker _fuld_ SQL-understøttelse,
dvs. også fx nestede queryes m.m. som ikke er tilgængeligt i mysql.

Men det vil da være spændende at høre om praktiske erfaringer om ting
som man har været nødt til at flytte over på de dyrere databaser pga.
størrelse/funktionalitet.

btw: kunne du ikke se på dit urs indstilling - det ser lidt spøjst ud
her hos mig

mvh

Jesper Brunholm

--
H.C. Andersen-Centret med nyt design: <http://www.andersen.sdu.dk/>
Phønix - dansk folk-musik fra unge musikere - <http://www.phonixfolk.dk/>

---

> Nu handler det vel ikke kun om at _kunne_ trække databasen, men også om
> at kunne det i fuldt tempo.

Nej, men hvis man nu designer sin database til at kunne køre på MySQL (dvs.
ingen avancerede ting), så tror jeg ikke du vil kunne sætte en finger på
hastigheden. Det er jo netop styrken ved MySQL. Simpelt og hurtigt... og
IMHO ganske stabilt (har aldrig haft bøvl)

> Næste afdeling kunne let være at man ønsker _fuld_ SQL-understøttelse,
> dvs. også fx nestede queryes m.m. som ikke er tilgængeligt i mysql.

Enig, men brugbarheden af joins og nestede queries afhænger også i høj grad
af hvordan du designer din database, eller om du tænker dig om. I nogle
tilfælde kan det se smart ud at joine 10 tabeller, men hurtigt bliver det
næppe. Jeg vil mene, at til de fleste ting, så behøver man ikke support for
alle de fancy ting som nestede queries, fremmednøgler og den slags.

Jeg tager uden tvivl fejl, hvilket også var derfor jeg søgte nogen som kunne
give mig et eksempel på en database der netop havde brug for disse ting.
Hvor jeg med brug, virkelig mener brug og ikke "jamen, så sparer jeg lige 2
queries der og 10 linier kode der"

> Men det vil da være spændende at høre om praktiske erfaringer om ting
> som man har været nødt til at flytte over på de dyrere databaser pga.
> størrelse/funktionalitet.

Yep!

> btw: kunne du ikke se på dit urs indstilling - det ser lidt spøjst ud
> her hos mig

Hmm, både ur og dato ser ud til at stå fint?

---

Således skrev "tsl" <dingamlemamma@hotmail.com> i dk.edb.database
Mon, 16 Dec 2002 15:50:38 -0800:

>
>> btw: kunne du ikke se på dit urs indstilling - det ser lidt spøjst ud
>> her hos mig
>
>Hmm, både ur og dato ser ud til at stå fint?

Fra din header:

Date: Mon, 16 Dec 2002 15:50:38 -0800

Din tidszone er lidt langt ude vestpå.

Knud
--
Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum
immane mittam.

---

Hej Thomas,

"tsl" <dingamlemamma@hotmail.com> wrote in message
news:3dfde888$0$208$edfadb0f@dread14.news.tele.dk...
> Enig, men brugbarheden af joins og nestede queries afhænger også i høj
grad
> af hvordan du designer din database, eller om du tænker dig om. I nogle
> tilfælde kan det se smart ud at joine 10 tabeller, men hurtigt bliver det
> næppe. Jeg vil mene, at til de fleste ting, så behøver man ikke support
for
> alle de fancy ting som nestede queries, fremmednøgler og den slags.
>

Tag f.eks. et kig på enhver ERP/CRM applikation (SAP, Oracle, Siebel,
PeopleSoft, etc.) -og du vil se hvorfor avancerede konstruktioner er
nødvendige.

vh. Jørgen

---

On Mon, 16 Dec 2002 13:36:50 +0000, Thomas Lesvang wrote:

> Hvem herinde har lavet en database som mySQL *IKKE* vil kunne
> trække/køre/håndtere?

Jeg har oplevet performanceproblemer med MySQL, af en ret irriterende
form: Det virker som om, at MySQL's performance-kurve ikke er
forudsigelig: Indtil en vis grænse går det helt fint, men lige pludselig
brager den ned til 99,9% ubrugelighed pga. for meget arbejde. Mit indtryk
er, at PostgreSQL's ydelseskurve er mere forudsigelig: I stedet for
pludselig at brage ned, går det blot langsommere og langsommere. Jeg skal
dog sige, at de to databaseinstallationers arbejdsmængde ikke var helt
sammenlignelig.

Noget andet: Jeg synes, at det er rart, at man i PostgreSQL kan
specificere dataintegritet mere detaljeret end i MySQL, via constraints,
foreign keys, osv. På den måde kan man etablere en sitation, hvor
applikationen kan tillade sig at stole på databasens data, og hvor man da
kan nøjes med at sanity-check'e indkommende brugerdata (i stedet for
principielt at skulle stille sig skeptisk overfor begge datakilder).

Fra MySQL savner jeg en lidt lettere systemadministration (herunder
særligt brugerrettigheder) og ENUMs (er det mon egentlig en officiel
SQL-feature?).

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

> Jeg har oplevet performanceproblemer med MySQL, af en ret irriterende
> form: Det virker som om, at MySQL's performance-kurve ikke er
> forudsigelig: Indtil en vis grænse går det helt fint, men lige pludselig
> brager den ned til 99,9% ubrugelighed pga. for meget arbejde. Mit indtryk
> er, at PostgreSQL's ydelseskurve er mere forudsigelig: I stedet for
> pludselig at brage ned, går det blot langsommere og langsommere. Jeg skal
> dog sige, at de to databaseinstallationers arbejdsmængde ikke var helt
> sammenlignelig.

Well, det har vel en naturlig forklaring. MySQL bruger tabel-level-locking
og postgre bruger row-level-locking. Dvs. hvis du har en tabel med rigtig
mange
inserts, så er MySQL med myISAM tabeller (default) et skidt valg. Hvis det
forekommer, så vil den netop opføre sig som du nævner fordi den konstant
venter på de andre tråde bliver færdige. Jo mere pres, jo flere tråde skaber
den som bare står og venter og så bang

Du skal vælge din tabeltype efter hvilke type queries din tabel får flest
af. InnoDB, Berkeley og andre tabeltyper skal installeres seperat, med
mindre
man installere MySQL MAX som har alle med fra starten.

Vælg den korrekte tabeltype den opgaven og så tror jeg du vil opleve mere
forudsigelighed, selvom jeg selvfølgelig ikke vil afvise at MySQL har
problemer på det område du nævner.

> Noget andet: Jeg synes, at det er rart, at man i PostgreSQL kan
> specificere dataintegritet mere detaljeret end i MySQL, via constraints,
> foreign keys, osv. På den måde kan man etablere en sitation, hvor
> applikationen kan tillade sig at stole på databasens data, og hvor man da
> kan nøjes med at sanity-check'e indkommende brugerdata (i stedet for
> principielt at skulle stille sig skeptisk overfor begge datakilder).

Der er flere sider af den sag. At stole på kun den ene kilde stiller rigtig
store krav til dit design. Der er også problemer med dumps af tabeller og
den slags, hvor man virkelig skal tænke sig om. Personligt undgår jeg gerne
constraints, fremmednøgler og den slags. Det er vel en smagssag i guess, men
jeg mener at kunne huske folkene bag MySQL komme med en lang smøre om hvor
onde fremmednøgler osv. var. Skal prøve og grave link frem, selvom det nok
er en smule "farvet" fremstillet

> Fra MySQL savner jeg en lidt lettere systemadministration (herunder
> særligt brugerrettigheder) og ENUMs (er det mon egentlig en officiel
> SQL-feature?).

Øhm, MySQL har ENUMs og har haft det lige så længe jeg kan huske?
Systemadministrationen er hammernem. Det er en smal sag at oprette en
bruger, give brugeren rettigheder osv. Selvfølgelig, der er intet visuelt
tool til det, men altså. Det tager 30 min. at flække sammen hvis man er
kræsen Ellers er der jo altid phpMyAdmin som letter arbejdet en del.

---

On Mon, 16 Dec 2002 16:35:13 +0000, tsl wrote:

> Du skal vælge din tabeltype efter hvilke type queries din tabel får flest
> af. InnoDB, Berkeley og andre tabeltyper
[...]

Går MySQL's hurtighed ved læsning ikke væk, hvis man kaster sig over de
alternative, mere "tunge" tabeltyper?

> Det er vel en smagssag i guess, men
> jeg mener at kunne huske folkene bag MySQL komme med en lang smøre om hvor
> onde fremmednøgler osv. var. Skal prøve og grave link frem, selvom det nok
> er en smule "farvet" fremstillet
Tak, jeg har læst det i tidernes morgen. Efter min mening skal en database
være god til at håndtere data, og herunder inkluderer jeg at den skal være
god til at håndhæve constraints.

>> Fra MySQL savner jeg en lidt lettere systemadministration (herunder
>> særligt brugerrettigheder) og ENUMs (er det mon egentlig en officiel
>> SQL-feature?).
>
> Øhm, MySQL har ENUMs og har haft det lige så længe jeg kan huske?
Netop: Siden jeg er gået over til primært at benytte PostgreSQL er jeg
stødt på et par ting, jeg savner fra MySQL. Derfor skal ovenstående læses
om at ENUMs i MySQL er rare (gør det let tydeligt at angive hvilke
værdier, som kun kan optræde).

I PostgreSQL er det - i sysadm sammenhæng - irriterende, at man ikke kan
gøre som i MySQL:
GRANT ... ON databasenavn.* to someone@localhost ...;

- Altså give en bruger adgang til en hel database ad gangen.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

> Går MySQL's hurtighed ved læsning ikke væk, hvis man kaster sig over de
> alternative, mere "tunge" tabeltyper?

Tjo, både og. Igen, det afhænger af din opgave. Det er klart hastigheden går
nedad, men du får til gengæld mulighed for commit/rollback og
transaktionslogs og den slags. Det er der vist flere herinde som har påpeget
at var en mangel med MySQL. Alt andet lige så vil en tabeltype der er
optimeret til læsning og simple operationer (myISAM) være hurtigere end en
type som understøtter mange featues og kan det hele. I teorien anyway

Spørgsmålet er jo altid om man har behov for rollback og større
datasikkerhed

> >> Fra MySQL savner jeg en lidt lettere systemadministration (herunder
> >> særligt brugerrettigheder) og ENUMs (er det mon egentlig en officiel
> >> SQL-feature?).
> I PostgreSQL er det - i sysadm sammenhæng - irriterende, at man ikke kan
> gøre som i MySQL:
> GRANT ... ON databasenavn.* to someone@localhost ...;
> - Altså give en bruger adgang til en hel database ad gangen.

Ahh, jeg læste vist forkert der. Troede du mente omvendt

---

Som svar på skriblerier nedfældet af tsl :

> Spørgsmålet er jo altid om man har behov for rollback og større
> datasikkerhed

Jamen det behov har man da lige netop i et OLTP system
Der _skal_ være 110% oppetid 24/7/356

Det nytter ikke noget at man "bare" kører forrige nats backup/dump af
databasen ind i tilfælde af et crash

mvh/Peter Lykkegaard

---

> > Spørgsmålet er jo altid om man har behov for rollback og større
> > datasikkerhed
> Jamen det behov har man da lige netop i et OLTP system
> Der _skal_ være 110% oppetid 24/7/356

Ja, jeg har vist heller ikke skrevet andet? Jeg skrev mit oprindelige indlæg
fordi folk ANTOG disse krav når nogen spurgte, for derefter at anbefale dem
en stor og dyr database. Det er disse antagelser jeg er lidt imod, selvom
det i en perfekt verden, hvor alle havde råd til Oracle og lign., jo var en
dejlig ting at kunne antage.

> Det nytter ikke noget at man "bare" kører forrige nats backup/dump af
> databasen ind i tilfælde af et crash

Se mine andre indlæg omkring det

---

Som svar på skriblerier nedfældet af tsl :

>>> Spørgsmålet er jo altid om man har behov for rollback og større
>>> datasikkerhed
>> Jamen det behov har man da lige netop i et OLTP system
>> Der _skal_ være 110% oppetid 24/7/356
>
> Ja, jeg har vist heller ikke skrevet andet? Jeg skrev mit oprindelige
> indlæg fordi folk ANTOG disse krav når nogen spurgte, for derefter at
> anbefale dem en stor og dyr database. Det er disse antagelser jeg er
> lidt imod, selvom det i en perfekt verden, hvor alle havde råd til
> Oracle og lign., jo var en dejlig ting at kunne antage.
>
I min verden er det et krav - derfor MSSQL
Databasen jeg anvender er i princippet et temporært transactionstorage
Dvs hovedmængden af data overlever ikke ugen ud

mvh/Peter Lykkegaard

---

> I min verden er det et krav - derfor MSSQL

Ja i din verden! Så fik vi lige sat det på plads

> Databasen jeg anvender er i princippet et temporært transactionstorage
> Dvs hovedmængden af data overlever ikke ugen ud

Og? Jeg har en tekstfil som jeg kalder todo.txt - Den har samme egenskaber,
men det lyder ikke nær så smart

---

Som svar på skriblerier nedfældet af tsl :

>> I min verden er det et krav - derfor MSSQL
>
> Ja i din verden! Så fik vi lige sat det på plads
>
>> Databasen jeg anvender er i princippet et temporært
>> transactionstorage Dvs hovedmængden af data overlever ikke ugen ud
>
> Og? Jeg har en tekstfil som jeg kalder todo.txt - Den har samme
> egenskaber, men det lyder ikke nær så smart

Øvelsen gik jo ud på hvorfor ikke anvende mySQL i stedet for MSSQL eller
lign
Jeg kommer med mine bud på nogle af de forskelle, der er imho er vigtige at
se på

Vi er da sikkert enige om at der kører mange MSSQL installationer der fint
kan køre på mySQL
Det har bare en pris!

Btw så stiller jeg mig lidt tvivlende overfor at din tekstfil kan arbejde
med transactionslogs og flerbruger access i et clustered miljø

mvh/Peter Lykkegaard

---

>Øvelsen gik jo ud på hvorfor ikke anvende mySQL i stedet for MSSQL eller
lign
>Jeg kommer med mine bud på nogle af de forskelle, der er imho er vigtige at
> Vi er da sikkert enige om at der kører mange MSSQL installationer der fint
> kan køre på mySQL
> Det har bare en pris!

Vi er enige

> Btw så stiller jeg mig lidt tvivlende overfor at din tekstfil kan arbejde
> med transactionslogs og flerbruger access i et clustered miljø

I know, det var nu også bare for at være lidt sjov men i bund og grund
er en tekstfil jo også en database, det er der bare ikke så mange der tænker
over.

---

Hej svarer lige mig selv...

On Mon, 16 Dec 2002 15:56:17 +0100, Troels Arvin wrote:

> Jeg har oplevet performanceproblemer med MySQL, af en ret irriterende
> form
[...]

Ret skal være ret:

Det forlyder fra velplacerede kilder, at MySQL i de seneste releases
(3.23.*) er blevet markant bedre til at skalere til rigtig mange samtidige
forbindelser.

Dér, hvor min erfaringer stammer fra (men hvor jeg ikke arbejder mere),
prøvede de for nylig at udskifte en MySQL-server med en PostgreSQL ditto
til en opgave, hvor der er rigtig mange, ret simple læsninger og få
opdateringer. Her kunne PostgreSQL ikke klare mosten, mens MySQL godt
kunne.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Hej.
Thomas Lesvang <dingamlemamma@hotmail.com> wrote in message
news:3dfdc92d$0$165$edfadb0f@dread14.news.tele.dk...

> Hvem herinde har lavet en database som mySQL *IKKE* vil kunne
> trække/køre/håndtere? Med andre ord, hvor mange er teoretikere og hvor
mange
> har praktiske erfaringer? Det er egenlig ikke fordi jeg er fanatisk i mit
> valg af database, men mere fordi jeg synes det kunne være interssant at få
> skildt teoretikerne fra. De har ofte med at lyde som en længere salgstale
> for et dyrt Microsoft produkt -Gerne før folks behov er klarlagt!

Mig, og stort set alle databaser. Som du selv skriver, så er det behovet,
der afgør valget af database, men det er også afgørende hvilket RDBMS kunden
har i forvejen. Det nytte ikke at kunne tilbyde en løsning på MS SQLServer,
hvis kunden er 'Oracle-kunde', og heller ikke det omvendte osv.

En forudsætning for - rigtige - databasesystemer er, at de kan understøtte
recovery indtil den sidst commitede transaktion.

mvh
Stig Johansen.

---

Som svar på skriblerier forfattet af Thomas Lesvang

> Hvem herinde har lavet en database som mySQL *IKKE* vil kunne
> trække/køre/håndtere?

MSMQ er ikke så vild med andet end MSSQL på NT4

Btw hvad findes der af disaster recovery på mySQL?
Hvilke Backup producenter understøtter online backup af mySQL?

mvh/Peter Lykkegaard

---

> Btw hvad findes der af disaster recovery på mySQL?

cat dagligbackup.sql | mysql

Nå det var ikke lige den løsning du spurgte efter, heh! Well, der findes
nogle tools til at fikse korrupte tabeller osv. men om de virker er vist
mere tvivlsomt. Jeg har faktisk aldrig prøvet :-/

> Hvilke Backup producenter understøtter online backup af mySQL?

Sikkert ingen og hvis der mod forventning skulle være nogen, så ligger de
sikkert i USA

---

Som svar på skriblerier nedfældet af tsl :

>> Btw hvad findes der af disaster recovery på mySQL?
>
> cat dagligbackup.sql | mysql
>
> Nå det var ikke lige den løsning du spurgte efter, heh! Well, der
> findes nogle tools til at fikse korrupte tabeller osv. men om de
> virker er vist mere tvivlsomt. Jeg har faktisk aldrig prøvet :-/
>
Er der en transactionlog man løbende kan tage backup af?
Fra den sidste fulde backup til serveren knækker nakken fx ved disknedbrud,
strømudfald ol skulle man jo gerne kunne rulle alle transactioner ind igen

Hvad sker der med mySQL hvis man slukker OS brutalt?

>> Hvilke Backup producenter understøtter online backup af mySQL?
>
> Sikkert ingen og hvis der mod forventning skulle være nogen, så
> ligger de sikkert i USA

Hmmm, dvs tager man backup af en mySQL så kan det kun laves til disk (eller
intern tapedrev) med mySQL's værktøjer og ikke fra centralt hold
(tapeloader), eller?

Btw hvordan har mySQL det i et clustered miljø?

mvh/Peter Lykkegaard

---

> Er der en transactionlog man løbende kan tage backup af?
> Fra den sidste fulde backup til serveren knækker nakken fx ved
disknedbrud,
> strømudfald ol skulle man jo gerne kunne rulle alle transactioner ind igen

Igen, det afhænger af tabeltypen. Hvordan InnoDB (med transaktioner) styrer
recovery ved jeg ikke. Der må du kigge på http://www.innodb.com/

> Hvad sker der med mySQL hvis man slukker OS brutalt?

Ikke alverden. Hvis du kører med myISAM så mister du de data du var ved at
indsætte (hvis du var det) og så skal du normalt lige køre en repair table
for at få styr på indexes igen. Hvis du kører med InnoDB, så se ovenfor.

Det afhænger selvfølgelig også af filsystemets måde at håndtere den slags
på. Man skal nok ikke vælge FAT/FAT32

> >> Hvilke Backup producenter understøtter online backup af mySQL?
> > Sikkert ingen og hvis der mod forventning skulle være nogen, så
> > ligger de sikkert i USA
> Hmmm, dvs tager man backup af en mySQL så kan det kun laves til disk
(eller
> intern tapedrev) med mySQL's værktøjer og ikke fra centralt hold
> (tapeloader), eller?

Tjo, mySQL kører jo over TCP/IP så du kan i princippet tage din backup
hvorfra i verden det skulle være. Der findes tools til stort set alle
platforme, som også virker remote.

Derudover er der altid muligheden for at tilknytte en eller flere
slave-servere (replikering). På den måde får du en backup der kører
automatisk og altid er "frisk". Desuden kan du hvis du har et meget
læse-intensivt miljø jo aflaste masterserveren - en slags simpel clustering

---

Hej Thomas,

"Thomas Lesvang" <dingamlemamma@hotmail.com> wrote in message
news:3dfdc92d$0$165$edfadb0f@dread14.news.tele.dk...
> Hvem herinde har lavet en database som mySQL *IKKE* vil kunne
> trække/køre/håndtere? Med andre ord, hvor mange er teoretikere og hvor
mange
> har praktiske erfaringer? Det er egenlig ikke fordi jeg er fanatisk i mit
> valg af database, men mere fordi jeg synes det kunne være interssant at få
> skildt teoretikerne fra. De har ofte med at lyde som en længere salgstale
> for et dyrt Microsoft produkt -Gerne før folks behov er klarlagt!
>
> Hvem tør stå frem?

Der er mange andre ting end netop performance, der er forskellen på mySQL og
andre databaser -mySQL er udmærket som et avanceret storage alternativ til
filer, men som andre nævner, så er der procedurer som recovery, backup osv.
som ikke umiddelbart lader sig gøre med baggrund i de krav mange
virksomheder har om høj oppetid og driftsikkerhed.

På det programmeringsmæssige niveau kommer det også i høj grad an på, hvad
man betegner som en database; er den "kun" til data, eller kan der også være
logik i den? -stored procedures findes ikke i mySQL, hvilket gør at triggers
f.eks. ikke er mulige, og du kan ikke umiddelbart beskytte dine data gennem
et API etc. Du kan så indvende at du kan lave dine egne i C -det er da nok
rigtigt, men hvordan forholder det sig så mht. transaktioner og integritet?
Du kan heller ikke lave auditering af DML i mySQL, ligesom f.eks. begrebet
read consistency heller ikke findes i den verden.

Det kan godt være at du synes at folk skyder over målet nogle gange, men det
er også nogle gange svært at fortælle folk, at med høje krav om
pålidelighed, skalerbarhed, oppetid etc. de har, så er der altså nogle
basale faciliteter, der skal være på plads -og dem honorerer mySQL ikke.
Jeg bruger selv mySQL, men ikke til noget der er forretningskritisk
overhovedet.

Så er ballet åbnet for flaming... ;)

vh. Jørgen

---

> Der er mange andre ting end netop performance, der er forskellen på mySQL
og
> andre databaser -mySQL er udmærket som et avanceret storage alternativ til
> filer, men som andre nævner, så er der procedurer som recovery, backup
osv.
> som ikke umiddelbart lader sig gøre med baggrund i de krav mange
> virksomheder har om høj oppetid og driftsikkerhed.

Hmm ja, jeg er sådan set enig, men jeg forstår ikke den med oppetiden. Min
database har kørt i over et år nu og der er stadig ikke kommet nedetid eller
fejl i mine tabeller? Jeg har måske været heldig på det punkt, men hva'
fanden. Kører det, så kører det.

Mht. backup så har jeg valgt den simple løsning bare at dumpe hele min
database en gang i døgnet. Så har jeg altid en fuld backup.

Hvis man er mere krævende, kunne man sætte en slaveserver op og spejle sine
data fx. Der er mange muligheder, som jeg stadig mener kan opfylde mange
mindre firmaers krav.

> På det programmeringsmæssige niveau kommer det også i høj grad an på, hvad
> man betegner som en database; er den "kun" til data, eller kan der også
være
> logik i den? -stored procedures findes ikke i mySQL, hvilket gør at
triggers
> f.eks. ikke er mulige, og du kan ikke umiddelbart beskytte dine data
gennem
> et API etc. Du kan så indvende at du kan lave dine egne i C -det er da nok
> rigtigt, men hvordan forholder det sig så mht. transaktioner og
integritet?
> Du kan heller ikke lave auditering af DML i mySQL, ligesom f.eks. begrebet
> read consistency heller ikke findes i den verden.

http://www.mysql.com/doc/en/InnoDB_overview.html

Jeg ved det stadig er på børnestadiet og der mangler mange featues osv., men
jeg synes alligevel folk skulle læse lidt om den tabeltype. Den er rar og
man
kan godt nå et stykke hen af vejen, i hvert fald på nogle punkter

> Det kan godt være at du synes at folk skyder over målet nogle gange, men
det
> er også nogle gange svært at fortælle folk, at med høje krav om
> pålidelighed, skalerbarhed, oppetid etc. de har, så er der altså nogle
> basale faciliteter, der skal være på plads -og dem honorerer mySQL ikke.
> Jeg bruger selv mySQL, men ikke til noget der er forretningskritisk
> overhovedet.



> Så er ballet åbnet for flaming... ;)

Det var nu ikke meningen at starte en flamekrig med mit indlæg

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"tsl" <dingamlemamma@hotmail.com> writes:

> Nej, men hvis man nu designer sin database til at kunne køre på
> MySQL (dvs. ingen avancerede ting), så tror jeg ikke du vil kunne
> sætte en finger på hastigheden. Det er jo netop styrken ved
> MySQL. Simpelt og hurtigt... og IMHO ganske stabilt (har aldrig haft
> bøvl)

Det er vist, som man tager det, hvis ellers man skal tro rygterne. Nu
har jeg ikke arbejdet så meget med netop de dele af MySQL, men som jeg
har forstået det, kan man vælge mellem god hastighed og acceptabel
dataintegritet i MySQL, men man kan ikke få begge på en gang. Når man
ikke hører flere klage over dette, skyldes det, gætter jeg på, at en
stor overvægt af MySQLs brugere ikke sætter dataintegritet særligt
højt. Der lader til at være en overvægt af webaber (i ordets kærligste
forstand) i MySQLs brugerskare, og dynamiske sider, blogs,
diskussionsfora osv. stiller nu engang ikke samme krav, som fx en
banks økonomiske transaktioner.

>> Næste afdeling kunne let være at man ønsker _fuld_
>> SQL-understøttelse, dvs. også fx nestede queryes m.m. som ikke er
>> tilgængeligt i mysql.
> Enig, men brugbarheden af joins og nestede queries afhænger også i
> høj grad af hvordan du designer din database, eller om du tænker dig
> om. I nogle tilfælde kan det se smart ud at joine 10 tabeller, men
> hurtigt bliver det næppe. Jeg vil mene, at til de fleste ting, så
> behøver man ikke support for alle de fancy ting som nestede queries,
> fremmednøgler og den slags.

Jeg har aldrig nogensinde hørt andre end tilhængere af MySQL omtale
disse features som fancy, for da slet ikke at sige overflødige, som
nogen mener. Det er meget muligt, at man i stedet for subqueries kan
foretage flere uafhængige queries og bruge midlertidige tabeller som
'mellemregninger', men det er da ærligt talt et forfærdeligt bøvl at
have med at gøre som programmør! Hvad fremmednøgler angår,
repræsenterer de en væsentlig del af den information, der ofte bliver
brugt i forbindelse med keyword-baseret søgning i relationelle
databaser. Af sådanne systemer kan nævnes bl.a. DISCOVER, BANKS,
DBXplorer og ESKuSE (som jeg er ved at udvikle).

> Jeg tager uden tvivl fejl, hvilket også var derfor jeg søgte nogen
> som kunne give mig et eksempel på en database der netop havde brug
> for disse ting. Hvor jeg med brug, virkelig mener brug og ikke
> "jamen, så sparer jeg lige 2 queries der og 10 linier kode der"

I den grundlæggende matematik kan potenser let erstattes med
multiplikation. Multiplikation kan igen erstattes med addition, og
bruger man en eftermiddag på at overveje, hvor få matematiske
redskaber man kan klare sig med, vil man nok blive en kende
forbløffet. Men det betyder ingenlunde, at man vil have lyst til at
spare, ahem, "2 operatorer her og 10 mellemregninger der", fordi det
simpelthen er for besværligt i praksis. Til mange ting ville jeg
sagtens (i teorien) kunne klare mig med MySQL, men fordi jeg så ofte
har erfaret, at jeg ofte bliver nødt til at foretage alle mulige
krumspring for at lave relativt enkle ting (især til eksperimenterende
ad hoc-forespørgsler, som i sagens natur ikke kan automatiseres), har
jeg sandt at sige set mig en kende sur på MySQLs begrænsede
SQL-implementering.

En parallel: jeg kunne skrive dette i fx Pico i stedet for Emacs, men
Emacs' features gør, at mange ting bliver meget lettere og
behageligere, fx ombrydning af citeret tekst, syntaksfarvning,
automatisk udskrivning af fork. osv. Det er med andre ord oftere
bekvemmelighed end udtrykskraft, der er den begrænsende faktor, men
den kan heller ikke ignoreres.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAj3/t0YACgkQYu1fMmOQldUi4wCguPsB4sa6TDnovwjRbQfunXvK
05sAoLpB8uhDzE7DbnEZBUiwsR/3ibWq
=5wl/
-----END PGP SIGNATURE-----