May 5, 2008 at 10:03 am
Our organization is in the process of reviewing a call tracking type software by Front Range (ITSM). The product supposely does more than incident management but my concern is with the design more than anything. Since I'm the DBA I took a look at the back end and noticed
there is very little there. No stored procs, functions, views. Although tables have a primary key, referential integrity is not enforced with foreign keys or check constraints in any way. I can only assume the referential integrity in enforced within the client application. Would anyone like to comment on this type of design? I'm guessing database level objects (procs) are absent so the product is not tied to a particular RDBMS vendor.
May 5, 2008 at 11:58 am
As a database guy, I like to have as much data integrity managed by the database engine. This means constraints, focused data types, triggers, stored procedures, etc. in the database.
Now, that is not to say that it is wrong to move data integrity into a data access layer of an application. In fact, it is often the point of having a data access layer is to make an application relatively independant of the database technology being used. So, if you want to support a wide array of database engines, you need to manage this type of logic in an application layer.
This can be done correctly, and well. It can also be done poorly. If you are not finding orphaned records and invalid data in your database, I would not be extremely concerned that the foreign key constraints are being managed in the application.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply