Dopiero co zacząłem od nierelacyjnych baz danych i nadal próbuję to obejść i dowiedzieć się, jaki byłby najlepszy model. Mogę mówić tylko w imieniu CouchDB.
Mimo to mam kilka wstępnych wniosków:
Czy wymyśliłeś alternatywne projekty, które działają znacznie lepiej w świecie nierelacyjnym?
Koncentracja na projektowaniu zmienia się: projekt modelu dokumentu (odpowiadającego tabelom DB) staje się prawie nieistotny, podczas gdy wszystko zależy od projektowania widoków (odpowiadających zapytaniom).
Baza danych dokumentów zamienia złożoność: SQL ma nieelastyczne dane i elastyczne zapytania, bazy danych dokumentów są na odwrót.
Model CouchDB to zbiór „dokumentów JSON” (w zasadzie zagnieżdżonych tabel skrótów). Każdy dokument ma unikalny identyfikator i można go w prosty sposób pobrać za pomocą identyfikatora. Dla każdego innego zapytania piszesz „widoki”, które są nazwanymi zestawami funkcji mapowania / redukcji. Widoki zwracają wynik w postaci listy par klucz / wartość.
Sztuczka polega na tym, że nie należy wysyłać zapytań do bazy danych w takim sensie, w jakim wysyłamy zapytania do bazy danych SQL: wyniki działania funkcji widoku są przechowywane w indeksie, a można zapytać tylko o indeks. (Jako „pobierz wszystko”, „pobierz klucz” lub „pobierz zakres klucza”).
Najbliższa analogia w świecie SQL byłaby taka, gdybyś mógł wysyłać zapytania do bazy danych tylko przy użyciu procedur składowanych - każde zapytanie, które chcesz obsługiwać, musi być wstępnie zdefiniowane.
Projekt dokumentów jest niezwykle elastyczny. Znalazłem tylko dwa ograniczenia:
- Przechowuj powiązane dane razem w tym samym dokumencie, ponieważ nie ma nic odpowiadającego złączeniu.
- Nie twórz dokumentów tak dużych, aby były aktualizowane zbyt często (np. Umieszczanie całej sprzedaży firmy za rok w tym samym dokumencie), ponieważ każda aktualizacja dokumentu powoduje ponowne indeksowanie.
Ale wszystko zależy od projektowania widoków.
Alternatywne projekty, które odkryłem, że rzędy wielkości pracy są lepsze z CouchDB niż z jakąkolwiek bazą danych SQL, są na poziomie systemu, a nie na poziomie pamięci. Jeśli masz jakieś dane i chcesz je udostępnić na stronie internetowej, złożoność całego systemu jest zmniejszona o co najmniej 50%:
- brak projektowania tabel DB (drobny problem)
- brak warstwy pośredniej ODBC / JDBC, wszystkie zapytania i transakcje przez http (problem umiarkowany)
- proste mapowanie DB na obiekt z JSON, które jest prawie trywialne w porównaniu do tego samego w SQL (ważne!)
- możesz potencjalnie pominąć cały serwer aplikacji, ponieważ możesz zaprojektować dokumenty tak, aby były pobierane bezpośrednio przez przeglądarkę za pomocą AJAX i dodać trochę dopracowania JavaScript, zanim zostaną wyświetlone jako HTML. (OLBRZYMI!!)
W przypadku zwykłych aplikacji internetowych bazy danych oparte na dokumentach / JSON są ogromną korzyścią, a wady mniej elastycznych zapytań i dodatkowego kodu do walidacji danych wydają się niewielką ceną do zapłacenia.
Czy uderzyłeś głową w coś, co wydaje się niemożliwe?
Jeszcze nie. Mapowanie / redukcja jako metoda wysyłania zapytań do bazy danych jest nieznana i wymaga dużo więcej myślenia niż pisanie SQL. Istnieje dość mała liczba prymitywów, więc uzyskanie potrzebnych wyników jest przede wszystkim kwestią kreatywności w określaniu kluczy.
Istnieje ograniczenie polegające na tym, że zapytania nie mogą przeglądać dwóch lub więcej dokumentów w tym samym czasie - nie ma połączeń ani innych rodzajów relacji obejmujących wiele dokumentów, ale jak dotąd nic nie było nie do pokonania.
Jako przykład ograniczenia, liczenia i sumy są łatwe, ale średnie nie mogą być obliczane przez widok / zapytanie CouchDB. Poprawka: Zwróć sumę i policz osobno i oblicz średnią na kliencie.
Czy udało Ci się wypełnić lukę za pomocą jakichkolwiek wzorców projektowych, np. Przy tłumaczeniu z jednego na drugi?
Nie jestem pewien, czy to wykonalne. To bardziej kompletne przeprojektowanie, jak tłumaczenie programu w stylu funkcjonalnym na styl obiektowy. Ogólnie rzecz biorąc, typów dokumentów jest znacznie mniej niż tabel SQL i więcej danych w każdym dokumencie.
Jednym ze sposobów, aby o tym pomyśleć, jest przyjrzenie się kodowi SQL w poszukiwaniu wstawek i typowych zapytań: które tabele i kolumny są aktualizowane, gdy na przykład klient składa zamówienie? A które z miesięcznych raportów sprzedaży? Te informacje powinny prawdopodobnie znaleźć się w tym samym dokumencie.
To znaczy: jeden dokument do zamówienia, zawierający identyfikator klienta i identyfikatory produktów, z powielonymi polami, jeśli jest to konieczne, aby uprościć zapytania. Wszystko w dokumencie może być łatwo sprawdzane, wszystko, co wymaga porównania między, powiedzmy, Zamówieniem i Klientem, musi być zrobione przez klienta. Jeśli więc chcesz uzyskać raport sprzedaży według regionu, prawdopodobnie powinieneś umieścić kod regionu w zamówieniu.
Czy w ogóle tworzysz teraz jawne modele danych (np. W UML)?
Przepraszamy, nigdy nie robiłem zbyt wiele UML przed bazami danych dokumentów :)
Ale potrzebujesz jakiegoś modelu mówiącego, które pola należą do których dokumentów i jakie rodzaje wartości zawierają. Zarówno dla twojego własnego późniejszego odniesienia, jak i dla upewnienia się, że wszyscy używający DB znają konwencje. Ponieważ na przykład nie pojawia się błąd, jeśli zapiszesz datę w polu tekstowym, a każdy może dodać lub usunąć dowolne pole, potrzebujesz zarówno kodu walidacyjnego, jak i konwencji, aby uzyskać luz. Zwłaszcza jeśli pracujesz z zasobami zewnętrznymi.
Czy brakuje Ci którejś z głównych dodatkowych usług dostarczanych przez RDBMS?
Nie. Ale z wykształcenia jestem programistą aplikacji internetowych, zajmujemy się bazami danych tylko w takim zakresie, w jakim musimy :)
Firma, dla której pracowałem, stworzyła produkt (aplikację internetową), który został zaprojektowany do działania w bazach danych SQL pochodzących od wielu dostawców, a „dodatkowe usługi” są tak różne od DB do DB, że musiały być wdrażane oddzielnie dla każdego DB. Więc mniej pracy było dla nas, aby przenieść funkcjonalność z RDBMS. To nawet rozszerzyło się na wyszukiwanie pełnotekstowe.
Więc cokolwiek rezygnuję, jest czymś, czego tak naprawdę nigdy nie miałem. Oczywiście twoje doświadczenia mogą się różnić.
Uwaga: obecnie pracuję nad aplikacją internetową do obsługi danych finansowych, notowań giełdowych i tym podobnych. Jest to bardzo dobre dopasowanie do bazy danych dokumentów, z mojego punktu widzenia wszystkie zalety bazy danych (trwałość i zapytania) są bezproblemowe.
Ale te dane są dość niezależne od siebie, nie ma złożonych zapytań relacyjnych. Otrzymuj najnowsze notowania według tickera, pobieraj cytaty według tickera i zakresu dat, pobieraj meta-informacje firmy, to prawie wszystko. Innym przykładem, który widziałem, była aplikacja blogowa, a blogi również nie charakteryzują się ogromnie skomplikowanymi schematami bazy danych.
Próbuję powiedzieć, że wszystkie udane aplikacje baz danych dokumentów, które znam, dotyczyły danych, które nie miały zbyt wielu powiązań: dokumenty (jak w wyszukiwarce Google), posty na blogach, artykuły z wiadomościami, dane finansowe .
Spodziewam się, że istnieją zbiory danych, które lepiej odwzorowują SQL niż model dokumentu, więc wyobrażam sobie, że SQL przetrwa.
Ale dla tych z nas, którzy chcą prostego sposobu na przechowywanie i pobieranie danych - a podejrzewam, że jest nas wielu - bazy danych dokumentów (jak w CouchDB) są wybawieniem.