Enforcing integrity using oracle specific data base commands .v. using fron

Question

Full subject : Enforcing integrity using oracle specific data base commands .v. using front end.
It ought to be generally accepted that it is better to enforce integrity directly in the data base using constraints, dependencies, triggers etc rather than leaving it to specific front end programmes.
In my view, the chief advantages - of enforcing integrity directly in the data base - are:
(1) No process can violate the integrity.
(2) Being server centric, these commands run on the server and so can be easily sized in one place.
(3) One time data migration (imports) into the system using Oracle tools or SQL commands would also need to conform to the integrity constraints. Thus an implementor would be assured that the basic data is alright.
I am faced with a situation where we are about to implement a new Oracle based package. During data migration, when we discovered that there are no integrity constraints built into the target data base, the package vendor asserted that it is not necessary to build in integrity into the database. This seems to be an extreme and risky view.
Further, it is argued by the package vendor that putting constraints directly in the data base would significantly increase the needed resources (RAM) on the server. In my view, this increase is trivial and anyway, hardware costs are crashing day by day.
In the absence of integrity checks in the data base, it seems to me that every program would have to extra zero value work to ensure integrity of the end user data. It will still never be complete.
I would like to know the pros and cons of implementing without integrity constraints.
OK.

Answer 1

AnanthaP wrote:
Full subject : Enforcing integrity using oracle specific data base commands .v. using front end.
It ought to be generally accepted that it is better to enforce integrity directly in the data base using constraints, dependencies, triggers etc rather than leaving it to specific front end programmes.
In my view, the chief advantages - of enforcing integrity directly in the data base - are:
(1) No process can violate the integrity.
(2) Being server centric, these commands run on the server and so can be easily sized in one place.
(3) One time data migration (imports) into the system using Oracle tools or SQL commands would also need to conform to the integrity constraints. Thus an implementor would be assured that the basic data is alright.
I am faced with a situation where we are about to implement a new Oracle based package. During data migration, when we discovered that there are no integrity constraints built into the target data base, the package vendor asserted that it is not necessary to build in integrity into the database. This seems to be an extreme and risky view.
Further, it is argued by the package vendor that putting constraints directly in the data base would significantly increase the needed resources (RAM) on the server. In my view, this increase is trivial and anyway, hardware costs are crashing day by day.
In the absence of integrity checks in the data base, it seems to me that every program would have to extra zero value work to ensure integrity of the end user data. It will still never be complete.
I would like to know the pros and cons of implementing without integrity constraints.
OK.It's a shame you seem to be so far into the process and committed to this vendor. I once had a vendor tell us his product would run on Oracle but they recommended MS SQL Server because "oracle can't handle more than 5 concurrent sessions." I made sure that vendor didn't make the short list.