Forum » Programiranje » Ne-relacijska baza
Ne-relacijska baza
papasmrk ::
Pozdravljeni,
kot sam naslov pove me zanima ali kdo od vas ima kakšne izkušnje z shranjevanjem podatkov v nerelacijsko bazo. Zanimam se predvsem zato, da bi se naučil tudi kaj novega in to nekako za test uporabil v praksi. Trenutno je pač tako da ko želim nek objekt v programu shranit, ga je potrebno razparcelirat in ga vpisat kot množico recordov v razne tabele. Ker pač izhajam iz SQL generacije me tudi zanima kako izgleda poizvedovanje v ne-relacijski tabeli.
hvala za odgovore
kot sam naslov pove me zanima ali kdo od vas ima kakšne izkušnje z shranjevanjem podatkov v nerelacijsko bazo. Zanimam se predvsem zato, da bi se naučil tudi kaj novega in to nekako za test uporabil v praksi. Trenutno je pač tako da ko želim nek objekt v programu shranit, ga je potrebno razparcelirat in ga vpisat kot množico recordov v razne tabele. Ker pač izhajam iz SQL generacije me tudi zanima kako izgleda poizvedovanje v ne-relacijski tabeli.
hvala za odgovore
680x0 ::
Če bi se rad priučil česa novega, si magari poglej Google App Engine z njihovo Big Table bazo.
Če si prebereš enega od spodnjih tutorialov, si boš odgovoril tudi na svoja vprašanja.
Java - http://code.google.com/intl/sl/appengin...
Python - http://code.google.com/intl/sl/appengin...
Če si prebereš enega od spodnjih tutorialov, si boš odgovoril tudi na svoja vprašanja.
Java - http://code.google.com/intl/sl/appengin...
Python - http://code.google.com/intl/sl/appengin...
BlueRunner ::
Če imaš v mislih key-value podatkovne zbirke, potem je poizvedba preprosto po ključu.
Njihova moč ni toliko v tem, da bi po njih karkoli relacijsko poizvedoval, temveč v temu, da lahko vsebino razpršiš na več točk, nato pa na posamičnih točkah razpršeno obdeluješ košček teh podatkov. Scatter-gather oziroma map-reduce pristop, kot se mu trenutno popularno reče.
Recimo primer forumov... vsaka tema je lahko svoja tabela. Vsaka tabela vsebuje zapise, ki so urejeni po času oziroma tako, kot so jih člani pisali. Za izpis ne potrebuješ nikakršne umetnosti, razen tega, da greš od prvega zapisa do zadnjega zapisa in vse izpišeš. Če pa želiš npr. iskati po vsebini, pa lahko delo porazdeliš med X računalnikov, kjer prvi obdeluje prvih 1/X zapisov, drugi obdeluje drugih 1/X zapisov in tako do zadnjega. Vsi vse obdelajo skupaj, nato pa se rezultati zberejo nazaj skupaj in vrnejo klicatelju.
Težava pa nastopi, če recimo en član takšnih forumov spremeni svoj vzdevek. Ker nerelacijske baze tipično niso normalizirane (isti podatek se podvaja v več tabelah) to pomeni, da moraš potem pognati proces, ki bo za vse tabele z objavami pregledal vse zapise in, če bo našel ime tega uporabnika, spremenil staro ime v novo ime. Seveda lahko to delo znova porazdeliš na več računalnikov, vendar pa je v primerjavi z normalizirano relacijsko bazo to še vedno strahotno neoptimalen proces.
Kar pomeni, da je vsaka stvar uporabna za svoj namen. Včasih so primerne relacijske baze, včasih pa nerelacijske. Pa še med nerelacijskimi imaš več različnih pristopov, ki se med seboj razlikujejo med funkcionalnostmi, ki jih podpirajo. Recimo za kakšno shranjevanje konfiguracij in podatkov katerih struktura je vnaprej znana in nespremenljiva, so nerelacijske baze s svojo majhnostjo in hitrostjo zelo popularne. Po drugi strani pa včasih ne moreš vnaprej napovedati kako boš moral podatke med seboj povezovati, zaradi česar greš v smeri relacisjkih SQL zbirk, pri temu pa zaradi optimizacije različnih sprememb poskušaš zbirko tudi čim bolj normalizirati (tudi normalizacija je klasična računalniška vezana trgovina - vedno tehtaš med porabo prostora in hitrostjo izvajanja).
Za tvoje potrebe (serializacija objektov) je vprašanje, kaj je najbolj primeren pristop. Če meniš, da normalizacije ne potrebuješ in, če imajo objekti svoj lasten identifikator po katerem jih lahko razločiš, potem bi verjetno šlo kar zlahka. Če pa imaš opraviti s "klasično" težavo razlike med objekti v aplikaciji in entitetami v podatkovni zbirki, pa ti nerelacijske baze ne bodo niti najmanj pomagale. Dejansko bi moral potem stopiti korak nazaj in še enkrat razmisliti o arhitekturi in možnostih uporabe nerelacijskega shranjevanja podatkov.
Pa še to je dobro vedeti, da pristopa nista nekompatibilna. Dejansko je zelo malo sistemov, ki bi bili čisto nerelacijski. Večina jih je dejansko hibridnih, kjer za določen del podatkov izkoristijo prednosti relacijske zbirke, za drug del pa prednosti nerelacijske. Tako imaš npr. uporabnike za forum v relacijski zbirki, slike, objave in ostale mehurčke (BLOB-e) pa v nerelacijski (tudi datotečni sistem je nerelacijska zbirka podatkov, kjer je pot do datoteke ključ, vsebina pa je vrednost zapisa).
Njihova moč ni toliko v tem, da bi po njih karkoli relacijsko poizvedoval, temveč v temu, da lahko vsebino razpršiš na več točk, nato pa na posamičnih točkah razpršeno obdeluješ košček teh podatkov. Scatter-gather oziroma map-reduce pristop, kot se mu trenutno popularno reče.
Recimo primer forumov... vsaka tema je lahko svoja tabela. Vsaka tabela vsebuje zapise, ki so urejeni po času oziroma tako, kot so jih člani pisali. Za izpis ne potrebuješ nikakršne umetnosti, razen tega, da greš od prvega zapisa do zadnjega zapisa in vse izpišeš. Če pa želiš npr. iskati po vsebini, pa lahko delo porazdeliš med X računalnikov, kjer prvi obdeluje prvih 1/X zapisov, drugi obdeluje drugih 1/X zapisov in tako do zadnjega. Vsi vse obdelajo skupaj, nato pa se rezultati zberejo nazaj skupaj in vrnejo klicatelju.
Težava pa nastopi, če recimo en član takšnih forumov spremeni svoj vzdevek. Ker nerelacijske baze tipično niso normalizirane (isti podatek se podvaja v več tabelah) to pomeni, da moraš potem pognati proces, ki bo za vse tabele z objavami pregledal vse zapise in, če bo našel ime tega uporabnika, spremenil staro ime v novo ime. Seveda lahko to delo znova porazdeliš na več računalnikov, vendar pa je v primerjavi z normalizirano relacijsko bazo to še vedno strahotno neoptimalen proces.
Kar pomeni, da je vsaka stvar uporabna za svoj namen. Včasih so primerne relacijske baze, včasih pa nerelacijske. Pa še med nerelacijskimi imaš več različnih pristopov, ki se med seboj razlikujejo med funkcionalnostmi, ki jih podpirajo. Recimo za kakšno shranjevanje konfiguracij in podatkov katerih struktura je vnaprej znana in nespremenljiva, so nerelacijske baze s svojo majhnostjo in hitrostjo zelo popularne. Po drugi strani pa včasih ne moreš vnaprej napovedati kako boš moral podatke med seboj povezovati, zaradi česar greš v smeri relacisjkih SQL zbirk, pri temu pa zaradi optimizacije različnih sprememb poskušaš zbirko tudi čim bolj normalizirati (tudi normalizacija je klasična računalniška vezana trgovina - vedno tehtaš med porabo prostora in hitrostjo izvajanja).
Za tvoje potrebe (serializacija objektov) je vprašanje, kaj je najbolj primeren pristop. Če meniš, da normalizacije ne potrebuješ in, če imajo objekti svoj lasten identifikator po katerem jih lahko razločiš, potem bi verjetno šlo kar zlahka. Če pa imaš opraviti s "klasično" težavo razlike med objekti v aplikaciji in entitetami v podatkovni zbirki, pa ti nerelacijske baze ne bodo niti najmanj pomagale. Dejansko bi moral potem stopiti korak nazaj in še enkrat razmisliti o arhitekturi in možnostih uporabe nerelacijskega shranjevanja podatkov.
Pa še to je dobro vedeti, da pristopa nista nekompatibilna. Dejansko je zelo malo sistemov, ki bi bili čisto nerelacijski. Večina jih je dejansko hibridnih, kjer za določen del podatkov izkoristijo prednosti relacijske zbirke, za drug del pa prednosti nerelacijske. Tako imaš npr. uporabnike za forum v relacijski zbirki, slike, objave in ostale mehurčke (BLOB-e) pa v nerelacijski (tudi datotečni sistem je nerelacijska zbirka podatkov, kjer je pot do datoteke ključ, vsebina pa je vrednost zapisa).
Iluvatar ::
V ogrodju .NET je trenutno zelo priljubljen Entity Framework (EF) in LINQ (language integrated query)
Ta dva skrbita za "parcelacijo" kot si sam to poimenoval.
Npr. pri EF je ideja ta, da proizvajalci spišejo provider, ki skrbi, da se bodo tvoje poizvedbe preko npr. Linq to Entities prevedle v ustrezne SQL stavke (npr T-SQL če uporabljaš MS SQL) ali v drug SQL, ki ga prebavi MySQL ali Oracel ipd. Imaš tudi provider za XML npr.
S programerjevega stališča delaš zmeraj z objekti in ne razmišljaš o tabelah, stoplcih in vrsticah.
EF s tremi XML datotekami opiše to parcelacijo. V eni je opisan STORE (tvoja baza), v drugi so tvoje ENTITETE (objekti), v tretji pa MAPING (kaj iz stora, gre v kateri property objekta).
Primer poizvedbe v EF:
Provider, ki ga uporabljaš bo poskrbel, da se bodo generirali ustrezni SQL ukazi na bazo.
Objekt lahko tudi shraniš in spet EF provider poskrbi da se objekt zapiše v bazo.
Fino v zgornjem primeru je da programer dela zmeraj na enkat način, ne glede nato kakšen store uporablja. (MySQL, MS SQL, XML...)
Slabosti pa so predvsem v tem, da EF provider ne generira "optimalne" SQL stavke.
V zgornjem primeru bo EF provider generiral dober SQL, ko pa pridemo do bolj kompleksnih poizvedb, pa je tudi generiran SQL "slab". No na srečo lahko overide-aš generiran SQL v takih primerih.
Kompleksnih poizvedb je načeloma manj (odvisno od problema, ki ga rešuješ)
EF pozna tudi koncepte kot so Eger Loading, Lazy loading, Deffered loading ipd...
To sicer ni objekta baza, lahko pa zelo dosti problemov rešiš s tem modelom in dosežeš to kar si ti v bistvu izpostavil. Hočeš delati z objekti, nebi pa jih rad "parceliral". Ni jih treba. EF zna zelo dobro poskrbeti za to.
Ta dva skrbita za "parcelacijo" kot si sam to poimenoval.
Npr. pri EF je ideja ta, da proizvajalci spišejo provider, ki skrbi, da se bodo tvoje poizvedbe preko npr. Linq to Entities prevedle v ustrezne SQL stavke (npr T-SQL če uporabljaš MS SQL) ali v drug SQL, ki ga prebavi MySQL ali Oracel ipd. Imaš tudi provider za XML npr.
S programerjevega stališča delaš zmeraj z objekti in ne razmišljaš o tabelah, stoplcih in vrsticah.
EF s tremi XML datotekami opiše to parcelacijo. V eni je opisan STORE (tvoja baza), v drugi so tvoje ENTITETE (objekti), v tretji pa MAPING (kaj iz stora, gre v kateri property objekta).
Primer poizvedbe v EF:
using(AdventureWorksDB aw = new
AdventureWorksDB(Settings.Default.AdventureWorks)) {
var newSalesPeople = from p in aw.SalesPeople
where p.HireDate > hireDate
select p;
foreach(SalesPerson p in newSalesPeople) {
Console.WriteLine("{0}\t{1}", p.FirstName, p.LastName);
}
}
Provider, ki ga uporabljaš bo poskrbel, da se bodo generirali ustrezni SQL ukazi na bazo.
Objekt lahko tudi shraniš in spet EF provider poskrbi da se objekt zapiše v bazo.
Fino v zgornjem primeru je da programer dela zmeraj na enkat način, ne glede nato kakšen store uporablja. (MySQL, MS SQL, XML...)
Slabosti pa so predvsem v tem, da EF provider ne generira "optimalne" SQL stavke.
V zgornjem primeru bo EF provider generiral dober SQL, ko pa pridemo do bolj kompleksnih poizvedb, pa je tudi generiran SQL "slab". No na srečo lahko overide-aš generiran SQL v takih primerih.
Kompleksnih poizvedb je načeloma manj (odvisno od problema, ki ga rešuješ)
EF pozna tudi koncepte kot so Eger Loading, Lazy loading, Deffered loading ipd...
To sicer ni objekta baza, lahko pa zelo dosti problemov rešiš s tem modelom in dosežeš to kar si ti v bistvu izpostavil. Hočeš delati z objekti, nebi pa jih rad "parceliral". Ni jih treba. EF zna zelo dobro poskrbeti za to.
noraguta ::
EF pozna tudi koncepte kot so Eger Loading, Lazy loading, Deffered loading ipd...no ja to ne more bit glih stvar knjižnice knede? bolj tega da so v jazik kateri konumira zadevo dodal nekaj izraznega Expression (programming) @ Wikipedia
sicer je bpa bolj ali manj zadeva podobna razen v res ekstremnih pogojih kar dostop do baze slučajno je.
EF pozna tudi koncepte kot so Eger Loading, Lazy loading, Deffered loading ipd...no ja to ne more bit glih stvar knjižnice knede? bolj tega da so v jazik kateri konumira zadevo dodal nekaj izraznega Expression (programming) @ Wikipedia
sicer je bpa bolj ali manj zadeva podobna razen v res ekstremnih pogojih kar dostop do baze slučajno je.
Pust' ot pobyedy k pobyedye vyedyot!
Zgodovina sprememb…
- spremenilo: noraguta ()
joze67 ::
Vsi imamo izkušnje s takimi bazami. File system anyone?
V časih, ko se je programska oprema gibala na robu zmogljivosti strojne opreme (in to ne vedno na isti strani), so bile popularne drevesno organizirane zbirke podatkov (Btreve, Raima, ...).
V časih, ko se je programska oprema gibala na robu zmogljivosti strojne opreme (in to ne vedno na isti strani), so bile popularne drevesno organizirane zbirke podatkov (Btreve, Raima, ...).
noraguta ::
klinc jože tis čudak sm te že opazu z enimi radikalizmi preh. sej trie je lohk dobra organizacija za search bazo sam infrastruktura pa use ostalo e problem , če se grešiš iz zdrave pamet naprej. sicer pa zanjo bit FSji dost bl zajebani. k nkol neveš kok bo polje dvog.
Pust' ot pobyedy k pobyedye vyedyot!
AndyS ::
klinc joĹže tis Äudak sm te Ĺže opazu z enimi radikalizmi preh. sej trie je lohk dobra organizacija za search bazo sam infrastruktura pa use ostalo e problem , Äe se greĹĄiĹĄ iz zdrave pamet naprej. sicer pa zanjo bit FSji dost bl zajebani. k nkol neveĹĄ kok bo polje dvog.
Jože skor zmer cilja prou... BTW
Zgodovina sprememb…
- spremenil: AndyS ()
noraguta ::
klinc joĹže tis Äudak sm te Ĺže opazu z enimi radikalizmi preh. sej trie je lohk dobra organizacija za search bazo sam infrastruktura pa use ostalo e problem , Äe se greĹĄiĹĄ iz zdrave pamet naprej. sicer pa zanjo bit FSji dost bl zajebani. k nkol neveĹĄ kok bo polje dvog.
Jože skor zmer cilja prou... BTW
nism reku ma filing, čene ga neb porajtu
Pust' ot pobyedy k pobyedye vyedyot!
Zgodovina sprememb…
- spremenilo: noraguta ()
Looooooka ::
A tle mogoce sprasujes o NoSQL resitvah ala MongoDB,Redis,RavenDB(zadnja dva naj bi mela podporo za Linq...za mongodb se pa baje neki ze dela na par hobi projektih)?
kopernik ::
BlueRunner, sej ni potrebno vzdevka duplicirati v vsakem data node-u oz. 'tabeli' kot ti temu praviš. Kot v relacijski, imaš lahko tudi v teh novodobnih bazah id -> vzdevek mapiranje shranjeno v posebnem node-u, v ostalih pa se potem duplicirajo id-ji. Če prav razumem, kaj hočeš povedati.
Zgodovina sprememb…
- spremenil: kopernik ()
BlueRunner ::
@Looooooka: Jaz sem razumel, kot da se vprašanje glasi na temo NoSQL - ne-relacijskih podatkovnih baz. Vse od TokyoCabinet in CouchDB pa do LDAP in FS. S poudarkom na key+value zbirkah, ki so IMHO čisto prikladne za shranjevanje kakšnih nastavitev in objektov.
@kopernik: Prav si razumel kaj sem želel povedati. Seveda pa imaš tudi ti prav. Jaz sem iz klobuka samo potegnil en primer, ki upam, da ilustrira nekatere pomembnejše razlike med relacijskim in enim izmed nereleacijskih pristopov. Ja, res je lahko za lase privlečen (ali pa tudi ne - odvisno od sistema in arhitekture). Da, seveda je zgodba še mnogo globja. Ampak naj debata pokaže v katero smer in do kakšne globine bo šla.
@kopernik: Prav si razumel kaj sem želel povedati. Seveda pa imaš tudi ti prav. Jaz sem iz klobuka samo potegnil en primer, ki upam, da ilustrira nekatere pomembnejše razlike med relacijskim in enim izmed nereleacijskih pristopov. Ja, res je lahko za lase privlečen (ali pa tudi ne - odvisno od sistema in arhitekture). Da, seveda je zgodba še mnogo globja. Ampak naj debata pokaže v katero smer in do kakšne globine bo šla.
noraguta ::
še ena taka priročna rešitev Extensible Storage Engine @ Wikipedia
Pust' ot pobyedy k pobyedye vyedyot!
papasmrk ::
Malce sem si ogledal tale RavenDB in je kar zanimiva zadeva moram priznat, ker lahko z LINQ poizveduješ po bazi.
Sem si pa tudi malce pogledal EF v kombinaciji z MVC... moram priznat da bi moral na kakem večjem projektu videt, ko je v DB cca 40 tabel, kako se potem to stvar vzdržuje. Pri MVC bi moral precej osvojiti koncept, da bi dal oceno ali je OK za neki novi projekt, ki se ga lotevam ali pa lepo ostanem na ASP.NET Web Forms.
Ima kdo od vas izkušnje, z EF ali MVC, ali pa kombinacija obojega ?
lp
Sem si pa tudi malce pogledal EF v kombinaciji z MVC... moram priznat da bi moral na kakem večjem projektu videt, ko je v DB cca 40 tabel, kako se potem to stvar vzdržuje. Pri MVC bi moral precej osvojiti koncept, da bi dal oceno ali je OK za neki novi projekt, ki se ga lotevam ali pa lepo ostanem na ASP.NET Web Forms.
Ima kdo od vas izkušnje, z EF ali MVC, ali pa kombinacija obojega ?
lp
Iluvatar ::
Jaz imam nekaj izkušenj z EF. Celotna rešitev uporablja več kot 40 tabel, od tega, jih je večina šifrantov.
Uporabljam EF 1, ki je del .NET framework 3.5 sp1. Imam več modelov, največji ima mapiranih 26 tabel.
Kompleksne poizvedbe pišem večinoma v stored procedurah, ki jih potem mapiram na model.
Designer za EF model tudi ne blesti, ko se začnejo stvari komplicirati, zato je potrebno marsikatero stvar ročno popravit v XML-jih.
Malo se je potrebno navadit, da to niso npr. dataseti, ki imajo odličen change tracking. Vendar, ko dojameš in se navadiš, nočeš več nazaj, sploh če si delal s kakimi datatable v asp.net :)
Zadeva deluje na MS SQL bazi, zdaj pa jo bom portal na MYSQL, kjer bo potrebno spremeniti samo stored procedure in triggerje, vse ostalo bo enako.
Če MONO dobro podipra WCF, bo strežniški del moje rešitve tekel tudi na LINUX in MYSQL.
Uporabljam EF 1, ki je del .NET framework 3.5 sp1. Imam več modelov, največji ima mapiranih 26 tabel.
Kompleksne poizvedbe pišem večinoma v stored procedurah, ki jih potem mapiram na model.
Designer za EF model tudi ne blesti, ko se začnejo stvari komplicirati, zato je potrebno marsikatero stvar ročno popravit v XML-jih.
Malo se je potrebno navadit, da to niso npr. dataseti, ki imajo odličen change tracking. Vendar, ko dojameš in se navadiš, nočeš več nazaj, sploh če si delal s kakimi datatable v asp.net :)
Zadeva deluje na MS SQL bazi, zdaj pa jo bom portal na MYSQL, kjer bo potrebno spremeniti samo stored procedure in triggerje, vse ostalo bo enako.
Če MONO dobro podipra WCF, bo strežniški del moje rešitve tekel tudi na LINUX in MYSQL.
kogledom ::
Se pridružujem mnenju Iluvatar-ja.
Uporabljamo .Net 4, EF, WCF RIA Services, Silverlight, MVVM.
EF model s 55 tabelami, mešano mapiranih po porebi (Table-per-type in Table-per-hierarchy).
EF je potrebno kar dobro naštudirat, da ti začne vračat nazaj, samo potem nočeš več vstran.
Se pa dajo tudi kompleksnejše pozvedbe izdelati brez stored procedur (ne uporabljamo niti ene).
Za fine nastavitve je na žalost res potrebno poseči po XML.
Uporabljamo .Net 4, EF, WCF RIA Services, Silverlight, MVVM.
EF model s 55 tabelami, mešano mapiranih po porebi (Table-per-type in Table-per-hierarchy).
EF je potrebno kar dobro naštudirat, da ti začne vračat nazaj, samo potem nočeš več vstran.
Se pa dajo tudi kompleksnejše pozvedbe izdelati brez stored procedur (ne uporabljamo niti ene).
Za fine nastavitve je na žalost res potrebno poseči po XML.
papasmrk ::
Na kakšen način se je najbolje lotiti, da prvo kreirate relacijsko bazo in potem objektni model v EF, ali pa prvo naredite objektni model in EF sam zgenerira relacijsko bazo z vsemi možnimi primary in foreign key.
lp
lp
Looooooka ::
Kakor si navajen...ljudje, ki so pred programiranjem veliko delali z bazami ponavadi hitreje spacajo bazo v mssql,mysql..itd designerju in potem importajo v projekt, kjer se zgenerira objektni model.
Ljudje, ki ne poznajo stored procedur in sql queryjev(zakaj bi pa jih saj so programerji...) delajo obratno in sploh nocejo pogledat fizicne baze :)
Ljudje, ki ne poznajo stored procedur in sql queryjev(zakaj bi pa jih saj so programerji...) delajo obratno in sploh nocejo pogledat fizicne baze :)
Iluvatar ::
Model first development ima svoje prednosti, ki lepo razložene v kakih debatah in člankih.
Pri nas smo modernizirali arhitekturo aplikacije nismo pa želeli poseči po bazi, predvsem zaradi tega, ker je morala na isti bazi do prihoda modernizirane različice teči še stara različica in se nismo želeli preveč ukvarjati s prenosom podatkov v novo bazo.
Sploh pa EF 1 out of the box ni podpiral generiranje baze iz modela. (Nekaj malega se je dalo, če si namestil neka orodja...) Drugače pa baje EF v .NET 4 podpira tudi to, da najprej zgeneriraš model, potem pa se zgenerira tudi baza.
Prednost EF je tudi v tem, da ti lahko dbadmin "parcelira" bazo da pridobi na performancah, tebi pa to ne povzroči sivih las, ker večinoma popravljaš samo maping v ostali del aplikacije pa se ti ni potrebno vtikat...
Pri nas smo modernizirali arhitekturo aplikacije nismo pa želeli poseči po bazi, predvsem zaradi tega, ker je morala na isti bazi do prihoda modernizirane različice teči še stara različica in se nismo želeli preveč ukvarjati s prenosom podatkov v novo bazo.
Sploh pa EF 1 out of the box ni podpiral generiranje baze iz modela. (Nekaj malega se je dalo, če si namestil neka orodja...) Drugače pa baje EF v .NET 4 podpira tudi to, da najprej zgeneriraš model, potem pa se zgenerira tudi baza.
Prednost EF je tudi v tem, da ti lahko dbadmin "parcelira" bazo da pridobi na performancah, tebi pa to ne povzroči sivih las, ker večinoma popravljaš samo maping v ostali del aplikacije pa se ti ni potrebno vtikat...
mitjaR ::
Pozdravljeni!
Potrebujem inštrukcije iz področja NoSql podatkovnih baz.
Moja naloga bi bila naslednja:
- preglejte NoSql koncepte, ki se vkljucujejo v relacijske PB, vkljucno z novimi Engini v MySQL (npr. za grafe, pomnilniski, ...)
- izberite primerne benchmarke
- stestirajte koncepte na MySQL, MariaDB razlicicah.
- poglejte si sisteme NewSQL, ki so relacijski sistemi z masovnim skaliranjem
- naredite pregled, stestirajte kaksen engine za MySQL
Cena po dogovoru.
Če kdo pozna koga oz. zna sam, se priporočam.
Lep pozdrav.
Potrebujem inštrukcije iz področja NoSql podatkovnih baz.
Moja naloga bi bila naslednja:
- preglejte NoSql koncepte, ki se vkljucujejo v relacijske PB, vkljucno z novimi Engini v MySQL (npr. za grafe, pomnilniski, ...)
- izberite primerne benchmarke
- stestirajte koncepte na MySQL, MariaDB razlicicah.
- poglejte si sisteme NewSQL, ki so relacijski sistemi z masovnim skaliranjem
- naredite pregled, stestirajte kaksen engine za MySQL
Cena po dogovoru.
Če kdo pozna koga oz. zna sam, se priporočam.
Lep pozdrav.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Baza podjetijOddelek: Loža | 4469 (3613) | M & M |
| » | Nova različica podatkovne baze PostgreSQL 9.5 prinaša obilico novosti (strani: 1 2 )Oddelek: Novice / Ostala programska oprema | 17676 (14542) | McAjvar |
| » | MemSQLOddelek: Programiranje | 1783 (1539) | vorantz |
| » | Kombinacija relacijske/nerelacijske podatkovne bazeOddelek: Programiranje | 1986 (1593) | AndrejO |
| » | branje xml datoteke s SQL stavkomOddelek: Programiranje | 1409 (1334) | kopernik |