it-swarm-eu.dev

Supertyp / podtyp rozhodující mezi kategoriemi: úplné disjunktní nebo neúplné překrývání

Vytvářím inventární databázi, která ukládá IT hardware, jako jsou stolní počítače, notebooky, přepínače, směrovače, mobilní telefony atd. Používám vzor supertyp/podtyp, kde jsou všechna zařízení uložena v jedné tabulce a konkrétní informace je vložen do tabulek podtypů. Moje dilema je mezi dvěma následujícími návrhy:

enter image description here

V horním diagramu sdílejí všechna zařízení společné podtypy. Například stolní počítače a notebooky by měly záznamy v následujících tabulkách: Zařízení, NetworkDevice. Přepínač by měl záznamy v: Device, NetworkDevice. Router by měl záznamy v: Device, NetworkDevice, WANDevice. Každé zařízení, pro které sledujeme polohu, bude mít záznam v umístění. Některé výhody a nevýhody, které jsem si pro toto nastavení:

  • Pro: VÝBĚR záznamů na základě společného pole, jako je Hostname nebo LocationID, je snazší.
  • Pro: Žádná nulová pole.
  • Con: Tabulky, které by měly být zahrnuty do operací CRUD pro konkrétní zařízení, nejsou zřejmé a mohou zaměňovat budoucí DBA.

Ve spodním diagramu mají všechna zařízení svůj vlastní podtyp (existuje více tříd zařízení, které zde nejsou zobrazeny). V této situaci je zřejmé, do kterých tabulek se záznamy vloží nebo vyberou. Stolní počítače a notebooky jdou do počítače atd. Některé výhody a nevýhody, které jsem pro toto nastavení myslel:

  • Pro: Je okamžitě zřejmé, které tabulky použít pro operace CRUD pro podtypy.
  • Pro: Pro operace CRUD je nutné použít pouze jednu tabulku.
  • Con: VÝBĚR záznamů na základě společných polí podtypů vyžaduje, aby byly všechny tabulky kombinovány, například vyhledávání podle názvu hostitele nebo LocationID.

V obou situacích je pole ClassDiscriminator umístěno do tabulek podtypů pro použití s ​​omezením CHECK pro kontrolu, které typy mohou být vloženy.

Existují nějaká doporučení, pro které je design lepší, nebo je to zcela věcí názoru a závisí na zamýšleném účelu databáze?

ÚPRAVA: Konkrétní otázku, kterou považuji za překrývající se povahu tabulky „NetworkDevice“. Tato tabulka je určena k uchovávání síťových informací pro jakékoli zařízení s názvem hostitele a/nebo IP adresou, ať už se jedná o počítač, přepínač nebo router. Je překrývající se povaha této tabulky něco, co by mohlo způsobit problémy, nebo je v pořádku ji implementovat tímto způsobem?

Předem děkujeme za veškerý poskytnutý vstup. Zeptejte se, zda jsou potřeba další informace.

11
TheSecretSquad

Fyzická implementace subtypování v databázi je složitá záležitost. Pokud nemáte situaci, kdy nabízí přesvědčivé výhody (viz níže jeden nebo dva příklady), zvyšuje to implementaci a poskytuje relativně malou hodnotu.

Když jsem to provedl se skutečně složitým podtypem (žádosti a věty v systému řízení soudních případů, různorodé struktury smluv o komerčním pojištění s kombinovaným rizikem), myslím, že k tomu mám několik připomínek. Některé významné rohové případy jsou:

  • Pokud je celkový počet databázových polí v podtypech relativně nízký (řekněme: méně než 100) nebo existuje významná společnost mezi podtypy, pak rozdělení podtypů do samostatných fyzických tabulek má pravděpodobně malou hodnotu. Přidá významné režijní náklady na hlášení dotazů a vyhledávání. Ve většině případů je nejlepší mít jednu tabulku a spravovat své podtypování v aplikaci. (Pravděpodobně nejblíže k vašemu problému)

  • Pokud je vaše podtypování velmi nespojité a různé podtypy mají datové struktury závislé na typu (tj. Podřízené tabulky nebo složitější struktury), pak tabulky podtypů dávají smysl. V tomto případě má každý subtyp pravděpodobně relativně malou společnost v aplikaci (tj. V aplikaci je pravděpodobně celý subsystém věnovaný tomuto subtypu). Většina hlášení a dotazování bude pravděpodobně probíhat v daném podtypu, přičemž křížové dotazy budou omezeny hlavně na několik společných polí. (Systém řízení soudních případů)

  • Pokud máte velké množství podtypů s různorodými atributy a/nebo požadavek, aby byl tento konfigurovatelný, může být vhodnější obecná struktura a doplňková metadata. Viz this SO účtování pro přehled o některých možných přístupech. (Systém správy pojistné smlouvy)

  • Pokud máte velmi velký počet polí s malou společností napříč svými podtypy a malým požadavkem dotazování napříč tabulkami podtypů (tj. Nic moc ve způsobu vícenásobných vnějších spojení s tabulkami podtypů), tabulky typů mohou pomoci se správou roztažení sloupců. (Patologicky komplexní verze vašeho problému)

  • Někteří O/R mapovače mohou podporovat pouze konkrétní přístup k řízení podtříd.

Ve většině případů jsou fyzické tabulky podtypu ve schématu DB trochu řešením při hledání problému, protože potenciálně mají nežádoucí vedlejší účinky.

Ve vašem případě předpokládám, že máte relativně skromný počet podtypů a zvládnutelný počet atributů. Vaše schéma a otázka nenaznačují žádný úmysl zavěsit podřízené tabulky ze záznamů. Navrhuji, abyste zvážili použití první výše uvedené možnosti a zachování jedné tabulky a správu dílčího psaní v aplikaci.

Zvažte nejprve vývoj zvukového logického datového modelu pomocí pravidel hierarchie klasifikace datového modelování, kterou najdete v Enterprise Model Patterns , kniha Davida Haye. Při vytváření hierarchie klasifikace musí být každý výskyt (řádek) jednoho a pouze jednoho podtypu. To znamená, že podtypy se vzájemně vylučují. Klasifikace musí být založena na jedné základní, neměnné vlastnosti. Použití tohoto základního pravidla poskytne vašemu modelu mnoho jasnosti. V modelu, který máte, je jediná charakteristika, kterou lze zařadit, účelem zařízení - telefon, síťový přepínač, počítač, router atd. Každé zařízení musí být jednoho a pouze jednoho z těchto typů. Například umístění by nebylo podtypem. Atributy, jako je IP adresa, patří do super typu.

Myslím, že zjistíte, že počet typů zařízení bude dostatečně velký, aby zaručoval vzor EAV, jak je uvedeno v jiné odpovědi. Kniha David Hay I, kterou odkazuji, tento model velmi efektivně pokrývá. Pokud je však počet podtypů málo, můžete se rozhodnout pro implementaci pouze tabulky super typů s mnoha nulovatelnými sloupci, pouze tabulek subtypu s duplikovanými sloupci nebo obojí. Pokud se každý podtyp značně liší ve svých atributech a nemá žádné vztahy na úrovni super typu, můžete použít pouze tabulky podtypu. Pokud je opak pravdou, můžete jít pouze s tabulkami super typu. Pokud existuje mix, implementujte oba.

Nakonec si můžete vždy implementovat vzor EAV jako schéma základní tabulky a poté vytvořit vrstvu abstrakce pohledu, která prezentuje data aplikaci jako tabulky super a subtypu. To vám poskytuje flexibilitu ve vrstvě úložiště, ale porozumění schopnosti ve vrstvě zobrazení aplikace.

3
Todd Everett

Produkt není inventář. Inventář a produkty jsou odlišné.

Produkt je ve skutečnosti specifikací produktu, nikoli fyzickou věcí.

Fyzická věc je aktivum, které společnost vlastní (nebo ukládá). Můžete mít aktiva, která sledujete podle sériového čísla (diskrétní aktiva), nebo aktiva, která sledujete pouze podle množství (aktiva inventáře).

Podíval bych se na Silverstonův datový model Resource Book Vol 1. Má dobré schéma pro hrdiny, funkce, ceny, inventář. Ušetří vám to spoustu času.

2
Neil McGuigan

Jednou z otázek, které bych položil, je, proč sledujete různé atributy svých položek inventáře? - Nebo konkrétně , co děláte s touto informací o atributu?

Pokud máte mnoho sestav nebo formulářů, které dávají konkrétní smysl konkrétním atributům, musíte použít přístup doporučený společností ConcernedOfTunbridgeWell. Pokud se na druhou stranu tyto atributy zaznamenávají pro účely jejich výpisu nebo pro případné srovnání s podobnými atributy podobných zařízení, můžete mít (a) dobrou omluvu k použití EAV. Vím, že „EAV je čisté zlo“ z mnoha důvodů, s výjimkou velmi vzácných případů, kdy tyto důvody nezáleží na konkrétní aplikaci. Vaše může být takovou aplikací.

Podívejte se na tuto odpověď týkající se návrhu systém inventáře zařízení a na tuto odpověď týkající se návrhu systém katalogu produktů a podívejte se, jak přístup EAV může vaši aplikaci zjednodušit s diskusí o tom, jaká jsou přesně rizika EAV a jak posoudit, zda se tato rizika nemusí vztahovat na vaši konkrétní žádost.

0
Joel Brown