Re: Validating Data
Date: Sun, 26 Feb 2012 19:11:46 +0100
Message-ID: <9qvavgF5btU1_at_mid.individual.net>
On 26.02.2012 01:17, Mladen Gogala wrote:
> On Sun, 26 Feb 2012 00:39:11 +0100, Robert Klemme wrote:
>
>>> With all due respect, why would you use a database for such thing?
>>
>> The most prominent reason is that general rule to check inputs when they
>> enter a system.
>
> This looks like a web application as the original poster has mentioned
> PHP. Web server looks like the most logical place to prevent an undesired
> data format from being entered into the system.
Absolutely.
> Of course, there is an
> advantage of doing it in the database, because the input checking is
> centralized and you don't have to worry about that in the applications.
My point is that robust application design does it in both places: the web app needs to ensure it works with proper data and the database should as well. Each layer decides for itself, what exactly "proper data" is, but of course upper layers (web app) need to take into consideration what storage layers (database) accept.
My intention was to provide the software engineering perspective on the matter. To give another example: when you build an object oriented application each class can be viewed as a module of its own. It's crucial for the OO paradigma to ensure the state of an object is valid under all circumstances (class invariant). To be able to ensure that, arguments passed to public accessible methods need to adhere to the method's contract conditions. That contract needs to be enforced by the method depending on language features (in Eiffel the compiler does if for you, in many other languages you need to do it manually).
> However, having in mind how lightweight things are, when done through PHP
> I would probably do it in PHP. Maintaining a simple filter on the data,
> to prevent non-printable characters in the certain fields should not be a
> problem, either way.
Right.
Kind regards
robert
-- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/Received on Sun Feb 26 2012 - 12:11:46 CST