I started off by putting the business logic in ttable descendants and
datamodules. However I now prefer it in Stored Procedures.
It is fast.
Future programmers cant stuff it up so easily with respect to event
order changing in dbaware components and windows. I have had
developers add a new table and forget to apply the correct transaction
to it. When the code is in the SP, there is no such problem, you add
another table inside and the transaction is automatically handled.
When support people are tempted to tweak something outside the app, the
logic still works.
Reports, app and triggers can utilise the same logic.
3 Tier approach is not required as the database is almost becoming the app.
If you stuff up the logic, it can be fixed online instead of recompiling
the app.
Incidentally, do others know that it is possible to add calculated
fields in firebird/interbase that actually obtain their value from
stored procedures. It makes the database very powerful. The drawback
is that you better not do select * accidentally. :-)
Richard Vowles wrote:
Its funny isn't it that architecturally all evidence says "don't put
your stuff in stored procedures" - it is hard to port and impossible to
scale. On the other hand, every vendor wants you to do it because it
ties you to them :-)
SO maybe I should promote stored procedures in InterBase? Rohit.....
---
Richard Vowles, Solutions Architect, Borland New Zealand
email: [EMAIL PROTECTED]
phone: +64-9-9184573
cell: +64-21-467747
other: MSN [EMAIL PROTECTED], skype: rvowles
blog: http://www.usergroup.org.nz/blogs/selectBlog.html?id=39769
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Neven MacEwan
Sent: Thursday, 1 June 2006 2:13 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Why InterBase
Richard
A bit self fulfilling this!
Richard Vowles wrote:
This is interesting - both Kylie and yourself have confirmed what I
have had experience - MS SQL's superior Stored procedure language wins
out on those who like to put a bit (or a lot) of code in the database
engine.
I'm not big on stored procedures, but that is probably because I focus
on InterBase and the stored procs are limited.
Richard
---
Richard Vowles, Solutions Architect, Borland New Zealand
email: [EMAIL PROTECTED]
phone: +64-9-9184573
cell: +64-21-467747
other: MSN [EMAIL PROTECTED], skype: rvowles
blog: http://www.usergroup.org.nz/blogs/selectBlog.html?id=39769
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Jeremy Coulter
Sent: Thursday, 1 June 2006 12:04 a.m.
To: 'NZ Borland Developers Group - Delphi List'
Subject: RE: [DUG] Why InterBase
I used IB for about 6-7 months after going from MSSQL 7(this is like 6
years ago now), and HATED that IB didn't have a nice GUI interface. I
didn't like this whole "Domains" thing for variables, although I did
see the sense in it after a while and did use them, and REALLY hated
having to use some other DLL to get any decent functions to use when
doing Stored Procs.
When I left that job, after 6mths cos I hated the pace, and got my
current role which I have had for 6years now, I went back to MSSQL,
and now MSSQL
2005 is out, I REALLY like it !
I guess it's the old story of horses for courses. We do a LOT with
stored procs (well not so much me these days) and we are ready to
start getting in MSSQL 2k5 soon as we can.
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
--
Neven MacEwan (B.E. E&E)
Ph. 09 620 1356 Mob. 027 4749 062
New Address Details
===================
MWK Computer Systems
1 Taumata Rd
Sandringham
Auckland
Ph 620 1356
Fx 620 1336
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
