Hlavní navigace

Názor k článku Michal Illich: IT vzdělání získáte praxí od ivs - > K te historii - SQL nevzniklo jako...

Článek je starý, nové názory již nelze přidávat.

  • 29. 11. 2004 14:18

    ivs (neregistrovaný)
    > K te historii - SQL nevzniklo jako fundamentalni odpoved na reseni pristupu k datum v nejake databazi nybrz jako INTERAKTIVNI dotazovaci jazyk pro bankovni pracovniky.

    SQL je "lidstejsi" zapis veci z relacni algebry databazi (pokud tedy vezmeme jen jadro SQL, bez procedur apod.), coz je fundamentalni podstata relacnich databazi. O notaci se muzeme dohadovat, nerikam, ze nic lepsiho nez SQL nemuze byt, dokonce se pouzivaji i jine notace, nicmene na principu relacnich databazi to nic nemeni. Stojim si za tim, ze pro nektere veci (a neni jich malo) jsou relacni databaze velmi vhodne, a pak urcite stoji zato pouzivat SQL.

    > uspesnost systemu - zde se hovori o komlexnich systemech a ne o nejakem primitivnim webu. A me nejsou znamy takove uspesne systemy.

    Priznavam, ze s bankami zkusenost nemam, ale na pomerne slozitem systemu (integrace pozadavku a navrhu z ruznych oblasti, programatori ze tri kontinentu) jsem pracoval. Vespodu bylo SQL, kupodivu to neznamenalo zadne problemy pro vyssi vrstvy - prave diky striktnimu oddeleni. Objektovy interface do datove vrstvy se po pocatecni stabilizaci menil jen po explicitnim souhlasu vsech, a prestoze se ta nejnizsi vrstva nekolikrat zmenila kvuli optimalizaci, nebyl to pro ty vyssi vrstvy zadny problem. Tj. databaze plnila svuj ucel, SQL pro to bylo vhodne, a nikdo si nestezoval, ze by bylo k nicemu.

    O primitivnim webu se asi nebudeme dohadovat - tam jak vidim sam uznavate, ze neplati, ze je SQL k nicemu (a zde se hovori o tom, proc je ci neni SQL k nicemu).

    > Znam ovsem projekty, kde je na pozadi nejaka relacni databaze ale v systemu se nepouziva zadny SQL statement

    a co se tedy pouziva pro rozhrani do teto relacni databaze?

    > deklarativni jazyky - problemy vznikle soucasnym pouzitim techto prostredku s imperativnimi se nazyva bezne "impedance mismatch" - v literature buhuzel casto zuzen na problematiku zobrazeni realneho sveta na relacni model.

    tohle moc nechapu - impedance mismatch se tyka problemu relacnich databazi v objektove orientovanych systemech. Ano, to je samozrejme problem - relacni a objektovy pristup je jiny, a pri spatnem oddeleni vrstev systemu to vede k problemum, ktere popisujete.

    Nechapu ale moc, jak to souvisi s deklarativnimi jazyky. OO jazyky nemusi byt deklarativni (a ty nejznamejsi nejsou). Jinak ja deklarativni jazyky pouzivam na nektere veci rad, a myslim si, ze jsou pro udrzbu lepsi nez imperativni jazyky.
    SQL je pro system brzda asi podobna tomu, ze deklarativni jazyk nakonec prece jen musi zavolat API systemu, aby se s uzivatelem domluvil.
    (Jak to rikal Dijsktra s temi vrstvami? :-))

    > Laicky by se dalo rici, ze "deklarativni systemy" potrebuju ke svemu zivotu UPLNOU znalost pravidel systemu, ve kterem funguji. To je ale v rozporu s principem modularity (information hiding), kde je dulezite, aby moduly existovaly samotne se vsim vsudy.

    Tohle ale vubec neni pravda. Deklarativni systemy se pouzivaji prave proto, ze nepotrebuji uplnou znalost pravidel systemu! (jako je v proceduralnich systemech, zejmena tech nepouzivajicich ani OO pristup, kdyz uz nic jineho).

    > V nejakem informacnim systemu je treba zjistit mnozstvi zbozi na sklade. V SQL-sytemech je to reseno tak, ze podle predem stanovenych pravidel se odsadi nejaky SELECT eventuelne se SUBSELECTY v nejake UNION apod.

    Ano, ve spatne navrzenem systemu to bude presne tak, jak popisujete. V dobre navrzenem systemu zalozenem na SQL se pouziji takzvane pohledy (VIEW), tj. budeme mit ono information hiding, ktere zminujete, bez ohledu na to, jak se v budoucnu zmeni tabulky v databazi. Kdyz se zmeni, je samozrejme treba upravit interface, ale uz nic nad tim - tj. pri zmene modulu nemusim menit nic jineho.

    > To je take duvod, proc se takove systemy realizuji v PROJEKTECH. To ze je SQL k nicemu by se zjistilo okamzite, kdyby nekdo zkusil takovy projekt realizovat oddelene.

    Duvod je ve spatnem navrhu - pokud neni nekdo schopen napsat stabilni modul, ktery interne SQL pouzije, pripadne nedava ven vse (pouziva treba VIEW), pak samozrejme nezbyva nez resit problem projektove (tj. po skonceni projektu nebo po odejiti nekolika programatoru muze zacit misto udrzby dalsi projekt, ktery totez resi znovu).
    Ovsem tato neschopnost nedava duvod k tvrzeni, ze SQL je k nicemu.

    Mimochodem, dekuji za Vasi reakci - myslel jsem, ze neodpovite. Docela by me zajimala odpoved na otazku vyse - tj. co misto SQL pouzivate k pristupu k relacnim databazim.