Relační nebo NoSQL databáze

Dejme tomu že chci udělat něco jako booking.com. Spousta podobných ale ne zcela stejných nabídek, s různými různě komplexními parametry. Kdybyste to měli navrhovat od nuly, volíte radši relační nebo NoSQL databázi? Případně kombinaci obojího? Ještě předpokládejme že performance není problém, ale je potřeba zohlednit složitost návrhu databáze a hlavně udržitelnost kódu. Za mě, NoSQL je lákavá, můžu tam nahrnout co chci a moc to předem neřešit. Ale moc si neumím představit jak se to potom bude udržovat, a jak udržet kód natolik robustní, aby si poradil s volně definovaným datovým modelem. Díky za podněty.

B pouziva RocksDB, v tvem pripade bych zacal treba s Elasticsearch, ale ten nezvladne prichozi husty objem update tzv. availability.Ale tak zalezi kolik toho budes mit, 1000 zaznamu * 3 typy pokoju nebo vice?

ak ide o vztahy tak najskor budes potrebovat grafovu databazu. sql a nosql je len o tom ze pri sql potrebujes vediet strukturu objektov dopredu a tusim nosql ma nejake "problemy" s transakciami(neviem, nikdy som nosql nemal potrebu pouzit).grafova databaza je dobra prave na to ze sa mozes pytat na otazky ktore si dopredu nevedel. cize napriklad pridas nejaky novy atribut podla ktoreho sa ma vyhladavat a zrazu zistis ze cela "sql" schema je na nic lebo su tam problematicke prepojenia a vztahy. grafova databaza presne toto riesi.taky standard je neo4j ktora vsak tusim nema podporu clusteru a fici na jave(hw narocnost). takze skor by som odporucil dgraph ktora navyse podporuje grapgql ktory moze byt zo zaciatku tazsie zmaknut ale dava viac flexibility ohladom dopytov a vytahovania dat.PS: aby bolo jasne, do grafovej db nedavas vsetko, len vztahy. cize pre data storage, ak nepoznas schemu dopredu, daj nosql, ale synchronizuj do grafovej databaze aktualizacie a vyhladavaj v nej.

Soustřeď se na byznys logiku a začni relační databází, k tomu máš nástroje a oporu, jakmile to přestane stačit (zejména výkonově), můžeš snadno migrovat (opačně migrovat již snadno nejde). Relační databáze postrádá většinou elementární kontrolní mechanismy (konzistence, integrita, transakčnost, rollback). Psát polymorfní aplikace, které rozumí staré, nové struktuře, které mají auto healing dat a vlastní data quality kontroly znamená míchat byznysovou logiku s tou infrastrukturní, znamená daleko vyšší náklady právě na vývoj nebo v na opačné straně příliš vysokou chybovost. Takové aplikace mají malou životnost a málokdy se podaří je udržovat funkční více let při neustálém vývoji.Grafová databáze není nic jiného než strašně dlouhý index s paralelním zpracováním takového stromu, viděl jsem v ČR minimum projektů, které jsou rychlejší a levnější na grafové databázi než na klasické relační.Nerelační databáze ti obecně poskytují velice rychlou první verzi aplikace a lineární škálování s dobrou replikací na více serverů. Jakýkoliv ale další a postupný rozvoj a interativní změny struktur přináší obrovské náklady proti relačním databázím s DDL modely. Klidně si prove of concept napiš nad mongem, sqlite, redisem, budeš v rychle cíli a ověříš si předpoklady, ale hned poté to přepiš tak, abys to měl stabilní i pro další rozvoj.Živým se právě implementováním do praxe těhle nových super cool databází, zpravidla nastapuji v momentě, kdy již sama firma v tom selhala a potřebuje někoho, kdo jí s tím pomůže a napraví křivdy. Vidím kolik to přináší problémů a práce navíc, kolik nových technologií se musí from scratch naprogramovat. Dokud máš velikost dat v jednotkách TB nebo hodnost atributů do desítek miliard, relační databáze bude pořád lepší volba, jakmile tyhle hodnoty překročíš již začínají být nové typy přístupu k datům vhodnější.

Díky za odpovědi, tak nějak to zapadá do toho co si myslím (možná confirmation bias, ale co se dá dělat :)). Takže sbohem Mongo, ať žije SQL Server.

Za mě rozhodně relační DB. Jak píše TomášX, nerelační dává smysl jen ve specifickém použití s hodně velkými objemy, na které se při rozjíždění nového projektu nejsi schopný dostat. Druhá věc je, že pokud to myslíš s podnikáním vážně a opravdu se ti to rozroste, bude tě kromě běhu zajímat i analytická část, reporting pro rozvoj budeš potřebovat aby ses rozhodoval na základě racionálních rozhodnutí vycházejících z čísel. Možná mě TomášX opraví, ale osobně jsem se zatím setkal s robustími nástroji jen v souvislosti s relačními databázemi, protože cokoliv analyzovat, nebo strukturálně měnit u nerelační databáze je peklo a často i výkonové peklo. V PowerBi moc nevím jak bych to dělal v Google Data Studio sice existuje postup jak napojit data z Mongo, ale reálně jsem s tím nepracoval a netuším kolik zádrhelů tam může nastat.