/ Forside / Teknologi / Udvikling / Perl / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Perl
#NavnPoint
bjarneA 141
poul_from 50
soccer 30
Nicknack 14
Tmpj 0
gemme en MySQL fejl ?
Fra : Simon...


Dato : 05-05-03 16:27

Hej,

jeg sidder lige og smider nogle urls i en MySQL db, som følger

$dbh->do("insert into $table values ('$current_url','$date');") or
report("$DBI::errstr");

som jeg håbede på ville kalde report subrutinen (som så ville skrive det i
en log fil til mig) men det ville den så ikke, den printer istedet til
skærmen ??
Hvordan får jeg perl til at kalde en subrutine med den errstr som argument -
så jeg kan gemme fejlene ?

jeg har også prøvet med følgende, som heller ikke hjalp mig (men det var
lidt mere et skud i tågen):

$dbh->do("insert into $table values ('$current_url','$date');") ;
report("$DBI::errstr") if !is_success($dbh);


mange tak
mvh.Simon



 
 
Morten Wulff (05-05-2003)
Kommentar
Fra : Morten Wulff


Dato : 05-05-03 17:00

On Mon, 5 May 2003 17:27:16 +0200, Simon... <devnull@linux.org> wrote:

> $dbh->do("insert into $table values ('$current_url','$date');") or
> report("$DBI::errstr");
>
> som jeg håbede på ville kalde report subrutinen (som så ville skrive det
> i en log fil til mig) men det ville den så ikke, den printer istedet til
> skærmen ??

Hvordan ser report() ud? Ovenstående vil kalde report() hvis do() fejler.

> Hvordan får jeg perl til at kalde en subrutine med den errstr som
> argument så jeg kan gemme fejlene ?

report($dbh->errstr)


/wulff


--
Self Injury Information and Support: www.psyke.org

"Let's say the docs present a simplified view of reality..." Larry Wall

Simon... (05-05-2003)
Kommentar
Fra : Simon...


Dato : 05-05-03 18:25


> Hvordan ser report() ud? Ovenstående vil kalde report() hvis do() fejler.

nu tror jeg så jeg forstår det, for do() fejler jo netop ikke, men sætningen
inde i do returnerer en error...

tak

mvh.Simon

min report() ser sådan ud hvis du stadig er nysgerrig :)


sub report
{
if (substr($_[0],0,9) ne "Duplicate")
{
open(OUT,">>hunter.log") or die("Couldnt open hunter.log for appending\n
$!");
print OUT "$date : $_[0]\n";
close (OUT);
}

else
{
$errors = 1;
}
}



Morten Wulff (05-05-2003)
Kommentar
Fra : Morten Wulff


Dato : 05-05-03 19:17

On Mon, 5 May 2003 19:25:14 +0200, Simon... <devnull@linux.org> wrote:

> min report() ser sådan ud hvis du stadig er nysgerrig :)
>
> sub report
> {
> if (substr($_[0],0,9) ne "Duplicate")
> {

Dvs. hvis $dbh->errstr _ikke_ starter med Duplicate så skriver du til din
log?

> }
> else
> {

Og hvis du får en fejl i stil med "Duplicate entry 'x' for key 'y'..." går
du ingenting?

> }
> }

Er det rigtigt forstået?


/wulff


--
Self Injury Information and Support: www.psyke.org

"Let's say the docs present a simplified view of reality..." Larry Wall

Simon... (05-05-2003)
Kommentar
Fra : Simon...


Dato : 05-05-03 20:03


> Er det rigtigt forstået?

fuldstændigt... :)
det er fordi jeg har lavet url'en som primary key jeg vil alligevel kun ha
en af hver, så hvis den prøver at sætte en ind
jeg har gider jeg ikke høre den brokke sig :)

det virker perfekt med den linie du gav mig, merci.

-SImon



Thomas Finnerup (06-05-2003)
Kommentar
Fra : Thomas Finnerup


Dato : 06-05-03 19:37

On Mon, 5 May 2003 21:02:31 +0200, "Simon..." <devnull@linux.org>
wrote:

> det er fordi jeg har lavet url'en som primary key jeg vil alligevel kun ha
> en af hver, så hvis den prøver at sætte en ind
> jeg har gider jeg ikke høre den brokke sig :)

Du kan undgå fejlmeddelelsen ved at bruge "INSERT IGNORE INTO <Tabel>
[...]".


Venligst
Thomas

Simon... (07-05-2003)
Kommentar
Fra : Simon...


Dato : 07-05-03 08:47


> Du kan undgå fejlmeddelelsen ved at bruge "INSERT IGNORE INTO <Tabel>
> [...]".

tak,
men den gør så også at jeg ikke kan se hvor mange nye links jeg rent
faktiskt fik :/
mvh.Simon



Andreas Plesner Jaco~ (05-05-2003)
Kommentar
Fra : Andreas Plesner Jaco~


Dato : 05-05-03 18:27

In article <3eb6828a$0$83056$edfadb0f@dtext01.news.tele.dk>, Simon... wrote:
>
> $dbh->do("insert into $table values ('$current_url','$date');") or
> report("$DBI::errstr");

Husk at bruge placeholders, hvis dine variabler stammer fra user input.

--
Andreas Plesner Jacobsen | Linux - Where do you want to fly today?
| -- Unknown source

Michael Legart (05-05-2003)
Kommentar
Fra : Michael Legart


Dato : 05-05-03 18:31

On Mon, 5 May 2003 17:26:57 +0000 (UTC), Andreas Plesner Jacobsen <apj@daarligstil.dk> wrote:
>> $dbh->do("insert into $table values ('$current_url','$date');") or
>> report("$DBI::errstr");
>
> Husk at bruge placeholders, hvis dine variabler stammer fra user input.

s/, hvis dine variabler stammer fra user input//

--
hestdesign.info - we put the hest in .com

Andreas Plesner Jaco~ (05-05-2003)
Kommentar
Fra : Andreas Plesner Jaco~


Dato : 05-05-03 19:14

In article <slrnbbd81g.4ak.legart@kamel.legart.dk>, Michael Legart wrote:

>>> $dbh->do("insert into $table values ('$current_url','$date');") or
>>> report("$DBI::errstr");
>>
>> Husk at bruge placeholders, hvis dine variabler stammer fra user input.
>
> s/, hvis dine variabler stammer fra user input//

Det er uden tvivl en god vane, men med visse DBDer vinder du jo intet.

--
Andreas Plesner Jacobsen | Please go away.

Flemming Frandsen (06-05-2003)
Kommentar
Fra : Flemming Frandsen


Dato : 06-05-03 07:45

Andreas Plesner Jacobsen wrote:
>>>Husk at bruge placeholders, hvis dine variabler stammer fra user input.
>>s/, hvis dine variabler stammer fra user input//
> Det er uden tvivl en god vane, men med visse DBDer vinder du jo intet.

Så er det en god idikator på at man bør skifte til en anden DBD/database
(iow: lad være med at bruge mysql).

Jeg kan meget varmt anbefale SAP DB, til store ting (multi-GB og mange
brugere) og firebird/phoenix/interbase/hvad-den-nu-hedder-i-dag til alt
der er mindre end nogle få hundrede MB.

Begge er fri software og opfylder ACID kravene (til forskel fra Mysql)...

.... og for at det ikke skal blive alt for offtopic kan det nævnes at jeg
har arbejdet på perl interfacet til begge DBMS'er; SAP DB blot bruger
DBD:BC (der skulle kun ganske få ændringer til) og det virker rigtigt
godt.

Interbase bruger DBD::InterBase som var af lettere tvivlsom kvalitet da
jeg holdt op med at arbejde på den for et par år siden, men den er
sikkert blevet bedre i mellemtiden og jeg har hørt rygter om at deres
ODBC interface skulle være tilgængeligt.

--
Regards Flemming Frandsen - http://dion.swamp.dk
PartyTicket.Net co founder & Yet Another Perl Hacker


Andreas Plesner Jaco~ (06-05-2003)
Kommentar
Fra : Andreas Plesner Jaco~


Dato : 06-05-03 08:29

In article <KSIta.53992$y3.3614196@news010.worldonline.dk>, Flemming Frandsen wrote:
>
> Jeg kan meget varmt anbefale SAP DB, til store ting (multi-GB og mange
> brugere) og firebird/phoenix/interbase/hvad-den-nu-hedder-i-dag til alt
> der er mindre end nogle få hundrede MB.

I en forening jeg har tilknytning til har vi en database med en del
transaktioner, (noget der ligner en fifo-tabel) - det er absolut også
noget man skal tage med i sine betragtninger, da fx postgresql, som vi
bruger til det ikke er 100-meter verdensmester i det.

--
Andreas Plesner Jacobsen | Rule the Empire through force.
|    -- Shogun Tokugawa

Flemming Frandsen (06-05-2003)
Kommentar
Fra : Flemming Frandsen


Dato : 06-05-03 09:36

Andreas Plesner Jacobsen wrote:
> I en forening jeg har tilknytning til har vi en database med en del
> transaktioner, (noget der ligner en fifo-tabel) - det er absolut også
> noget man skal tage med i sine betragtninger, da fx postgresql, som vi
> bruger til det ikke er 100-meter verdensmester i det.

Måske man skulle lave en simpel benchmark som tester netop den opførsel?

Det kunne være interessant at se hvordan diverse DBMS'er håndterer det,
specielt når postgresql er ustyrligt dårlig til det.

Jeg kunne forestille mig at interbase har en svaghed på samme punkt da
den også bruger concurrent versioning.


Hvordan ser traffikken ud?

Er der mange forskellige producenter (insert) og mange forskellige
forbrugere (select/delete) af data?

--
Regards Flemming Frandsen - http://dion.swamp.dk
PartyTicket.Net co founder & Yet Another Perl Hacker


Andreas Plesner Jaco~ (06-05-2003)
Kommentar
Fra : Andreas Plesner Jaco~


Dato : 06-05-03 11:32

In article <FuKta.54033$y3.3621234@news010.worldonline.dk>, Flemming Frandsen wrote:

> Måske man skulle lave en simpel benchmark som tester netop den opførsel?

Man må næsten gå ud fra at det findes.

> Hvordan ser traffikken ud?
>
> Er der mange forskellige producenter (insert) og mange forskellige
> forbrugere (select/delete) af data?

En producent der hælder data ind i bulk, mange forbrugere, der henter
lige så stille.

--
Andreas Plesner Jacobsen | An honest tale speeds best being plainly told.
|    -- William Shakespeare, "Henry VI"

Ask Bjoern Hansen (08-05-2003)
Kommentar
Fra : Ask Bjoern Hansen


Dato : 08-05-03 13:11

Andreas Plesner Jacobsen <apj@daarligstil.dk> wrote in message news:<slrnbbdafg.hv3.apj@slartibartfast.nerd.dk>...

> > s/, hvis dine variabler stammer fra user input//
>
> Det er uden tvivl en god vane, men med visse DBDer vinder du jo intet.

Performance? Nej nogle gange ikke.

Færre problemer med din kode? Ja, ofte.

Bliver det marginalt nemmere at portere applikationen til en anden DBMS? Ja.

IIRC kommer der bedre place holder support i MySQL i 4.1.


- ask

Adam Sjøgren (06-05-2003)
Kommentar
Fra : Adam Sjøgren


Dato : 06-05-03 15:18

On Tue, 06 May 2003 08:44:48 +0200, Flemming Frandsen wrote:

> Begge er fri software og opfylder ACID kravene (til forskel fra
> Mysql)...

(Heller ikke med innobase? I.e. hvad er det MySQL ikke lever op til
der?)


Mvh.

--
"Från och med nu, så är 'så snart Adam Sjøgren
som möjligt' 53 timmar!" asjo@koldfront.dk

Flemming Frandsen (06-05-2003)
Kommentar
Fra : Flemming Frandsen


Dato : 06-05-03 17:30

Adam Sjøgren wrote:
>>Begge er fri software og opfylder ACID kravene (til forskel fra
>>Mysql)...
> I.e. hvad er det MySQL ikke lever op til
> der?)

De to værste problemer med mysql er:
* Ingen foreignkey constraints.
* Transaktioner er ikke atomare.

Der er flere problemer end det:
* Ingen support for placeholders.
* Kun table-level locking (i gamle dage, de har vist fået rowlevel
locking efterhånden)
* mysql bruger fil systemet til at gemme data filer i stedet for at
bruge diske direkte, det betyder mere kompleksitet, dårligere
performance og større risiko for at miste data ved fejl.

mysql folkene har længe haft den holdning at "man" ikke har brug for
transaktioner og foreignkey support.


> Heller ikke med innobase?

innobase er ikke mysql, så vidt jeg husker er det en helt anden database
som bare bruger mysqls sql parser og et par andre sager, men jeg kunne
jo huske forkert.


Interbase og SAP DB er begge meget ældre end mysql (og postgresql) og
designet til at være rigtige databaser fra starten af og derfor er de
meget bedre gennemtestede end mysql/innobase/postgresql har haft tid til
at blive.


Forstå mig ret, jeg siger ikke at mysql er værdiløs, der er en masse
områder hvor hård dataintegritet ikke er nødvendigt.

Tag f.eks. de ca. 8000 content management systemer som driver websites
rundt omkring, det er ikke en katastrofe hvis der er nogle foreignkeys
som peger på rækker der ikke eksisterer eller hvis man kun får opdateret
2 rækker ud af 5 hvis systemet crasher.

Hvis vi derimod taler om lager styring eller økonomisystemer så vil den
slags fejl være katastrofale.

Denne side beskriver ret godt tingene:
http://openacs.org/philosophy/why-not-mysql hvis mysql siden har ændret
sig så er de ændringer max 3 år gamle og ikke noget jeg vil udsætte mine
data for.


Et datapunkt: SAP sælger SAP R/3 systemer som kører på Sapdb, det viser
at de stoler på deres database *og* at de kan få deres kunder til at
gøre det samme i stor nok grad til at deres kunder betror *hele* deres
virksomhed til databasens ACID features.

Det kan i den sammenhæng nævnes at en friskinstalleret SAP R/3 har over
16000 tabeller, over 19000 indexer og over 2 GB data:
http://www.daemonnews.org/200007/SAP_meets_BSD.html

Et SAP R/3 system har typisk mange, mange GB data i databasen.

Det, sammen med at jeg ikke har fundet nogen egentlige fejl i databasen,
gør at jeg tør stole på at systemet ikke ødelægger mine data.

--
Regards Flemming Frandsen - http://dion.swamp.dk
PartyTicket.Net co founder & Yet Another Perl Hacker


Adam Sjøgren (06-05-2003)
Kommentar
Fra : Adam Sjøgren


Dato : 06-05-03 18:03

On Tue, 06 May 2003 18:29:37 +0200, Flemming Frandsen wrote:

> De to værste problemer med mysql er:

> * Ingen foreignkey constraints.
> * Transaktioner er ikke atomare.

Hverken det ene eller det andet er sandt, og har ikke været det i to
år.

> Der er flere problemer end det:

Jo jo, men nu spurgte jeg alene til hvad det er, du mener gør at MySQL
ikke er en rigtig ACID database.

Det er så forældede oplysninger - MySQL giver mulighed for at vælge.

> mysql folkene har længe haft den holdning at "man" ikke har brug for
> transaktioner og foreignkey support.

Sandsynligvis stemmer denne holdning overens med den periode hvor de
ikke har selv har haft de features i deres eget program

Man skulle tro at perioden hvor folk kritiserer MySQL for ikke at være
ACID var begrænset til samme. Men folk bliver ved.

>> Heller ikke med innobase?

> innobase er ikke mysql, så vidt jeg husker er det en helt anden
> database som bare bruger mysqls sql parser og et par andre sager, men
> jeg kunne jo huske forkert.

Ja:

"7.5.1 InnoDB Tables Overview

InnoDB provides MySQL with a transaction-safe (ACID compliant)
storage engine with commit, rollback, and crash recovery
capabilities. InnoDB does locking on row level and also provides an
Oracle-style consistent non-locking read in SELECTs. These features
increase multiuser concurrency and performance. There is no need for
lock escalation in InnoDB, because row level locks in InnoDB fit in
very small space. InnoDB tables support FOREIGN KEY constraints as
the first table type in MySQL."

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

Lidt mere overblik:

"Note that MySQL supports two different kinds of tables:
transaction-safe tables (InnoDB and BDB) and not transaction-safe
tables (HEAP, ISAM, MERGE, and MyISAM).

Advantages of transaction-safe tables (TST):

* Safer. Even if MySQL crashes or you get hardware problems, you
can get your data back, either by automatic recovery or from a
backup + the transaction log.

* You can combine many statements and accept these all in one go
with the COMMIT command.

* You can execute ROLLBACK to ignore your changes (if you are not
running in auto-commit mode).

* If an update fails, all your changes will be restored. (With
NTST tables all changes that have taken place are permanent)

* Can provide better concurrency if the table gets many updates
concurrently with reads.

Note that to use InnoDB tables you have to use at least the
innodb_data_file_path startup option. See section 7.5.3 InnoDB
Startup Options.

Advantages of not transaction-safe tables (NTST):

* Much faster as there is no transaction overhead.

* Will use less disk space as there is no overhead of
transactions.

* Will use less memory to do updates.

You can combine TST and NTST tables in the same statements to get
the best of both worlds."

<http://www.mysql.com/doc/en/Table_types.html>


Dine negative 'anbefalinger' er ikke så overbevisende, når du ikke har
sat dig ind i det du taler om.


(Lidt datering:

"7.5.5.2 Foreign Key Constraints

Starting from version 3.23.43b InnoDB features foreign key
constraints. InnoDB is the first MySQL table type which allows you
to define foreign key constraints to guard the integrity of your
data."

<http://www.mysql.com/doc/en/InnoDB_foreign_key_constraints.html>

3.23.43b blev frigivet i 2001:

<http://www.mysql.com/doc/en/News-3.23.x.html>).

> Denne side beskriver ret godt tingene:
> http://openacs.org/philosophy/why-not-mysql hvis mysql siden har
> ændret sig så er de ændringer max 3 år gamle og ikke noget jeg vil
> udsætte mine data for.

Det er jo en dejlig nem måde at affærdige forbedringer på.

Har du det på samme måde med de styresystem-versioner du kører dine
databaser, og dermed dine data, på?

Hvad med den udgave af fortolkeren til det programmeringssprog, Perl,
du bruger til at håndtere dine data med? [Tilbage til topic ]


Mvh.

--
"Från och med nu, så är 'så snart Adam Sjøgren
som möjligt' 53 timmar!" asjo@koldfront.dk

Flemming Frandsen (06-05-2003)
Kommentar
Fra : Flemming Frandsen


Dato : 06-05-03 18:54

Adam Sjøgren wrote:
> Det er så forældede oplysninger - MySQL giver mulighed for at vælge.

Ja, det har du ret i.


> InnoDB does locking on row level and also provides an
> Oracle-style consistent non-locking read in SELECTs.

Hmm, det lyder lidt som interbases/oracles concurrent versioning hejs,
men alligevel ikke.


> Dine negative 'anbefalinger' er ikke så overbevisende, når du ikke har
> sat dig ind i det du taler om.

Well, det har du ret i, det er sikkert en religiøs overbevisning jeg har
tillagt mig, jeg prøvede mysql for nogle år siden og fandt ud af at det
var noget ufatteligt dårligt makværk og at der var andre, langt bedre
løsninger, som jeg så skiftede til.

Jeg har også haft "æren" af at forsøge at få data fra mysql databaser
til at give mening, som var tæt på værdiløst fordi der var vilde mængder
af fejl som ikke ville have været der hvis man havde brugt transaktioner
og foreignkeys.

Selvfølgeligt er det irrationelt at jeg automatisk antager at mysql
stadig er noget makværk når, ikke prøvet at putte rigtigt data i den i
flere år.

Jeg tror du har givet mig en del af den motivation der skal til for at
lave lidt testing, af forskellige DBMS'er, det kunne være godt at have
nogle tal at quote...


> "7.5.5.2 Foreign Key Constraints
> 3.23.43b blev frigivet i 2001:

Det vil altså sige at ACID i mysql har er max 1-2 år gammelt?


>>hvis mysql siden har ændret sig så er de ændringer max 3 år
>>gamle og ikke noget jeg vil udsætte mine data for.
>
> Det er jo en dejlig nem måde at affærdige forbedringer på.

Ja det er lidt kujonagtigt af mig, men det er stadig sandt at folk der
bruger mysql ofte ikke er helt afsindigt bekymret for data integrity og
de features (TST) ikke ser nær så meget brug som de dele af koden som
har med NTST ting at gøre.

Det er naturligtvis bare min teori, men jeg er ret sikker på at det
holder en hel del af vejen.


> Har du det på samme måde med de styresystem-versioner du kører dine
> databaser, og dermed dine data, på?

Nej, men det en database gør er langt, langt mere komplekst end at
flytte data mellem RAM og disk og at flytte data mellem RAM og disk er
noget som bliver testet meget og grundigt af alle der bruger Os'et så
det er ret sikkert at det virker.


> Hvad med den udgave af fortolkeren til det programmeringssprog, Perl,
> du bruger til at håndtere dine data med?

Crazy talk! du ved jo godt perl er perfekt


> [Tilbage til topic ]

Ja det var nok en god ide:)

--
Regards Flemming Frandsen - http://dion.swamp.dk
PartyTicket.Net co founder & Yet Another Perl Hacker


Thorbjoern Ravn Ande~ (06-05-2003)
Kommentar
Fra : Thorbjoern Ravn Ande~


Dato : 06-05-03 23:24

Flemming Frandsen <ff-news.tiscali.dk@partyticket.net> writes:

> Jeg har også haft "æren" af at forsøge at få data fra mysql databaser
> til at give mening, som var tæt på værdiløst fordi der var vilde
> mængder af fejl som ikke ville have været der hvis man havde brugt
> transaktioner og foreignkeys.

Man skal ikke bruge (skulle?) MySQL til noget man ikke ville putte i
et filsystem, og som krævede mere komplicerede handlinger end et
filsystem. Her var det til gengæld også ganske fortrinligt.

Databaser er lidt ligesom programmerignssprog - de har hver især ders
fordele og ulemper og ingen løser alle problemer lige godt.

Næh, hvis du gerne vil se rigtig ringe opførsel, så prøv at brug
DBD::CSV som backend :)

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

Adam Sjøgren (06-05-2003)
Kommentar
Fra : Adam Sjøgren


Dato : 06-05-03 19:04

On Tue, 06 May 2003 19:54:12 +0200, Flemming Frandsen wrote:

> Jeg tror du har givet mig en del af den motivation der skal til for
> at lave lidt testing, af forskellige DBMS'er, det kunne være godt at
> have nogle tal at quote...

Det kunne være sjovt at læse

>> "7.5.5.2 Foreign Key Constraints
>> 3.23.43b blev frigivet i 2001:

> Det vil altså sige at ACID i mysql har er max 1-2 år gammelt?

Sådan som jeg forstod historien dengang, så har InnoDB en længere
historie - koden/tabeltypen blev indkorporeret i MySQL i 2001.

<http://www.innodb.com/>

> Ja det er lidt kujonagtigt af mig, men det er stadig sandt at folk
> der bruger mysql ofte ikke er helt afsindigt bekymret for data
> integrity og de features (TST) ikke ser nær så meget brug som de
> dele af koden som har med NTST ting at gøre.

Det tror jeg du har ret i.

(Hvis man skulle give det et positivt spin, så har de folk der ikke
har brug for de mere komplicerede features valgt den hurtige
letvægtsløsning i stedet for kun at bruge et hjørne af en stor,
indviklet ting).

Men det er sådan set ikke MySQLs "skyld" - det eneste det indikerer er
at MySQL er rimelig let at gå til for mange mennesker, og at MySQL
blev "kendt" på det rigtige tidspunkt i forhold til webfnidder.

Hm. Er der en database-gruppe? Sørme så. Evt. videre diskussion
derovre.


Mvh.

--
"Från och med nu, så är 'så snart Adam Sjøgren
som möjligt' 53 timmar!" asjo@koldfront.dk

Ask Bjoern Hansen (08-05-2003)
Kommentar
Fra : Ask Bjoern Hansen


Dato : 08-05-03 13:08

spamtrap@koldfront.dk (Adam Sjøgren) wrote in message news:<877k94uf3a.fsf@virgil.koldfront.dk>...

> > Ja det er lidt kujonagtigt af mig, men det er stadig sandt at folk
> > der bruger mysql ofte ikke er helt afsindigt bekymret for data
> > integrity

Det er også sandt at der er folk der bruger Oracle som ikke er
bekymrede for data integritet. What's your point?

> > og de features (TST) ikke ser nær så meget brug som de
> > dele af koden som har med NTST ting at gøre.
>
> Det tror jeg du har ret i.

Med fire millioner mysql installationer får "TST" delene en del brug,
også selvom det kun er say 10% der bruger dem.

Og uanset det så er det et fjollet argument. Der er *mange* der bruge
Microsoft Windows; betyder det at de er gode til at lave det stabilt?

Det lyder som om at Flemming mener transaktioner altid er bedre end
ikke-transaktioner. Hvorfor bruge transaktioner og millioner ekstra
på hardware i de dele af ens applikation hvor de ikke er nødvendige?
Det vil da være dumt.

Tilsvarende med foreign keys og [name your favorite database feature].

Der er også tilfælde hvor det er billigere at programmere eller
designe sig rundt om at bruge den slags features for at få bedre
performance end at skalere den vertikale hardware.


- ask (der brugte MySQL til at tælle tusinder af data stumper i
sekundet[1] der var penge værd for 4 år siden; uden InnoDB i sagens
natur)

[1] Og jo, der var[2] mange gigabytes data)

[2] Nu er der endnu flere men jeg er der ikke mere[3].

[3] Nu bruger jeg den meste af min tid et sted[4] hvor vi bruger store
Oracle bokse med et umuligt antal database servere, tabeller, foreign
keys og travle DBAs.

[4] En CMS agtig web applikation; go figure.

Flemming Frandsen (08-05-2003)
Kommentar
Fra : Flemming Frandsen


Dato : 08-05-03 13:51

Det ser ikke ud til at vi er ret gode til at FUTe over i database
gruppen, så undskyld til dem der kun interesserer sig for perl og ikke
værdien af msyql...


Ask Bjoern Hansen wrote:
> Det er også sandt at der er folk der bruger Oracle som ikke er
> bekymrede for data integritet.

Så er de jo malinformerede og har for mange penge.


> What's your point?

At hvis der ikke er mange kritiske brugere af en feature, hvordan kan
man så være sikker på at den virker?


> Og uanset det så er det et fjollet argument. Der er *mange* der bruge
> Microsoft Windows; betyder det at de er gode til at lave det stabilt?

Nej, for brugere af Microsoft Windows er jo ikke kritiske brugere, så
havde de jo kasseret det makværk for længe siden.

Windows bruger: "Nej se endu en blå skærm, men det er jo nok bare mig
der gør noget dumt, oh well, jeg havde også brug for noget mere kaffe."

Kritisk bruger: "Hvad?! endu et crash?!, det her system er jo totalt
defekt, jeg vil have mine penge tilbage! Grr! Dø Gates-svin!"

.... eller katastrofalt offtopic:)


> Det lyder som om at Flemming mener transaktioner altid er bedre end
> ikke-transaktioner.

Ikke altid, jeg tror nok jeg fik sagt at man skal bruge mysql hvis det
er det bedste værktøj man kan finde til at løse sin opgave med.

Det er bare min påstand at hvis du laver et system hvor dataintegritet
er vigtigt, til f.eks. lager styring eller økonomi så er det absolut
nødvendigt at man har transaktioner og foreignkeys.


> Hvorfor bruge transaktioner og millioner ekstra
> på hardware i de dele af ens applikation hvor de ikke er nødvendige?
> Det vil da være dumt.

Ja, jeg er enig.

Hvis man arbejder med data som ikke kræver transaktioner og foreignkeys
så er mysql fint.


Det interessante spørgsmål er derfor ikke om mysql er god til at
opbevare ikke-krævende data i, men om mysqls transaktions- og fk-
features er stærke nok til at måle sig med andre frie alternativer (som
postgresql, sapdb og interbase)


Det er alt sammen et spørgsmål om synsvinkel, folk der arbejder med
simple data mener at transaktioner og foreignkey constraints er noget
langsomt knald fordi de ikke har brug for det.

Folk der har brug for transaktioner og foreignkey constraints synes at
en database med dårlig support for det er noget værdiløst makværk.


.... og skulle vi så ikke lade være med at være så offtopic?

--
Regards Flemming Frandsen - http://dion.swamp.dk
PartyTicket.Net co founder & Yet Another Perl Hacker


Jesper Krogh (08-05-2003)
Kommentar
Fra : Jesper Krogh


Dato : 08-05-03 15:07

I dk.edb.programmering.perl, skrev Flemming Frandsen:
> Det interessante spørgsmål er derfor ikke om mysql er god til at
> opbevare ikke-krævende data i, men om mysqls transaktions- og fk-
> features er stærke nok til at måle sig med andre frie alternativer (som
> postgresql, sapdb og interbase)

Nu har jeg set denne et par gange i debatten. Er du sikker på at sapdb
er frit? Altså frit software?



--
../Jesper Krogh, jesper@krogh.cc
Jabber ID: jesper@jabber.krogh.cc
Tøm din hjerne for Linuxviden på http://www.linuxwiki.dk


Flemming Frandsen (08-05-2003)
Kommentar
Fra : Flemming Frandsen


Dato : 08-05-03 15:10

Jesper Krogh wrote:
> Nu har jeg set denne et par gange i debatten. Er du sikker på at sapdb
> er frit? Altså frit software?

Ja, jeg har selv uviklet lidt på det[1].

Læs: http://sapdb.org/

Linie 7: "Distributable under the GPL/LGPL"


[1] Bugfixes i DBD::SAP_DB ind til jeg indså at DBD:BC var et bedre
valg end en separat driver, så da jeg fik DBD:BC til at virke
droppede jeg (og SAP) DBD::SAP_DB.

--
Regards Flemming Frandsen - http://dion.swamp.dk
PartyTicket.Net co founder & Yet Another Perl Hacker


Jesper Krogh (08-05-2003)
Kommentar
Fra : Jesper Krogh


Dato : 08-05-03 16:16

I dk.edb.programmering.perl, skrev Flemming Frandsen:
> Jesper Krogh wrote:
> > Nu har jeg set denne et par gange i debatten. Er du sikker på at sapdb
> > er frit? Altså frit software?
>
> Ja, jeg har selv uviklet lidt på det[1].
>
> Læs: http://sapdb.org/
>
> Linie 7: "Distributable under the GPL/LGPL"

Ja, jeg takker mange gange.. de gør godtnok noget for at tage
markedsandele fra Oracle

--
../Jesper Krogh, jesper@krogh.cc
Jabber ID: jesper@jabber.krogh.cc
Tøm din hjerne for Linuxviden på http://www.linuxwiki.dk


Christian Laursen (08-05-2003)
Kommentar
Fra : Christian Laursen


Dato : 08-05-03 15:13

Jesper Krogh <jesper@krogh.cc> writes:

> I dk.edb.programmering.perl, skrev Flemming Frandsen:
> > Det interessante spørgsmål er derfor ikke om mysql er god til at
> > opbevare ikke-krævende data i, men om mysqls transaktions- og fk-
> > features er stærke nok til at måle sig med andre frie alternativer (som
> > postgresql, sapdb og interbase)
>
> Nu har jeg set denne et par gange i debatten. Er du sikker på at sapdb
> er frit? Altså frit software?

http://www.sapdb.org/

"Distributable under the GPL/LGPL"

--
Med venlig hilsen
Christian Laursen

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408914
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste