ProgrammeringsBaren! Småprat, om det du elsker!

[Gjest Slettet+9871234]

Inntrykket mitt er at de fleste bruker MySQL, og kun noen få foretrekker PostgreSQL. Men såvidt jeg vet, så er PostgreSQL flinkere til å følge SQL standarden enn MySQL, har flere funksjoner, og er godt dokumentert.

 

Hvem bryr seg om den standarden når den vanligvis ligger år etter de som finner nye database løsninger? Ofte kommer standarden diltende etter og så vidt jeg vet er den heller ikke gratis.

 

Kjenner du standarden?

Endret 25. april 2013 av Slettet+9871234

[Lycantrophe]

Du er en bra fyr, kgun :---)

[tomsi42]

Jeg bruker mysql når det er det eneste valget ...

 

Selv har jeg et svakt hjerte for Firebird (tidligere Interbase) - en fin no-nonsense database for mellomstore datamengder.

[Occi]

Inntrykket mitt er at de fleste bruker MySQL, og kun noen få foretrekker PostgreSQL.

Syns det virker som om de fleste som har prøvd både MySQL og PostgreSQL gjerne fortrekker PostgreSQL. Har brukt det litt med SQLAlchemy (Python), og det er en knallsterk kombo.

[puse]

Har prorammert lite database applikasjoner, men når jeg nylig skulle velge for et nytt prosjekt endte jeg opp med MySQL pga Workbench, etter litt kjapp Googling etter noe tilsvarende for PostgreSQL så resultatene lite appellerende ut. Er jo egentlig ett fett hva jeg bruker, koden jeg skriver blir jo ikke noe annerledes for ting på mitt nivå, da jeg bruker SQLAlchemy uansett.

[GeirGrusom]

SQL er et idiotisk spørrespråk. Det er helt fantastisk at det ikke er blitt erstattet over årene med noe litt mer fornuftig.

[siDDis]

Heilt ueinig! SQL er eit fantastisk spørrespråk! Finnes ingen verdens grunn til å bytte det ut med noko anna.

[GeirGrusom]

Heilt ueinig! SQL er eit fantastisk spørrespråk! Finnes ingen verdens grunn til å bytte det ut med noko anna.

Syntaksen er inkonsekvent og ekstremt kompleks.

SELECT er heller ikke spesielt ekspressiv, og det er mange tilfeller der ting som virker trivielt kan være ekstremt komplisert å få til i SQL.

SELECT skjer i gal rekkefølge også. Man velger kolonner fra en tabell man enda ikke har definert. og velger dataene fra tabellen uten å ha spesifisert uttrykket for å velge ut data.

 

Det er SELECT kolonner FROM tabell WHERE uttrykk, men det burde vært FROM tabell WHERE uttrykk SELECT kolonner.

 

SELECT kolonne, (SELECT kolonne2 FROM tabell2 WHERE foo) FROM tabell1 WHERE foo

Her havner det indre uttrykket midt oppi suppa.

 

Vs.

FROM tabell1 WHERE foo SELECT kolonne, (FROM tabell2 WHERE foo SELECT kolonne2)

Endret 26. april 2013 av GeirGrusom

[tomsi42]

Det er SELECT kolonner FROM tabell WHERE uttrykk, men det burde vært FROM tabell WHERE uttrykk SELECT kolonner.

Når ble "FROM tabell WHERE uttrykk SELECT kolonner" mer logisk en det SQL bruker i dag?

[GeirGrusom]

Når ble "FROM tabell WHERE uttrykk SELECT kolonner" mer logisk en det SQL bruker i dag?

 

1. Fordi man starter med å si hva datakilden er, før man fortelle hva man faktisk skal lese fra den.

Fordelen med dette er at en teksteditor kan gi deg auto-complete med en gang du starter å skrive ettersom du gir den nødvendig informasjon i riktig rekkefølge.

 

2. Indre uttrykk vil ikke havne midt inni andre spørreuttrykk, men legge seg på slutten.

 

3. Det er ingen forvirring: Du kan bruke hvilke felt du vil i en WHERE setning, det er uavhengig av hva du skriveer i SELECT, men dette er heller ikke helt selvforklarende ettersom du starter med å si hva du skal velge ut. Dersom select er på slutten, så er det ingen tvil om at WHERE driter i hva som står i SELECT.

[tomsi42]

Tror du skal tenke over dette en gang til

[GeirGrusom]

Tror du skal tenke over dette en gang til

Hva er fordelen med SELECT FROM WHERE kontra FROM WHERE SELECT?

 

SQL ble utviklet for å være enkelt å bruke for folk som ikke drev med programmering.

Endret 26. april 2013 av GeirGrusom

[tomsi42]

SQL syntaxen flyter bedre - noe som gjør det mer lesbart i mine øyne. Forslaget ditt er ikke noe mer lesbart, snarere tvert i mot.

[GeirGrusom]

SQL syntaxen flyter bedre - noe som gjør det mer lesbart i mine øyne. Forslaget ditt er ikke noe mer lesbart, snarere tvert i mot.

At du synes ting om flyt og lesbarhet er ikke et argument. Hvilke spesifikke fordeler har SQL syntaks over den jeg skrev?

[siDDis]

SQL er verken inkonsekvent eller komplekst. Det er det mest logiske språket for å gjere datauttrekk, spesielt kompliserte som krevje diverse formar for JOINS/HAS/GROUP BY osv...

 

Med tanke på at dokumentasjonen idag er ganske god og generell(fungerer på tvers over forskjellige produkter/løysningar) så er det heilt idiotisk å bruke tid på å kverulere med at SQL er gammalt vræl og bør skrivast om. Det er mange som prøver seg, finnes jo hundrevis av forskjellige ORM'er. Men ingen av dei er ein skikkeleg erstatning for god gamaldags, standardisert og dokumentert SQL.

[tomsi42]

At du synes ting om flyt og lesbarhet er ikke et argument. Hvilke spesifikke fordeler har SQL syntaks over den jeg skrev?

Jeg vil si at lesbarhet er noe man alltid skal strebe etter i kode. Kode leses mer enn skrives; og god lesbarhet gjør feilsøking lettere.

 

Standard SQL har, som siDDis nevner, den fordelen at den er godt dokumentert og standarisert.

[GeirGrusom]

SQL er verken inkonsekvent eller komplekst. Det er det mest logiske språket for å gjere datauttrekk, spesielt kompliserte som krevje diverse formar for JOINS/HAS/GROUP BY osv...

 

Med tanke på at dokumentasjonen idag er ganske god og generell(fungerer på tvers over forskjellige produkter/løysningar) så er det heilt idiotisk å bruke tid på å kverulere med at SQL er gammalt vræl og bør skrivast om. Det er mange som prøver seg, finnes jo hundrevis av forskjellige ORM'er. Men ingen av dei er ein skikkeleg erstatning for god gamaldags, standardisert og dokumentert SQL.

Jeg vil si at lesbarhet er noe man alltid skal strebe etter i kode. Kode leses mer enn skrives; og god lesbarhet gjør feilsøking lettere.

 

Standard SQL har, som siDDis nevner, den fordelen at den er godt dokumentert og standarisert.

 

Dette er en helt forferdelig holdning fra noen som jobber med teknologi etter mitt syn.

 

edit: dere ignorerer også det at det er bare PostgreSQL som etterstreber å følge SQL standarden.

 

Eksempel på inkonsistens i SQL er at INSERT og UPDATE har helt vidt forskjellig syntaks.

Endret 26. april 2013 av GeirGrusom

[tomsi42]

Skal noe forandres, så må det være for å få en reell forbedring og forenkling samtidig som endringen løser problemer med dagens løsning.

 

Jeg klarer ikke se noe av dette i ditt forslag; det er mer et forslag som går på å gjøre det litt enklere for deg å skrive koden.

[Runar]

Selv har jeg et svakt hjerte for Firebird (tidligere Interbase) - en fin no-nonsense database for mellomstore datamengder.

 

Læreren vi hadde i Databaser på høgskolen elsket Firebird. Noen lagde til og med et spill med læreren som hovedperson, og hytta han alltid snakket om i timene var med i spillet.

[GeirGrusom]

Skal noe forandres, så må det være for å få en reell forbedring og forenkling samtidig som endringen løser problemer med dagens løsning.

 

Jeg klarer ikke se noe av dette i ditt forslag; det er mer et forslag som går på å gjøre det litt enklere for deg å skrive koden.

 

Jeg var borti en case her i fjor en gang. Den skulle telle antall forekomster av en enum verdi i et felt på en tabell. En skulle tro man kunne ta count og order by, men det viste seg å ikke være så enkelt som det burde vært. De som var 0 ville ikke komme med i det hele tatt, og det tullet til datasettet fullstendig.

 

Koden som var der orginalt kjørte en SELECT for alle mulige verdier av feltet. Etter en stund, lot jeg det bare ligge, fordi jeg kom ingen steder.

Endret 26. april 2013 av GeirGrusom