sql >> Databáze >  >> RDS >> Sqlserver

Jaké jsou výhody a nevýhody ponechání SQL v uložených procesech versus kód

Nejsem příznivcem uložených procedur

Uložené procedury jsou lépe udržovatelné, protože:* Nemusíte znovu kompilovat aplikaci v C#, kdykoli budete chtít změnit nějaké SQL

Nakonec to stejně překompilujete, když se změní datové typy nebo budete chtít vrátit sloupec navíc nebo cokoli jiného. Počet případů, kdy můžete „transparentně“ změnit SQL zespodu vaší aplikace, je celkem malý

  • Skončíte opětovným použitím kódu SQL.

Programovací jazyky, včetně C#, mají tuto úžasnou věc, nazývanou funkce. To znamená, že můžete vyvolat stejný blok kódu z více míst! Úžasný! Do jednoho z nich pak můžete vložit znovu použitelný kód SQL, nebo pokud chcete získat opravdu špičkovou technologii, můžete použít knihovnu, která to udělá za vás. Věřím, že se jim říká Object Relational Mappers a jsou v dnešní době docela běžné.

Opakování kódu je to nejhorší, co můžete udělat, když se snažíte vytvořit udržovatelnou aplikaci!

Souhlasím, a proto jsou storageprocs špatná věc. Je mnohem snazší refaktorovat a rozložit (rozdělit na menší části) kód na funkce než SQL na... bloky SQL?

Máte 4 webové servery a spoustu aplikací pro Windows, které používají stejný kód SQL Nyní jste si uvědomili, že je malý problém s kódem SQL, takže raději...... změňte proc na 1 místě nebo pošlete kód všem webové servery, přeinstalujte všechny desktopové aplikace (může pomoci clickonce) na všech oknech

Proč se vaše aplikace pro Windows připojují přímo k centrální databázi? Vypadá to jako VELKÁ bezpečnostní díra a úzké hrdlo, protože to vylučuje ukládání do mezipaměti na straně serveru. Neměli by se připojovat přes webovou službu nebo podobně jako vaše webové servery?

Takže vložit 1 nový sproc nebo 4 nové webové servery?

V tomto případě je snazší prosadit jeden nový sproc, ale podle mých zkušeností 95 % „zatlačených změn“ ovlivňuje kód a ne databázi. Pokud ten měsíc posíláte 20 věcí na webové servery a 1 do databáze, stěží ztratíte mnoho, pokud místo toho pošlete 21 věcí webovým serverům a nulu do databáze.

Snazší kontrola kódu.

Můžete vysvětlit jak? Tomu nerozumím. Zvláště vidět, že sprocs pravděpodobně nejsou pod kontrolou zdroje, a proto k nim nelze přistupovat prostřednictvím webových prohlížečů SCM a tak dále.

Další nevýhody:

Storedprocs žijí v databázi, která se navenek jeví jako černá skříňka. Jednoduché věci, jako je chtít je umístit pod kontrolu zdroje, se stávají noční můrou.

Je tu také otázka pouhého úsilí. Mohlo by mít smysl rozdělit vše na milion úrovní, pokud se snažíte svému generálnímu řediteli zdůvodnit, proč je stálo jen 7 milionů dolarů vybudování některých fór, ale jinak je vytváření uloženého procesu pro každou maličkost jen oslí práce navíc. prospěch.



  1. Konfigurace oprávnění ScaleGrid na AWS pomocí šablony zásad IAM

  2. Analytics s MariaDB AX – tThe Open Source Columnar Datastore

  3. Jednoduchý případ použití pro indexy na primárních klíčích

  4. ORA-02287:pořadové číslo zde není povoleno