Design your stored procedures like you'd design any other API. Just as
it would be silly to write an API for a program called AddTwoIntegers, I
wouldn't necessarily use it to wrap a simple update.

Good architecture and design tends to be platform agnostic. Your
database is an important component of your design, don't treat it as
just a bucket that holds some random data.

-----Original Message-----
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Zd
Sent: Saturday, April 19, 2008 7:31 AM
To: firebird-support@yahoogroups.com
Subject: [firebird-support] Good DB design: When to use stored
procedures?

Hi,

I've read in the FB papers that using stored procedures is highly
recommended because it optimizes network traffic and makes query
execution faster.

The question is:
I have over 50 tables in my DB and a lot of different queries acessing
them in different ways. If I started making stored procedures for each
dynamic query I'm executing now from my program, I'd end up with 200
stored procedures at least.

So is it a good idea to put EVERYTHING into stored procedures (like even
a simple update or insert into statement which puts a few rows to the
DB)?

Thanks:
Zd

Disclaimer: This message (including attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. RxStrategies, Inc. shall not be liable for the improper or incomplete transmission of the information contained in this communication or for any delay in its receipt or damage to your system. RxStrategies, Inc. does not guarantee that the integrity of this communication has been maintained nor that this communication is free from viruses, interceptions or interference.