» »

[SQL, C#] dve proceduri z transkacijo

[SQL, C#] dve proceduri z transkacijo

robotek87 ::

Imam en objekt nakup, ki hrani informacije o nakupu...

class Nakup
{
   DateTime datum;
   ..
   ..
   ..
   List<IzdelekVKosarici> seznam;

}

class IzdelekVKosarici
{
   Guid ID;
   Guid ID_Izdelka;
   float kolicina;
}


V bazi imam dve tabeli
Nakup - ID, datum, kupec....
KupljeniIzdelki - ID, ID_nakupa, ID_izdelka, kolicina...

Pri shranjevanju imam trenutno narejeni dve proceduri (stored procedures) za vsako tabelo posebaj...

Problem se pojavi pri transkacijah (rollback za obe proceduri...)

Ima kdo kak predlog, kako narediti proceduro, katera bi lahko sprejela List? (da bi lahko shranil obe tabeli v eni proceduri...)
Oziroma ali obstaja še kak boljši način za transkacije?

Hvala ;)

krneki0001 ::

Ko opravi prva procedura ne sme narediti komita na bazi. Komit naredi šele naslednja, če pa ne naredi pravilno, pa naredi rollback. Vsaj tako lahko narediš na DB2 bazi.

Zakaj pa vse skupaj ne narediš kot eno proceduro?

BlueRunner ::

Poglej si metodo System.Data.Common.DbConnection.BeginTransaction ali pa razred System.Transactions.TransactionScope.

robotek87 ::

Glavna težava je v tem, da imam za Nakup en komit, za KupljeneIzdelke pa več komitov (ker je List).. torej rollback bi moral biti za vse KupljeneIzdelke ter za en Nakup :( Če bi se sam List ali Array dal nekako prenest v proceduro bi bilo idealno :)...

baza je pa MSSQL :|


edit:

Rešil problem, sem ustvaril svoj User-Defined Table Type (v bistvu nek tip tabele IzdelekVKosarici) tako lahko v proceduro kot parameter dobim cel DataTable.

Zgodovina sprememb…

klemen18 ::

A bi bil tok prjazn pa bi to men poslov na klemen18@dolenjska.com k jest tud delam to pa imam velike probleme, tako da sploh nevem če mi bo ratal nardit.

Se že v naprej zahvaljujem.

Hvala.
LP. Klemen

d-mon ::

Transakcijo mora upravljat tvoja poslovna logika in ne stored procedura.

Priporocam ti, da ne uporabljas stored procedur (ne bo delalo nic pocasneje) in ce jih ze v zacetku ne bi uporabil, do tega problema sploh ne bi prisel.

In pol delas nekaj takega:

class Nekaj
{
public void Shrani(IList<Nakup> nakupi)
{
try
{
//Begin transaction
foreach(Nakup n in nakupi)
{
//Validacija (ob napaki throw Exception)
//Shrani
}
//Commit
}
catch(Exception ex)
{
//Rollback
}
}
}
[D-mon]

robotek87 ::

klemen18 sem ti poslal...
d-mon zakaj bi bil tak način boljši od stored procedur? performance,varnost? - razen tega, da ne bi naletel na težavo...


Hvala vsem ;)

d-mon ::

Ena stvar je, da so nove baze optimizirane tako za adhoc sql stavke kot tudi za stored procedure in naceloma v performanci ni razlik.

Druga je pa ta, ko bos spremenil podatkovni model, bos po vsej verjetnosti spremenil tudi stored proceduro, in ker bos spremenil stored proceduro bos spremenil se program. Se pravi bo sprememba na treh mestih in ne samo na dveh. To ti poveca moznost napake.

Tretja stvar je, da ko enkrat zacnes pisati stored procedure kaj kmalu vanje zacnes tlacit tudi T-SQL (if stavki in podobno) in se ti poslovna logika razprsi na dva dela. Nekaj bos imel v stored procedurah, nekaj v programu.

Cetrta. Stored procedure je tezje debagirat, se posebej ce upostevas celotno poslovno logiko (ki je sedaj na dveh mestih).

Peta. Stored procedure so se spomnili v starih casih client/server sistemov, kjer je zaradi posodabljanja programa bilo treba posodobiti vse cliente (ki jih je bilo veliko) in je bilo smiselno del kode prestaviti na streznik. To je bil takrat pac SQL streznik in so izumili TSQL (PL/SQL in podobne zadeve). Amapk ta jezik je za pisanje poslovnih pravil zelo okoren, zato so kmalu presli na 3 nivojsko arhitekturo in so na srednjem nivoju zaceli uporabljati programske jezike tretje generacije (c++, c#, java...), ki so pa za implementacijo poslovne logike bistveno bolj fleksibilni. No in potem so se pocasi vse stvari zacele seliti na srednji nivo od security-ja pa tja do ne vem cesa se.

Sestic. Poglej kam se razvoj programske opreme odvija. Popularnost ORM-jev (ki sami generirajo sql stavke -- in ne klicejo stored procedur -- razen ce explicitno ne zahtevas), vizualnega programiranje poslovnih pravil (WWF) in vsega boga...Tako da je podatkovna baza ostala samo za to kar je namenjena - sistematicno shranjevanje podatkov.

Sedmic. V velikih sistemih se stremi k temu, da je podatkovni streznik cim manj obremenjen - se pravi naj samo shranjuje/bere podatke in ne dela nic drugega.

Osmic. Store procedure zavzamejo pomnilnik podatkovnemu strezniku in ga tako posredno obremenjujejo.

Pa se kaj bi se naslo.
Vec info v moji diplomi, ki se je dotaknila del tega tvojega problema:
http://de.scientificcommons.org/38083648
[D-mon]

robotek87 ::

d-mon hvala ti za tole:)

Bom se znebil teh procedur, ter naredil data access z LINQ... 8-)

GeeDee ::

Drugače pa:

using System.Data;
using System.Data.Common;
using System.Transactions;
.
.
.
using (TransactionScope scope = new TransactionScope())
{
using (DbConnectionScope db = new DbConnectionScope())
{
// Tvoja koda, kjer kličeš poljubno št. procedur na bazi
}

scope.Complete();
}

darkolord ::

Cetrta. Stored procedure je tezje debagirat
No v bistvu jih je precej lažje, tudi kot del programa, saj lahko enostavno nastaviš breakpoint v proceduri in jo razhroščuješ tako kot ostalo kodo.

Tako da je podatkovna baza ostala samo za to kar je namenjena - sistematicno shranjevanje podatkov.
Žal se baze vse prevečkrat uporabljajo samo tako, kot si napisal. Potem seveda pride do tega, da se (pre)velik kos podatkov prenese na clienta, kjer se potem lokalno (čist neoptimizirano) obdeluje in se za enako stvar porabi precej več resourcov. Aplikacije postajajo vedno počasnejše (dokler se hw razvija se to sicer navadno ne opazi toliko)
V ostalih zadevah gre seveda trend ravno v drugo smer - podatke za procesiranje se offloada na server.

Poleg tega je še ena prednost SP - po defaultu so parametrizirane, pa tudi dovoljenja se lahko določajo na nivoju SPjev.

Sicer uporabe SPjev v splošnem ne podpiram (razen da specifične zadeve, kjer se precej bolje obnesejo), je pa treba v obzir vzeti tudi prednosti, ki jih prinašajo

Zgodovina sprememb…

  • spremenilo: darkolord ()

GeeDee ::

Se strinjam z darkolordom. Vse je odvisno od namenske situacije. Obstaja tudi logika razvoja, ki pravi, da čim več podatkovne logike prenesti na podatkovni strežnik... kot pravim, vse je odvisno od situacije.


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Ne-relacijska baza

Oddelek: Programiranje
193838 (2461) mitjaR
»

Triger pokliče java funkcijo?

Oddelek: Programiranje
111431 (1194) krneki0001
»

SQL injection

Oddelek: Izdelava spletišč
121867 (1665) CCfly
»

SQL vprašanje

Oddelek: Izdelava spletišč
302537 (2100) jerneju
»

Izvorna koda mojega par dnevnega dela; ce jo malo pokomentirate :) (strani: 1 2 )

Oddelek: Programiranje
606152 (4497) Microsoft

Več podobnih tem