Validations in an Application

I have a question about validations in applications.
See, when we create apps, we always do input validation, thus there wont be any invalid data in our DBs. (assuming the validation is 100% accurate)

And then we use these data for manipulation. For an example , we create an app to collect student marks to compute their grades.

Since our input data is validated 100% , do we have to validate them in the computaion part again?

This is the question I have. Do we need to take extra burden to validate them again when we do computations on the already validated data?


And not to forget eventhough the app validates these data, we can change them in the DB itself (Admins?)
So do we need to validate them again or make them validated in the DB? (if triggers are supported it d be easy I guess.)


Hope you got my question clearly.

Thanks In Advance
:wave:

I normally do validation on save of data. Then again when I go to use that data anywhere else. Just in case some one changed it in the DB using SQL commands.

Quote:

---

Originally Posted by GaryMazzone

Just in case some one changed it in the DB using SQL commands.

---

This I m worried. We have so much data in our system which we validate in input (ie SaveData)
ANd again when using them , we validte SOME of them.
But do we have to do that everywhere for all the data we use?
If so whats the point in validating in the input ?
Its a real headache sometimes.:mad:

I definatly agree with you on the headache part. But (espcially here) some places allow personnel access to the data directly and I want the results I display to be correct. So validate once and then once more and once more.....

I wonder if there is another way to do this.
And if we have trigers, we could chek em in inserts and updates right?
(Unfortunately DB version we have dont support trigers, :( but my question is general to any DD)
:(

You can use a trigger to test on update. If the value is not proper then the trigger can put the old value back in place. Just think you would have to check every column on each table. Lots of triggers. Then again I guess it would be a before after (before) insert also. Some could just try and add the data by hand from SQL statements.

Yes, you are right.
Trigger would be a mess If I try that. and I cant as for the moment we dont have any.

So the final answer would be Validate ALWAYS to make sure its ok.
And i guess its better to use custom validate functions right?
We use it for basic types
like currancy
number
email
date

but we should use some application specific validation functions also ?
like Customer Ids' ?
:wave:

EDIT: big typo

belts and braces,

If you inherate a system then you also are unsure if the validation is 100%. however as stated in a systems like access then a user can just link to the db via word excel or open the file Direclty and alter the DB. i always validate the data at both ends. this also reduces the errors you could encounter on future computations.

Dav

If customer ID's are application generated I would at least look at them. Are they carried down as an FK to another table?

Quote:

---

Originally Posted by GaryMazzone

If customer ID's are application generated I would at least look at them. Are they carried down as an FK to another table?

---

Yes, they become FKs in many tables, almost every table. th CUSTOMERID is the heart of relations of bussinesslogic.
Ther are many Ids like this. EG : GL ACcount IDs, ProductIDs, etc ...
Ssome have specific formats. eg : GL Accounts
But this FORMAT is not complusory. Its there only for the purpose of identification and sometimes to easily identify records.
Eg: 01-02-003 -> BranchID-AccountType-SubAccountID

But all these FORMATS are not complusory. So do we need to validate the format?
I mean if its a FK, we can validate from the intergrity constraint , right? Should we bother to check them again?