Vlákno názorů k článku Markus Winand: SQL Performance Explained od SB - Ono by možná pro zrychlení či odstranění některých...

Prostě se použije něco, co je prověřené a funguje to. Třeba u mě v telefonu, seznam kontaktů, který je v relaci na seznamy hovorů a SMS. Ony se RD dají vždy nějak ohnout, aby zadaný úkol splnily.

Pokud bude takováto DB součástí systému, pak ji mohou aplikace (a vývojáři rádi) používat. Předimenzování bych viděl jinde, třeba když se k aplikaci typu kniha jízd instaluje 300 MB MS SQL Serveru.

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.

ORM je dneska nutnost. Kdyz mate slozitejsi datovy model - rekneme 500 tabulek tak se v tom hrabat rucne pokud to neni performance critical cast je nesmysl.

JPQL je mor.

Ja mam na mysli criteria query api

http://www.ibm.com/developerworks/java/library/j-typesafejpa/

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.