Jakie są zasady i zalety "modelu partyjnego"?

Question

"Model partyjny" to "wzór" dla projektu relacyjnej bazy danych. Przynajmniej część tego wymaga znalezienia wspólności między wieloma podmiotami, takimi jak klient, pracownik, partner itd., I uwzględnienie tego w niektórych bardziej "abstrakcyjnych" tabelach baz danych.

Chciałbym dowiedzieć się swoimi przemyśleniami na:

1. Jakie są podstawowe zasady i siły motywujące za modelem partii?
2. Co oznacza przepisanie twojego modelu danych? (Mój nieco wyżej jest dość wysoki poziom i całkiem prawdopodobnie niepoprawny pod pewnymi względami. Byłem przy projekcie, który go używał, ale pracowałem z oddzielnym zespołem skupionym na innych kwestiach).
3. Jakie są twoje wrażenia z tego doświadczenia? Czy używałeś go, a jeśli tak, czy zrobiłbyś to ponownie? Jakie były plusy i minusy?
4. Czy model imprezy ograniczył wybór ORMów? Na przykład, czy musiałaś wyeliminować pewne ORM-y, ponieważ nie pozwoliły na wystarczającą "warstwę abstrakcji" między twoimi obiektami domeny a fizycznym modelem danych?

Jestem pewien, że każda odpowiedź nie rozwiąże każdego z tych pytań ... ale wszystko, co dotyczy jednego lub więcej z nich, pomoże mi podjąć pewne decyzje, z którymi mam do czynienia.

Dzięki.

Answer 1

1. Jakie są podstawowe zasady i siły motywujące tył modelu partii?

Do tego stopnia, że ​​używałem go, to głównie o kodzie ponownego użycia i elastyczność. Używaliśmy go wcześniej w modelu gość/użytkownik/admin i na pewno okazuje się on przydatny, gdy trzeba przenieść użytkownika z jednej grupy do drugiej. Poszerz to, aby organizacje i firmy były reprezentowane przez użytkowników pod nimi, a to naprawdę zapewnia formę abstrakcji, która nie jest szczególnie związana z SQL.

2. Co to znaczy, że robisz to w swoim modelu danych? (Mój nieco wyżej jest dość wysoki poziom i całkiem prawdopodobnie niepoprawny w pewien sposób. Byłem w projekcie , który go używał, ale byłem pracujący z oddzielnym zespołem skupiającym w innych kwestiach).

Jesteś całkiem słusznie wiertła powyżej, choć potrzebuje trochę więcej szczegółów. Można sobie wyobrazić sytuację, w której podmiot znajdujący się w bazie danych (nazywany Stroną) zleca innej stronie, która z kolei może zlecić podwykonawstwo. Stroną może być Pracownik, Wykonawca lub Firma, wszystkie podklasy Partii. Z mojego zrozumienia wynika, że ​​posiadasz tabelę Partii, a następnie bardziej szczegółowe tabele dla każdej podklasy, które następnie mogą być dalej klasyfikowane (Party -> Person -> Contractor).

3. Jakie są twoje wrażenia z tego powodu? Czy używałeś go, a jeśli tak, czy zrobiłbyś to ponownie? Jakie były plusy i minusy?

Ma swoje zalety, jeśli trzeba elastycznie, aby dodać nowe typy do systemu i tworzenia relacji między typami, że nie spodziewałem się na początku i architekt (użytkowników poruszających się na nowy poziom, firmy wynajmu inne firmy itd.). Daje także korzyści z prowadzenia pojedynczego zapytania i pobierania danych dla wielu typów stron (firm, pracowników, wykonawców). Z drugiej strony, dodajesz dodatkowe warstwy abstrakcji, aby dostać się do danych, których faktycznie potrzebujesz i zwiększasz obciążenie (lub przynajmniej liczbę połączeń) w bazie danych, gdy szukasz konkretnego typu. Jeśli twoja abstrakcja posuwa się zbyt daleko, prawdopodobnie będziesz musiał uruchomić wiele zapytań w celu pobrania danych, ponieważ złożoność zaczyna być szkodliwa dla czytelności i obciążenia bazy danych.

4. Czy model party ograniczył wybór ORMów? Na przykład, czy musiałeś wyeliminować pewne ORM, ponieważ nie pozwoliły na wystarczającą liczbę "warstwy abstrakcji" pomiędzy Twoimi obiektami domeny a modelem fizycznym modelu ?

Jest to obszar, że jestem wprawdzie nieco słaby, ale uznaliśmy, że przy użyciu widoków i lustrzaną abstrakcja w warstwie aplikacji nie uczyniły to zbyt wielkim problemem. Prawdziwym problemem dla mnie zawsze było "gdzie jest fragment X życia", kiedy chcę bezpośrednio odczytać źródło danych (nie jest to zawsze intuicyjne dla nowych programistów w systemie).

Answer 2

Nie jestem pewien, ale model partyjny brzmi jak szczególny przypadek wzorca uogólniania-specjalizacji. Wyszukiwanie "modelowania relacyjnego specjalizacji generalizacji" zawiera interesujące artykuły.

Answer 3

To jest szeroki temat, polecam lekturę The Data Model Resource Book Volume 3 - Universal Patterns for Data Modeling autorstwa Len Silverston i Paula Agnew.

Właśnie otrzymałem mój egzemplarz i jest całkiem niezły - zapewnia widok na wiele podejść do modelowania danych, w tym hybrydowych wzorów ról kontekstowych i tak dalej. Posiada szczegółowe PRO i CON dla każdego podejścia.

Istnieje wiele sposobów modelowania relacji partyjnych i ról ze wszystkimi ich zaletami i wadami. Pytanie, które zostało zaakceptowane jako odpowiedź, dotyczy tylko jednego przykładu "modelu partyjnego".

Na przykład w wielu podejściach pojęcia "Pracownik", "Menedżer projektu" itp. To role, które strona może grać w określonym kontekście. Postaram się dać ci lepsze załamanie po powrocie do domu.

Answer 4

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

W każdym razie wycofuję się z tych pomysłów, ponieważ ten konkretny projekt był jednym z najbardziej przekonujących dowodów, jakie kiedykolwiek widziałem na temat "rewolucyjnego" pomysłu (który z pewnością był wtedy).

To zmusza do niczego. I to nie powstrzymuje cię przed niczym (od jakiegokolwiek pomyłki, mam na myśli). Tym, który definiuje twój własny model informacji, jesteś Ty.

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

Answer 5

Ideą modeli partyjnych (inaczej schematu podmiotowego) jest zdefiniowanie bazy danych, która wykorzystuje niektóre zalety skalowalności baz danych bez schematów. Model partyjny dokonuje tego, definiując swoje jednostki jako rekordy typu partii, w przeciwieństwie do jednej tabeli na jednostkę. Rezultatem jest niezwykle znormalizowana baza danych z bardzo małą liczbą tabel i bardzo małą wiedzą na temat semantycznego znaczenia przechowywanych danych. Cała ta wiedza jest popychana do dostępu do danych w kodzie. Aktualizacja bazy danych za pomocą modelu partyjnego jest minimalna lub żadna, ponieważ schemat nigdy się nie zmienia. Jest to w zasadzie gloryfikowana struktura modelu pary klucz-wartość z pewnymi wymyślnymi nazwami i kilkoma dodatkowymi atrybutami.

Za:

• RW ass poziomy skalowalności. Po zdefiniowaniu 5-6 tabel w modelu podmiotu można przejść na plażę i popijać margarity. Możesz praktycznie skalować tę bazę danych tak, jak chcesz, przy minimalnym wysiłku.
• Baza danych obsługuje dowolną strukturę danych, którą na nią rzucasz. Możesz także zmieniać struktury danych i definicje partii/jednostek 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.
• To jest raj dla programistów, ponieważ kod, który piszą, zdefiniuje rzeczywiste elementy, których używają w kodzie, i nie ma odwzorowań z obiektów na tabele lub coś w tym stylu. Można myśleć o tabeli Partii jako przedmiot podstawy swojej ramach wyboru (System.Object NET)

Wady:

• modele Party/podmiot nigdy dobrze grać z ORMs, więc zapomnieć o użyciu EF lub NHibernate w celu uzyskania znaczących semantycznie jednostek z bazy danych encji.
• Wiele złączeń. Wyzwanie związane z dostrajaniem wydajności. Ten "con" jest związany z praktykami, których używasz do definiowania twoich bytów, ale można bezpiecznie powiedzieć, że będziesz robił o wiele więcej tych zginających umysł zapytań, które przyniosą ci nocne koszmary.
• Trudniej spożywać. Programiści i eksperci DB niezaznajomieni z Twoją firmą będą mieli więcej czasu na przyzwyczajenie się do podmiotów ujawnionych przez te modele. Ponieważ wszystko jest abstrakcyjne, nie ma diagramu ani wizualizacji, które można zbudować na bazie danych, aby wyjaśnić, co jest przechowywane innej osobie.
• Potrzebne będą ciężkie modele dostępu do danych lub silniki reguł biznesowych. Zasadniczo musisz zrobić pracę, aby zrozumieć, 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 przyjęcie lub schemat podmiotu w relacyjnej bazie danych, powinieneś spojrzeć na inne rozwiązania, takie jak magazyn danych NoSql, BigTable lub magazyny KV. Istnieje kilka świetnych produktów z ogromnymi wdrożeniami i trakcją, takimi jak MongoDB, DynamoDB i Cassandra, które były pionierem tego ruchu.

Answer 6

jako prosta rozmowa z mojego zrozumienia: modelowanie partii zapewnia elastyczność i wymaga więcej wysiłku (jak przyłączenie T-sql i ...).
Chcę także wskazać, że "używanie modelowania partyjnego (serializacja/generalizacja) daje możliwość posiadania FK-Relation do innych tabel". na przykład: pomyśl o różnych typach użytkowników (administrator, użytkownik, ...), który uogólnił się na tabelę User, a możesz mieć UserID w tabeli Authorization.