Skąd mam wiedzieć, że moje dane mają charakter relacyjny lub obiektowy?

Po prostu przeczytaj te linie

• Jeśli Twoje dane mają charakter obiektowy, użyj magazynów obiektów („NoSQL”). Będą znacznie szybsze niż relacyjna baza danych.

• Jeśli Twoje dane mają charakter relacyjny, warto narzucić relacyjną bazę danych.

od-

http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

Skąd więc mam wiedzieć, czy moje dane mają charakter relacyjny czy obiektowy?

Na ryzyko roztrzaskania się na kawałki spróbuję prostej angielskiej definicji.

„Relacyjny charakter” jest dla mnie tłumaczony: wszystkie elementy danego typu mają prawie takie same atrybuty, co sprawia, że ​​dość łatwo jest zaprojektować prostą tabelę, ale wszystkie elementy w tej tabeli, a następnie SQL, aby wykonać CRUD i pobieranie. Ponadto, jeśli dane mogą być modelowane w taki sposób, że wszystkie elementy mają jeden z ograniczonego zestawu typów, można następnie zdefiniować relacyjną strukturę danych, która odpowiada temu zestawowi typów.

„Charakter obiektu” przekłada się na: Przedmioty podobnego typu mogą mieć wiele różnych atrybutów, a atrybuty te mogą mieć różnorodne cechy i charakter. Bardzo często można to (przy wystarczającym wysiłku) przetłumaczyć na model relacyjny, ale wiele tabel byłoby bardzo rzadko zapełnianych, co skutkowałoby bardzo nieefektywnymi połączeniami LEFT OUTER, co powoduje, że wydajność relacyjnej bazy danych jest powolna w porównaniu do bazy danych NOSQL.

Chciałbym powiedzieć, że z mojego punktu widzenia nie ma ścisłej linii oddzielającej te dwa elementy. Prawdopodobnie można znaleźć dowolną liczbę przykładów, które mieszczą się gdziekolwiek między dwoma skrajnościami.

OK, więc teraz otworzyłem się na snajperów ze wszystkich stron. Wszelkie komentarze są mile widziane. Zobaczmy, czy możemy ulepszyć tę definicję razem.

Dane są oba.

(ściśle mówiąc, nie może to być obiekt w przyrodzie, ponieważ nie ma w nim zachowania, ale nie podrywamy).

Decyzje o przechowywaniu danych w bazie danych RDBMS lub NoSQL zależą bardziej od Ciebie zamierzasz je wykorzystać , niż od prawdziwej „natury” samych danych.

Jeśli zamierzasz obsługiwać wszystkie rodzaje ścieżek nawigacyjnych do danych, możesz chcieć przechowywać dane w RDBMS, ponieważ będziesz mieć różne sposoby dostępu do danych i ich prezentacji. Potrzebujesz bazy danych, aby wykonać dla ciebie wiele ciężkich zadań. Na przykład dane „Zamówienia” można uzyskać za pośrednictwem klienta, sprzedawcy, SKU (pozycji), daty, regionu itp.

Z drugiej strony, jeśli masz minimalne ścieżki nawigacyjne, możesz po prostu zapisać cały obiekt. Na przykład „Koszyk”, do którego dostęp ma tylko interfejs internetowy i który nie jest długo przechowywany ani analizowany, może lepiej pasować do sklepu NoSQL. Poświęcenie składanych danych (wartości dokumentu lub klucza) NoSQL polega na tym, że robisz to bez relacji między kolekcjami - jeśli nie potrzebujesz tych relacji (do ścieżek nawigacyjnych, zapytań ad-hoc lub raportów) i zajmij się nimi w swoim aplikacji, wszystko będzie dobrze.

Oczywiście możesz przechowywać dane w obu przypadkach z różnych powodów, ale ma to swoje wady.

Dane nie są „przedmiotem z natury” ani „relacyjnym”. Każdy rodzaj danych może być reprezentowany zarówno w relacyjnej, jak i obiektowej strukturze / strukturze wykresu. To, co jest właściwe, zależy od sposobu wykorzystania danych przez aplikacje. Często możesz mieć oba. Na przykład dane używane na stronie internetowej mogą być przechowywane w relacyjnej bazie danych, ale na żądanie ładowane do struktury wykresu, która jest następnie buforowana w magazynie kluczy i wartości w pamięci.

Stwierdzenie, że obiekty przechowujące / NoSql będą szybsze niż relacyjne dla niektórych rodzajów danych, jest po prostu błędne. Liczy się ponownie sposób, w jaki aplikacja korzysta z danych, a nie forma samych danych. Składowanie obiektów będzie szybsze w ładowaniu wykresu obiektów przechowywanego jako jednostka, ale będzie znacznie wolniejsze w przypadku zapytań ad-hoc dotyczących wielu obiektów lub aktualizacji właściwości wielu obiektów.

Myślę, że kluczową linią tego artykułu jest:

"Likewise, sometimes the output will be a single object X, which is easy to represent. But sometimes the output will be a grid of aggregate data, or a single integer count"

Wydaje mi się, że autor ma rację w tym, że jeśli twój kod na przykład uzyskuje liczbę klientów w Hiszpanii dla pewnej logiki, nie powinieneś wypełniać listy klientów wszystkimi klientami w Hiszpanii, a następnie liczyć klient sprzeciwia się. (do którego ORM może cię popchnąć)

Oczywiście nie można powiedzieć na podstawie samej struktury danych klienta, czy zostanie ona wykorzystana w ten sposób. dlatego uważam, że powinniśmy interpretować „dane” w ten sposób, że oznaczają „wszystkie informacje wykorzystywane przez twoją aplikację”. Jeśli obejmuje to rzeczy takie jak agregaty lub „Wszystkie X związane z Y”, wówczas „dane” nie są odpowiednie dla atomowego podejścia NoSql