Državni sektor ne koristi nikakve baze podataka, tamo rade nepismeni koji su kupili diplome na državnim univerzitetima. Oni ne umeju ni da uključe kompjuter, šta njima znači referencijalni integritet.

Privatni i državni sektor su kao jing i jang. U svakom državnom sektoru ima bar malo privatnog i u svakom privatnom ima bar malo državnog. Iako su na suprotnim stranama samo zajedno čine celinu. Imaju mnogo toga zajedničkog. I jedan i drugi čine sebični i pohlepni ljudi. Njihovo različito ponašanje je uslovljeno različitim pravilima igre koja važe u ovim sektorima. Državni sektor je rigidna i glomazna mašinerija koja melje sve pred sobom. Takvoj mašineriji baš odgovaraju relacione baze podataka. Jedna naša prijateljska država ima izreku "Smrt i porez", što je možda i najbolja definicija državnog sektora. Prvi računari su nastali baš za potrebe državnog sektora, prvo popis stanovništa (smrt), onda porezi (porez), pa ratovi (opet smrt) itd... Privatni sektor ima računare samo zato što je državni sektor shvatio da može više poreza da ubere ako dozvoli i privatnom sektoru da ih koristi. Pomodni sektor koristi dokument, ključ-vrednost i ostele NoSql hype baze tamo gde im nije mesto. Međutim, čini mi se da graf baze nisu samo pomodarstvo. One imaju snažnu osnovu u matematici, kao i relacione. Mislim da bi mogle da budu dobra alternativa relacionim bazama u privatnom sektoru. Privatni sektor je jedno dinamično okruženje koje mora stalno da se prilagođava pravilima i zamkama koje nameće državni. Rigidna šema modela podataka nije tako dobra u tom slučaju jer ne može dovoljno brzo da isprati promene. Za razliku od relacinog modela, struktura graf baza je bezšemna, odnosno šema je definisana samim podacima. Veze između čvorova mogu da se dodaju veoma jednostavno, a određene klase upita koje zahtevaju veliki broj JOIN-a kod relacionih baza, graf baze rešavaju na jednostavan i efikasan način. Zanima me šta privatni sektor misli o graf bazama, da li ih koristi i u kojoj meri?

Mi u privatnom sektoru ne mislimo, ima ko je plaćen za to. Mi smo tu da radimo i stvaramo, za sebe, ali i za ove lopove iz državnog sektora.

To je lepo.

Nadao sam se da će tema skrenuti u offtopic i da ćeš reći nešto o grafovima. Delovalo mi je da je to tvoja oblast, ali moguće da sam te pomešao sa onim drugim Bradzorfom.

Hm grafovi, to beše ono, graf je uređena dvojka (V, E) gde je V skup svih čvorova, a E skup ivica grafa. Orijentisani i neorijentisani, Hamiltonovi itdisl. Ma koga u privatnom sektoru briga za grafove, time se više ni četnici ne bave. Samo oni glupi komunisti, ali doći će i njima kraj.

Sa verom u boga za kralja i otađbinu.

Za koju klasu problema je graf baza bolja od relacione baze?
Pretpostavljam da to treba nekom ko previse zvralja seme na tabli..

Treba komunjarama i ovima iz državnog sektora.

Boj ne bije srce u junaka, već boj bije svijetlo oružje.

Na primer za upit poput: daj mi listu prijatelja sa kojima imam zajedničke prijatelje.

Što se tiče žvrljanja dijagrama, to se ne može izbeći. Pitanje je samo da li je bolje dijagrame realizovati preko unapred definisanih tabela i primarnih i stranih ključeva ili grafova koji omogućavaju dinamičko kreiranje novih veza.

Nisam koristio graf baze. Razmišljao sam nešto u tom pravcu dok još uvek nisu bile popularne. Tehnologija polako dostiže zrelost, tako da mislim da je sada pravo vreme za razmatranje ovih baza.

Neke od popularnih baza su:

https://neo4j.com/
https://dgraph.io/
https://janusgraph.org/
https://orientdb.org/
https://www.arangodb.com/
https://github.com/cayleygraph/cayley - može da koristi relacionu bazu kao bekend (PostgreSQL, CockroachDB, MySQL, SQLite)


2018 je godina graf baza, evo i zašto

Ignorisacu da je ovo MadZone, pa cu probati da ti odgovorim koliko mogu... ;) (Imam NDA ovo je forum):

Graph baze su napravljene da resavaju probleme, sto neko rece, "koliko imam prijatelja i prijatelja prijatelja". Cela ta fora sa indexima unutar noda omogucava da u odnosu na relacione baze, koristis pretragu po dubini graph-a - a ne brdo LEFT JOIN upita. Ovo je jako efikasno ako imas nekoliko velikih tabela (milioni slogova) i nekoliko n-n relacija izmedju njih (again, milioni relacija), gde jedan slog sam po sebi ima nekoliko relacija, ali zato ukupni broj relacija bude veliki.

Nije dobro resenje da zameni EAV model. Vrlo je zanimljivo resenje za recomendation sisteme i natural language procesing.... Tipa, kad te hoces interakciju sa klijentom koji trazi nesto povezano sa necim....

Ako ce pomoci, pogledaj ovo:

https://neo4j.com/developer/graph-db-vs-rdbms/

Na jednom projektu sam podizao komercijalni Neo4J, prebacili su neke sulude upite sa baze na njega, bas je pomoglo da se rastereti ceo sistem. Jednostavno, fora je da kad pises node, odma upises i brdo date sa njim - i onda time ubrzavas citanje. Dodatno, time sto pises indexe na istom mestu ubrzavas i pisanje, u poredjenju sa update-om index-a na milionskim tabelama. Mane su sto je pisanje rasuto, sto je bio problem pre SSD-ova i mana je sto pises vise date po disku.

nkrgovic

Rekao bih da ste Zurg i ti dali dobro objašnjenje, što mi govori da niste komunisti i ne radite u privatnom sektoru, što je za svaku pohvalu.

Ako dozvoljavate, koliko se ja razumem u sir i vojnu muziku, priroda problema koji rešavaju ove baze je takva da tu i ne moramo imati mnogo podataka, već mnogo relacija među njima. Sa hiljadu dve slogova je moguće imati veliki broj relacija koje nije lako obraditi u nekom standardnom sql modelu.

Hm, u svakom slučaju, ne bi bilo loše navesti neki primer, da zavirimo ispod haube.

Ever:"Na primer za upit poput: daj mi listu prijatelja sa kojima imam zajedničke prijatelje. "

Ovo je problem SQL-a. Programski bez sql-a ovo se lako resi jednim fajlom koji uparuje prijatelje i kvadratnim algoritmom.
Iz glave tesko da bih napravio SQL pogotovo sto ne znam kako da napravim presek dva skupa rezultata select upita.

Nikola:"Graph baze su napravljene da resavaju probleme, sto neko rece, "koliko imam prijatelja i prijatelja prijatelja". Cela ta fora sa indexima unutar noda omogucava da u odnosu na relacione baze, koristis pretragu po dubini graph-a - a ne brdo LEFT JOIN upita."

Koji query jezik koriste, meni se cini da je pre ovo nedostatak SQL-a nego strukture baze. Recimo da bi se izrazile sve kombinacije prijatelja nije potrebno vise od jedne tabele.

Mislim da graf baze odgovaraju za manji data set sa kompleksnim relacijama, od oka.

Prateći temu i sam sam se zapitao šta je bolje/pogodnije
graf ili relacionine baze podataka?

I tako, nakon više od dva sata razmatranja
zatekao sam se kako se bavim analitičkom geometrijom crtajući hiperbole.

Ne pitajte me zašto sam zbog ovako važne teme ustao jutros u 5 (sad je već 20 do 8)
ni kako sam od baza podataka došao do glatkih krivih i bijekcija.

Napisaću samo da zaključujem da su graf i relacione baze podataka medjusobno elvivalentne
a da odluka o tome šta je pogodnije zavisi od predznanja i potreba krajnjeg korisnika.


Idem sad do kladionica u Novom Sadu da vidim kolika je kvota na Djokovića.

SQL je u stvari "sintaksni šećer" preko relacione algebre. Da bi ovo rešio neophodno je spajanje tabele sa samom sobom i to jeste uslovljeno strukturom. Inače, mislim da je SQL fenomenalna stvar.

Graf baze, za razliku od relacionih, imaju više jezika upita. Ja sam uspeo da izguglam Cypher, Gremlin i GraphQL, a pored toga skoro svaka baza ima i/ili neku svoju varijantu jezika upita.

Cypher upit za nalaženje zajedničkih prijatelja:



https://developer.ibm.com/dwbl...raph-database-query-languages/

Ne znam Cypher, ali kod mi je na prvi pogled jasan.

Mislim da se graph baze koriste za "big data", a ne samo za mali broj čvorova sa velikim brojem veza.