#1 Is the system proprietary? If so, then do what ever you want. If
the system
is always only going to be on this DB. Then do what you want. If it is
targeted
to be multi DB compliant, put the business rules in a third tier (even
if it is only
a logical third tier in your client ap.

#2 When anyone says always, they are often wrong. These are called
surrogate
keys. Use surrogate keys when appropriate. Sometimes they are and
sometimes
they aren't.

Nico Callewaert wrote:

>Hi,
>
>A few days ago, I had a visit from mr. consultant again :-)
>He analyzed the database and made a report of it, here are the
>remarks that I would like to have a second opinion of.
>
>1) Don't use triggers and stored procedures, all the DB logic should
>exist in your application ?
>
>For me I thought good designers use the full power of the DBMS
>engine ?
>
>2) A primary key should not have any meaning related to the data in
>the table. So, that means all primary keys of all tables should be
>build up out of generators.
>
>The primary key of my customers table is the customer no. Is that
>wrong ??
>
>Thaks for comments, Nico
>
>
>
>To unsubscribe from this group, send an email to:
>ib-support-unsubscribe@egroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>

--
Thomas Miller
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com