15

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?

Ruchan
  • 3,124
  • 7
  • 36
  • 72
  • 4
    I think you are mistaking server side validation with database constraints. – twoleggedhorse Jun 11 '13 at 08:49
  • 4
    Front-end is not enough. Best effort must go into back-end validation and front end for usability. – PeterMmm Jun 11 '13 at 08:52
  • Check out http://stackoverflow.com/questions/162159/javascript-client-side-vs-server-side-validation – twoleggedhorse Jun 11 '13 at 08:52
  • #twoleggedhorse no mate, i did not. I actually put the serverside validation as a front-end validation. – Ruchan Jun 11 '13 at 08: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 '13 at 08:55
  • Front end validation - On the page the user interacts with , usually javascript. Server side - Done on the web server when it receives data back from the web page. Database - Such as triggers, keys, constraints in the database itself. – twoleggedhorse Jun 11 '13 at 08:58

6 Answers6

41

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.

Niels Keurentjes
  • 41,402
  • 9
  • 98
  • 136
  • 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 '14 at 04: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.

Burhan Khalid
  • 169,990
  • 18
  • 245
  • 284
  • 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). – Niels Keurentjes Jun 11 '13 at 09:00
  • 1
    Integrity of data can be many things (explicit `NULL`s, 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. – Burhan Khalid Jun 11 '13 at 09: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. – Niels Keurentjes Jun 11 '13 at 09: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 :) – Burhan Khalid Jun 11 '13 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 – Niels Keurentjes Jun 11 '13 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.

Gergely Králik
  • 440
  • 4
  • 14
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).

L-Four
  • 13,345
  • 9
  • 65
  • 109
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.

jpmc26
  • 28,463
  • 14
  • 94
  • 146
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.

Adrian G
  • 775
  • 6
  • 11