Efter min mening bør databaser være Somebody Else's Problem. Det interesserer mig ikke om MySQL ikke overholder ACID-kravene og om PostgreSQL er langsom. Jeg kan godt se at det kan være interessant, jeg har bare undgået at skulle beskæftige mig med det og blev lidt brændt af dræbende kedelige 3 måneders database-kursus på universitetet.
Når jeg personligt har brug for et program der understøtter en eller anden arbejdsprocess, så leder jeg først efter noget der kan køre i screen på min hjemmeserver. Hvis det ikke lykkes, så leder jeg efter en passende webapplikation, og det er her de irriterende smådatabaser kommer ind.
Terminalprogrammer og grafiske programmer kan oftest klare sig uden en ekstern database, men ikke webapplikationer. Ganske ofte er de bundet til en bestemt af de to store open source-databaser, enten fordi udvikleren har en holdning til MySQL vs. PostgreSQL flamewar'en eller fordi udvikleren bare er en dum PHP-programmør der ikke bruger et database-abstraktionslag, selvom han kun bruger simple selects. Derfor ender man med at have begge databaser installeret og kørende.
Derefter skal der oprettes database-brugere og tabeller. Er man heldig så kan man vælge et prefix til tabelnavnene så man kan have flere ting kørende i samme database. Ellers er der altid en 'user' eller 'users' tabel, som forhindrer fredelig sameksistens. Og når jeg er færdig med at lege skal der slettes database-brugere og databaser.
Min foretrukne database er SQLite. Ingen server der skal køre, hele database-motoren er indlejret i applikationen. Databasen er bare en fil og rettigheder styres via filsystemets rettigheder. Oprydning er en enkelt fil der skal fjernes.
Alle burde understøtte SQLite, men selvfølgelig helst gennem et abstraktionslag, så man kan flytte over til en mere traditionel database hvis behovet opstår. SQLite er i øvrigt ikke kun til webapplikationer, for eksempel anvender Mozilla SQLite til mozStorage og i Firefox 3.0 vil bookmarks og history bruge SQLite.
Så skal jeg ikke nyde noget af FF 3, kan jeg forstå. Bloat og overkill, det er hvad jeg vil kalde det.
Hvad dælen skal man bruge SQL til i forbindelse med bookmarks?
Plain text forever!
-Lasse
Musikafspilleren Amarok bruger den også.
.. og der arbejdes på at bruge sqlite til cachen for openSUSEs pakkemanager.
Lasse:
Før du afskriver Mozilla XX 3, så skulle du måske lige kigge nærmere på det nuværende format kaldet Mork.
Mork er et rædselsfuldt format. SQLite er mange gange bedre.
Så vidt jeg husker, så vil bookmarks stadig blive gemt i XML, som nu.
Thunderbird vil nok få lidt mere ud af skiftet til SQLite end Firefox, men de er i hvert fald ikke noget minus.
Havde vi snakket om et pænt tekstformat kunne jeg måske være bekymret, men de eksisterende bookmark-filer i firefox er noget pseudo-HTML der inkluderer base64-kodede binærblobs og sikkert skal overholde nogle implicitte regler for HTML-struktur meget præcist.
Så tror jeg egentligt jeg foretrækker et (binær)format der understøtter et rimelig veldefineret generelt query-language. Så må værktøjskasse følge med så vi kan behandle SQLite-filer lige så let som tekstfiler.
Det kunne måske være rart at kunne lave dynamiske bookmark-foldere der viste resultatet af en søgning. Jeg kunne godt finde brug for en folder med "bookmarks jeg ikke har brugt" eller "bookmarks til Version2-artikler der er nyere end en uge" (de debatter jeg følger).
XML-blobs i en SQL-database lyder stygt. Hvorfor så ikke ren XML og så bruge XQuery?
Jeg tænkte specifikt på bookmarks filen. Den er ikke XML, men "HTML" (elementnavne er med store bogstaver) og går formentlig uændret helt tilbage til NCSA Mosaic. Jeg skal indrømme at tidsstempler burde angives i læsbart ISO 8601 format i stedet for seconds in epoch - jeg har en gang imellem konverteret bookmarks med et perlscript fra Mac-epoke (1901) til Unix-epoke (1970) - men ellers er der ikke meget i den der er "unaturligt". At ikoner er embedded i et BASE64 encodet format er selvfølgelig ikke så nydeligt, de burde vel snarere ligge i Cachen, med et flag i databasen der siger at de bruges af bookmarks og derfor ikke skal flushes. (eller rettere, de skal markeres som live hver gang bookmarks.html tilgås.)
Skulle der endelig laves noget om, så skulle det som Peter foreslår være til XHTML, så kunne man jo bruge XQuery, hvis man tænder på den slags.
Men en SQLite fil ville jeg ikke umiddelbart vide hvad jeg skulle stille op med uden at skulle læse en masse dokumentation. Og selv da er det ikke sikkert det vil virke hensigtsmæssigt. Vil man fx kunne tilgå en SQLite database (bare for læsning) mens den samtidig er åben for skrivning fra et andet program? Og hvad hvis den bliver korrupt? Min til dels "hjemmestrikkede" Seamonkey med Java og Mplayer plugins native under NetBSD crasher pt for et godt ord. En tekstfil kan jeg med ganske lidt møje hive noget meningsfuldt ud af - hvad kan jeg med SQLite? Jeg siger ikke det er umuligt, jeg ved bare hvad jeg kan i dag, og det vil jeg ikke vide umiddelbart med SQLite. Og jeg hylder altså Perls tre dyder, især den første.
Stod det til mig, var history formatet ikke en pind anderledes. For mig at se burde history være client pendanten til serverens access.log. Det er jo også en tekstfil, ikkesandt?
-Lasse
--
"There is no excuse for second-hand knowledge of something as vital as international standards." /Carl Malamud
og alle de andre databaser :-)
Ja, der er for mange databaser og databaseformater.
Mine favoritter er Postgresql og så det som mine webapplikationer på Tomcat'en ellers bruger ...
Hvad de bruger ved jeg ikke, nogle af dem bruger flade filer tror jeg, andre bruger noget indlejret som jeg ikke skal bekymre mig om.
Fordelen ved webapplikationer som jeg bruger er at de nemt kan "opgraderes" til en rigtig databaseløsning (Postgresql) ved at ændre få filer.
SQLite er dejligt simpel og den fungerer godt som en primitiv database, et skridt over tekstfiler - men meget bedre. Den bruges blandt andet i Mail.app på Mac OS X til indexes over e-mail m.v. - ikke at Mail.app af den grad er super til behandling af store mængder post.
SQLite kan derfor gøre det nemmere at vokse til en rigtig datase. Det alene gør at den må anbefales fremfor at rode i egne (proprietære) formater.
NB: bemærk at jeg slet ikke omtaler PHP+MySQL idet jeg undgår begge dele som pesten. De kan måske bruges til en hurtig prototype, men drift - nej tak!
Et abstraktionslag ville give mening hvis man vel at mærke kunne sende de samme SQL-forespørgsler til alle databaser. Det kan man ikke.
Det ville hjælpe på det hvis alle databaser overholdt SQL99. At stå med to databaser der begge overholdt SQL99 har jeg aldrig prøvet, og jeg tror ærlig talt at der stadig vil være problemer med at skrive programmer der kunne med dem begge samtidigt.
Abstraktionslag er noget man lære om i skolen, det er ikke noget der fungere i virkeligheden. (udsagnet bygger på MySQL, PostgreSQL og Oracle erfaringer)
Kramshøj: Hibernate løser ikke ovenstående problem.
Hvilke DBMS understøtter SQL99 i dag?
Mig bekendt ingen. Nogen gør det 95%, men ingen 100%.
"Et abstraktionslag ville give mening hvis man vel at mærke kunne sende de samme SQL-forespørgsler til alle databaser. Det kan man ikke."
Nej, derfor bruger man et abstraktionslag som fx SQLObject, hvor man slet ikke skal skrive SQL.
apt-get install sqlite3
så kan man scripte sig ud af ethvert ændringsbehov i sqlite databaser:
eksempel: sqlite3 ~/.gnome2/f-spot/photos.db .dump
Ja, Gnomes F-spot billedorganizer (http://f-spot.org/) bruget også sqlite.
En sjov ting ved sqlite er at den ingen licens har, den er public domain (ja, hverken BSD eller GPL, ren PD, udviklerne har skrifteligt fraskrevet sig copyright).
Mikkel,
Hibernate er jo slet ikke en database men netop et abstraktionslag.
Jeg er helt enig med Kristian Thy om at man bør bruge abstraktionslag til enhver kommunikation med sin database uanset hvilken dette skulle dreje sig om. Selvom der er stor forskel i de understøttede features samt måden disse bruges på fra database til database så kan man ofte det samme, set i et overordnet perspektiv. Med det rette abstraktionslag vil man derfor kunne udføre de samme operationer på mange forskellige databaser uden problemer.
Hvis vi endelig skal ned og snakke SQL standarder kan man jo holde sig til SQL-92 som, trods alt, understøttes i langt større grad end (popversionen) SQL-99.
>XML-blobs i en SQL-database lyder stygt. Hvorfor
>så ikke ren XML og så bruge XQuery?
Uden at vide det vil jeg gætte på, at en SQLite-base er bedre til at håndtere små ændringer i store filer end en XML-fil, der (i visse tilfælde) skal skrives påny fra ende til anden, hvilket kan tage sin tid, hvis der er meget data.
Jeg antager, at SQLite-basen understøtter en internt art "filsystem", der tillader, at data ikke er lagret sekventielt med i stedet ligger a la en fragmenteret disk.
> "Ganske ofte er de bundet til en bestemt af de to store open source-databaser, enten fordi udvikleren har en holdning til MySQL vs. PostgreSQL flamewar'en eller fordi udvikleren bare er en dum PHP-programmør der ikke bruger et database-abstraktionslag, selvom han kun bruger simple selects."
Well, når det er open source kan du jo bare skrive det abstraktionslag selv og dermed bidrage til det pågældende projekt, værre er det vel ikke.
Hvis man kan hitte ud af at oprette en mappe til webapplikationen og konfigurere webserveren til at køre applikationen, kan jeg simpelthen ikke se problemet i at have flere databaser - SÅ svært er det ikke at holde styr på. Det samme gælder præfikset - hvis du virkelig savner det, så brug dog det par minutter på at rette systemet til at bruge præfiks. Bidrag i stedet for at ynke og brokke over at nogen har lavet noget for dig.
Finn, jeg synes at det er en ynkelig undskyldning at lave noget suboptimalt bare fordi det er open source.
Giv en mand en fisk og han kan bliv mæt den dag, lær ham at fiske og han kan brødføde dig fremover. Jeg vil egentlig langt hellere bruge en halv time på at 'ynke og brokke' mig over et generelt problem end at bruge timevis i fremtiden på at refaktorerer kode uden at komme nogen vegne.
Så kan jeg nemlig bruge tiden på at bidrage til det rigtige projekt istedet for at spilde unødvendig meget tid på at installerer og afinstallere projekter.
Et abstrationslag virker skam. Spørgsmålet er bare niveauet af abstration: Det skal være så abstrakt at det er lige meget om man opererer mod en database, en flad fil, over netværk, hulkort, rækker af store/små isvafler osv.
Hvis det laves rigtigt, sparer det tid på sigt og giver uendelige muligheder for at gemme data på nye måder.
Jeg har selv brugt det med success i flere applikationer.
Et abstrationslag virker skam. Spørgsmålet er bare niveauet af abstration: Det skal være så abstrakt at det er lige meget om man opererer mod en database, en flad fil, over netværk, hulkort, rækker af store/små isvafler osv.
Hvis det laves rigtigt, sparer det tid på sigt og giver uendelige muligheder for at gemme data på nye måder.
Jeg har selv brugt det med success i flere applikationer.
Peter > Det synes jeg så er for tyndt - at forlange at enhver programmør der lægger et projekt ud til fri afbenyttelse skal være ekspert i databaseabstraktion, blot for at nogle få der ikke bruger den database der nu engang er valgt som udgangspunkt får netop den understøttelse de foretrækker. Så må andre der er eksperter i netop dette jo bidrage med de nødvendige forbedringer til projektet.
Jeg vil da mene at det er mindst lige så vigtigt at tilføje nye features til et system som det er at tilføje abstraktionslag - vi har alle vores forcer og vores svagere områder. Chip in or stay away. At begynde at skyde på databaseabstraktionen er bare en tand for billigt - så bliver det næste vel brok over at der ikke er AJAX? Eller template-systemer? Eller RSS? Nej, det synes jeg altså bare lige er en tand for billigt. Selvfølgelig bør det laves ordentligt, men hvis projektet ikke indeholder muligheden må man altså selv bidrage til forbedringerne! :-)
Finn, jeg taler ikke om hvornår man må lægge ting ud eller ej. Jeg taler om hvornår det man lægger ud er kvalitet.
Hvis jeg skal vælge mellem 4-5 kalendersystemer, så vil jeg selvfølgelig tage udgangspunkt i den af højst kvalitet og så lave de nødvendige tilrettelser derfra. Hvis jeg klart kan undvære at bekymre mig om at installere nye databaser og ryde op bagefter, så får projektet en pil op.
Efterfølgende er der et indlysende spørgsmål om jeg kan lave de nødvendige tilrettelser i brugergrænsefladen. Der er det absolut også en pil opad hvis jeg kan fjerne unødige felter og tilføje egne hjælpeforklaringer uden at skulle pille for meget i selve logikken.
Du er velkommen til at udvikle open source-projekter uden at tænke på kvalitet. Men jeg tror ikke at dit open source-projekt bliver specielt vellykket som open source-projekt at betragte. I dette blogindlæg snakker jeg meget konkret om et bestemt kvalitets-aspekt, som du kan være enig elle ruenig i. Men kvalitet mener jeg egentligt er et ufravigeligt krav.
I forhold til hvilken form for abstraktionslag, så mener jeg man kommer langt med at vælge en forholdsvis konservativ SQL (i.e sql92) og så nogle meget tynde wrapper omkring databasefunktionerne. Perls DBI eller PHP's PDO istedet for de andre database-specifikke funktionsnavne de andre PHP's API'er har.
Jo der er tilfælde hvor mere advanceret database-adgang er ønskværdig. Men mange webapplikattioner har ikke behov og udviklerne behersker dem ikke (som du også selv er inde på).
