Kenneth, > maybe i was jumping to conclusions - what i am saying is that a > rdbms has the capacity to implement a lot of business logic within > the rdbms itself, so one should attempt to put the maximum of the > business logic there, where it will be looked after by the db > itself rather than doing it in the application code where it is too > easy to miss things. If you dont do this, or if you duplicate what > the rdbms enforces in your application code, it makes more sense to > use a more lightweight storage solution.
Point clear. Considering I am working a data intensive app, I will put extra effort on properly enforcing business logic to my rdbms. > database design mandates that every row in a table must be unique. > Where there is a serial data type as the primary key, this holds > good even if every row was identical except for the serial id > field. This would be bad design. Therefore, for every table one has > to identify one row, or a combination of rows that has to be > unique. There are two approaches to this problem - one is to make > the unique field or combination of fields the primary key, and > specify the id field to be unique. The other way is the opposite. > And there is a never ending battle between proponents of 'natural' > primary keys and 'surrogate' primary keys. I see. Thanks for your clear explanation. Regards, Mike
