× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 18 Oct 2012 16:02, Nathan Andelin wrote:
As I think about this, wouldn't you want to implement constraints
using program logic whether constraints are DB defined or not, in
order to validate data prior to "insert" or "update" <<SNIP>>

Perhaps, but...

Concurrency can easily vitiate the intention of such pre-check logic. Coding in a proactive manner can easily fail identically to how having coded in a reactive manner would not fail, but only due to its monitor and handling that error. Often there can be little value to the overhead of duplicated data checking; for both maintenance and performance.

That is, consider this scenario: Is the key I am about to insert already there? Lookup the key value. Not found, so let's insert. Argh! Duplicate key error on the write!

Thus since the code likely needs to handle the duplicate key error irrespective of this advance lookup having been coded to ensure the key value does not exist, then how much value was there in checking first in the application? Is it purely overhead? Perhaps just perform the insert and handle the exception only if\when it occurs.?

Obviously those scenarios where there can be no concurrency for the validated I\O, the application need not worry that its check is not going to be consummate with regard to concurrent operations. However because effectively the same work is going to be performed again by the database, questioning how much value there is in checking in the application first, still seems valid. I suppose for completeness or hope to avoid missing something, someone might want to ensure all of the checks are performed in both places. However having to 'code' corrections\additions\removals to the business rules once in the application and again in the database, might be somewhat burdensome. Of course this same dilemma for repeated and redundant data checking comes up for the user interface all the way down to the database.

Hmmm... that reminds me, that others have complained about the requirements for exclusive allocations to change business rules implemented in the database. So I suppose that is another possible con. However an application could be designed\coded to allow for enabling such changes to go into production with a small impact; even if not as small and simple as moving a new program into production.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.