– MySQL 5.1 ikke klar

[Bolson]

PostgreSQL, MySQL... It's all the same. Dagene til relasjonsdatabaser er forbi uansett.

 

Er det ikke fornuftig å begrunne et slik påstand.

 

Tenk deg da; du lagrer [i flesteparten av tilfellene] ALT på ett sted, og det du lagrer henger på en eller annen måte tett sammen med noe annet som du lagrer. ALT er satt inn i en firkantet boks, med predefinert schema, låser, replikering for å håndtere maskinfeil og whatnot. Jeg kan være enig i at noen ganger er det veldig fint med en relasjonsdatabase, men å prøve å jobbe smidig mot noe så satt som en RDBMS er bare håpløst.

 

Velkommen CouchDB.

 

Som de fleste av ideer/nyheter knyttet til datalagring er dette også en løsning som fungerer i gitte rammer, og for gitte løsninger, her lagring av ustrukturerte data. Det har vært mange aktuelle løsninger/nyvinninger gjennom tiden, men relasjonsdatabaser har vist seg særdeles overlevningsdyktige og langt mer fleksible.

 

CouchDB er egentlig ikke en database i tradisjonell forstand, men et "Content Repository". Faktisk er det mer eller mindre en flatfildatabase. Det har også vært på markedet en del andre slike semistrukturerte løsninger.

 

Da er etter min mening tankegangen bak JSR-170/JSR-283 vel så bra.

[DarkSlayer]

PostgreSQL, MySQL... It's all the same. Dagene til relasjonsdatabaser er forbi uansett.

 

Er det ikke fornuftig å begrunne et slik påstand.

 

Tenk deg da; du lagrer [i flesteparten av tilfellene] ALT på ett sted, og det du lagrer henger på en eller annen måte tett sammen med noe annet som du lagrer. ALT er satt inn i en firkantet boks, med predefinert schema, låser, replikering for å håndtere maskinfeil og whatnot. Jeg kan være enig i at noen ganger er det veldig fint med en relasjonsdatabase, men å prøve å jobbe smidig mot noe så satt som en RDBMS er bare håpløst.

 

Velkommen CouchDB.

hehe...

Det har sikkert sine fordeler, men det lille jeg så på CouchDB, så sliter jeg med å se hvordan man har relasjoner her. Tipper det er opp til egen kode å fikse relasjoner.

Og da er vi over på det som er styrken til rdbms, for jeg vedder på at oracle gruser denne når kompleksiteten øker littegran.

 

Det finnes flere lagrings-løsninger ute i verden, men så langt er det kun rdbms/sql databaser som har vist seg som gode all-round baser.

Selv jobber jeg på en base med en hel skog av tabeller og koblinger. Stress? Garantert. Men jeg kan ikke se det løst på en ikke-relasjons måte for å si det slik.

 

Det er når man har jobbet en stund på slike store datasett at man ser fordelen.

"Idag skal vi finne personer som blablabla" - ikke f om noen tenkte at vi skulle få slike oppdrag da basen ble designet. Men data ligger der, oppsamlet over tid. Noen join/union, og sub-selects så kan man gjøre mye magi. Men om man sitter på små-/enkle jobber så kommer man skjelden forbi select * from my_table. Og da er jo sql en pain.

Og så begynner noen med ORM og annet faenskap, kun for å slippe sql i grunn - av typen select * ... Så ender du opp med å bruke mye tid og krefter på å lære kvasisql implementert av noen luringer.

Har selv gjort joins i kode, men da visste jeg ikke bedre.

[siDDis]

Synes CouchDB virker interresant, det er sikkert ein ypperleg teknologi til sosiale nettsteder. Men om det erstatter ein RDBMS heilt trur eg ikkje. SQL er eit svært godt språk til å hente ut data effektivt.

[krigun]

Det har sikkert sine fordeler, men det lille jeg så på CouchDB, så sliter jeg med å se hvordan man har relasjoner her. Tipper det er opp til egen kode å fikse relasjoner.

 

Ja, og det er akkurat dette CouchDB ikke håndterer i det hele tatt; det er ikke en relasjonsdatabase.

 

Og så begynner noen med ORM og annet faenskap, kun for å slippe sql i grunn - av typen select * ... Så ender du opp med å bruke mye tid og krefter på å lære kvasisql implementert av noen luringer.

 

La oss ikke snakke om ORM her, blir så ufine diskusjoner

 

Og da er vi over på det som er styrken til rdbms, for jeg vedder på at oracle gruser denne når kompleksiteten øker littegran.

 

La meg presentere noen eksempler. Hvis vi på den ene siden har en RDBMS, i BCNF hvor forretningslogikken er fanget i stored procedures. Her trenger man bare a sette sammen enkel kode "utenfor databasen" for å ha et litt mer vennlig grensesnitt til forretningslogikken. Dette fungerer veldig bra hvis du på forhånd har kravspecen skåret ut i stein, og vet at antallet brukere ikke vil overstige N brukere.

 

PÅ den andre ekstreme siden, så har vi en applikasjon som lagrer alt løst i dokumenter (CouchDB), hvor du på forhånd ikke helt vet hvilke krav som kommer "neste uke", og antallet brukere er fullstendig ute i det blå (husker vel hvilke problemer Twitter hadde). Applikasjonen har mye høyere kompleksitet, men er dermed også mye enklere å endre fra dag til dag da man ikke har låst seg fast i ett databaseskjema. Dataene ligger ikke på ett og samme sted, asynkrone operasjoner, osv. Er selfølgelig endel ubesvarte spørsmål her, og jeg skal være den første til å innrømme at CouchDB ikke er god "all rounder" som dagans RDBMS er, men i mine øyne er det iallefall en god start.

[Bolson]

@krigun:

 

Da vil jeg påstå at bruken av JSR-170/JSR-283 som "content repository" lag mellom applikasjonslaget og lagringsdelen, som her kan være database, flatfiler eller kombinasjon, vil gi en langt bedre fleksibilitet. Det er nemlig slik at i nettløsninger er det data med struktur som egner seg 100 % for typisk databaselogikk, f.eks brukerdata, mens andre data har andre karakteristikker.

 

Problemet er at JSR-170/JSR-283 pr dato bare finnes for Java, selv om man har kommet langt med en PHP versjon og arbeidet er startet i det små med en versjon i Ruby.

[krigun]

@krigun:

 

Da vil jeg påstå at bruken av JSR-170/JSR-283 som "content repository" lag mellom applikasjonslaget og lagringsdelen, som her kan være database, flatfiler eller kombinasjon, vil gi en langt bedre fleksibilitet. Det er nemlig slik at i nettløsninger er det data med struktur som egner seg 100 % for typisk databaselogikk, f.eks brukerdata, mens andre data har andre karakteristikker.

 

Problemet er at JSR-170/JSR-283 pr dato bare finnes for Java, selv om man har kommet langt med en PHP versjon og arbeidet er startet i det små med en versjon i Ruby.

 

Veldig interessant, var faktisk ikke klar over de spesifikasjonene (lese lese). Takk

[Gjest Slettet-Pqy3rC]

Bah... snodig diskusjon...

 

Personlig operer jeg/vi alltid med multi-layer apps. så hvor data er eller hvordan ting lagres blir helt irrelevant for UI laget.

 

[uI app(s)] <-> [server App] <-> [DataStore(s)]

 

UI app'en kan således (uten at den vet noe) motta data fra flere fysiske datastore's (SQL servere) og flatfil lagere.

 

Vi opererer i tillegg med masterserver og slaveserver(e) for å enklere kunne øke antallet UI apps.

[krigun]

Bah... snodig diskusjon...

 

Personlig operer jeg/vi alltid med multi-layer apps. så hvor data er eller hvordan ting lagres blir helt irrelevant for UI laget.

 

[uI app(s)] <-> [server App] <-> [DataStore(s)]

 

UI app'en kan således (uten at den vet noe) motta data fra flere fysiske datastore's (SQL servere) og flatfil lagere.

 

Vi opererer i tillegg med masterserver og slaveserver(e) for å enklere kunne øke antallet UI apps.

 

Det er bra, og fortsett med det. Men akkurat hvordan applikasjoner er designet er ikke poenget her [i mine poster iallefall]. Det du derimot sier der at det ikke er så nøye hvordan dataene er lagret, som er greia, sålenge du får tak i dem igjen, og klarer å håndtere en løsere koblet langringstruktur.

 

Her er hyggelig lesestoff om denormalisering:

InfoQ Denormalization

 

Martin Fowler om at EBay kjører uten databasetransaksjoner:

Transactionless

 

Og til slutt, Mnesia DBMS til Erlang:

Mmmmmnesia