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

When it comes to performance: What is the better way to validate the user input?

If you think about a phone number and you only want numbers in the database, but it could begin with a 0, so you will use varchar:

Is it better to check it via the entity model like this:

 @Size(min = 10, max = 12)
 @Digits(fraction = 0, integer = 12)
 @Column(name = "phone_number")
 private String phoneNumber;

Or is it better to use on the database side a CHECK (and no checking in the entity model) for the same feature?

share|improve this question

Performance is irrelevant for validating user input.

If it's taking too long to validate your form, your form has too many fields on it. They would have to number in the thousands (in most programming languages) before performance ever became a limiting factor.

Where you validate depends on what your goals are. If your database will connect to different systems, it might make sense to do validation right in the database system. But the validation model can be richer elsewhere, as the example in your question illustrates.

Also, if you validate on the client side, you will still have to validate again on the server side (never trust client data).

share|improve this answer
thx for the fast answer. is there else any reason why i should use the entity check and not the db check? (or vice versa?) – Joerg Jun 28 '12 at 16:38

You typically end up repeating some validation:

  • You validate on the client just for performance (instant feedback)
  • You validate on the server because you don't trust the client and validation is technically business logic and doesn't belong in the data layer
  • You validate in the database (data layer) iff something other than your application writes to the database that doesn't do perfect validation itself

Unfortunately this means repeating yourself, but that's life when it comes to programming today. Technically if you were using Node.js you should be able to share the validation code between the client and the server.

share|improve this answer

If you are using a database shared by many applications and all applications share the same rules, then validation in the database layer makes sense. This is also true if your database is populated from feeds such as batch feeds. Otherwise, it is common to include validations that does not require database data in the client or at the business layer or on both. Database constraints are always used for Referential Integrity, PK enforcements and 'not null' enforcement. Considering the need for speed during data entry, waiting for the database to respond with an error is hard to justify as per @chaos reply.

It is best if you can centralize your validation processing. As for using Check constraint note that:

  • Check constraint don't allow for custom error messages

  • They apply only to data in 1 table

  • They don't apply to views

share|improve this answer

Your entity model rules can be both applied on the server side and rendered as JavaScript code to be applied on the client side, vastly improving user experience. There's no contest.

share|improve this answer

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.