Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it better to check for allowed domain values on the frond end or let the database engine handle the domain integrity. For example If you have a data entry form for employee, is it better to check for allowed values on the data entry form before submitting the data to the database assuming network IO is not a big issue. What if there are lots of checks to be performed, would the engine be faster or would checking the value on the front end take the load of the dB engine?

share|improve this question
up vote 7 down vote accepted

It is best to have checks in both places.

Have checks on the client side in order to give direct feedback to the client without having to roundtrip to the server.

Have checks on the server side because you can't trust the client (you never know if data has been spoofed, someone hacked your UI or whatever).

share|improve this answer
+1. Yes, or simply because of reuse of database calls (whether in a DAL or on the DB itself - SPROC). It is easy to reuse calls, especially checks, in other functions, and best to have consistant coal-face checks employed. A quarter of a century ago, my programming instructor (COBOL/370 Assembler/IMS db|dc/CICS/DB2) told us that we should always validate at both ends of any interface (data transfer) and it remains just as true today. – Wolf5370 Jul 13 '12 at 17:04
Great feed back thank you! – Irfarino Jul 14 '12 at 0:38

To me, the best place to check it is in two places. First on the UI (presentation layer), make sure the data entered meets the very basic requirements. For example, a user has to enter a date in a text box, the presentation layer would make sure the value entered is in fact a date.

The second place would be the service layer, or depending on your architecture, the business layer. The data entered in the UI would be placed into an object and sent down to the service layer (or business layer), which would enforce the business rules. For example, the date entered has to be after the current day. Other types of validation can occur here as well, no duplicate entries, and so on.

Once the data has been validated by the service layer then it will send it down to the repository (or data access layer) to be inserted into the database. I am not a real big fan of putting validation on the database. Mostly because it is next to impossible to unit test properly. The type of validation done on a database should really be limited to ensure foreign key integrity or unique indexes.

share|improve this answer
+1. This is one of the main benefits of using Stored Procedure/Programs at the database layer, it allows for better (and testable) validation at that layer too. I like to have the SPROC to the second level validation (if pos) and all myy SPROCS (any RDBMS) return a return code and message which I can check (through params as usual) on return in the DAL - I then pass this back to the BAL for business logic to "decide" what to do about it. It can often be more efficient to do it at the DB level too - though sometimes (especially for non DB held data) it is not possible or efficient. – Wolf5370 Jul 13 '12 at 16:59

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.