16

With Back-end validations I mean, during the- Triggers,CHECK, Procedure(Insert, Update, Delete), etc. How practical or necessary are they now, where nowadays most of these validations are handled in front-end strictly. How much of back-end validations are good for a program? Should small things be left out of back-end validations?

For example: Lets say we have an age barrier of peoples to enter data of. This can be done in back-end using Triggers or Check in the age column. It can/is also be done in front-end. So is it necessary to have a back-end validation when there is strict validation of age in the front-end?

6
  • 4
    I think you are mistaking server side validation with database constraints. Jun 11, 2013 at 8:49
  • 4
    Front-end is not enough. Best effort must go into back-end validation and front end for usability.
    – PeterMmm
    Jun 11, 2013 at 8:52
  • Check out stackoverflow.com/questions/162159/… Jun 11, 2013 at 8:52
  • #twoleggedhorse no mate, i did not. I actually put the serverside validation as a front-end validation.
    – Ruchan
    Jun 11, 2013 at 8:55
  • There are barely any good practice that works for "everything". There's always some scenarios where you'd better bend the rules.
    – Serge
    Jun 11, 2013 at 8:55

6 Answers 6

42

This is a conceptual question. In general modern programs are built in 3 layers:

  1. Presentation
  2. Business Logic
  3. Database

As a rule, layer 1 may elect to validate all input in a modern application, providing the user with quick feedback on possible issues (for example a JS popup saying "this is not a valid email address").

Layer 2 always has to do full validation. It's the gateway to the backend and it can check complex relational constraints. It ensures no corrupt data can enter the database, in any way, validated against the application's constraints. Those constraints are oft more complex than what you can check in a database anyway (for example a bank account number here in the Netherlands has to be either 3 to 7 numbers, or 9 or 10 and match a check digit test).

Layer 3 can do validation. If there's only one 'client' it's not a necessity per se, if there's more (especially if there are 'less trusted' users of the same database) it should definitely also be in the database. If the application is mission-critical, it's also recommended to do full validation in the database as well with triggers and constraints, just to have a double guard against bugs in the business logic. The database's job is to ensure its own integrity, not compliance to specific business rules.

There's no clear-cut answers to this one, it depends on what your application does and how important it is. In a banking application - validate on all 3 levels. In an internet forum - check only where it is needed, and serve extra users with the performance benefits.

1
  • 1
    Another benefit of validating in layer 1 is that you reduce the number of requests sent to layer 2. In a web application, this reduces the load on your server.
    – jpmc26
    Jan 28, 2014 at 4:13
16

This might help:

  1. Front end (interface) validation is for data entry help and contexual messages. This ensures that the user has a hassle free data entry experience; and minimizes the roundtrip required for validate correctness.

  2. Application level validation is for business logic validation. The values are correct, but do they make sense. This is the kind of validation do you here, and the majority of your efforts should be in this area.

  3. Databases don't do any validation. They provide methods to constraint data and the scope of that should be to ensure referential integrity. Referential integrity ensures that your queries (especially cross table queries) work as expected. Just like no database server will stop you from entering 4000 in a numeric column, it also shouldn't be the place to check if age < 40 as this has no impact on the integrity of the data. However, ensuring that a row being deleted won't leave any orphans - this is referential integrity and should be enforced at the database level.

5
  • 1
    +1 for the explicit part about databases not checking business rules but internal integrity. It's worth mentioning though that many mission-critical databases also check for things like "Age must be between 0 and 200" because it provides an extra safeguard against corruption (and thus integrity). Jun 11, 2013 at 9:00
  • 1
    Integrity of data can be many things (explicit NULLs, for example), but the "prime directive" for database validation should be for referential integrity; then anything else. A 0 age could mean many things (was it not entered? is it a "blank" value?), so having to enforce that might put extra constraints. Not to mention, tomorrow if the business logic changes - you have to edit it in the middleware plus the database. Not good for maintenance. Jun 11, 2013 at 9:17
  • An age of 0 means someone hasn't had their first birthday yet :) If it is unknown and/or not entered it should be NULL. A negative value is impossible, as is one over 200. That's also why I suggest 200 explicitly, not something like 120 that's 'unlikely' but not 'impossible'. You indeed don't want to have to change the DB's constraints frequently, it should at most safeguard against 'logical impossibilities' in addition to its mandatory internal integrity. Jun 11, 2013 at 9:22
  • What should and what is rarely match in the real world. Come by sometime to my office and let me show you how databases are abused in production :) Jun 11, 2013 at 10:20
  • Haha I've worked at several multinationals through the years, seen more than my fair share of magic numbers and the like. I'm just saying "when you do the design, do it by the rules". No database that I designed ever was broken in a such way. Had to work with more than enough of them though indeed :P Jun 11, 2013 at 10:24
5

back end validations are necessary!

if the front end uses JavaScript validation, and the user disables the JavaScript in the browser the validation is turned off. So there is need for back-end validation.

4

Put contraints on your database. This is NOT business validation, more like data validation, for example - foreign key constraints, or making sure your primary keys are unique. It's making sure your data is consistent.

The validation you are talking about is business validation, and this kind of validation should be in your business layer, for example in your domain, and should be the main source for validation. If these rules change, you modify them in the business layer and all of your clients immediately are affected.

In the UI you could/should also do basic input validation - like checking mandatory fields, or validity of an email address; and updating or disabling UI controls based on that. I would say that this is the kind of validation that doesn't change (a lot).

3

The age old answer: it depends.

It really depends on your needs. If users will be modifying the database directly, I would say you absolutely need to constrain your database. That said, a large number of databases are only modified by a web application. While you definitely need server side validation in the web application itself, because users can bypass your web pages, you may not need database constraints.

You should still do validation on the client side as a convenience to the client.

0

If you are concerned about security then everything should be validated on the server to prevent someone creating an alternative client to access/manipulate your database. Front end is also necessary as it improves efficiency and prevents the server being accessed with inappropriate data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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