it-swarm-eu.dev

Uložené procedury jsou špatnou praxí v jedné z největších světových konzultačních firem v oblasti IT softwaru?

Pracuji na projektu v jedné z nejlepších světových 3 IT konzultačních firem a agentura DBA mi řekla, že stavově uložené postupy nejlepší praxe společnosti nejsou „nejlepší praxí“. To je v rozporu se vším, co jsem se naučil.

Uložené procedury vám umožňují opětovné použití kódu a zapouzdření (dva pilíře vývoje softwaru), zabezpečení (můžete udělit/zrušit oprávnění pro jednotlivý uložený proces), chránit vás před útoky SQL injekcí a také pomoci s rychlostí (i když to DBA řekl, že počínaje serverem SQL Server 2008, který zkompiluje i běžné dotazy SQL, pokud jsou spuštěny dostatečně krát).

Vyvíjíme komplexní aplikaci pomocí metodiky Agile pro vývoj softwaru. Může někdo vymyslet dobré důvody, proč by nechtěl používat uložené procs? Můj odhad byl, že DBA nechtěla udržovat tyto uložené proci, ale zdá se, že existuje příliš mnoho negativ, které by takové rozhodnutí o návrhu ospravedlňovaly.

152
user22453

Podle mých zkušeností s prací na velmi velkých projektech musíte mít jasno v tom, kde žije obchodní logika. Pokud povolíte prostředí, ve kterém mohou jednotliví vývojáři vkládat obchodní logiku do vrstvy obchodních objektů nebo do uložené procedury, jak to považují za vhodné, bude velká aplikace obtížně srozumitelná a udržovatelná.

Uložené procedury jsou skvělé pro urychlení určitých operací DB. Mým architektonickým rozhodnutím je ponechat veškerou logiku v obchodní vrstvě aplikace a cíleně využívat uložené procedury, aby se zlepšil výkon tam, kde to benchmarking naznačuje, že je to opodstatněné.

282
Eric J.

Některá pozorování

Uložené procedury umožňují opětovné použití kódu a zapouzdření (dva pilíře vývoje softwaru),

Pouze pokud je použijete správně v kontextu, ve kterém mají být použity. Stejné tvrzení lze říci o funkcích (ve strukturovaném programování) nebo metodách (v objektově orientovaném programování), a přesto vidíme 1K funkce a mega-ass objekty.

Artefakty vám tyto výhody neposkytují. Správné použití těchto artefaktů je to, co tyto výhody přináší.

zabezpečení (můžete udělit/zrušit oprávnění pro jednotlivý uložený proces),

Ano. To je dobrý bod a jeden z hlavních důvodů, proč mám uložené procedury rád. Poskytují jemnější kontrolu přístupu než to, čeho lze obvykle dosáhnout pouze pomocí zobrazení a uživatelských účtů.

chrání vás před útoky SQL injekcí,

To není specifické pro SP, protože pomocí parametrizovaných příkazů SQL a čištění vstupu můžete dosáhnout stejné úrovně ochrany. Použil bych SP kromě těchto, nicméně, jako záležitost "hloubky zabezpečení" .

a také pomoci s rychlostí (i když DBA řekl, že počínaje SQL Server 2008, že i běžné dotazy SQL jsou kompilovány, pokud jsou spuštěny dostatečně krát).

Toto je vysoce specifické pro dodavatele databáze, ale obecně je vaše DBA správná. Příkazy SQL (statické nebo parametrizované) se kompilují. SP vám pomohou, pokud chcete/potřebujete agregovat a vypočítat data, která nemůžete dělat s jednoduchými příkazy SQL, ale jsou pevně integrovány s SQL a nezaručují zpáteční cestu na aplikační server.

Dobrým příkladem je dotazování dat na dočasný kurzor (nebo kurzory), ze kterého se má spustit jiný SQL samotný. Můžete to udělat programově na aplikačním serveru, nebo můžete uložit více zpátečníky provedením v db.

To by však nemělo být normou. Pokud máte mnoho z těchto případů, pak je to známka špatného návrhu databáze (nebo vytahujete data z tak nekompatibilních databázových schémat napříč odděleními).

Vyvíjíme komplexní aplikaci pomocí metodiky Agile pro vývoj softwaru.

Agility se týká procesů softwarového inženýrství a správy požadavků, nikoli technologií.

Může někdo vymyslet dobré důvody, proč by nechtěl používat uložené procs?

Špatná otázka

Otázka je špatná a odpovídá otázce „existují dobré důvody k použití GOTO“? Na toto téma jsem s Niklausem Wirthem víc než s Dijkstrem. Dokážu pochopit, odkud pocházel Dijkstrův sentiment, ale nemyslím si, že je 100% použitelný ve všech případech. Stejné jako u obchodů procs a jakékoli technologie.

Nástroj je dobrý, pokud je dobře používán pro zamýšlený účel a je nejlepším nástrojem pro konkrétní úkol. Jeho použití jinak neznamená, že nástroj je špatný, ale že wielder neví, co dělá.

Správná otázka zní: „Jakému typu vzorů použití uložené procedury by se nemělo vyhýbat.“ Nebo „za jakých podmínek měl bych (nebo neměl) používat uložené procedury ". Hledání důvodů ne použití technologie znamená jednoduše vinu na nástroj, na rozdíl od toho, aby inženýrská odpovědnost byla umístěna přímo tam, kam patří - do inženýra.

Jinými slovy, jedná se o kopii nebo prohlášení o nevědomosti.

Můj odhad byl, že DBA nechtěla udržovat tyto uložené proci, ale zdá se, že existuje příliš mnoho negativ, které by takové rozhodnutí o návrhu ospravedlňovaly.

To, co dělají, pak promítá výsledky špatných technických rozhodnutí o nástrojích, které špatně použili.

Co dělat ve vašem případě?

Moje zkušenost je , když jsem v Římě, jako Římané .

Nebojuj to. Pokud lidé ve vaší společnosti chtějí označit prodejní postupy jako špatný postup, nechte je. Vezměte však na vědomí, že se může jednat o červenou vlajku v jejich technických postupech.

Typické označování věcí za špatnou praxi se obvykle děje v organizacích s tunami nekompetentních programátorů. Zakázáním určitých věcí se organizace snaží omezit škody způsobené interně jejich vlastní neschopností. Do prdele.

Generalizace jsou matkou všech upoutávek. Říká se, že uložené proci (nebo jakýkoli typ technologie) jsou špatnou praxí, to je zobecnění. Zobecnění jsou pro nekompetentní výhrůžky. Inženýři nepracují s očividným zobecněním. Provádějí analýzu případ od případu, provádějí analýzu kompromisů a provádějí technická rozhodnutí a řešení podle skutečností, které mají k dispozici, v kontextu, v němž mají vyřešit problém.

Dobrý inženýři neoznačují věci za špatnou praxi tak zobecňujícími způsoby. Dívají se na problém, vyberou nástroj, který je vhodný, kompromisy. Jinými slovy, dělají inženýrství.

Můj názor na to, jak je nepoužívat

  • Nevkládejte do nich komplexní logiku za shromažďování dat (a možná nějaké transformace). Je v pořádku do nich vložit nějakou logiku masírování dat nebo do agregovat výsledek více dotazů s nimi. Ale to je o tom. Cokoli jiného by se kvalifikovalo jako obchodní logika, která by měla sídlit někde jinde.

  • Nepoužívejte je jako jediný mechanismus obrany proti SQL injekci. Necháte je tam v případě, že jim něco špatného způsobí, ale před nimi by měla být řada defenzivní logiky - validace/drhnutí na straně klienta, validace/drhnutí na straně serveru, možná transformace na typy, které mají smysl ve vašem doménovém modelu, a konečně předání parametrizovaným příkazům (což by mohlo být parametrizované příkazy SQL nebo parametrizované uložené procedury.)

  • Nedělejte z databází jediné místo, které obsahuje váš obchod procs. S vašimi obchodními programy by se mělo zacházet stejně jako s vaším C # nebo Java zdrojový kód. To znamená, že zdroj ovládá textovou definici vašich prodejních proců. Lidé si nechtějí říkat, že prodejní proci nemohou být řízeni zdrojem - býčí brada, prostě nevědí, o čem to sakra mluví.

Můj názor na to, jak a kde je použít

  • Vaše aplikace vyžaduje data, která musí být transponována nebo agregována z více dotazů nebo pohledů. Můžete je odložit z aplikace do db. Zde musíte provést analýzu výkonu, protože a) databázové stroje jsou efektivnější než aplikační servery v těchto věcech, ale b) aplikační servery jsou (někdy) snáze škálovatelné horizontálně.

  • Řízení přístupu v jemném zrnu. Nechcete, aby se ve vašem db přidali nějaké idiotské kartézské spoje, ale nemůžete jen lidem zakázat provádění takového libovolného příkazu SQL, jako je tento buď. Typickým řešením je umožnit libovolné příkazy SQL ve vývojových prostředích a prostředích UAT a zároveň je zakázat v prostředích systest a production. Jakékoli prohlášení, které ho musí přimět k systestování nebo produkci, jde do procedury úložiště, kterou vývojáři a dbas kontrolují.

Jakákoli platná potřeba spustit příkaz SQL ne v úložišti proc prochází jiným uživatelským jménem/účtem a oblastí připojení (s použitím vysoce monitorovaným a odrazujícím).

  • V systémech, jako je Oracle, můžete získat přístup k LDAP nebo vytvořit symlinks do externích databází (řekněme volání proc store na db obchodního partnera přes vpn.) Snadný způsob, jak udělat kód špagety, ale to platí pro všechna programová paradigmata a někdy máte specifické požadavky na podnikání/prostředí, pro které je toto jediné řešení. Ukládat procesy pomáhají zaplnit tuto ošklivost pouze na jednom místě, v blízkosti dat a bez nutnosti přecházet na aplikační server.

Zda to spouštíte na db jako obchod proc nebo na aplikačním serveru, záleží na kompromisní analýze, kterou musíte jako inženýr provést. Obě možnosti musí být analyzovány a odůvodněny některým typem analýzy. Jde tak či onak jednoduše obviňovat druhou alternativu jako „špatnou praxi“, je to jen chromý inženýrský cop-out.

  • V situacích, kdy jednoduše nemůžete zvětšit aplikační server (.ie. Žádný rozpočet na nový hardware nebo cloudové instance), ale s dostatečnou kapacitou na db back-end (to je typičtější, že mnoho lidí si to připouští), vyplatí se přesouvat obchodní logiku pro ukládání proců. Není hezký a může vést k anemickým doménovým modelům ... ale pak znovu ... kompromisní analýza, to, co většina hackerů softwaru saje.

Ať už se to stane trvalým řešením nebo ne, je to specifické pro omezení pozorovaná v daném okamžiku.

Doufám, že to pomůže.

172
luis.espinal

Důvodem je to, že spoléhání se na vrstvu uložených procedur omezuje přenositelnost a váže vás k určité DB. Jako důvod se uvádějí také dodatečné náklady na údržbu. Také jsem se chtěl vyjádřit k tomuto bodu, který jste uvedl:

(uložené procedury) vás chrání před útoky SQL injekcí

Je to vlastně parametrizované dotazování, které vás chrání, což můžete snadno udělat pomocí prostého textu sql dotazování.

56
System Down

Některé z důvodů, proč souhlasím s uloženými proky, nejsou osvědčeným postupem.

  • Obchodní a aplikační logika by měla být v kódu, nikoli v databázi. Logika v DB vyvolává obavy.
  • Ve zbývajících aplikačních logikách nemůžete testované uložené procesy testovat stejně hladce jako kód v běžných projektech testování jednotek.
  • Uložené proci nepovažuji za vhodné pro testování prvního programování, když píšu kód.
  • Uložené procs není snadné ladit jako kód aplikace, když ladíte program v IDE.
  • Řízení verzí/ovládání zdroje SP vs. normální kód
48
Gilles

Uložené procedury umožňují opětovné použití kódu a zapouzdření (dva pilíře vývoje softwaru),

Ano, ale za cenu, že dokážeme splnit jiné agilní cíle v designu. Pro jednu věc je obtížnější je udržovat. Pokud je projekt, na kterém pracuji, náznakem, pravděpodobně skončí s několika nekompatibilními SP, které v zásadě vykonávají stejnou práci, bez jakéhokoli prospěchu.

chrání vás před útoky SQL injekcí,

Ne. Ne. Nemůžu ani začít hádat, odkud tento nápad mohl přijít, jak jsem to slyšel říkat často, a prostě to není pravda. Může to zmírnit určité typy útoků SQL injekcí, ale pokud nepoužíváte parametrizované dotazy, nezáleží na tom. Stále mohu '; DROP TABLE účty; -

a také pomoci s rychlostí (i když DBA řekl, že počínaje SQL Server 2008, že i běžné dotazy SQL jsou kompilovány, pokud jsou spuštěny dostatečně krát).

Obvykle se také kompilují, když používáte připravené parametrizované příkazy (alespoň s několika databázemi, které jsem použil). V době, kdy aplikace začne provádět dotaz (nebo obzvláště při provádění stejného připraveného dotazu vícekrát), je jakákoli výhoda výkonu, o které si myslíte, že váš SP má, zcela).

Důvodem pouze použití uložené procedury IMHO je situace, kdy je třeba vytvořit složitý, vícestupňový dotaz, který bude vycházet z více seřazených zdrojů. SP by neměla obsahovat logiku rozhodování na nízké úrovni a měla by nikdy jednoduše zapouzdřit jinak jednoduchý dotaz. Neexistují žádné výhody a pouze mnoho nedostatků.

Poslouchejte svůj DBA. Ví, co se děje.

23
greyfade

Všechny tři společnosti, které pracuji pro použité uložené procedury pro jejich aplikační logiku s SQL Serverem. Opravdu jsem to neviděl jinak. Ale pro mě jsou velký nepořádek. Obvykle neexistují velmi dobrá zařízení pro zpracování chyb nebo zařízení pro opakované použití kódu s uloženými procedurami.

Řekněme, že máte uloženou proceduru, která vrací datovou sadu, kterou chcete použít, jak ji můžete použít v budoucích uložených procedurách? Mechanismy na serveru SQL Server nejsou příliš dobré. EXEC INTO ... funguje pouze na jednu nebo dvě úrovně) vnoření (nyní zapomínám). Nebo musíte předdefinovat pracovní stůl a nechat jej klíčovat. Nebo musíte předem vytvořit dočasnou tabulku a nechat ji naplnit procedurou. Ale co když dva lidé nazývají dočasnou tabulku stejnou věc ve dvou různých postupech, které nikdy neplánovali použít současně? V jakémkoli běžném programovacím jazyce můžete pouze vrátit pole z funkce nebo přejděte na objekt/globální strukturu sdílenou mezi nimi (s výjimkou funkčních jazyků, kde byste vrátili datovou strukturu na rozdíl od pouhé změny globální struktury ... )

A co opětovné použití kódu? Pokud začnete vkládat běžné výrazy do UDF (nebo dokonce horších dílčích dotazů), zastavíte kód. Nemůžete zavolat uloženou proceduru pro provedení výpočtu pro sloupec (pokud nepoužíváte kurzor, předávejte hodnoty sloupce jeden po druhém a poté nějakým způsobem aktualizujte svou tabulku/datovou sadu). Takže v podstatě, abyste získali co nejlepší výkon, musíte vyjmout/vložit běžné výrazy na celé místo, což je noční můra údržby ... Pomocí programovacího jazyka můžete vytvořit funkci pro generování společného SQL a poté jej zavolat odkudkoli při stavbě řetězec SQL. Pak, pokud potřebujete upravit vzorec, můžete provést změnu na jednom místě ...

A co vyřizování chyb? SQL Server má mnoho chyb, které okamžitě zastaví provádění uložené procedury a některé dokonce vynucují odpojení. Od roku 2005 existuje pokus/úlovek, ale stále existuje řada chyb, které nelze zachytit. Totéž se stane s duplikací kódu v kódu pro zpracování chyb a vy opravdu nemůžete předávat výjimky tak snadno nebo je bublinovat na vyšší úrovně tak snadno jako většina programovacích jazyků .....

Také jen rychlost. Mnoho operací na datových sadách není orientováno na SET. Pokud se pokusíte dělat věci orientované na řádky, buď použijete kurzor, nebo použijete „kurzor“ (když vývojáři často dotazují každý řádek jeden po druhém a ukládají obsah do proměnných @ stejně jako kurzor. .. I když je to často pomalejší než kurzor FORWARD_ONLY). S serverem SQL Server 2000 jsem měl něco, co trvalo 1 hodinu, než jsem ho zabil. Tento kód jsem přepsal v Perlu a skončil za 20 minut. Když skriptovací jazyk, který je 20-80x pomalejší než C, kouří SQL ve výkonu, určitě nemáte žádné obchodní psaní řádkově orientovaných operací v SQL.

Nyní má SQL Server integraci CLR a mnoho z těchto problémů zmizí, pokud používáte uložené procedury CLR. Ale mnoho DBA neví, jak psát .NET programy nebo vypnout CLR kvůli bezpečnostním problémům a držet se Transact SQL .... I s CLR máte stále problémy se sdílením dat mezi více procedurami efektivním způsobem .

Obecně je také nejtěžší škálovat databázi. Pokud je veškerá vaše obchodní logika v databázi, pak když bude databáze příliš pomalá, budete mít problémy. Pokud máte obchodní vrstvu, můžete přidat více mezipaměti a více obchodních serverů pro zvýšení výkonu. Tradičně jiný server pro instalaci oken/linux a spuštění .NET/Java je mnohem levnější než nákup jiného databázového serveru a licencování více SQL Serveru. SQL Server má nyní více podporu klastrování, ačkoli původně neměl žádné. Pokud tedy máte spoustu peněz, můžete přidat klastrování nebo dokonce provést přepravu protokolů, abyste vytvořili více kopií pouze pro čtení. Ale celkově to bude stát mnohem víc, než jen mít zápis za mezipamětí nebo tak něco.

Podívejte se také na zařízení Transact-SQL. Řetězcová manipulace? Vezmu si každý den Java Třídu řetězců/Tokenizer/Scanner/Regex). Hash tabulky/propojené seznamy/Etc. Vezmu Java Sběratelské rámce atd. ... A stejné pro .NET ... Oba C # a Java jsou mnohem vyvinutější jazyky než Transact SQL ... Heck kódování pomocí Transact-SQL mě žárlí na C...

Na plus plus uložené procedury jsou efektivnější pro práci s velkým datovým souborem a použití více dotazů/kritérií k jeho zmenšení před návratem do podnikové vrstvy. Pokud musíte do klientské aplikace poslat spoustu obrovských datových sad a rozložit data u klienta, bude to mnohem neefektivnější než jen dělat veškerou práci na serveru.

Také uložené procedury jsou dobré pro bezpečnost. Můžete omezit veškerý přístup k podkladovým tabulkám a povolit přístup pouze prostřednictvím uložených procedur. U některých moderních technik, jako je XML, můžete mít uložené procedury, které provádějí dávkové aktualizace. Poté je veškerý přístup řízen uloženými procedurami, pokud jsou data zabezpečená/správná, data mohou mít větší integritu.

Argument SQL injection se už tak moc nepoužije, protože jsme parametrizovali dotazy na straně programovacího jazyka. Opravdu ještě předtím, než parametrizované dotazy trochu nahradily ("'", "" ""), fungovaly většinu času také (ačkoli stále existují triky, které můžete použít k překonání konce řetězce, abyste získali to, co chcete).

Celkově si myslím, že SQL a Transact SQL jsou skvělé jazyky pro dotazování/aktualizaci dat. Ale pro kódování jakéhokoli typu logiky, provádění manipulace s řetězci (nebo manipulace se soubory ... jste překvapeni, co můžete dělat s xp_cmdshell ....) prosím ne. Doufám, že najde budoucí místo, které většinou nepoužívá uložené procedury. Z hlediska udržovatelnosti kódu jsou noční můrou. Co se stane, pokud chcete přepínat platformy (i když opravdu, pokud jste platili za server Oracle/DB2/Sybase/Sql Server/atd., Můžete z nich získat vše, co z nich můžete udělat, pomocí každého proprietárního rozšíření, které vám může pomoci. ..).

Také překvapivě často není obchodní logika stejná. V ideálním světě byste vložili veškerou logiku do uložených procedur a sdíleli ji mezi aplikacemi. Ale docela často se logika liší v závislosti na aplikacích a vaše uložené procedury se nakonec stávají příliš složitými monolity, které se lidé bojí změnit a nechápou všechny důsledky. Zatímco s dobrým objektově orientovaným jazykem můžete kódovat vrstvu přístupu k datům, která má nějaké standardní rozhraní/háčky, které každá aplikace může přepsat podle svých vlastních potřeb.

18
Cervo

To byla oficiální linka, když jsem před několika lety pracoval pro jednu z pěti. Důvodem bylo, že jelikož jsou SP spojeny s konkrétními implementacemi (PL/SQL vs T/SQL vs ...), zbytečně omezují výběr technologií.

Poté, co jsem prožil migraci jednoho velkého systému z T/SQL na PL/SQL, chápu tento argument. Myslím, že je to ale trochu kachna - kolik míst opravd se stěhují z jedné databáze do druhé rozmaru?

17
DaveE

Jak verze uložené procedury na serveru?

Pokud přesunete uložené procedury na server z řízení verzí, vyhodíte uložený plán provádění.

Uložené procedury by neměly být upravovány přímo na serveru, jinak jak víte, co je skutečně spuštěno? Pokud tomu tak není, potřebuje implementační nástroj přístup k zápisu uložených procedur do databáze. Budete muset nasadit na každé sestavení (plán spuštění může být jiný)

Přestože uložené procedury nejsou přenosné, není ani SQL obecně (kdy bylo vidět Oracle data handling - uggghhh).

Pokud tedy chcete přenositelnost, vytvořte interní rozhraní API pro přístup k datům. Můžete to nazvat jako volání funkcí a interně se můžete vestavět do jakéhokoli žargonu, který chcete, pomocí parametrizovaných dotazů a lze jej ovládat podle verze.

12

To je v rozporu se vším, co jsem se naučil.

Možná budete muset dostat více. [úsměvy] Vážně, uložené proky byly na ústupu nejméně 10 let. Téměř od té doby, co n-vrstva nahradila klientský server. Pokles byl urychlen pouze přijetím OO jazyků jako Java, C #, Python atd.).

To neznamená, že uložené proci stále nemají své zastánce a zastánce - ale toto je dlouhodobá diskuse a debata. Není to nic nového a bude to pravděpodobně ještě nějakou dobu pokračovat; IMO, odpůrci uložených proců jasně vyhrávají.

Uložené procedury umožňují opětovné použití kódu a zapouzdření (dva pilíře vývoje softwaru)

Velmi pravdivé. Ale také slušně vytvořená vrstva OO).

zabezpečení (můžete udělit/zrušit oprávnění pro jednotlivé uložené proc)

I když to můžete udělat, jen málokdo to kvůli vážným omezením. Zabezpečení na úrovni DB není dostatečně podrobné, aby bylo možné provádět kontextová rozhodnutí. Vzhledem k režii výkonu a správy je neobvyklé mít také připojení pro jednotlivé uživatele - takže v kódu aplikace stále potřebujete určitou úroveň autorizace. Můžete použít přihlašování na základě rolí, ale musíte je vytvořit pro nové role, udržovat roli, kterou používáte, přepínat připojení tak, aby fungovala „na úrovni systému“, jako je protokolování atd. A nakonec, pokud vaše aplikace je vlastněna - stejně jako vaše připojení k DB.

chrání vás před útoky SQL injekcí

Nic víc, než dělat parametrizované dotazy. Což musíte třeba přesto dělat.

a také pomoci s rychlostí (i když DBA řekl, že počínaje SQL Server 2008, že i běžné dotazy SQL jsou kompilovány, pokud jsou spuštěny dostatečně krát).

Myslím, že to začalo v MSSQL 7 nebo 2000. Proběhlo mnoho debat, měření a dezinformací o uloženém proc vs. inline výkonu SQL - to vše soustředím pod YAGNI. A pokud to potřebujete, vyzkoušejte.

Vyvíjíme komplexní aplikaci pomocí metodiky Agile pro vývoj softwaru. Může někdo vymyslet dobré důvody, proč by nechtěl používat uložené procs?

Nemohu myslet na mnoho důvodů, pro které byste chtěli. Java/C #/libovolný 3. GL jazyk jsou všechny mnohem schopnější než T-SQL při zapouzdření, opětovném použití a splnitelnosti atd. Většina z nich je zdarma vzhledem k polovičnímu důstojnému ORM.

Také, vzhledem k radě "distribuovat podle potřeby, ale ne více" - myslím, že důkazní břemeno v těchto dnech je na SP obhájci.) Častým důvodem pro ukládání uložených proc heavy je to, že T- SQL je jednodušší než OO a obchod má lepší T-SQL devs než OO. Nebo, že DBA se zastaví ve vrstvě databáze a uložené procs jsou rozhraním mezi dev a DBA. Nebo dodáváte polotovar produkt a uložené procs mohou být uživatelsky přizpůsobené. Vzhledem k tomu, že některé takové úvahy nejsou, myslím, že výchozí pro jakýkoli projekt Agile SW bude v těchto dnech ORM.

9
Mark Brackett

S ohledem na všechny výše uvedené případy bych rád přidal ještě jeden. Volba SP) může také záviset na výběru lidí.

Osobně se cítím frustrovaný, když lidé vkládají velmi komplexní logiku SP a věřím, že takový SP je velmi složitý na údržbu a ladění). Dokonce i v mnoha případech se vývojář sám potýká problém při ladění kódu za (řekněme jazykovou část) je mnohem jednodušší než v SP.

SP by se měl používat pouze pro jednoduché operace. To je moje volba.

4
Rimbik

Chci pokrýt jak pro, tak i problémy s uloženými proc. Používáme je značně s LedgerSMB , a naším pravidlem je, s několika velmi konkrétními příponami, „pokud je to dotaz, udělej z něj uložený proc.“

Náš důvod pro to byl usnadnit opakované použití dotazů v různých jazycích. Neexistuje lepší způsob, jak to udělat upřímně.

Nakonec je otázka vždy na detailech. Díky dobře používaným a uloženým postupům je situace mnohem snazší a špatně používaná činí věci mnohem těžší.

Takže na straně ošidit.

  1. Jak se tradičně používá, uložené procedury jsou křehké. Používají-li samostatně, vytvářejí možnost přidávat do kódu chyby na místech, která jste neočekávali, z jiného důvodu, než že se změnila syntaxe volání. Používá-li se samostatně, je to trochu problém. Mezi vrstvami je příliš mnoho soudržnosti, což způsobuje problémy.

  2. Ano, je možné mít injekci intra-sproc sql, pokud děláte jakýkoli dynamický sql. Je špatné mít v této oblasti příliš sebevědomí, a proto je třeba mít v této oblasti značné zkušenosti s bezpečností.

  3. Změny rozhraní jsou poněkud problematické s uloženými procedurami z důvodu č. 1 výše, ale pokud se jedná o velké množství klientských aplikací, může to být velmi velká noční můra.

Výše uvedené je docela těžké popřít. Stávají se. Každý, pro-SP a anti-SP, měl pravděpodobně hororové příběhy týkající se těchto. Problémy nejsou neřešitelné, ale pokud jim nevěnujete pozornost, nemůžete je vyřešit (v LedgerSMB používáme lokátor služeb k dynamickému sestavování SP hovorů za běhu), abychom se vyhnuli výše uvedené problémy úplně. I když jsme pouze PostgreSQL, něco podobného by se dalo udělat i pro ostatní db).

Na pozitiva. Za předpokladu, že můžete vyřešit výše uvedené problémy, získáte:

  1. Možnost větší přehlednosti v sadách operací. To platí zejména v případě, že váš dotaz je velmi velký nebo velmi flexibilní. To také vede ke zvýšené testovatelnosti.

  2. Pokud již v této oblasti pracuji s vyhledávačem služeb, zjistím, že uložené procedury zrychlují tempo vývoje, protože uvolňují vývojáře aplikací od problémů db a naopak. To má určité potíže při správném jednání, ale není těžké to dělat.

  3. Opětovné použití dotazu.

Jo a pár věcí, které byste v SP nikdy neměli dělat:

  1. netransakční logika. Odeslali jste e-mail, že objednávka byla odeslána, ale transakce byla vrácena zpět ... nebo nyní čekáte na pokračování, než se e-mailový server přepne do režimu online ... nebo co je horší, vrátíte transakci zpět, protože nemůžete dosáhnout e-mailový server ....

  2. spousta malých dotazů volně spojených dohromady, posypaných procedurální logikou ....

4
Chris Travers

Je velmi obtížné přepínat značky databází a používat stejné uložené procedury.

Váš tým buď nemá DBA a nikdo jiný nechce mít nic společného s sql.

Toto není nic víc než soutěž v pissing programátor v DBA.

3
JeffO

Pro koho pracujete?

Odpověď může záviset na tom, kdo jste zaměstnáni, poradenská firma nebo společnost samotná. To, co je pro společnost nejlepší, často není nejlepší pro poradenskou firmu nebo jiného dodavatele softwaru. např. Inteligentní společnost touží mít trvalou výhodu oproti svým konkurentům. Naproti tomu dodavatel softwaru chce být schopen zajistit stejné řešení všem podnikům v konkrétním odvětví za nejnižší cenu. Pokud v tom uspějí, nebude pro klienta žádná čistá konkurenční výhoda.

V tomto konkrétním případě aplikace přicházejí a odcházejí, ale velmi často podniková databáze žije navždy. Jednou z primárních věcí, kterou RDBMS dělá, je zabránit nevyžádaným datům v vstupu do databáze. To může zahrnovat uložené procedury. Pokud je logika dobrá a je nepravděpodobné, že by se rok od roku změnila, proč by neměla být v databázi a udržovat ji interně konzistentní, bez ohledu na to, jaká aplikace je napsána pro použití databáze? O několik let později bude mít někdo dotaz, který se chce zeptat na databázi, a bude odpovědné, pokud nezabrání vstupu do DB.

Možná to má něco společného s tím, že vaše DBA pracuje pro poradenskou firmu. Čím přenosnější mohou svůj kód vytvořit, tím více mohou znovu použít kód z klienta na klienta. Čím více logiky si mohou v aplikaci spojit, tím více je společnost svázána s prodejcem. Pokud v tomto procesu zanechají velký nepořádek, dostanou zaplaceno za to, že jej vyčistí, nebo ho nikdy neuvidí. V každém případě je to pro ně vítězství.

enter image description here

Pro (hodně) více diskuse na obou stranách plotu si přečtěte diskusi na kódovací hrůza . FWIW Nakláním se ke straně těch, kteří se zasazují o SP.

3
user21007

Programování sólo, Nemůžu odolat psaní uložených procedur.

Používám především MySQL. Doposud jsem nepoužíval objektově orientované databáze jako PostGreSQL, ale to, co umím s SP v MySQL, je abstraktní struktura tabulky trochu pryč. SP mi umožňují navrhnout tyto primitivní akce, jejichž vstupy a výstupy nezmění se, i když se databáze pod ní změní změní.

Mám tedy postup s názvem logIn. Když se přihlásíte, vždy stačí projít username a password. Výsledek předaný zpět je celé číslo userId.

Když je logIn uložená procedura, mohu nyní přidat další práci, která se má provést při přihlášení, která se stane současně s počátečním přihlášením. V uložené proceduře najdu řadu příkazů SQL s vloženou logikou - snazší zápis než (volající prostředí FETCH) -> (získat výsledek) -> (volající prostředí FETCH) musíte udělat, když píšete svou stranu logického serveru.

2
bobobobo

Vždy je zdrojem problémů, aby se obchodní logika rozdělila mezi různé vrstvy pomocí různých programovacích jazyků. Sledování chyby nebo provádění změn je mnohem obtížnější, když musíte přepínat mezi světy.

To znamená, že vím, že společnosti, které se daří dobře, vkládají všechny obchodní logiku do PL/SQL balíčků žijících v databázi. Nejedná se o příliš velké aplikace, ale ani o triviální; řekněme 20K-100K LOC. (PL/SQL je pro tento druh systému vhodnější než T-SQL, takže pokud znáte pouze T-SQL, pravděpodobně vám nyní nevěřícně zavrtí hlavou ...)

2
user281377

To je další bod, který ještě nebyl zmíněn:

Nástroje pro generování kódu a nástroje pro reverzní inženýrství se s uloženými procedurami opravdu neumí dobře vyrovnat. Nástroj obecně neumí říci, co dělá proc. Vrací proc sadu výsledků? Několik výsledků? Načte své sady výsledků z několika tabulek a dočasných tabulek? Je proc pouze zapouzdřeným aktualizačním výkazem a nevrací nic? Vrací výsledkovou sadu, návratovou hodnotu a nějaký „výstup z konzole“?

Pokud tedy chcete použít nástroj k automatickému vytvoření vrstvy DTO a DAO pro přenos dat (jako například „tvůrce služeb“ v průběhu života), nemůžete to snadno udělat.

Navíc, ORM jako Hibernate nemohou opravdu správně fungovat, když je zdrojem dat SP. Přístup k datům je v nejlepším případě pouze pro čtení.

2
knb

IMO záleží. Uložené postupy mají své místo, ale nejedná se o osvědčený postup, ani se jim za každou cenu nelze vyhnout. Inteligentní vývojář ví, jak správně vyhodnotit danou situaci a zjistit, zda je uložená procedura odpovědí. Osobně jsem fanouškem použití ORM nějakého druhu (i základního, jako je surový Linq až Sql), spíše než uložených procedur, s výjimkou možná pro předdefinované zprávy nebo podobné, ale opět je to opravdu případ od případu.

2
Wayne Molina

Souhlasím s Markem, že komunita se už nějakou dobu opravdu vzdálila od uložených procedur. Zatímco mnoho bodů, které původní plakát upozorňoval na to, proč bychom mohli chtít používat SP, bylo platné najednou, bylo to docela dlouho a, jak řekl další plakát, prostředí se změnilo. Například si pamatuji jeden argument PRO, který používal SP „zpět v den“, byl nárůst výkonu dosažený, protože jejich plány provádění byly „předkompilovány“, zatímco dynamické SQL z našeho kódu muselo být „znovu kompilováno“ s každým provedením. To již neplatí, protože hlavní databáze se změnily, vylepšily, přizpůsobily atd.

To znamená, že používáme SP v mém aktuálním projektu. Důvodem je jednoduše to, že stavíme nové aplikace na existující databázi, která stále podporuje starší aplikace. V důsledku toho je provádění změn schématu velmi obtížné, dokud nevypneme starší aplikace. Rozhodli jsme se vědomě navrhnout naše nové aplikace na základě chování a pravidel požadovaných pro danou aplikaci a použít SP k dočasnému propojení s databází tak, jak bychom chtěli, a umožnit SP přizpůsobit se stávajícímu SQL . To vede k předchozímu příspěvkovému bodu, že SP usnadňují provádění změn na úrovni databáze, aniž by bylo nutné měnit kód aplikace. Použití SP jako implementace vzoru adaptéru pro mě určitě dává smysl (zejména vzhledem k mému současnému projektu), a může být jediným argumentem, který mohu skutečně vidět pro jejich použití dnes.

Fwiw, naším záměrem je odstranit SP, když je schéma aktualizováno. Ale stejně jako u všech ostatních v rozvoji společnosti uvidíme, jestli se to někdy stane! [úsměv]

1
SonOfPirate

Chci také zdůraznit, že uložené procedury využívají na serveru čas procesoru. Ne moc, ale některé. Část práce provedené v pracovním postupu lze provést v aplikaci. Měřítko vrstvy aplikace je snadnější než vrstva dat.

1

Jen jsem chtěl udělat stručný přehled toho, jak bych doporučil používání uložených procedur. Nemyslím si, že jsou vůbec špatnou praxí, a stejně jako jiní říkali, že by se měli používat ve správných situacích.

Vidím problémy, kde procedury psaní pro různé aplikace mohou být matoucí ve funkčnosti a oddělit obchodní logiku aplikace a vést k tomu, že databáze bude také více narušena a omezena.

Proto bych použil uloženou proceduru v relačních datově orientovaných úkolech specifických pro databázi. Jinými slovy, pokud existuje logika používaná pro databázové operace, která je konzistentní s daty pro jakoukoli aplikaci, může být použita uložená procedura, aby byla data uložena konzistentně (má smysl). Dobré příklady toho jsou: konzistentní protokolování, důsledná údržba, práce s citlivými informacemi atd.

Další úkoly, které manipulují s údaji tak, aby vyhovovaly potřebám aplikace, které následují silný datový model databáze, by měly být poté uloženy v jiné vrstvě obsahující obchodní logiku. Stručně řečeno, manipulace s daty specifické pro databázi by mohla použít uložené procedury, kde konzistence přesahuje model schématu integrity databáze.

0
Mark