> Essentially you are embedding data integrity logic in
> two places - which opens the door to inconsistency.
I am talking about using SPs at a higher level than just updating records.
A non-normalised database 'opens the door to inconsistency' but people still
design them that way, and make money at it.
> It is really applying OO paradigms to SQL Servers - Just consider
> Tables as collections of Objects, Row Clumns as properties, and then
> triggers as event driven methods.
And stored procedures as normal standard methods. I agree.
> Updating via stored procs (without triggers) is then
> analagous to writing delphi progs only using RTTI
I'm sorry I don't see this at all. Isn't using triggers instead of stored
procs like writing a Delphi program with no direct method calls, only
message handlers?
I was simply trying to say that complex data manipulation is a breeze in
Transact-SQL, and far simpler than other databases I have experienced. And
that a 3 tier application model is absolute overkill for many problems and
so you can't ALWAYS say "I think taking this appoach (updating thru strored
procs) is a 'poor mans' multi-tier".
It is clear I am looking at this from a different perspective to you, and as
such these generalisations aren't going to achieve much. I'll therefore
leave you to it.
Paul Ritchie.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"