ProgrammeringsBaren! Småprat, om det du elsker!

[Gjest Slettet+9871234]

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

 

Så gjør det selv da.

 

Og så er det mulig å abstrahere bort syntaksen og lage sitt eget kvasi "språk" hvor den underliggende databaseplattformen er abstrehert bort, slik drupal har gjort.

 

Det er antagelig mer enn godt nok for 95 % av alle webutviklere og noen ganger er godt nok best.

 

Når det gjelder syntaks. Hvilken av disse

 

SELECT title
		  title_id,
		  price,
		  au_lname
FROM	titles,
		  authors,
		  titleauthor
WHERE  titles.title_id = titleauthor.title_id
		  AND  titleauthor.au_id = authors.au_id

 

SELECT
		  title
		 ,title_id
		 ,price
		 ,au_lname
FROM  
		  titles
		 ,authors
		 ,titleauthor
WHERE
		  titles.title_id = titleauthor.title_id
AND
		  titleauthor.au_id = authors.au_id

 

 

 

foretrekker du og hvorfor? Forumets editor er ikke helt god på tabs. Dere forstår sikker hvordan det skal være formatert i første spørring. Alt skal følge samme marg og innrykkene skal ikke være så store.

Endret 26. april 2013 av Slettet+9871234

[tomsi42]

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.

Du må bruke group by i slike tilfeller.

[Gjest Slettet+9871234]

Ja og HAVING er for GROUP BY som WHERE for SELECT.

[MikkelRev]

Det blir litt som å diskutere at yyyy-mm-dd er et bedre datoformat enn dd-mm-yyyy. Er jo kanskje logisk at man begynner med det største (yyyy eller table) også driller seg ned til det minste (dd eller kolonner). Men vanesak har også noe å si. Å snu opp ned på syntaxen har en litt for stor konsekvens til at jeg tror det er verdt det. Det vil ta flere år før det har blitt normalisert (no pun), og vinningen er minimal.

[Gjest Slettet+9871234]

Når det gjelder min andre syntaks, mener jeg den er bedre ettersom det er lettere å finne vanlige komma feil med den. Ta bort kommaet etter pris i de to eksemplene ovenfor. Innfør også et ekstra komma etter au_lname. I andre spørring kommer da kommaet på en egen linje og syntaksfeilen bør oppdages med en gang.

 

Jeg mener dessuten det er klarere og ha nøkkelord som SELECT, WHERE ... på egen linje og skrive dem med store bokstaver.

 

Smak og behag kan man diskutere, men man blir sjelden enig.

Endret 26. april 2013 av Slettet+9871234

[siDDis]

Det blir litt som å diskutere at yyyy-mm-dd er et bedre datoformat enn dd-mm-yyyy. Er jo kanskje logisk at man begynner med det største (yyyy eller table) også driller seg ned til det minste (dd eller kolonner). Men vanesak har også noe å si. Å snu opp ned på syntaxen har en litt for stor konsekvens til at jeg tror det er verdt det. Det vil ta flere år før det har blitt normalisert (no pun), og vinningen er minimal.

Følg ISO standarden for dato! https://en.wikipedia.org/wiki/ISO_8601

Ikkje finn opp ein ny!

[GeirGrusom]

Du må bruke group by i slike tilfeller.

det funker ikke, fordi elementer uten verdier kommer ikke med.

 

edit: altså, hvis det er 0 forekomster av "Hurra for deg" i datasettet, så blir den ikke med ut i det hele tatt.

Endret 26. april 2013 av GeirGrusom

[tomsi42]

det funker ikke, fordi elementer uten verdier kommer ikke med.

Men er det en svakhet med SQL eller en svakhet i designet av applikasjonen? Jeg vil si at SQL oppfører seg som forventet ut i fra hvordan NULL er definert.

[GeirGrusom]

Men er det en svakhet med SQL eller en svakhet i designet av applikasjonen? Jeg vil si at SQL oppfører seg som forventet ut i fra hvordan NULL er definert.

Det var ikke akkurat det som var problemet, snarere at det jeg ville uttrykke, som høres ut som en triviell oppgave, er dritvanskelig å få til med bare SQL.

 

Det er her hele greia er. SQL er ikke et fantastisk spørrespråk. Dette er et eksempel på noe som er vanskelig å uttrykke i ren SQL, men burde strengt tatt ikke vært det. Jeg har vært borti flere andre slike anledninger, men kan ikke komme på neon akkurat i farta. Det med SELECT var mer for å peke på et aspekt hvor noe var standardisert men kanskje ikke så godt tenkt igjennom der og da.

 

Språket var først og fremst laget for å være enkelt å bruke for folk uten programmeringserfaring, og det skinner greit igjennom på insert, update og select.

Endret 26. april 2013 av GeirGrusom

[kenjako2]

Heisan alle sammen.

 

Har programmert litt i C++ med SDL engine, og har fått implementert og testet ut SDL_Rotozoom funksjonen. Har fått dette til å fungere, slik at jeg får roterert og zoomet/endret størrelse på bilder.

 

Spørsmålet mitt er som følger:

Noen som kunne hjulpet meg med å finne en enkel kode som viser riktig koding av rotozoom funksjonen mot en surface som skal være transparent.

Bilde som er koblet mot surface er satt med en bestemt rgb verdi(255,0,255) for transparency, som fungerer så lenge jeg ikke bruker rotozoom. Så fort jeg bruker rotozoom er den ikke transparent lenger...

 

 

Kenneth.

Endret 26. april 2013 av kenjako2

[MikkelRev]

Følg ISO standarden for dato! https://en.wikipedia.org/wiki/ISO_8601

Ikkje finn opp ein ny!

Du finner ikke opp hjulet på nytt uansett hvilken av de to datoformatene du bruker.

yyyy-mm-dd er ISO og NS-standard.

dd.mm.yyyy er Språkrådets standard, og mye mer vanlig å bruke i Norge i dagligdags.

 

Men poenget var egentlig å vise at det å diskutere hvilken av disse to datoformatene som er "best", blir som å diskutere om det er bedre å skrive FROM SELECT enn SELECT FROM.

[GeirGrusom]

Men poenget var egentlig å vise at det å diskutere hvilken av disse to datoformatene som er "best", blir som å diskutere om det er bedre å skrive FROM SELECT enn SELECT FROM.

Nå pekte jeg på tre praktiske fordeler ved å bruke den ene formen fremfor den andre uten at noen ville fortelle noen grunner til å bruke den andre annet enn at "DET ER STANDARDISERT LOL" og "SMAKEN ER SOM BAKEN DIN STINKER LOL".

[siDDis]

Du finner ikke opp hjulet på nytt uansett hvilken av de to datoformatene du bruker.

yyyy-mm-dd er ISO og NS-standard.

dd.mm.yyyy er Språkrådets standard, og mye mer vanlig å bruke i Norge i dagligdags.

 

Men poenget var egentlig å vise at det å diskutere hvilken av disse to datoformatene som er "best", blir som å diskutere om det er bedre å skrive FROM SELECT enn SELECT FROM.

Du lagrer data som ISO standard, og presenterer den heller eventuelt som Språkrådets standard.

 

Eg hater å måtte jobbe med APIer som brukar dato med ein heilt anna formatering. Bare masse ekstraarbeid for noko som eigentleg er reint tull.

[tomsi42]

Nå pekte jeg på tre praktiske fordeler ved å bruke den ene formen fremfor den andre uten at noen ville fortelle noen grunner til å bruke den andre annet enn at "DET ER STANDARDISERT LOL" og "SMAKEN ER SOM BAKEN DIN STINKER LOL".

Nei, du har kommet med tre punkter der du synes at SQL suger. Som forsåvidt kan diskuteres.

 

Men eksempelet du kommer med ser for meg som om du bare stokker om på ordene i utrykket uten at det løser noe som helst grunnleggende

[tomsi42]

Du lagrer data som ISO standard, og presenterer den heller eventuelt som Språkrådets standard.

Jeg hadde lagret datoer som datatype DATE jeg, og latt presentasjonslaget bekymre seg om formatet.

 

Hvis du skal lagre datoer som strenger, så er ISO formatet å anbefale, for å få riktig sortering; men å lagre datoer som strenger er vel ikke så smart?

[Sokkalf™]

Med mindre man bruker SQLite, da, som ikke støtter annet.

[Gjest Slettet+9871234]

det funker ikke, fordi elementer uten verdier kommer ikke med.

 

edit: altså, hvis det er 0 forekomster av "Hurra for deg" i datasettet, så blir den ikke med ut i det hele tatt.

 

Det er jo vanskelig å svare deg når du ikke eksplisitt viser et eksempel (forbehold om at du har gjort det tidligere i tråden - jeg leser ikke alt som skrives her) og hva du er ute etter. Null verdier er spesielle i databaser etter som man ikke kjenner verdien. NULL verdier er ikke lik noe ettersom verdien er ukjent. De kan være lik en verdi eller de kan ikke være lik en verdi. Følgende er viktig:

• Du bestemmer når en kolonne opprettes om den kan ha NULL verdier.
  
• Null verdier behandles konsistent med IS NULL eller IS NOT NULL. Så vidt jeg vet funker = NULL på MS SQL server, men det er MS i vanlig kjent stil. Ingen regel (standard) uten unntak. Når man bryter standarden, må man være klar over hva man gjør og tenke portabilitet.
  
• Et eksempel kombinasjon av operator og IS NULL:
  <> OR kolonne IS NULL.
  
• Merk følgelig nøkkelordene, NOT, NOT EXIST, NOT IN, NOT NULL
  
• Funksjonene NULLIF samt COALESCE.
  
• Der kan være andre spesielle funksjoner, nøkkelord og operatorer i andre databaser, men vær veldig varsom når du behandler NULL. Djevelen er i høyeste grad i detaljene og tenker du portabilitet bør du følge standarden.
  

SQL er på en måte som sjakk. Det er lett å lære trekkene, men det er vanskelig å bli en mester. Få om ingen kommer på Magnus Carlsen sitt nivå og får en så omfattende Wikipedia artikkel som ham i ung alder.

 

Men er det en svakhet med SQL eller en svakhet i designet av applikasjonen? Jeg vil si at SQL oppfører seg som forventet ut i fra hvordan NULL er definert.

 

Enig.

Endret 27. april 2013 av Slettet+9871234

[Gjest Slettet+9871234]

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.

 

Interessant. Går det også med SQLite. Til enkle Python / Django drevne siter kan jeg komme til å bruke SQLite som jo er en database implementert i filsystemet (som kan være en fordel noen ganger).

[Gjest Slettet+9871234]

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.

 

Fant du http://www.pgadmin.org/ ?

 

Merk også at hostere som støtter PostgreSQL har som regel phpPgAdmin http://phppgadmin.sourceforge.net/doku.php installert på tilsvarende måte som phpMyAdmin er implementert hos de som kun tilbyr MySQL. Noen hostere tilbyr begge plattformer og begge verktøy.

[Occi]

Interessant. Går det også med SQLite. Til enkle Python / Django drevne siter kan jeg komme til å bruke SQLite som jo er en database implementert i filsystemet (som kan være en fordel noen ganger).

Avhengig av scenario kan det være både fornuftig og ufornuftig å prøve å sammenligne SQLite med PostgreSQL. Såvidt jeg vet er det ikke mulig å koble til en SQLite base over et nettverk uten å bruke sshfs e.l, men det er også kanskje meningen fordi den ikke er ment for slikt.