Najlepsze praktyki wdrożeniowe NoSql/Raven DB

Question

Prowadzę dochodzenie w sprawie nowego projektu, który będzie witryną w stylu portalu społecznościowego. Czytam na RavenDb i podoba mi się wygląd wielu jego funkcji. Nie czytałem na nosql tyle, ale zastanawiam się, czy istnieje nisza, w której najlepiej pasuje, a old school sql nadal jest najlepszym wyborem dla innych rzeczy.

Myślę, że wtyczka uprawnień będzie idealna dla witryny w stylu społecznościowym - ale czy rzeczywiście będzie działać w środowisku, w którym baza danych zostanie uderzona - lub czy jest zoptymalizowana pod kątem bardziej raportującego systemu możliwe jest wciąż rzucanie nowych struktur danych do bazy danych i raportowanie o tych strukturach.

Jestem chętny do użycia odpowiedniego narzędzia do pracy - będę używać MVC3, Windsor + albo serwer Nhibernate + Sql, albo RavenDb.

Czy powinienem trzymać się starej szkoły sql lub pójść z nowym dzieckiem na bloku: ravendb?

Answer 1

To pytanie może być bardzo subiektywne (nawet jeśli tak naprawdę nie jest), mówimy o NoSQL tak, jakby to była tylko jedna rzecz, a tak nie jest.

Masz

• baz danych wykresu (Neo4j itp),
• mapę/zmniejszenia bazy dokumentów styl (tapczan, Raven),
• dokument baz danych, które próbują się poczuć jak zwykłych baz danych (Mongo)
• Przechowywanie kluczy/wartości (Cassandra itp.)
• moar idzie tutaj.

Każdy z nich stara się rozwiązać inny problem za pomocą różnych środków, i czy chcesz używać jednego z nich nad tradycyjnym sklepie relacyjnej jest

• Kwestia przydatności
• Kwestia osobistych preferencji

Pod koniec dnia, po pierwotnej składowania danych dla pojedynczego systemu , baza dokument lub relacyjna sklep jest prob Dokładnie tego, czego oczekujesz, chociaż dla różnych części twojego systemu możesz dobrze skończyć korzystając z bazy danych wykresów (do obliczania sąsiadów itp.) lub magazynu klucz/wartość (jak Facebook robi/zrobił dla wiadomości skrzynki odbiorczej).

Główną korzyścią wynikającą z wyboru magazynu dokumentów jako sklepu podstawowego, a nie relacyjnego, jest to, że nie musisz się martwić, że próbujesz zamapować swoje obiekty do zbioru tabel, i że mniej jest narzutów związanych z konfiguracją zaangażowany w to.

Innym minusem/pozytywem będzie to, że musisz nauczyć się czegoś nowego i popełniać błędy po drodze.

Więc moja odpowiedź, jeśli mam zamiar być bezpośredni?

• RavenDB byłby odpowiedni
• SQL byłby odpowiedni

Które wolisz używać?W dzisiejszych czasach pewnie po prostu wybrałbym się do Ravena, wiedząc, że mogę zrzucić dane do relacyjnego sklepu w celach raportowania i prawdopodobnie robię to samo dla innych części mojego systemu, a także bez wyszukiwania i szybkiego pisania/szybkiego czytania bez wychodzenia z domu. poprzez wysiłek definiowania oddzielnych sklepów do odczytu/zapisu jest ogólną wygraną.

Ale to ja i jestem stronniczy.