Hej alla! I en SQL/relationsdatabas jobbar man mot tabeller som består av rader som består av fält. För att komma åt och uppdatera data används SQL, Structured Query Language som satsvis (likt "strukturerad programmering") hämtar, lägger till, ändrar eller tar bort rader i databasen. de flesta oodb's skryter med att dom har _bättre_ prestanda än relationsdatabaser Eller så kanske det är just därför de säger att det är så mycket bättre: De vill att nån annan köper deras usla produkt så snabbt som möjligt, innan ryktet sprids :) <b>de flesta oodb's skryter med att dom har _bättre_ prestanda än relationsdatabaser</b> <b>Men varför har då varken Microsoft, Oracle eller IBM satsat stort på OODB? >Om det vore sant skulle det väl vara allmänt känt. T ex Jasmine från Computer Associates har en enastående prestanda. Orsaken är att ingen transformation av data måste ske, data sparas i form av binärdumpar i en process som påminner starkt om vanlig memory paging, spm finns i t ex Windows Mats, OK men hur funkar det då om jag t.ex vill skapa relationer mellan objekt och "joina" liknande SQL JOIN, då måste väl alla objekt "packas upp" och läsas sekventiellt? Eller hur har man löst det? >skapa relationer mellan objekt och "joina" liknande SQL JOIN en kompis till mig som jobbar på ett företag som en del av jobbet är stream sa någonting i still med följande: <b>Håller dock med dig att det låter konstigt med en databas som enbart sparar information som en BLOB. Vad har det med objektorientering at göra?</b> <b>medans en rdb förmodligen är snabbare när det gäller att filtrera data . tex hämta alla orderrader med artikel xyz för alla orders..</b> >i korta drag så fungerar det så att när du inte använder ett objekt längre så laddas det ut ur minnetobjektorienterade databaser
Jag är nybörjare och har inte förstått riktigt vad skillnaden är mellan objektorienterade databaser och SQL databaser.
mycket tacksam om någon förklara skillnaden lite närmare för en nybörjare Sv: objektorienterade databaser
I en obj. orienterad databas vet du inte riktigt hur datat lagras och du behöver inte bry dig om det heller. Det kan lagras på liknande sätt som i en relationsdatabas eller som binära datamängder. För att komma åt och ändra data använder du OOP (object oriented programming) alltså i stället för SQL SELECT * FROM.. kanske du skulle skriva (i VB)
Dim DbCustomer As New OODB.Schemas.Customer
DbCustomer.Find("bla bla")
MsgBox (DbCustomer.Address)
Jag har inte jobbat med någon OODB, men från vad jag har hört kan jag inte rekommendera det. Det verkar ju väldigt praktiskt för en programmerare vid en första titt, men det ska tydligen vara problematiskt. T.ex. dålig prestanda. Det kan jag tänka mig stämmer. RelatonsDB är ju byggd för att hantera data så snabbt och effektivt som möjligt. Decennier av forskning har lett fram till de databassystem som i dag finns. Min erfarenhet säger mig att i 9 fall av 10 fixas prestandaproblem i databasen, genom att förbättra t.ex: indexering, lagrade procedurer, eller JOINs.
OODB har mer fokus på att det ska vara lätt att programmera mot databasen. Det blir mycket "black box" över det och du får nog svårt att finjustera för prestanda.
Något som jag däremot tror på mer är Object-Relational Mapping. Det går ut på att du har en relationsdatabas i botten och att du har ett program som skapar kod (Data access layer) för enklare åtkomst till databasen från din kod. Du kan då få ut det bästa av båda världarna.
MEN en annan erfarenhet med detta då.. :)
Om du får problem i din kod och problemet ligger i den svarta lådan.. (i den tusentals rader långa skapade koden), vad gör du då...? Gör om allt från början? :) Det är alltid ett risktagande att lita på andras kod. Man får se upp med det och ta reda på om det verkligen är bra grejer man använder. Om man däremot skriver all kod själv, då vet man att det funkar och om det inte funkar kan man hitta felet ganska lätt...Sv:objektorienterade databaser
och vore det så att man kan få bättre kräm i en relationsdatabas med ormapping , så skulle förmodligen ingen byggt någon oodb ever eftersom det skulle vara meningslöst.
om folk har pyntat ner miljoner kr för att utveckla sina produkter kan man nog räkna med att dom har någon fördel att komma med.Sv: objektorienterade databaser
/mickeSv: objektorienterade databaser
Nåja jag har aldrig sett nån benchmark som skulle visa detta. Om det vore sant skulle det väl vara allmänt känt. I alla prestandatävlingar för databaser är det ju alltid Oracle, MS SQL, och DB2 som det gäller..
<b>och vore det så att man kan få bättre kräm i en relationsdatabas med ormapping , så skulle förmodligen ingen byggt någon oodb ever eftersom det skulle vara meningslöst.</b>
Som jag ser på ORM är det inget som man bara applicerar rakt av utan att fundera något på relationsdatabasens design och optimering. Men tillsammans med god design, indexering, stored procedures, kan man dra nytta av fördelarna med ORM främst avseende utvecklingstid/kostnad.
<b>om folk har pyntat ner miljoner kr för att utveckla sina produkter kan man nog räkna med att dom har någon fördel att komma med.</b>
Men varför har då varken Microsoft, Oracle eller IBM satsat stort på OODB?
Kanske för att de helt enkelt inte fungerar så optimalt som OO-fundamentatlister vill att de ska göra.
Jag har ingenting emot OODB! det skulle vara enormt praktiskt om de fungerade bra. Vilken programmerare skulle inte vilja fixa lagringen av sina objekt genom att skriva Obj.SaveInDb()? :)
Jag gillar såklart OOP så varför inte! Men jag tror inte på att de kan prestera lika bra (än så länge).Sv:objektorienterade databaser
Kanske för att de helt enkelt inte fungerar så optimalt som OO-fundamentatlister vill att de ska göra.</b>
För att det finns en annan uppenbar nackdel med oodb
data i databaser lever ofta längre än vad applikationerna / språken som applikationerna som använder db gör.
vilket gör att din oodb blir helt värdelös den dagen ni skal sluta använde det språk som oodb'n stödjer.
det problemet finns inte med relationsdatabaser..
<b>Vilken programmerare skulle inte vilja fixa lagringen av sina objekt genom att skriva Obj.SaveInDb()? :)
</b>
ja det skulle väl vara de programmerare som vet att databasrelaterad kod inte borde ligga i businessobjekten utan i något utanför ;-)
hur som , det fanns iaf en artikel på codeprojekt om caché (tror jag den hette) , enligt den artikeln var caché mycket snabbare än sqlserver på att hämta dataSv:objektorienterade databaser
Det är allmänt känt.
/Mats HelanderSv:objektorienterade databaser
/Mats HelanderSv: objektorienterade databaser
Och vanlig sökning hur funkar det? Jag antar att man från början måste definiera att t.ex. KundNamn skall vara indexerat? Men om man sen vill utöka sökning på Ort, hur går det till?Sv:objektorienterade databaser
Om man vill ha relationer skall man väl använda en relationsdatabas?
Poängen med en objektorienterad databas måste väl ändå vara att man inte skall använda sig av relationer (inte i samma mening iallafall)
Håller dock med dig att det låter konstigt med en databas som enbart sparar information som en BLOB. Vad har det med objektorientering at göra?Sv: objektorienterade databaser
min chef säger att våra databas (oodb) har mycket bättre presstanda än relationsdatabaser,
hans motivation är att ingen relationsdatabas sulle klara vår streaming som kanske 100000 anändare samtidigt kollar på en film samtidigt, ingen relationsdatabas skulle klara av det.Sv: objektorienterade databaser
fast det är ju inte riktigt så det fungerar
i korta drag så fungerar det så att när du inte använder ett objekt längre så laddas det ut ur minnet ner till disk (som en blob)
om någon sedan läser en property på ett objekt som refererar till ditt urladdade objekt så kommer det lazyloadas tillbaka in i minnet.
vilket gör att det _verkar_ som att hela din objektgraf är laddad hela tiden.
de enda relationer man jobbar med i en oodb är de relationer man har mellan objekten i form av properties vilket gör att inga sökningar i db behöver göras när man ska läsa tex en property eftersom propertyn/collection propertyn vet vilka objekt den pekar på och var i minnet / på disk den ska hämta dess data.
så att jämföra rdb med oodb är lite galet eftersom de fungerar på helt olika sätt och därför är bra på helt olika saker..
tex oodb är överlägset snabbare på att hämta objekt som refereras av ett objekt (tex orderrader från en order)
medans en rdb förmodligen är snabbare när det gäller att filtrera data . tex hämta alla orderrader med artikel xyz för alla orders..
//RogerSv:objektorienterade databaser
Detta är ett vanligt scenario för oss som arbetar med administrativa system i någon form.
Användarna vill filtrera, vrida, vända, sortera helt valfritt och det klarar vi att bygga mycket effektivt med en RDB, jag tvivlar starkt på att man kan ha samma flexibilitet i en OODB.
Att använda en RDB till att streama film verkar onödigt. I det fallet är säkert en oodb bättre.
Eller speciell programvara som är avsedd för just streaming av media är väl allra bäst..Sv:objektorienterade databaser
>ner till disk (som en blob)
Vad är skillnaden mot memory-mapped IO eller en vanlig swap-fil?