Używanie kanapy i serwera sql obok siebie

Question

Mamy obecnie ładnie relacyjną bazę danych SQL Server 2008, która jest naszą główną bazą danych aplikacji. Szukamy usprawnienia istniejącego mechanizmu przechowywania dokumentów, który wykorzystuje typy danych xml z czymś bardziej bezproduktywnym, które może obsłużyć podobne, ale nie identyczne dokumenty i pomyślał, że couchdb byłby odpowiedni.

Chodzi o to, że wspólne dane meta dotyczące dokumentów mogą być przechowywane w serwerze sql dla łatwości wyświetlania/agregacji/raportowania, ale rzeczywiste dokumenty są przechowywane na kanapie, aby obsłużyć subtelne różnice w dokumentach. Chodzi o to, aby w pełni wykorzystać dwie różne technologie.

Na przykład status, typ, powiązana osoba i data utworzenia byłyby wspólne dla wszystkich dokumentów i przechowywane w formacie sql, ale wiadomość e-mail i litera (oczywiście z różnymi polami) mogły być przechowywane na kanapie.

Następnie możemy wyświetlić naszą siatkę dokumentów dla wszystkich typów dokumentów (tysięcy dokumentów), które mogą być sprawdzane przez sql, ale wyświetlanie dokumentu pobiera dane z kanapy, gdy użytkownik chce ją wyświetlić.

Należy pamiętać, że niektóre typy dokumentów są generowane na podstawie szablonów, które również są dokumentami (pomyśl o scaleniu/znalezieniu i zastąpieniu korespondencji).

Warstwa aplikacji jest asp.net 4.5, C#, repozytorium wzór, Windsor dla MKOl, JavaScript

Więc na pytanie ...

Czy to podejście rozsądny sposób, aby większość z dwa różne paradygmaty przechowywania danych?

Czy sprawiamy, że nasze życie programistyczne jest niepotrzebnie skomplikowane w dążeniu do "użycia najbardziej odpowiedniej technologii do rozwiązania problemu"?

Czy ktoś ma jakieś doświadczenia z próbowaniem czegoś podobnego, a jeśli tak, to jak poszło?

Answer 1

Bardzo często używa się dwóch różnych formatów przechowywania dokumentów: Jeden dla aspektów przeszukiwania i metadanych, a drugi dla prezentacji.

Patrząc na to w sposób bardziej ogólny, podejście jest nieco podobny do tego, który rozwinięty na Królewskiej Duńskiej Biblioteki i pchnął w projekcie Planety UE:

http://www.researchgate.net/publication/221176211_Archive_Design_Based_on_Planets_Inspired_Logical_Object_Model

Oto kolejny papier, który omawia to podejście w bardziej ogólny sposób: "Opening Schrödingers Library"

Celem była archiwizacja. Zauważyliśmy, że podczas konwersji dokumentów do archiwizacji lub przechowywania żaden format zapisu znacznika nie był lepszy we wszystkich aspektach zachowania atrybutów, formatów, wyglądu, zawartości itp. Oryginalnego dokumentu. Rozwiązanie: Konwertuj na kilka formatów i używaj wyrafinowanego obiektu cyfrowego do śledzenia konwersji i najlepszych aspektów oryginału, które najlepiej zachowały konwersję.

Moim zdaniem podejście jest teoretycznie i praktycznie prawidłowe.

Zagadnienia praktyczne: Prawdopodobnie będziesz potrzebował jakiegoś cyfrowego obiektu, który śledzi różne części dokumentu, np. czy występuje tylko w jednym systemie (i takim, który), czy w obu. Wygląda na to, że do tego aspektu użyjesz SQLserver, a to brzmi sensownie.

Rzeczywiście wdrożyliśmy model obiektu, który opisujemy w artykule, i ostatnio słyszę, że wciąż go używają.