Validering av forretningslogikk

[Kul drittunge]

Vi kommer antagelig nå snart til å vurdere litt forskjellige fremgangsmåter for å håndtere innlegging og uthenting av data på en konsistent måte, og i den forbindelse har jeg gjort meg opp noen tanker selv.

 

Men jeg skulle likt å høre hvordan andre går frem, for å høste litt uavhengig inspirasjon. Derav et veldig åpent spørsmål innledningsvis.

 

Tanker og meninger?

[blackbrrd]

Det er ikke så lett å vite hva du spør etter. Spørsmålet ditt er rimelig vagt.

[Manfred]

Det er ikke så lett å vite hva du spør etter. Spørsmålet ditt er rimelig vagt.

Det var mildt sagt...

[roac]

Som sagt, dette var sinnsykt vagt formulert. Det eneste man egentlig kan svare her er at du bør bruke de verktøy og metoder du har til rådighet for å sørge for konsistens, herunder transaksjoner, prosedyrer, funksjoner, view med måte (og for all del ikke begyn å nøste og joine store views) og unngå dynamisk SQL.

[Kul drittunge]

Vel, var vel litt vag med en hensikt.

 

Når det gjelder validering av uthenting, så tenker jeg at vi begynner med å kjøre på eksempelvis:

 

select n.*
from tblNode n 
inner join dbo.validateNode () vn on vn.nodeid = n.nodeid

 

Her er da validateNode ():

alter function [dbo].[validateNode]
(	

)
returns table
as return
select n.nodeid
from tblNode n 
where 0 = 0
	and 
	(
		n.customerid > 0
		and n.deleted = 'false'
	)
	and	
	(
		n.onweb = 'true'
		or n.onweb is NULL
	)			
	and	
	(
		n.fromdate <= getdate()
		or n.fromdate is null
	)
	and
	(
		n.todate >= getdate()
		or n.todate is null
	)

 

Fordelene her er da at man kan bare oppdatere betingelser i funksjonen, og slipper å gjøre det på samtlige spørringer.

 

Når det gjelder innlegging, tenkte jeg å basere meg på triggere, og da spesielt på after insert / update som går mot prosedyrer, slik at disse prosedyrene kan kjøres uavhengig av å ha tilgang til inserted.

Er sistnevnte en grei tanke?

 

Hvis jeg fremdeles er uklar, kan jeg heller komme med noen eksempler.

[roac]

Impulsivt svar: Jeez. Se på constraints og null-håndtering da mann (eller kvinne). Det er jo nettopp slike ting som dette det er beregnet på:

 

Check Constraints

isnull()

 

IMHO: Triggere bruker du kun til validering dersom ingen andre metorder fungerer.

Endret 29. april 2008 av roac

[kaffenils]

Fordelene her er da at man kan bare oppdatere betingelser i funksjonen, og slipper å gjøre det på samtlige spørringer.

 

Et av problemene med funksjoner er at de har en lei tendens til å ødelegge den effektive set-baserte eksekveringen, men jeg mener bestemt at så lenge du holder deg til Inline Table-valued Functions så vil SQL Server embedde select-statementet inn den spørringen som kaller funksjonen, og dermed så beholdes den set-baserte eksekveringen. Vær derimot forsiktig, og test nøye, hvis du bruke scalar funksjoner i spørringer, både i WHERE og SELECT delen. Scalar functions vil bl.a. hindre parallell prosessering av spørringer.

 

Jeg tror jeg vil konkludere med at så lenge du holder deg til Inline Table-valued Functions så er du på trygg grunn.

[Kul drittunge]

Impulsivt svar: Jeez. Se på constraints og null-håndtering da mann (eller kvinne).

 

Joda, men ting er litt mer kompliserte enn hva enkle beskrankningar kan ta seg av.

Og vår bruk av NULL kunne nok i en del tilfeller vært litt mer konsistent.

 

Ellers har kaffenils rett, inline koker seg rett ned i where-delen uten noe mer dikkedarer.

 

Tror det er nødt til å bli litt trigger-happy tilstander.

[blackbrrd]

Eksempelet i 2. posten til zY8pKPhR8XLJ burde vel være grei å legge inn som en CHECK constraint? (I postgresql tror jeg ikke du hadde hatt lov til å referere til getdate metoden dog)...

[Kul drittunge]

Uthenting?

 

Forøvrig en genial beskrivelse av forskjellen mellom isnull og coalesce.

 

ISNULL and COALESCE though equivalent, can behave differently. An expression involving ISNULL with non-null parameters is considered to be NOT NULL, while expressions involving COALESCE with non-null parameters is considered to be NULL.

 

Tror ikke jeg tør tenke for mye over den, av frykt for at hjernen min krasjer a la BLIT.

Endret 29. april 2008 av zY8pKPhR8XLJ

[blackbrrd]

Det er i sånne tilfeller man begynner å vurdere å bruke CASE setninger istedet... De er ihvertfall rimelig lette å forstå uten noe mer forklaring. F.eks

 

CASE WHEN a IS NULL THEN 0.00 ELSE a END

[kaffenils]

...while expressions involving COALESCE with non-null parameters is considered to be NULL.

 

Javel? Den skjønte jeg absolutt ikke. Har du noen eksempler på hva som menes med dette?

 

Hvordan kan coalesce(1,2,3) validere til NULL?

[Kul drittunge]

select isnull (null,null)
go
select coalesce (NULL, NULL)
go
declare @foo bit

select coalesce (@foo, null)

 

(1 row(s) affected)

Msg 4127, Level 16, State 1, Line 1

At least one of the arguments to COALESCE must be a typed NULL.

 

(1 row(s) affected)

Endret 30. april 2008 av zY8pKPhR8XLJ

[kaffenils]

select isnull (null,null)
go
select coalesce (NULL, NULL)
go
declare @foo bit

select coalesce (@foo, null)

 

(1 row(s) affected)

Msg 4127, Level 16, State 1, Line 1

At least one of the arguments to COALESCE must be a typed NULL.

 

(1 row(s) affected)

 

Mulig jeg er dum, men jeg ser ikke hva eksempelet ditt har med "expressions involving COALESCE with non-null parameters is considered to be NULL."

 

Jeg fant derimot en artikkel som viser endel forskjeller her: http://databases.aspfaq.com/database/coale...isnull-sql.html

[Kul drittunge]

Bokstavelig NULL har ingen type, fordi det er NULL.

En variabel har en type, som kan være av typen NULL.

Endret 30. april 2008 av zY8pKPhR8XLJ

[kaffenils]

Bokstavelig NULL har ingen type, fordi det er NULL.

En variabel har en type, som kan være av typen NULL.

 

Ja det vet jeg jo, og det fremkommer jo av feilmeldingen. Men det har jo ingenting med at COALESCE antas å være null, mens ISNULL antas å være not null. Dette har heller med hvordan de kan brukes i kalkululerte kolonner med primary key constraint.

 

En annen forskjell, som jeg ikke visste om og som fremkommer av artikkelen) er at coalesce bruker datatypen med høyest presedens, men isnull bruker datatypen til første parameter.

 

Men uansett så har jo ikke dette noe med det opprinnelige spørsmålet ditt

[Kul drittunge]

En annen forskjell, som jeg ikke visste om og som fremkommer av artikkelen) er at coalesce bruker datatypen med høyest presedens, men isnull bruker datatypen til første parameter.

 

Høh. Snedig eller snodig?

 

select coalesce (null, 1.0, 1)
select coalesce (null, 1, 1.0)

---------------------------------------

1.0

 

 

---------------------------------------

1.0

 

Nuvel, tror egentlig det ikke er så veldig mye å diskutere, med mindre folk har store innsigelser mot bruk av triggere.

Litt av kluet her er å ivareta automatisk setting av verdier, ved import til tabeller.

Da skal det nemlig opprettes endel ting og tang, og det blir helt umulig å få til dette med å gå mot applikasjonen, ergo gjenstår det kun to valg, som er enten å deaktivere alt av ting som ivaretar beskrankningar mens man importerer, og så bygge det hele opp med reparasjonsskript etterpå, eller mer formålstjenelig, å snekkre en automatisk ivaretagelse av disse.

 

Beskrankningar er forøvrig et genialt norsk ord for constraints, som dessverre blir brukt alt for sjelden.

Endret 30. april 2008 av zY8pKPhR8XLJ

[roac]

I så tilfelle at det er det som er problemstillingen, så kan man stille seg spørsmålet om du kanskje hadde vært mer tjent med å se på SSIS?

[Kul drittunge]

Er nytt for meg, men jeg kan jo kikke på det.

 

Hvilke erfaringer har folk med det?

Endret 1. mai 2008 av zY8pKPhR8XLJ

[roac]

Er nytt for meg, men jeg kan jo kikke på det.

 

Hvilke erfaringer har folk med det?

Jeg har i hvert fall god erfaring med det. Det kan ta litt tid å sette seg inn i tankegangen bak en dataflyt hvis du ikke allerede har jobbet med det, men når det er på plass så synes jeg det er et nydelig verktøy for import av data.