Hacker News new | past | comments | ask | show | jobs | submit login

Couldn’t agree more. Database constraints should be thought of as the last line of defence against madness rather than as means to validate input. Database constraints are not really suitable to defend against attackers. Constraints might stops users from creating extremely large records but they won't stop users from creating an extremely large number of records etc. You need to sanitise your input thoroughly in the application layer.



There is also a maintenance cost by putting restraints on the database as almost assuredly your application will have similar constraints. Therefore if those constraints change the workload is not just doubled because you have to update the application in two places. But perhaps tripled or more as the developer tries to find any other locations where the same logic might have been put as well.

If the logic is in two places it might very well be in three or more.


Silly example, who decides what is 'an extremely large number of records'? Whoever has a view about this should monitor and police the limit. If you are saying that you can't protect against every eventuality so you may as well guard against none, then that is asinine.

Applications should enforce correct application behaviour regardless of user behaviour. Databases should maintain database integrity regardless of application bahaviour.

If this requires duplicated effort then so be it.


I think it would be difficult to defend an argument claiming that constraints on data size help maintaining data integrity.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: