Ono by možná pro zrychlení či odstranění některých problémů úplně stačilo použít něco jiného než relační databázi (dále jen RD).
Je ironií, že autor píše o fixaci na jednu technologii, ale přitom se sám fixuje na RD se SQL. RD se používají na každou pičovinu, přičemž většina reálných dat nemá vůbec povahu relací, takže nutně přichází mapování (obvykle na objektový model), ale to něco stojí. A zde pochopitelně přichází kámen úrazu a všichni se velice diví, proč je to pomalé a v potu tváře hledají nejoptimalizovanější maxiselecty, které budou danému db serveru dost dobré.
Nemám nic proti používání věcí, které fungují, ale relační databáze přece nejsou jedinou věcí, která funguje, a pro seznam hovorů a SMS v telefonu jsou předimenzovaným řešením. Problém je v onom nepěkně pojmenovaném procesu „ohýbání“ - ono když se něco moc ohýbá, většinou to pak stojí za hovno (osobní zkušenosti).
V mém seznamu kontaktů mám ke kontaktu uložené jméno a příjmení, u některých pak společnost, narozeniny, výročí, různé e-maily (s rozlišením, který je který), různé telefony (opět s rozlišením), adresy pro instant messaging… A když se objeví nový IM protokol, nová sociální síť nebo jen další využití telefonního čísla, chci si to do kontaktů přidat. Relační databáze se k tomu dá ohnout, ale nejspíš to skončí tak, že si budu moci u telefonu vybrat, zda je to mobil nebo telefon do zaměstnání nebo domů, protože udělat to obecně by s relační databází bylo moc práce.
Vaši argumentaci beru jen napůl - v relační db pro novou sociální síť s jiným formátem (a jinou sémantikou) přidám další relaci - a je to bez jakhokoliv znásilňování - a pokud mám dobře napsanou aplikaci (nebo používám pohledy a procedury), tak taková změna může být i relativně lokální v aplikaci.
Jinak souhlasím, že v document db udělám podobnou úpravu ještě jednodušeji. U relačních databází je důležité mít na začátku dobrý návrh a pak už ho moc neměnit - což pak může mít pozitivní vliv na kvalitu dat (bo jsou stabilní a udržují jakousi štábní kulturu) nebo naopak negativní - když intenzivně potřebujete měnit schéma.
Výhoda relačních SQL db jsou:
* Navrženo pro hromadné operace
* Navrženo pro ad-hoc dotazy - SQL, rychlé operace i bez indexů
* Navrženo pro dlouhodobě udržovaná data (vynucuje si konzistenci)
* Dobrá aplikační podpora (reporty, spreadsheety)
* ACID
Pokud ani jeden z těchto bodů nevyužijete (případně jde proti Vašim požadavkům např. ACID), tak pak pro Vás SQL databáze není ta pravá ořechová, a použijete jinou. Není důvod se tlačit za každou cenu do SQL relační db - před 10 roky tu moc velký výběr nebyl, ale už cca posledních 4, 5 let je relativně široká nabídka db (i O.S. db).
ja budu jedine rad, kdyz se budu vice setkavat s oop db misto desivymi orm systemy, kdyz budou fy pouzivat sloupcove nebo proudove db, pripadne inteligente cache. svet bude barevnejsi :-) na druhou stranu relacni db maji k realite stejne daleko jako oop db nebo sitove db, pokazde pracujete s urcitym modelem, ktery ma svoje vyhody a nevyhody a ktery vyzaduje urcite ohybani a zjednoduseni reality.
JPQL je mor.
Ja mam na mysli criteria query api
http://www.ibm.com/developerworks/java/library/j-typesafejpa/
No, tak důvodem ke vzniku OOP bylo právě připodobnění k realitě, takže je na tom v modelování reality velice dobře, ale to je můj osobní názor. Ale jestliže máte v paměti objektový model (tedy graf) a chcete ho uložit, je asi hovadinou zkoušet ho rozstříhávat na (principiálně nekompatibilní) relace a potom ho zase pracně z relací skládat (bez ohledu na použitelnost dnešních objektových DB), když je možné jej uložit zase jako graf. To se snad shodneme. A kdo někdy v aplikaci ORM používal, ví, co je to za peklo a balast navíc představující nemalou část aplikace.
Relační databáze (relační model) velice efektivně (a šetrně ke zdrojům) dokáže provádět hromadné operace nad velkým množstvím dat. Což byl, podle mne, jeden z důvodů, proč se tyto databáze v 80 a 90 letech tak rychle rozšířily a prakticky zneviditelnily OOP db (a samozřejmě svůj vliv měl i marketing a peníze majoritních dodavatelů SQL serverů).
Aktuálně je pro většinu projektů zdrojí (paměť, CPU, Disc) dost, a tudíž jeden z důvodů (šetrnost využívaní zdrojů) pro relační databáze mizí. I když jak jsme svědky, dodavatelé dokáží vyrobit systémy, které nezvládnou 1000 uživatelů.
Myslím si, že RD tady budou stále - s OOP db nejsou vzájemně zastupitelné.
U objektových databázi bude asi zakopaný pes ve složitosti návrhu. V relační databázi začínám na úrovni jednoduchých tabulek, které se propojí relativně přímočarými vazbami. Vytvořit abstrahovaný model pomocí objektů vyžaduje mnohem víc představivosti. A každá změna návrhu je pak u objektů výrazně složitější. A čas jsou peníze.
RDB pracuje rychle s relacemi, které jsou uložené v jedné či pár tabulkách, v okamžiku, kdy je relace sestavena z mnoha tabulek (typická situace u členitých doménových modelů), jde výkon vlivem spojování tabulek do řiti.
RDB jsou rozšířené, protože začaly nejméně o 10 let dříve než ODB a protože IT má velkou setrvačnost, takže jejich vytlačení do jejich oblasti užití bude nějakou dobu trvat.
Zastupitelné jsou (vizte dnešní stav), ale dře to.
Ze svoje praxi vidim problem nekde jinde. Management se zepta "Ochrani ta vec nase data stejne dobre jako Oracle?" a tim diskuze skonci. ODB jsou tu od toho aby zjednodusily praci programatorum - opravdovy business je tam kde jsou data cenejsi nez lidka prace.
PS: Spojovani mnoha tabulek taky neni problem, dnesni optimalizatory dokazi opravdu hodne.
V puli 90 let bylo kolem oop neskutecne halo, a saturace sql databazemi nebyla tak velka, tudiz byl prostor pro alternativy - OOP bylo vsude, i na systemove urovni, napr remote object, byly i pokusy o OOP DB, napr. GEM ale nikdy se nijak zvlast nerozsirily (patrne kvuli pametivym narokum) ackoliv snaha byla, OOP bylo cool a uz tehdy byly relacni db drobet omsela technologie. Tudiz si nemyslim, ze by dominance sql db byla jen 10 let. naskokem,