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 2009/10/29 Micke Karlsson <mi...@mikadako.com>: > > 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 > _______________________________________________ Lisp mailing list Lisp@lisp.se http://mailman.nocrew.org/cgi-bin/mailman/listinfo/lisp
