devel.cz

ODBC mělo ze začátku obrovské ambice. Mělo sjednotit přístup k datovým zdrojům.

1. Počínaje .CSV a .XLS pro které měl driver obsahovat celý "zbrusu nový" engine.
2. Přes .DBF a další lokální db kde se mělo spolupracovat s proprientárními vlastnostmi (indexy, ...) těchto souborových db.
3. Konče serverovými SQL databázemi, kde se měl provádět SQL překlad.
   Taková práce je ovšem obrovská a pokud akceptujeme, že se vlastnosti db enginů mění (zlepšují) tak i nekonečná. Podle mě si ukousli větší koláč než na který stačili.

Na druhou stranu je potřeba se na vznik ODBC podívat tehdejší perspektivou, tj. perspektivou vzniku Win. Před vznikem Win. byl jeden z hlavních problémů při psaní programu tisk. Ke každému (DOSovému) programu, který měl tisknout bylo potřeba vytvořit drivery na všechny tiskárny na kterých měl mít možnost tisknout. Což bylo dost šílené. Pak přišly Win., MS udělal pár jednoduchých driverů (v grafickém režimu a pomalých) nicméně i to byl pro programátory obrovský pokrok. Načež se MS podařilo, že si drivery pro Win začaly vytvářet jednotliví výrobci tiskáren, protože si tím konkurovali čí tiskárna je lepší (rychlejší atd...). To byla pro MS obrovská výhra neboť vlastně definovat standart, tvůrci aplikací a tiskáren jej akceptovali a zákazníci si prostě Win (jehož byl standart součástí) museli koupit.

V ODBC driverech se MS (který za nimi hlavně v začátku stál) pokusil o něco podobného. Pokusili se oddělit db engine a aplikační formuláře s tím, že by komunikovaly přes nějakou jejich vrstvu. Napsali pár jednoduchých driverů a ukazovali jak "hromadná korespondence" ve Wordu funguje pro malý počet záznamů v Excelu, pro větší počet z dat v .dbf a pro největší z nějakého SQL serveru.
Jenomže teorie, že někdo bude psát třeba účetnictví na ODBC driver a zákazník co má 100 faktur pojede na .CSV, co jich má 1000 pojede na .DBF (či access, paradox) a kdo jich má 100.000 pojede na SQL serveru se ukázala jako úplná blbost. Ono totiž účetnictví pro 100.000 faktur vypadá o dost jinak než účetnictví na 100 faktur.
Jako první to asi pochopili výrobci SW kteří stále psali pro konkrétní db. Výrobci db enginů se tedy do vylepšovaní MS driverů nijak extra nehrnuli a ty získaly pověst pomalých. MS zřejmě zkusil podpořit (hlavně znalostmi, certifikáty atd...) nějaké "třetí firmy", které psaly ODBC drivery a prodávaly je. Ale zájem nebyl nijak převratný a velká část z nich zanikla.
Pak tomu sice trochu vdechla život java a JDBC, jenomže naopak praktické používání ODBC/JDBC vedlo k rozbití standartu na jednotlivé databázové dialekty (aby se využili všechny funkce db enginu), takže původní idea stejné komunikace s jakýmkoliv zdrojem se v podstatě rozpadla.

Podle mě je to špatně navržená technologie, protože praxe ukázala, že rozdělení vrstev neodpovídá požadavkům praxe. Aplikační požadavky jsou více databázově závislé než se očekávalo. To, ale asi ze začátku nikdo nemohl tušit. To jak jsou aplikační požadavky databázově specifické nakonec korunoval SAP, který si vytvořil vlastní db. Navíc formuláře se připojují k aplikačnímu serveru, nikoliv k databázovému.
Ale to, že by ODBC nesloží k tomu k čemu bylo navržené neznamená, že by bylo nepoužitelné. Třeba noční čerpání dat mezi apliakcemi přes ODBC bych nezavrhoval. A pokud je celý řetěz (db engine, ODBC, formulářový klient) od jednoho výrobce, který jej aktivně ladí tak to taky snad bude fungovat ok.
Ale původní představa univerzálního skládání aplikací z libovolného databázového a "zásobníku formulářů" serveru spojeného přes ODBC je podle mě totálně chcíplá.