Objektové databáze
Hitem posledních let (a tak trochu buzzwordem, podobně jako HTML5) jsou tzv. NoSQL databáze, tedy databáze, které nejsou relační. Relační databáze mají mnoho užitečných vlastností (proto jsou ostatně nejrozšířenější), ale občas se hodí i jiný způsob práce se strukturovanými daty. Zastánci NoSQL databází vyzdvihují například jejich škálovatelnost. Pro obrovské objemy dat je využívají společnosti jako Google, Amazon apod.
Podtypem NoSQL databází jsou databáze objektové. Mají rozhraní pro objektově orientované jazyky a ukládají transparentně celé hierarchie objektů. Pro programátora se chovají podobně jako ORM (ukládání objektů do relačních databází), ovšem bez potřeby psát anotace do kódu nebo bokem do XML.
Je zřejmé, že pro rozumnou funkčnost musí použitý jazyk podporovat introspekci objektů a ideálně také přístup k AST kódu (alespoň u výrazů a podmínek). Jednou z nejrozšířenějších objektových databází je db4objects (zkráceně db4o). Její vývoj běží už deset let a je k dispozici ve verzích pro Javu a C#. Její použití ve velmi jednoduché. Databázi otevřeme jedním řádkem:
ObjectContainer db = Db4o.openFile("test.db")
Rovněž jediným řádkem uložíme objekt:
db.set(person); Dotazy do databáze lze specifikovat nativně. Celý koncept se jmenuje „native queries“ (případně „safe queries“) a spočívá ve způsobu zápisu dotazu. Místo řetězce (jako v SQL), ve kterém nám překladač neodhalí syntaktické nesrovnalosti ani překlepy v názvech tabulek a atributů, se používá přímo konstrukce daného jazyka, tedy např. lambda výrazy v C# nebo vnořené anonymní třídy v Javě:
List<Person> people = db.query(new Predicate<Person>() {
public boolean match(Person person) {
return person.getAge() == 30;
}
})
Tento kód vrátí seznam všech osob v databázi (instancí třídy Person), jejichž věk je 30 let. Na první pohled se může zdát, že třída Predicate a její metoda match je použita na každý objekt v databázi jako filtr. Takové sekvenční zpracování by samozřejmě bylo obecně nepoužitelné. Db4o je ale mnohem chytřejší. Kód v metodě match nevyhodnocuje, ale analyzuje. Z výrazu za return vytvoří syntaktický strom (podobně jako překladač, ovšem v tomto případě nemá databáze k dispozici zdrojový kód a musí pracovat s mezikódem), který následně použije pro vyhledání objektů podle indexů, jež fungují zcela stejně jako indexy v relačních databázích. Výhody tohoto postupu jsou zřejmé: programátor se nemusí učit další jazyk (např. SQL nebo OQL), ale pracuje jen v jednom jazyku, v němž píše zbytek kódu. Navíc při překladu dochází ke kontrole jmen tříd a atributů. Lze využít automatické doplňování (IntelliSense pro C#). Kód lze automaticky refaktorovat. A tak dále…
Objektové databáze mají dlouhou historii, ty nejstarší vznikaly pro Smalltalk v rámci výzkumných projektů. Později se jich několik objevilo pro C++ a v poslední době pro spravované (managed) jazyky (Java, C#) a některé dynamické. Poslední vývoj přináší nativní dotazy také do C++.
-
Související články na blogu Zmatení (programovacích) jazyků
-
Databáze a C++: najdete řešení? 14. 9. 2013 13:03
-
Objektová databáze pro C++/CX 19. 10. 2011 10:55
-
-
Hynek (Pichi) Vychodil (neregistrovaný)
Označit objektové databáze za NoSQL podtyp by mě nenapadlo ani omylem. Na škále SQL a NoSQL (dynamo, bigtable, CouchDB, MongoDB, etc.) jsou objektové databáze na opačné straně od SQL. Objektové databáze jsou mnohem více "relační" než klasické SQL databáze což se mimo jiné projevuje právě na jejich škálovatelnosti.
-
PH (neregistrovaný)
@2 Objektové databáze (předpokládám, že nikdo není takový trotl, aby za objektovou databázi označil ORM nad relačním DBMS) jsou stejně NoSQL jako databáze dokumentové, grafové, key-value-stores apod. Jako posledně jmenované také objektové databáze škálují. Doporučuji přečíst si nějaký úvod do databází, případně i nakouknutí do kódu (db4o je open source).
-
valinor (neregistrovaný)
@2 Že objektové databáze jsou víc relační než relační databáze - LOL. Tak nějak by vypadal náhled manažera se špičatými vlasy, který někde letmo zahlédl popisný obrázek o databázích :) Kromě toho bych poznamenal, že objektové databáze zažívaly první boom v době kdy zažíval boom celý objektový přístup - od analýzy, přes jazyka až po databáze. Jen aby si někdo nemyslel, že objektové databáze jsou nějaký převratný nový objev ;)
-
wdolek (neregistrovaný)
[3] [4] Vidite, a ja si vzdy myslel, ze objektove db jsou "vyspelejsi" databaze (co se zpusobu relacnich dat tyce), a NoSQL jsem vzdy povazoval za jednodussi lepe skalovatelne hracicky.
Samozrejme, kdyz na to budu koukat jako na NoSQL - ano, do db ukladam "dokument" - tedy objekt, ktery ma pak v sobe kdo vi co. Z programatorskeho hlediska na to ale koukam jako na ukazatele do pameti - tedy relace.
Ve Smalltalku mohu napriklad pracovat s libovolnou urovni instanci objektu, vselijak se zanorovat a pracovat s ostatnimi objekty. V NoSQL mam klic k zaznamu, ale nejak si nedovedu predstavit, jak bych z klice vytahnul treti uroven objektu a jeste s podminkou porovnavajici s objektem nekde jinde.NoSQL se pak daji z vesela skalovat, rozkladat a skladat do clusteru... U objektovych databazi jsem zatim nic takoveho nepotkal. Nevim presne, jak db4o pracuje, ale... lze nejak smysluplne bez nakladne rezie kolem vytvorit clustery pro objektove databaze?
Rad se necemu naucim, vyvedte me z meho omylu... (Doufam, ze to necte muj byvaly profesor na ODBMS)
-
wdolek (neregistrovaný)
[6] Modelova situace:
- clanek, odkazuje na kategorii a autora
- kategorie, jedna kategorie pro vice clanku
- pisalek, vice clanku od jednoho autoraKdyz pracuji s instancemi objektu, co je ten "odkaz" z clanku na autora? To je snad ukazatel nekam do pameti, kde sidli instance odkazovaneho objektu, neni liz pravda... ?
U NoSQL databaze bych mohl udelat:
a) ulozit to cele, takze budu ukladat neco, co je jiz ulozene (kategorie, pisalek) - pri zmene jmena autora pak budu muset provest zmenu u vsech zaznamu clanku
b) ukladat klic k hodnote a "nasimulovat" si tak relaci - takze proc bych vlastne neco takoveho delal v NoSQL?U relacni databaze si pomuzu IDcky a vzdalenymi klici. U objektove databaze bych ocekaval, ze z databaze vytahnu instanci clanku (podle nejakych kriterii) a automaticky k tomu dostanu instanci kategorie a pisalka (v pripade pozadavku na tyto vlastnosti, ktere jsou v aplikaci (psane v Jave, C#, C++, ...) proste ukazatelem jinam).
Kazdopadne tak jako tak, reagoval jsem na vytku od PH a valinor, ze ODBMS jsou blizsi NoSQL. Vzdy jsem mel ODBMS zafixovane na nejvyssim evolucnim zebricku (byt stale s nedostatky), pak RDBMS a uplne vespod vyhypovane NoSQL.
-
Tomáš Vondra (neregistrovaný)
wlodek: Autoři předchozích komentářů se vám snažili naznačit že "relační" databáze jsou za relační označovány proto že tabulka je obdoba pojmu relace z relační algebry, tj. podmnožiny kartézského součinu. Nikoliv proto že v nich lze prostřednictvím cizích klíčů zachycovat vztahy mezi daty v různých tabulkách. To se mimochodem v angličtině neoznačuje jako "relation" ale "relationship".
Kdybych chtěl, mohu si jakési cizí klíče implementovat i v databázích které jsou nerelační (např. na úrovni column families v Cassandře apod.).
zboj
Autor se zabývá vývojem kompilátorů a knihoven pro objektově-orientované programovací jazyky.
Nejčtenější články autora
-
Co zlepšit na českých VŠ?
Přečteno 35 878×
-
Potřebují programátoři VŠ?
Přečteno 25 101×
-
Proč je Java za zenitem
Přečteno 23 535×
-
Jaký jazyk jako první?
Přečteno 19 981×
-
Potřebujeme vynikající programátory?
Přečteno 17 304×
Poslední názory
-
\
Re: Jaký jazyk jako první?
ke článku Jaký jazyk jako první? -
\
Re: Potřebujeme vynikající programátory?
ke článku Potřebujeme vynikající programátory? -
\
Re: Typy programátorů
ke článku Typy programátorů -
\
Re: Potřebují programátoři VŠ?
ke článku Potřebují programátoři VŠ? -
\
Re: Nerozumím...
ke článku Nerozumím...
