Discussion:
SQL, Bibliotek, Fråga
(too old to reply)
Mats
2009-10-27 06:58:48 UTC
Permalink
Raw Message
Hej,

Jag tänkte höra om någon är extra nöjd med sitt SQL bibliotek som de
använder.

Har just tittat på SQLAlchemy och tycker det ser intressant ut. Just hur de
kan bygga upp SQL-frågan i små enkla steg är väldigt tilltalande.
http://www.sqlalchemy.org/docs/05/sqlexpression.html#intro-to-generative-selects-and-transformations

Frågan är:
1. Vilka SQL bibliotek använder Lisp på ett bra sätt?

/Mats
Mikael Jansson
2009-10-27 07:23:09 UTC
Permalink
Raw Message
Post by Mats
Hej,
Jag tänkte höra om någon är extra nöjd med sitt SQL bibliotek som de
använder.
Har just tittat på SQLAlchemy och tycker det ser intressant ut. Just hur de
kan bygga upp SQL-frågan i små enkla steg är väldigt tilltalande.
http://www.sqlalchemy.org/docs/05/sqlexpression.html#intro-to-generative-selects-and-transformations
1. Vilka SQL bibliotek använder Lisp på ett bra sätt?
Det diskuterades Någon Annanstans(tm) häromsistens. Jag har för mig att
CL-SQL <http://clsql.b9.com/> rentav är modellerat efter SQLAlchemy,
just vad gäller det du frågar. Har desvärre ingen egen erfarenhet, så
allt är hörsägen.
--
Mikael Jansson | http://mikael.jansson.be | GPG Key 0x88986608
Limp: The Vim Lisp IDE - http://mikael.jansson.be/hacking/limp
Björn Lindberg
2009-10-27 07:24:21 UTC
Permalink
Raw Message
Post by Mats
Hej,
Jag tänkte höra om någon är extra nöjd med sitt SQL bibliotek som de
använder.
Jag är mycket nöjd med pg.lisp, men det är, ser jag nedan, inte
riktigt vad du söker. Pg.lisp är nämligen bara ett tunt gränssnitt
till Postgresdatabasen, och har inga finesser för att konstruera frågor.
Post by Mats
Har just tittat på SQLAlchemy och tycker det ser intressant ut. Just
hur de kan bygga upp SQL-frågan i små enkla steg är väldigt
tilltalande.
http://www.sqlalchemy.org/docs/05/sqlexpression.html#intro-to-generative-selects-and-transformations
Efter en snabb titt får jag intrycket att de med mycket möda och stort
besvär nu kan skriva SQL-frågor med Pythonsyntax. Det imponerar inte
på mig. Vad jag i så fall gärna skulle ha till Lisp vore SQL-anpassad
relationsalgebra skriven med S-uttryck. Det kan jag tänka mig
verkligen skulle vara användbart när man vill konstruera frågor
dynamiskt. Tyvärr känner jag inte till ett bibliotek som
tillhandahåller någonting sådant.


Björn
Henrik Hjelte
2009-10-27 08:38:35 UTC
Permalink
Raw Message
Post by Mats
Hej,
Jag tänkte höra om någon är extra nöjd med sitt SQL bibliotek som de
använder.
Har just tittat på SQLAlchemy och tycker det ser intressant ut. Just hur de
kan bygga upp SQL-frågan i små enkla steg är väldigt tilltalande.
http://www.sqlalchemy.org/docs/05/sqlexpression.html#intro-to-generative-selects-and-transformations
1. Vilka SQL bibliotek använder Lisp på ett bra sätt?
clsql har redan nämnts.

postmodern tycker jag är ganska elegant, det finns några exempel här:
http://common-lisp.net/project/postmodern/
Exempelvis hur man kan skapa en tabell som mappar mot en klass enkelt.

cl-perec är ju en Object-Relational mapper, men det har ett ganska
lispig syntax för frågor, men jag tror inte man kan använda frågedelen
utanför deras OR-värld:
http://common-lisp.net/project/cl-perec/showcase.html. De har ett
kundvagnsexempel också som kanske är ännu tydligare.

Någon gång innan jag dör vill jag göra en riktig relationsdatabas i
Lisp, baserad lite på vad jag läst från Date/Darwens The Third
Manifesto.

/Henrik
Mats
2009-10-27 22:50:17 UTC
Permalink
Raw Message
Tack för alla svar. Jag har en hel del att undersöka nu. Jag blev väldigt
intresserad av hur CLSQL fungerar.
Men postmordern är det jag tycker verkar mest pragmatiskt. Jag gillar att
man kan falla tillbaka i SQL. Det känns tryggt. Väldigt elegant.

Hittade just det här:
http://www.cliki.net/Sexql
http://www.cliki.net/Septeql

Tyvärr kommer man inte åt koden.
Post by Mats
Post by Mats
Hej,
Jag tänkte höra om någon är extra nöjd med sitt SQL bibliotek som de
använder.
Har just tittat på SQLAlchemy och tycker det ser intressant ut. Just hur
de
Post by Mats
kan bygga upp SQL-frågan i små enkla steg är väldigt tilltalande.
http://www.sqlalchemy.org/docs/05/sqlexpression.html#intro-to-generative-selects-and-transformations
Post by Mats
1. Vilka SQL bibliotek använder Lisp på ett bra sätt?
clsql har redan nämnts.
http://common-lisp.net/project/postmodern/
Exempelvis hur man kan skapa en tabell som mappar mot en klass enkelt.
cl-perec är ju en Object-Relational mapper, men det har ett ganska
lispig syntax för frågor, men jag tror inte man kan använda frågedelen
http://common-lisp.net/project/cl-perec/showcase.html. De har ett
kundvagnsexempel också som kanske är ännu tydligare.
Någon gång innan jag dör vill jag göra en riktig relationsdatabas i
Lisp, baserad lite på vad jag läst från Date/Darwens The Third
Manifesto.
/Henrik
_______________________________________________
Lisp mailing list
http://mailman.nocrew.org/cgi-bin/mailman/listinfo/lisp
Mathias Dahl
2009-10-27 21:46:05 UTC
Permalink
Raw Message
Jag tyckte att CLSQL fungerade bra för ett litet projekt (en handfull
enkla tabeller, få relationer) jag micklade med för något år sedan. Om
jag minns rätt fanns det två sätt att prata med databasen, via det
funktionella och via det objektorienterade gränssnittet och man kunde
välja det som kändes/passade bäst efter vad man just då ville få till
i en viss funktion. Hade lite jox med att få det att kompilera bara
men jag är ingen van CL:are heller.
Post by Mats
Hej,
Jag tänkte höra om någon är extra nöjd med sitt SQL bibliotek som de
använder.
Har just tittat på SQLAlchemy och tycker det ser intressant ut. Just hur de
kan bygga upp SQL-frågan i små enkla steg är väldigt tilltalande.
http://www.sqlalchemy.org/docs/05/sqlexpression.html#intro-to-generative-selects-and-transformations
1. Vilka SQL bibliotek använder Lisp på ett bra sätt?
/Mats
_______________________________________________
Lisp mailing list
http://mailman.nocrew.org/cgi-bin/mailman/listinfo/lisp
Micke Karlsson
2009-10-29 02:12:39 UTC
Permalink
Raw Message
Jag gillar inte rdbms och/eller sql överhuvudtaget, så jag skulle
inte vilja ha det i botten på en applikationsstack jag byggde
överhuvudtaget. En del som kanske vet vad dom pratar om säger att
riktig, äkta relationsalgebra är jättebra på alla sätt och vis,
men att det som brukar kallas relationsdatabaser långt ifrån är
riktiga relationsdatabaser och att sql långtifrån är
relationsalgebra. Det har jag ingen möjlighet att bedöma, men jag
har upprepade gånger bankat huvet mot två (olika?) problem
arbetandes med rdbms-er:

1) Jag kan uttrycka vad jag vill i SQL, och databasen kan göra
vad jag vill, men gör det på ett alldeles för ineffektivt sätt.

2) Jag kan uttrycka vad jag vill på svenska, i C, på ett
skissblock eller genom att ringa in saker i ett kalkylark, men
jag kan fan inte uttrycka det i SQL; det bara går inte.



Exempel på när 1) kan inträffa: tabell X innehåller 400 miljoner
rader. Vissa rader i denna tabell som uppfyller vissa inte
särskilt krångliga vilkor (kanske några joins/subselects?) skall
grupperas ihop och summeras. Det finns inga index som gör att man
kan plocka ut bara de rader man är intresserad av. Det gäller
alltså att få rdbms:en att springa igenom den stora tabellen _en
enda gång_ och summera ihop relevant data.

Hur jag än formulerar dethär i vanlig sql (även med en massa
hints) resulterar det i att rdbms:en springer framlänges och
baklänges, grupperar och sorterar och gör allehanda jobbiga saker
i dendär stora tabellen. Det tar inte en timme, som det skulle
göra i idealfallet, utan flera dygn. Svårt att få in i
körschemat!


I dethär läget är jag rökt, och måste fråga nån som gått de relevanta
oracle-kurserna eller som råkat snappa upp den relevanta voodoo som
behövs för att få databasen att göra det man vill att den skall
göra. Det brukar vara nån oraclespecifik secret sauce som inte går att
läsa sig till. Det är inte alltid det finns nån på plats som klarar
att svara på frågan. Det är inte ens säkert att konsulter inkallade
från oracle alltid kan lösa problemet (inte ett såhär enkelt exempel,
men samma typ av problem i en mycket mer komplex kontext). Isåfall får
man antingen leva med plågan eller riva allting och skriva om frågan
som pl/sql.


Fall 2) brukar jag råka ut för när jag skall summera/gruppera ihop
djupt nästlade grunkor med en massa subqueries, subsubqueries osv och
lite olika ranges, och lite olika förekomster av null på olika ställen
i tabellerna ifråga. Jag brukar hamna i att jag vill referera i
wherevillkoren till nån aggregatkolumn som jag namngivit med "select
... as" en eller några våningar upp (eller till en annan subquery?,
kommer inte ihåg), men det går inte; det finns ingenting som heter
så. Sen provar jag att formulera om på några olika vis ett tag tills
det är dags att besöka experten. Som skriver om frågan till
oigenkännlighet: svaret på problemet är _inte_ att uttrycka sig på ett
listigt abstrakt vis utan att mycket mer konkret specificera hur
rdbms:en skall traversera tabellerna ifråga.

Sen kan jag se ett problem till med sql, och det är att man är
hänvisad till proprietär syntax om man skulle vilja modellera ett träd
eller en hierarkisk graf av något slag. Dock har jag inte träffat på
nåt sånt problem i verkligheten nån gång; sällan eller aldrig drabbas
nog en dba eller en sqldatabasdesigner av insikten att nånting
lämpligen modelleras som ett träd. Om man själv designade en databas
skulle nog risken föreligga att man skulle vilja ha nåt data
trädstrukturerat.


Jag undrar om någon omformulering av sql i python eller lispsyntax som
sedan trollas om till SQL hjälper mot 1 eller 2 ovan.

Skulle jag behöva skriva kod som bökade med en befintlig sqldatabas
kanske det vore vits med nåt sorts mappningslager. Kommer inte ihåg om
Dan Weinreb sagt nåt om hur dom gör på ITA (dom kör oracle i botten),
det kanske går att googla fram.

Jag tänker använda nån enkel objektdatabas (persistenta clos-klasser)
för mitt pågående enkla lisphack och nöjer mig med att skriva lispkod
istället för att formulera queries i nåt frågespråk. Skulle det bli
aktuellt att skriva invecklade frågor mot en databas i nåt eget
projekt nån gång skulle jag tjacka lispworks enterprise och skriva
frågorna i prolog. Men det skulle behöva vara på ett lite större
projekt, kostar trettifem lax. Kan inte nån ta och fixa till en bra,
fri prologkoppling ovanpå persistent clos? Cristophe Rhodes har
snyggat till Norvigs prolog från PAIP, kan inte nån skriva lite
debuggers, optimerare och sånt som man antagligen behöver om man skall
utföra riktigt arbete med en sån? Snälla?

Kolla Franz' prolog ovanpå allegrocache för vad som vore optimalt att
jobba med som databas. kostar tyvär $$$. (antagligen mycket mer än
lispwork enterprise, deras priser är en förhandlingsfråga).


--micke
Mathias Dahl
2009-10-29 21:36:52 UTC
Permalink
Raw Message
Själv känner jag mig naken när jag inte har tillgång till en trygg och
pålitlig gammal databas :) Jag har jobbat med Oracle, som
DBA/tekniker/utvecklare sedan 1996, och visst finns det knöliga eller
långsamma frågor, och visst får man ibland använda PL/SQL för att få
till något som SQL inte fixar (men kan du göra det med SQL är det
ganska ofta det snabbaste) men på det stora hela diggar jag databaser.
Och jo, grupperingar kräver (oftast?) sortering och sortering tar tid,
speciellt om allt data inte finns i minnet. Man måste ibland, tyvärr,
klappa Oracle medhårs, så som dina experkollegor lärt sig.

Har läst lite om Prolog (i PAIP) och RDF som tangerar det (väl?) och
lockas av hur dynamiskt det är men jag skulle gissa att det straffar
sig i form av dålig prestanda och/eller minneskrävande system om man
vill göra saker som passar bra i ett RDBMS. Am I right? Annars hade
det varit grymt. Saknar du ett attribut i en tabell? Fine, lägg till
det bara utan att modda tabellen. Hmm, fixar inte Couchdb något åt det
hållet förresten? Nåväl, databaser is the shit :)

/Mathias
Post by Micke Karlsson
Jag gillar inte rdbms och/eller sql överhuvudtaget, så jag skulle
inte vilja ha det i botten på en applikationsstack jag byggde
överhuvudtaget. En del som kanske vet vad dom pratar om säger att
riktig, äkta relationsalgebra är jättebra på alla sätt och vis,
men att det som brukar kallas relationsdatabaser långt ifrån är
riktiga relationsdatabaser och att sql långtifrån är
relationsalgebra. Det har jag ingen möjlighet att bedöma, men jag
har upprepade gånger bankat huvet mot två (olika?) problem
1) Jag kan uttrycka vad jag vill i SQL, och databasen kan göra
   vad jag vill, men gör det på ett alldeles för ineffektivt sätt.
2) Jag kan uttrycka vad jag vill på svenska, i C, på ett
   skissblock eller genom att ringa in saker i ett kalkylark, men
   jag kan fan inte uttrycka det i SQL; det bara går inte.
Exempel på när 1) kan inträffa: tabell X innehåller 400 miljoner
rader. Vissa rader i denna tabell som uppfyller vissa inte
särskilt krångliga vilkor (kanske några joins/subselects?) skall
grupperas ihop och summeras. Det finns inga index som gör att man
kan plocka ut bara de rader man är intresserad av. Det gäller
alltså att få rdbms:en att springa igenom den stora tabellen _en
enda gång_ och summera ihop relevant data.
Hur jag än formulerar dethär i vanlig sql (även med en massa
hints) resulterar det i att rdbms:en springer framlänges och
baklänges, grupperar och sorterar och gör allehanda jobbiga saker
i dendär stora tabellen. Det tar inte en timme, som det skulle
göra i idealfallet, utan flera dygn. Svårt att få in i
körschemat!
I dethär läget är jag rökt, och måste fråga nån som gått de relevanta
oracle-kurserna eller som råkat snappa upp den relevanta voodoo som
behövs för att få databasen att göra det man vill att den skall
göra. Det brukar vara nån oraclespecifik secret sauce som inte går att
läsa sig till. Det är inte alltid det finns nån på plats som klarar
att svara på frågan. Det är inte ens säkert att konsulter inkallade
från oracle alltid kan lösa problemet (inte ett såhär enkelt exempel,
men samma typ av problem i en mycket mer komplex kontext). Isåfall får
man antingen leva med plågan eller riva allting och skriva om frågan
som pl/sql.
Fall 2) brukar jag råka ut för när jag skall summera/gruppera ihop
djupt nästlade grunkor med en massa subqueries, subsubqueries osv och
lite olika ranges, och lite olika förekomster av null på olika ställen
i tabellerna ifråga.  Jag brukar hamna i att jag vill referera i
wherevillkoren till nån aggregatkolumn som jag namngivit med "select
... as" en eller några våningar upp (eller till en annan subquery?,
kommer inte ihåg), men det går inte; det finns ingenting som heter
så. Sen provar jag att formulera om på några olika vis ett tag tills
det är dags att besöka experten. Som skriver om frågan till
oigenkännlighet: svaret på problemet är _inte_ att uttrycka sig på ett
listigt abstrakt vis utan att mycket mer konkret specificera hur
rdbms:en skall traversera tabellerna ifråga.
Sen kan jag se ett problem till med sql, och det är att man är
hänvisad till proprietär syntax om man skulle vilja modellera ett träd
eller en hierarkisk graf av något slag. Dock har jag inte träffat på
nåt sånt problem i verkligheten nån gång; sällan eller aldrig drabbas
nog en dba eller en sqldatabasdesigner av insikten att nånting
lämpligen modelleras som ett träd. Om man själv designade en databas
skulle nog risken föreligga att man skulle vilja ha nåt data
trädstrukturerat.
Jag undrar om någon omformulering av sql i python eller lispsyntax som
sedan trollas om till SQL hjälper mot 1 eller 2 ovan.
Skulle jag behöva skriva kod som bökade med en befintlig sqldatabas
kanske det vore vits med nåt sorts mappningslager. Kommer inte ihåg om
Dan Weinreb sagt nåt om hur dom gör på ITA (dom kör oracle i botten),
det kanske går att googla fram.
Jag tänker använda nån enkel objektdatabas (persistenta clos-klasser)
för mitt pågående enkla lisphack och nöjer mig med att skriva lispkod
istället för att formulera queries i nåt frågespråk. Skulle det bli
aktuellt att skriva invecklade frågor mot en databas i nåt eget
projekt nån gång skulle jag tjacka lispworks enterprise och skriva
frågorna i prolog. Men det skulle behöva vara på ett lite större
projekt, kostar trettifem lax. Kan inte nån ta och fixa till en bra,
fri prologkoppling ovanpå persistent clos? Cristophe Rhodes har
snyggat till Norvigs prolog från PAIP, kan inte nån skriva lite
debuggers, optimerare och sånt som man antagligen behöver om man skall
utföra riktigt arbete med en sån? Snälla?
Kolla Franz' prolog ovanpå allegrocache för vad som vore optimalt att
jobba med som databas. kostar tyvär $$$. (antagligen mycket mer än
lispwork enterprise, deras priser är en förhandlingsfråga).
--micke
_______________________________________________
Lisp mailing list
http://mailman.nocrew.org/cgi-bin/mailman/listinfo/lisp
Mikael Jansson
2009-10-30 15:55:43 UTC
Permalink
Raw Message
Post by Mathias Dahl
Har läst lite om Prolog (i PAIP) och RDF som tangerar det (väl?) och
lockas av hur dynamiskt det är men jag skulle gissa att det straffar
sig i form av dålig prestanda och/eller minneskrävande system om man
vill göra saker som passar bra i ett RDBMS. Am I right? Annars hade
Normalisering är inte alltid av ondo, så just av prestandaskäl tror jag
definitivt att du kan få ut något som ofta räcker (eller överträffar)
det du behöver, från triplar.

-- Mikael

Loading...