Jakie są zasady i korzyści wynikające z "modelu partyjnego"?

Ideą stojącą za modelami party (aka entity schema) jest zdefiniowanie bazy danych, która wykorzystuje niektóre z zalet skalowalności wolnych od schematów baz danych. Model party robi to, definiując swoje jednostki jako rekordy typu party, w przeciwieństwie do jednej tabeli na jednostkę. Rezultatem jest niezwykle znormalizowana baza danych z bardzo małą ilością tabel i bardzo małą wiedzą na temat znaczenia semantycznego przechowywanych danych. Cała ta wiedza jest popychana do dostępu do danych w kodzie. Aktualizacja bazy danych przy użyciu model party są minimalne do żadnego, ponieważ schemat nigdy się nie zmienia. Jest to zasadniczo gloryfikowana struktura modelu danych pary klucz-wartość z kilkoma wymyślnymi nazwami i kilkoma dodatkowymi atrybutami.

Plusy:

Niesamowita skalowalność pozioma. Po zdefiniowaniu 5-6 stołów w modelu jednostki możesz udać się na plażę i popijać margarity. Możesz praktycznie skalować tę bazę danych tak bardzo, jak chcesz, przy minimalnym wysiłku.
• baza danych obsługuje dowolną strukturę danych rzucaj. Możesz również zmieniać struktury danych i definicje stron/podmiotów na bieżąco bez wpływu na aplikację. To jest bardzo potężne.
• można modelować dowolne jednostki danych, dodając rekordy, nie zmieniając schematu. Oznacza to, że możesz pożegnać się ze skryptami migracji schematu.
• jest to raj dla programistów, ponieważ kod, który piszą, określa rzeczywiste byty, których używają w kodzie, i nie ma mapowania z obiektów do tabel lub czegoś podobnego. Ty można traktować tabelę stron jako podstawowy obiekt wybranej struktury (System.Obiekt dla. Net)

Wady:

• Modele Party / Entity nigdy nie grają dobrze z ORMs, więc zapomnij o używaniu EF lub NHibernate, aby uzyskać semantycznie znaczące encje z bazy danych encji.
• Wiele łączy. Wyzwania związane z tuningiem wydajności. Ten "przekręt" odnosi się do praktyk, których używasz do definiowania swoich podmiotów, ale można śmiało powiedzieć, że będziesz robił o wiele więcej z tych umysłowe pytania, które przyniosą Ci koszmary w nocy.
Trudniejsze do spożycia. Deweloperzy i profesjonaliści DB, którzy nie znają Twojej firmy, będą mieli trudniej przyzwyczaić się do podmiotów narażonych na te modele. Ponieważ wszystko jest abstrakcyjne, nie ma diagramu lub wizualizacji, które można zbudować na bazie danych, aby wyjaśnić, co jest przechowywane do kogoś innego.
• potrzebne będą ciężkie modele dostępu do danych lub mechanizmy reguł biznesowych. Zasadniczo musisz wykonać dzieło zrozumienia co do cholery chcesz z bazy danych w pewnym momencie, a twój model bazy danych nie pomoże ci tym razem.

Jeśli rozważasz schemat strony lub podmiotu w relacyjnej bazie danych, prawdopodobnie powinieneś rzucić okiem na inne rozwiązania, takie jak magazyn danych NoSql, BigTable lub kV Stores. Istnieje kilka świetnych produktów z masowymi wdrożeniami i trakcją, takich jak MongoDB, DynamoDB i Cassandra, które były pionierami tego ruchu.

Kiedy byłem częścią zespołu realizującego te pomysły na początku lat 80-tych, nie ograniczało to naszego wyboru ORM, ponieważ nie zostały one jeszcze wynalezione.

Wycofałbym się z tych pomysłów w każdej chwili, ponieważ ten konkretny projekt był jednym z najbardziej przekonujących dowodów koncepcji, jakie kiedykolwiek widziałem o" rewolucyjnej " idei (która z pewnością była w tamtym czasie).

Zmusza cię do niczego. I to nie powstrzymuje cię przed niczym (od jakiegokolwiek błędu, mam na myśli). Ten definiujący własne model informacyjny to Ty.

Wszystkie strony mają wiele wspólnych właściwości. Fakt, że mają nazwę i takie (nazwaliśmy je "signaletics"). Fakt, że mają główne/główne lokalizacje zwane "adresami". Fakt, że wszyscy są w pewnym sensie zaangażowani w umowy biznesowe.

Jest to rozległy temat, polecam lekturę The Data Model Resource Book Volume 3-Universal Patterns for Data Modeling autorstwa Lena Silverstona i Paula Agnewa.

Właśnie otrzymałem swoją kopię i jest ona całkiem dobra - zapewnia widoczność wielu podejść do modelowania danych, w tym hybrydowych kontekstowych wzorców ról i tak dalej. Ma szczegółowe plusy i minusy dla każdego podejścia.

Istnieje mnóstwo sposobów modelowania relacji i ról partyjnych z ich zalety i wady. Pytanie, które zostało przyjęte jako odpowiedź, obejmuje tylko jeden przypadek "modelu partyjnego".

Na przykład w wielu podejściach pojęcia takie jak" pracownik"," kierownik projektu " itp. są to role , które partia może odgrywać w określonym kontekście. Postaram się dać Ci lepsze załamanie, gdy wrócę do domu.

Jako prosta rozmowa z mojego zrozumienia: Modelowanie stron daje elastyczność i wymaga więcej wysiłku (jak T-SQL join i ...) do realizacji.
Chcę również zauważyć, że "korzystanie z modelowania stron (serializacja/generalizacja) daje możliwość posiadania FK-relacji do innych tabel". na przykład: pomyśl o różnych typach użytkowników (admin, user,...), które uogólniono do User tabeli, i można mieć UserID w Authorization tabeli.

Nie jestem pewien, ale model partyjny brzmi jak szczególny przypadek wzoru uogólnienia-specjalizacji. W dziale "generalizacja specjalizacja modelowanie relacyjne" znajdziesz kilka ciekawych artykułów.