dotNETportal.cz

Zdravim panove, zacinam programovat vetsi aplikaci na DB, ve ktere bude vice sql prikazu. Otazka zni jak resit jejich ulozeni? Primo v kodu? Kdyz mam 500 sql prikazu a ted bych napr. zmenil nazev DB a nasledne musel prochazet cely kod, tak me z toho asi mrdne. Ukladat sql dotazy do externiho textoveho souboru mi prijde hardcore. Jak to resite vy?

Jakou používáte databázi? Pokud to bude běžet na SQL serveru tak bych určitě doporučoval používat uložené procedury namísto zasílání hotových dotazů aplikací.

Jinak nevím jak to máte dělané, ale někde v aplikaci by jste měl mít jeden connections string který mimo jiné obsahuje i název databáze, jméno, heslo atd. Pokud se změní název databáze (což se ale za normálních okolností zas tak často neděje), změníte to pouze na jednom místě v tom connection stringu.

Přesně jak píše kolega předemnou :) Spojení do DB mít uložené v config souboru. Aplikace a DB optimalizovat tak,aby ani jedna strana nedělala úkoly té druhé. Tj,úlohy,které jsou spíše pro DB nechat zpracovat DBMS(stored procedure,view,atd.). Já osobně pokud píši aplikace,která slouží čistě ke komunikaci s DB,tak dotazy,u kterých vím,že se mohou během využívání změnit(a to i několikrát) ukládám také do config souboru - ničemu to nevadí,jelikož v něm žádná citlivá data nejsou a je pak snazší měnit jeden dotaz v config souboru než ho měnit přímo v kódu na x místech. Dle mého je důležité udělat důkladný koncept a návrh aplikace/databáze,a až poté se pustit do psaní kódu.

V planu je pouzit SQLite. Ten procedury neumi :-((. Ja sem to jmeno DB jen dal jako priklad. Asi spatnej tak treba jmeno sloupce ;-). Ja vim, ze se takove zmeny "temer" nedeji, ale chtel jsem proste vedet jak se to efektivne resi.

To je stejný problém jako u SQL Serveru Compact. V tom případě bych místo uložených procedur vytvořil příslušné metody v TableAdaptérech typového DataSetu, nebo zvážil použití nějakého O/R mapperu.

Prasárna! Mechanizmy výběru dat přesunout do uložených procedur a připojovací řetězec do konfiguračního souboru. Rovněž souhlasím s důsledným promyšlením celé struktury databáze do posledního detailu.

Já bych určitě zvážil použití O/R mapperu. Značně to ulehčí práci a vyvarujete se mnoha chybám. Poměrně dobré zkušenosti mám s entity frameworkem, samozřejmě můžete použít jiný O/R mapper (nhibernate.linq atd.). Pokud se jedná o malou databázi (10-20 tabulek), možná bych zvážil code first přístup + database migration. Ušetří to zase hodně práce.

inspirace zde:

http://www.asp.net/web-forms/tutorials/g...