---

Hej!

Jeg bruger perl på en windoze maskine (activestate), og så ville jeg
gerne vide om der findes et databasesystem, som gik forholdsvis hurtigt,
som kun kræver en driver man kan lægge med, eller sådan noget.
Jeg har leget lidt med perl2exe programmet, og jeg havde tænkt mig at
mit program skulle være en executable, der legede sammen med en
database, men jeg kan ikke se nogle baser der ikke bruger en installeret
driver på det system man kører programmet i. Jeg har prøvet .csv, og det
har ELENDIG
perfomance

/Martin

---

"Martin Andersen" <martin@kampsax.dtu.dk> wrote in message
news:3B7BEED6.52206906@kampsax.dtu.dk...

> Jeg bruger perl på en windoze maskine (activestate), og så ville jeg
> gerne vide om der findes et databasesystem, som gik forholdsvis hurtigt,
> som kun kræver en driver man kan lægge med, eller sådan noget.

Du skriver du allerede har prøvet .csv, jeg går ud fra at du mener
DBD::CSV? - Den synes jeg ellers at jeg engang testede, og fandt at den
egentligt kørte tilpas hurtigt, alt efter hvad man kunne forvente..

Hvis programmet kun skal køre på en windows maskine kan du jo evt. bruge M$
Access, jeg ved dog ikke om den kan give nogen form for brugbar performance.

Alternativt kan du måske kigge på Berkeley DB (perldoc DB_File), der er det
i hvert fald ikke hastigheden der kan være problemet, men mere
ease-of-use..(f.eks. kan du ikke fyre SQL statements af)

--
Mvh. Nezar Nielsen
http://fez.dk/

---

Nezar Nielsen wrote:

> Du skriver du allerede har prøvet .csv, jeg går ud fra at du mener
> DBD::CSV? - Den synes jeg ellers at jeg engang testede, og fandt at den
> egentligt kørte tilpas hurtigt, alt efter hvad man kunne forvente..

DBD::CSV ja. Man kan vel ikke forvente så meget af en flad fil, men der er
ekstrem
forskel på performance i sammenligning med access.

> Hvis programmet kun skal køre på en windows maskine kan du jo evt. bruge M$
> Access, jeg ved dog ikke om den kan give nogen form for brugbar performance.

Men er access driveren installeret pr. default på en win maskine, eller skal man
først installere
noget af office før det sker?
Performance er udemærket på access. (Nu hvor man kun har en bruger, jeg ville
ikke bruge den hvis der var flere)

> Alternativt kan du måske kigge på Berkeley DB (perldoc DB_File), der er det
> i hvert fald ikke hastigheden der kan være problemet, men mere
> ease-of-use..(f.eks. kan du ikke fyre SQL statements af)

Jeg kigger på det, men kan nu godt lide sql. (læs: er vant til det) :)

/Martin

PS. Tak for Jeres svar iøvrigt (dig og ABH)

---

Martin Andersen wrote:

> DBD::CSV ja. Man kan vel ikke forvente så meget af en flad fil, men der er
> ekstrem
> forskel på performance i sammenligning med access.

DBD::CSV læser hele filen ind i hukommelsen og benytter ikke
index-filer. Det gør meget stor forskel.

> Jeg kigger på det, men kan nu godt lide sql. (læs: er vant til det) :)

Hvis din information kan ligge i flade filer, så gør dog det. Ønsker du
ydelse svarende til en database, må du have en database igang.

--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Thorbjørn Ravn Andersen wrote:

> DBD::CSV læser hele filen ind i hukommelsen og benytter ikke
> index-filer. Det gør meget stor forskel.

gør den det?
Så kan jeg slet ikke forstå forskellen i perfomance på DBD::CSV og på
DBD::RAM, som skulle gøre det samme.
Det kan selvf. være bedre programmering....

/Martin

---

Martin Andersen wrote:

> Thorbjørn Ravn Andersen wrote:
>
> > DBD::CSV læser hele filen ind i hukommelsen og benytter ikke
> > index-filer. Det gør meget stor forskel.
>
> gør den det?
> Så kan jeg slet ikke forstå forskellen i perfomance på DBD::CSV og på
> DBD::RAM, som skulle gøre det samme.
> Det kan selvf. være bedre programmering....

Eller anderledes prioritering. Der er ikke indeks-information i filen.
Det er derfor nødvendigt enten at klare sig uden eller bygge den nødvendige
information ved kørselsstart. Jeg har ikke studeret modulerne nærmere, men
jeg ville kun bruge dem ved små datafiler.

Kig i dokumentationen og evt i kildeteksten. Måske bliver du klogere?

--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Martin Andersen <martin@kampsax.dtu.dk> writes:

[...]
> mit program skulle være en executable, der legede sammen med en
> database, men jeg kan ikke se nogle baser der ikke bruger en
> installeret driver på det system man kører programmet i. Jeg har
> prøvet .csv, og det har ELENDIG perfomance

Hvilken slags data og hvordan bruger du dine data?


- ask

--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();

---

Ask Bjoern Hansen wrote:

> Martin Andersen <martin@kampsax.dtu.dk> writes:
>
> [...]
> > mit program skulle være en executable, der legede sammen med en
> > database, men jeg kan ikke se nogle baser der ikke bruger en
> > installeret driver på det system man kører programmet i. Jeg har
> > prøvet .csv, og det har ELENDIG perfomance
>
> Hvilken slags data og hvordan bruger du dine data?

Jeg har 2 tabeller, en simpel kedelig en, og en der har reference til
sig selv.
Eksempel:
felter i tabel vi kan kalde "files":
id
name
size
file_id

file_id værdien referer tilbage til en anden række, altså en slags
træ-struktur.
Egentlig havde jeg tænkt mig en primitiv kopi af et fil-system.
Hvis spørgsmålet gik på om der var nogle specielle felter som store
objekter og såen, så
er der ikke andet end almindelige værdier, bortset fra en dato.

Performance er nok ikke det største problem, men det er rart at ha' god
performance alligevel.
Jeg har indtil videre prøvet DBD::CSV og DBD::RAM
RAM stoler jeg ikke 100% på, da den har lavet nogle mærkelige fejl, men
den er lidt hurtigere end csv (ca. 25-30%). Det bliver nok RAM jeg ender
med at bruge

Mht. brug af data, så kunne det være rart at kunne fyre nogen gode
sql'er af, der fangede træstrukturen, men jeg har kun set det hos oracle
(med "connect by").

/Martin