current community

your communities

more stack exchange communities

Stack Exchange
tour help
careers 2.0
Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote -1 down vote favorite

When developing a webapplication we usually implement data validation both in PHP scripts and in our database (as constraints and triggers).

Do we really need to repeat this task twice? What is the point of that?

Client-side validation ensures that most user input is correct, so in most cases server-side validation will pass.

So, what is the best choice? PHP validation, database validation or both?

share|improve this question

closed as primarily opinion-based by vascowhite, Ondrej Janacek, Andrei I, tereško, Ocramius Dec 10 '13 at 10:01

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

6 Answers 6

up vote 5 down vote accepted

It is a common mistake to think the databases actually validate data. It does not. Constraints are just here to ensure data consistency which is different from data validation.

The PHP layer has to validate and clean inputs so programmers know what they are dealing with. There are according errors for validation, form or fields errors based on the format or the presence of data.

The database has to ensure data consistency through a constraint system (types and CHECK clauses) so programmers can trust data coming from the database.

Programmers protect themselves from the users so users can trust programs. Databases protect themselves from the programmers so programmers can trust databases.

share|improve this answer
up vote -1 down vote

You should ensure that all data should be validated according to database standard.

Because in PHP validation is fine, but when you manipulate with database then data should be sanitized, unless you are at risk of SQL injection.



For client side and server side validation:

  1. You have to use both to ensure not much traffic on server side, as filtration happened on client side.

  2. If you don't use server side validation then its risky that someone POST data by any tool.

share|improve this answer
1  
that was not what the question was about... re-read it. –  eis Dec 10 '13 at 8:42
1  
the question is ambiguous, it does indeed talk about client-side validation. –  sevenseacat Dec 10 '13 at 8:45
    
@eis I think he has to re-write the description. –  Parixit Dec 10 '13 at 8:48
    
@sevenseacat um, I don't see the ambiguity. he said that client-side validation will catch most of the errors, and php will do the rest on server side code, so should db validation used as well. Or am I missing something? I don't see any problem with the question. –  eis Dec 10 '13 at 9:21
up vote 0 down vote

yes, some time both are necessary.

php validation and database validation.

let's have a simple situation. if we don't assign a primary key or unique key, then if , somehow, (intended) user by pass php code validation then database will have same records twice. but if we assign a primary key then it would be not possible.

It is always but according to need.

let's simply explain.

the final important thing is your database , like a vault. Now you have to decide it where to put it in a house. means after how many gates should be there to access that vault.

like if you have less important things then you will not need to worry about them , but for most important things, like cash, gold etc, you will always put it in secure and more authenticated place.

So it basically depends upon needs. In application like, accounting,erp, etc you will always try put a constraint(database validation) b/w columns so that error chances b/w balance would be very low.

share|improve this answer
up vote -2 down vote

This not directly answers the question, however, it probably is the solution to go anyway.

You can/should use an object-relational mapper with which you do not create the database yourself but use the ORM's syntax to dynamically create them. That also allows you to validate the data. So when you try to insert new data in your database, the ORM checks the data. Now you never have to validate your input again, but can just use the ORM for that functionality.

share|improve this answer
2  
What a load of utter rubbish! ORM's are not some magic bullet that remove the requirement to validate input from the user. –  vascowhite Dec 10 '13 at 8:51
    
I don't see your point. ORMs allow you to exactly define what data might be stored in a database. Before you store it, you can ask the system whether the data validates, and if it does, store it. If it does not, you can show an error message to the user. –  str Dec 10 '13 at 8:54
    
@vascowhite Care to elaborate on that? –  str Dec 10 '13 at 9:02
    
No, not really. –  vascowhite Dec 10 '13 at 9:03
    
I think @str might be talking about things like Hibernate Validation / JSR303, etc, i.e. declarative object model validators. They're useful, but no substitute for in-database constraints and checking. –  Craig Ringer Dec 10 '13 at 9:06
up vote -1 down vote

Its a best practice to do both client-side and server side validation. With both in place you can also offer your user better user experience since client-side validation can provide immediate feedback (e.g. show invalid email format, etc...) without submitting the form.

While server side validation will help you protect from malicious data entry. Also help ensure proper data type is being saved to your database.

share|improve this answer
up vote 0 down vote

When talking about constraints, in most of the cases you have to have the same validation in PHP, at least the user to not see DB related errors, but your custom ones, or to hide content, etc.

Let's say you have user-based application, where users buy items. One user can have one item only once. So you build constraint unique user_id && item_id. If you have user_id = 5 and item_id = 10 in one row, once a new record tries to go with user_id = 5 and item_id = 10, te Database will return error Duplicate entry for key.... You can leave things this way. The user with ID = 5 will see this items with ID = 10 in the items section, and once he try to buy it, he will see blank page with the error for duplicate entry. Is that what you really want? Or better you have method i.e. isItemOwned() which is used either to be checked in Items section to hide the owned items, also used if user tries to trigger the buyItems() method for example, somehow - then you can raise error "You already have that item, you might need another one?". So you will protect the DB for unnecessary calls which will result in database errors (in this case duplicate entry) and also will protect the user to see them, will give it a chance to understand the real problem and also will hide unnecessary content. So handling the constraints in PHP will give you the opportunity to interact with the user the best way, instead of just giving the user to interact with the database directly.

The constraint for example will be triggered (and one will not see the real error, only in your logs) when for example the connection lagged and somehow 2 or more request were sent to the database to request the same item_id, before the validation in PHP triggers, so both request will not result in records, because of the unique key constraint.

share|improve this answer

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