Bazy obiektowe są nadal w użyciu?

głosy
16

Dość dawno temu, słyszałem o bazach danych obiektu. Fajny pomysł i wszystko. Teraz, wraz z przypadku ORMs wszędzie, czy ktoś jeszcze użyć dowolnego z systemów zorientowanych baz danych obiektu? Są one istotne? Są one praktyczne?

Utwórz 09/12/2008 o 17:00
źródło użytkownik
W innych językach...                            


10 odpowiedzi

głosy
11

OO nigdy bazach wyszedł z niszy rynkowej. Są dobre dla niektórych aplikacji - gdzie struktura danych nadaje się do reprezentowane przez wykres obiektu - ale nigdy nie trzymał przekonujące przewagę nad RDBMS przekroczyć przepaść. Kluczową zaletą reklamowany produktów OODBMS jest ścisła integracja z językiem hosta - nie ma żadnego obiektu / relacyjnego niedopasowanie impedancji.

Jednak nadal istnieje kilku producentów OODBMS takie jak Gemstone , Versant lub Cardinal , którzy robią bardzo ładnie z ich produktów. Technologia ta jest przydatna dla niektórych typów struktur danych i mogą być bardziej efektywne niż RDBMS, ale wydaje się być słaby dla zapytań ad hoc w porównaniu do współczesnych dialektów SQL.

Jak różne inni zauważyli, Kamień staje się trochę uwagi ze względu na ich poparcie dla Seaside i Maglev (portu Ruby do VM Gemstone z Rails działa na nim). Możemy znaleźć to dostaje mili ludzie z Gemstone trochę prasie a wraz z nim nieco więcej uwagi paradygmatu OODBMS.

Odpowiedział 09/12/2008 o 17:55
źródło użytkownik

głosy
7

W rzeczywistości, systemy baz danych są jednym z obszarów, że zasadnicze zmiany są naprawdę trudne. Miliardy dolarów wydawane są na relacyjnych systemów baz danych i pracują całkiem dobrze.

W prawdziwym życiu, że po prostu nie jest prawdą. Głównym powodem naszych problemów z bazami danych (widziałem roszczenia 30% wszystkich wierszy bazy danych zawierają błędów) jest stosowanie bardzo prymitywnego typowania i zatwierdzania w SQL. Ponadto, mimo że są one o nazwie relacyjny, są bardzo złe na obsługę relacji. Rezultatem jest denormalized datamodels i wynikające błędy aktualizacji.

Powodem firm jak relacyjnych baz danych, ponieważ są one bardzo przewidywalne. Mają wydawać dużo pieniędzy na nich, oni potrzebują dużo programistów i konserwacji robi głównie rutynowych zadań. Oni nie zobaczyć ilość powielania, które mogłyby zostać wyeliminowane jako zaletę. Rutynowa praca pozwala programistom wchłonąć ryzyko trudnej pracy. Przejście do OODB by utrzymać mniej przewidywalną pracę.

Odpowiedział 11/12/2008 o 13:30
źródło użytkownik

głosy
4

Zacząłem używać Gemstone niedawno. GLASS (Kamień na Linux (lub OS X) z morzem (smalltalk web framework)) jest prawdopodobnie najlepszym środowiskiem programistycznym dla złożonych aplikacji internetowych. Smalltalk czyni ożywienie, jako „prawdziwy rubin”.

Poparcie dla zmian schematu i zapytań jest o wiele lepsza niż w RDBMS.

Ważną różnicą jest to, że tym razem są one przystępne.

Odpowiedział 09/12/2008 o 18:58
źródło użytkownik

głosy
4

W rzeczywistości, systemy baz danych są jednym z obszarów, że zasadnicze zmiany są naprawdę trudne. Miliardy dolarów wydawane są na relacyjnych systemów baz danych i pracują całkiem dobrze. Są sprawdzone technologie i były one na tyle elastyczne, aby zaspokoić większość potrzeb (przy użyciu ORM na przykład, jak pan powiedział). Bazy obiektowe nie istnieją w rzeczywistości, nawet poza środowiskiem akademickim. Ale nie spodziewałem się zobaczyć coś tak duży jak SQL Server lub Oracle w tym zakresie w najbliższym czasie. One istnieją jako teorii i jako małe, baz danych specyficznych dla aplikacji i różnych produktów. Zasadniczo Przewiduję relacyjnych baz danych stają się bardziej zorientowane w przyszłości obsługiwać wymagania lepszy obiekt.

Odpowiedział 09/12/2008 o 17:10
źródło użytkownik

głosy
4

Sprawdź db4o .

Odpowiedział 09/12/2008 o 17:09
źródło użytkownik

głosy
3

Ponieważ koszt ich oprogramowanie nie jest na tyle łatwe, aby dowiedzieć się.

I wyrejestrowany obiektywizmu db4o, Versant, a żaden z nich nie ma ceny oprogramowania z góry na swojej stronie internetowej.

Już prawie stracił zainteresowanie właśnie z tego powodu.

Czy ktoś wie, wszędzie tam, gdzie jest wycena i licencja Porównanie tych wszystkich różnych oodbs?

Odpowiedział 03/09/2009 o 08:01
źródło użytkownik

głosy
3

Używamy Versant bazie obiektów w produkcie pracuję dalej. (Dawniej FastObjects, dawniej baza Poeta). Jest to baza danych obiektu, a okazuje się, że to działa znacznie lepiej niż relacyjnej modelu dla niektórych aspektów naszego produktu, głównie przechowywania obiektów konfiguracyjnych, relacje z kodu Java.

Zobacz także te wcześniej zadawane pytanie: https://stackoverflow.com/questions/52144/object-oriented-database-experiences

Odpowiedział 09/12/2008 o 17:04
źródło użytkownik

głosy
2

Korzystanie Kamień dla dużej aplikacji biznesowej. To wspaniałe i to jest bardzo praktyczne. Użyliśmy go od kilku lat i przez ten czas nie to pozwoliło nam zrobić wiele bardzo mało zasobów. Niestety istnieją i zostały liczne nieporozumienia o obiektowych baz danych i myślę, że to sprawia, że ​​są mniej istotne w świecie biznesu. Mam nadzieję, że coś takiego szkła (Kamień, Linux i Seaside Smalltalk) zmieni, że będzie w przyszłości.

Odpowiedział 09/12/2008 o 23:39
źródło użytkownik

głosy
1

Baza obiekt jest cool koncepcji aż do teraz. Jednak implementacje są plaqued zagadnień skalowalność i stabilność. Teraz z prawej wcielonego, który adresuje te dwie bestie, równanie może ulec zmianie.

Co myślę jest silnikiem danych (niekoniecznie obiektu bazy danych) i RDBMS naprawdę mogą żyć obok siebie, w rzeczywistości nie jest to idealne miejsce dla silnika danych w warstwie pośredniej, wbudowane Aplikacje / systemy, ... Również , poprawna implementacja silnika dane pozwolą wsparcie zarówno dla Trwałość obiektów na niskim poziomie i na wyższym poziomie, konstruktami RDBMS / SQL. Oznacza to, że aplikacja może zdecydować się na pracę z obiektami, należy silnik danych dla trwałości obiektu i dokonać Przedmioty dostępne jako wiersze / kolumny tabeli poprzez interfejs RDBMS.

Jest to idealne ustawienie. Mamy zlikwidować dwie technologie i zapewnienie alternatywy dla programistów programować w preferowanym interfejsem. Ktoś może argumentować, musimy to teraz, na przykład - SQL Server obsługuje hosting CLR obiektów, ale obecne implementacje cierpią z powodu spowolnienia impedancji. czyli - w ścieżce danych jest dużo konwersji / Tłumaczenia jako obiekty = dwa dane przestrzenne, a więc wtedy, gdy App, która zajmuje się obiektami zapisuje je do DB, rozwiązanie musi konwertować / przełożyć je do wiersza danych w tabeli!.

Ale jeśli odwrócić sytuację, czyli - silnik pracuje na danych obiektach wtedy nie będzie niedopasowanie impedancji. Dodawanie dwuwymiarowe rzuty danych nie jest niczym więcej niż implementacji interfejsu kolekcji Objecct, więc nie ma naprawdę żadnego mapowania / tłumaczenie, które występuje, gdy obiekty są eksponowane jako wierszy danych z tabeli. To jest moja teoria.

Więc to może kolejna fala technologii w tej dziedzinie jest silnikiem dane, które pozwolą obiektów, jak interfejs niskiego poziomu oraz interfejs RDBMS siedzi na szczycie tego. I ta technologia jest już dostępna!

B-Tree Złota wersja 4.0 Scalable Trwałość Obiekt ten ma jako główny cel projektu. osiąga ona następujące cechy i dlatego jest dobrze dostosowany do bycia silnik dane z wyboru na następną RDBMS, która w zasadzie jest warstwą na wierzchu. Dwa z jego głównych punktów kluczowych są: Skalowalność: 100 mln Wstawki w 17 godzin w zwykłym / avg wyposażona laptopa. Stabilność: przemysłowy transakcja siła, która zapewni DB nie jest uszkodzony i może cofnąć się do poprzednio popełnione państwa.

Aby to działało, silnik musi spełniać dane skalowalność i stabilność wymaganą przez serwery RDBMS. To bardzo trudne zadanie, ale nie niemożliwe. B-Tree Złota wersja 4.0 SPO spełnił tego wymogu, a więc jesteśmy naprawdę gotowi do wdrożenia tego rodzaju rozwiązania, bez naprawdę wpychając go pod naszą szyję jak SPO daje wolność wyboru, jak chcesz go użyć. Może być stosowany na wiele sposobów, na przykład - uzupełniając RDBMS Serwery jako warstwy pośredniej stacji buforowania, osadzone w DB po stronie klienta, itp ... nie wspominając już o czym silnik dane niskiego poziomu samego serwera RDBMS!

Odpowiedział 16/07/2010 o 08:24
źródło użytkownik

głosy
0

Przynajmniej z mojego punktu widzenia są one prawie martwy. Ale potem znowu pracuję głównie w oprogramowaniu komercyjnym. Może na terenach akademickich są nadal w użyciu gdzieś.

Odpowiedział 09/12/2008 o 17:03
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more