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
_______________________________________________
Lisp mailing list
Lisp@lisp.se
http://mailman.nocrew.org/cgi-bin/mailman/listinfo/lisp
