it-swarm-eu.dev

Je vnořené zobrazení dobrý design databáze?

Četl jsem někde dávno. Kniha uvádí, že bychom neměli dovolit mít vnořené zobrazení na serveru SQL. Nejsem si jistý důvod, proč to nemůžeme udělat, nebo si pamatuji nesprávné tvrzení.

Studenti

SELECT studentID, first_name, last_name, SchoolID, ... FROM students

CREATE VIEW vw_eligible_student
AS 
SELECT * FROM students
WHERE enroll_this_year = 1

čitelé

SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers

CREATE VIEW vw_eligible_teacher
AS 
SELECT * FROM teachers
WHERE HasCert = 1 AND enroll_this_year = 1

Školy

CREATE VIEW vw_eligible_school
AS 
SELECT TOP 100 PERCENT SchoolID, school_name 

FROM schools sh 
JOIN
     vw_eligible_student s 
     ON s.SchoolID = sh.SchoolID
JOIN 
     vw_eligible_teacher t
     ON s.SchoolID = t.SchoolID

Na svém pracovišti jsem prozkoumal jednu z našich interních databázových aplikací. Prohlédl jsem si objekty, které zjistily, že jsou dvě nebo tři vrstvy pohledu navzájem. To mi připomnělo, co jsem četl v minulosti. Může někdo pomoci vysvětlit to?

Pokud to není v pořádku, chci vědět, že je omezen pouze na SQL Server nebo je obecně určen pro návrh databáze.

Další informace: Aktualizoval jsem příklad od své společnosti. Trochu se změním, aby byl obecnější, aniž by bylo příliš mnoho technických (v tomto příkladu příliš mnoho sloupců). Většinou je vnořené zobrazení, které jsme použili, založeno na abstraktním nebo agregovaném pohledu. Máme například velký studentský stůl se stovkami sloupců. Řekni, Eligible Student View je založeno na studentech, kteří se zapsali tento rok. A pohled způsobilý studentovi by mohl být použit i na jiných místech, například v uložené proceduře.

43

Bez ohledu na platformu platí následující poznámky.

(-) Vnořené názory:

  • jsou těžší pochopit a ladit

    např. Na který sloupec tabulky odkazuje tento sloupec zobrazení? Lemme Dig through 4 úrovně definic pohledu ...

  • zkomplikujte optimalizátor dotazů s nejefektivnějším plánem dotazů

    Viz this , this , this a this pro předběžné důkazy. Porovnejte s this , což ukazuje, že optimalizátor je často dost chytrý, aby správně rozbalil vnořené pohledy a vybral optimální plán, ale ne bez nákladů na kompilaci.

    Náklady na výkon můžete měřit porovnáním dotazu pohledu s ekvivalentním dotazem zapsaným proti základním tabulkám.

(+) Na druhé straně vám vnořená zobrazení umožňují:

  • centralizovat a znovu použít agregace nebo obchodní pravidla
  • odtrhněte svoji základní strukturu (řekněme od jiných vývojářů databází)

Zjistil jsem, že jsou zřídka nezbytné.


Ve vašem příkladu používáte vnořená zobrazení k centralizaci a opětovnému použití určitých obchodních definic (např. „Co je způsobilý student?“). Toto je platné použití pro vnořená zobrazení. Pokud spravujete nebo vyladíte tuto databázi, zvažte náklady na jejich udržení oproti nákladům na jejich odstranění.

  • Udržovat: Zachováním vnořených pohledů získáte výše uvedené výhody a nevýhody.

  • Odebrat: Chcete-li odebrat vnořená zobrazení:

    1. Všechny výskyty pohledů musíte nahradit jejich základními dotazy.

    2. Nezapomeňte aktualizovat všechny relevantní dotazy, pokud se změní vaše definice způsobilého studenta/učitele/školy, na rozdíl od pouhé aktualizace příslušné definice pohledu.

47
Nick Chammas

Někdy se vnořená zobrazení používají k zabránění opakování agregátů. Řekněme, že máte názor, který počítá zprávy a seskupuje je podle userid, možná byste měli mít názor, že se počítá počet uživatelů, kteří mají> 100 zpráv, takový druh. Toto je nejúčinnější, když základní pohled je indexované zobrazení - nemusíte nutně vytvářet další indexované zobrazení, které bude reprezentovat data s mírně odlišným seskupením, protože nyní platíte za údržbu indexu dvakrát tam, kde je výkon pravděpodobně přiměřené proti původnímu pohledu.

Pokud se jedná pouze o vnořená zobrazení, ve kterých si vyberete *, ale změníte pořadí nebo vrchol, zdá se, že by to bylo lépe zapouzdřeno jako uložená procedura s parametry (nebo funkce s inline tabulkou) než banda vnořených pohledů. IMHO.

26
Aaron Bertrand

Pozdější verze SQL (2005+) se zdají být lepší při optimalizaci využití pohledů. Pohledy jsou nejlepší pro konsolidaci obchodních pravidel. EG: kde pracuji, máme databázi telekomunikačních produktů. Každý produkt je přiřazen k sazebníku a tento sazebník může být zaměněn a sazby v sazebníku mohou být aktivovány/deaktivovány, jakmile se sazby zvýší nebo změní.

Abychom to usnadnili, můžeme vytvořit vnořené pohledy. 1. pohled právě spojuje plány sazeb s jejich sazbami pomocí jakýchkoli tabulek, které jsou potřeba, a vrací veškerá potřebná data, která budou potřebovat další úrovně pohledů. 2. pohledy mohou izolovat pouze aktivní sazebníky a jejich aktivní sazby. Nebo jen ceny zákazníků. Nebo zaměstnanecké sazby (pro zaměstnanecké slevy). Nebo obchodní vs. rezidenční sazby zákazníků. (sazebníky se mohou komplikovat). Jde o to, že pohled na nadaci zajišťuje, že naše celková obchodní logika sazebníků a sazby jsou správně spojeny na jednom místě. Další vrstva pohledů nám dává větší zaměření na konkrétní plány sazebníku (typy, aktivní/neaktivní atd.).

Souhlasím s tím, že názory mohou ladit nepořádek, pokud vytváříte dotazy a názory současně. Pokud však používáte vyzkoušené zobrazení důvěryhodné, usnadňuje ladění. Víte, že pohled již prošel vyzváněním, takže víte, že problém pravděpodobně nezpůsobuje.

Problémy však mohou přijít s vašimi názory. "co když je produkt spojen pouze s neaktivní sazebníkem?" nebo „co když sazebník obsahuje pouze neaktivní sazby?“ No, to se může chytit na front-end úrovni s logikou, která zachytí chyby uživatele. Msgstr "Chyba, produkt je neaktivní sazebník ... prosím opravte". Můžeme také spustit audity dotazů, abychom je před fakturační kontrolou dvakrát zkontrolovali. (vyberte všechny plány a nechte se připojit k aktivnímu zobrazení sazebníku. Vraťte pouze plány, které nemají aktivní plán sazebníku, jako problémy, které je třeba řešit).

Dobrá věc na tom je zobrazení, které vám umožní velmi kondenzovat dotazy na hlášení, fakturaci atd. Můžete mít zobrazení zákaznického účtu, pak zobrazení pouze na úrovni 2 aktivních zákazníků. Tým, který s ohledem na adresu zákazníka. Tým, který se podíval na produkt (y) (připojil se na jaký produkt (y) zákazník má). Tým, který si prohlédne plán produktů. Tým, který s ohledem na funkce produktu. Zobrazit, zobrazit, zobrazit, každá pokusná n-chyba, aby byla zajištěna integrita. Váš konečný dotaz pomocí pohledů je velmi kompaktní.

upravit:

Jako příklad toho, jak by byl pohled lepší než pouhý dotaz na tabulky ... měli jsme dočasného dodavatele, aby provedl nějaké změny. Řekli mu, že na věci existují názory, ale rozhodl se vyrovnat všechny jeho dotazy. Fakturace způsobovala některé z jeho dotazů. Stále dostávali vícenásobné tarify a sazby za věci. Ukázalo se, že jeho dotazy chyběly kritéria, která by umožňovala vyúčtování sazeb pouze v případě, že byly mezi počátečním a koncovým datem, o kterém měl tarifní plán použít tyto sazby během. Jejda. Kdyby použil názor, už by tuto logiku zohlednil.

V zásadě musíte zvážit výkon vs. zdravý rozum. Možná můžete dělat všechny druhy fantastických věcí pro zvýšení výkonu databáze. Ale pokud to znamená, že je to noční můra pro novou osobu, která má převzít/udržet, opravdu to stojí za to? Opravdu to stojí za to, že nový chlap musí hrát rána, musí najít všechny dotazy, které potřebují, aby se jejich logika změnila (a riskovat, že zapomene/tloustne), b/c někdo rozhodl, že názory jsou „špatné“ a nekonsolidovalo nějakou základní obchodní logiku do té, která by se dala použít ve 100 dalších dotazech? Je to opravdu na vašem podnikání a na vašem týmu IT/IS/DB. Ale já bych raději jasnost a konsolidaci z jednoho zdroje před výkonem.

7
blah blah

Skutečným problémem nejsou vnořené pohledy samy o sobě. Skutečným problémem je množení vnořených pohledů, protože vývojáři vytvářejí další vylepšení stávajících pohledů. Našel jsem dotazy se 4 vrstvami vnořeného pohledu, které se skutečně připojily k jednomu z pohledů ve své definici. Naše tendence vyjít snadnou cestou ven, než analyzovat a vyřešit problém, je kořenem problému.

4
Ray

V mém prostředí replikujeme mnoho tabulek z produkčního serveru na server sestav. Na serveru sestav máme spoustu pohledů založených na replikovaných produkčních tabulkách A jsou vnořeny. Před zahájením replikace musíme odstranit všechna zobrazení, abychom replikaci umožnili (používáme přetažení a vytváření, protože struktura tabulek se ve výrobě často mění). Po ukončení replikace musíme znovu vytvořit všechna zobrazení.

Nyní je tu zábavná část: Protože mnoho pohledů je vnořeno, musíme je znovu vytvořit v určitém pořadí. Při provádění jakýchkoli změn v definici pohledů musíme věnovat pozornost udržování správného pořadí při obnově. Je to celkem nepořádek. Pokud používáte replikaci nebo jednoduše přetáhnete a znovu sestavíte tabulky, které jsou zdrojem pro zobrazení, rozhodně nedoporučuji používat vnořená zobrazení.

Výkon je další věc. Pohledy, které jsou založeny na jiných pohledech, nejsou ničím jiným než několika dotazy k provedení. Je snazší dát dohromady větší dotaz, vytvořit práci a vytvořit z něj tabulku. Usnadňuje a zlepšuje výkon.

0
Narwhal