Em Tuesday 19 August 2008 22:40:46 Matt Wilson escreveu: > Yeah, I figured that's *how* I could do it. I'm curious about if I > *should* do it this way. Is there some subtle danger in this > approach?
I don't do that. And I'll comment below.
> Thanks, but in this case, the current user is editing the profile of
> other people in my database, so that won't work.
When editing the profile, you shouldn't edit / change the PK of the record. I
don't see a point in doing that (what is the difference if the user_id is 1 or
50?).
> You got me right, but what I really want is advice about if this
> strategy is wise. Am I doing too much in the validation layer? I
> know it is technically possible, but is it wise?
Since he shouldn't change the ID, he shouldn't be able to do it. And then you
wouldn't need to validate if it exists on the database because you retrieved
this information from there: the user exists.
And, if he submits something manually from outside your application interface
and there was a user_id that didn't exist on the database, then he should get
an error generated from the database when your application tried to update an
non-existent record. The database will do the validation for you 100% of the
time if you use PKs and FKs correctly. Since you'd have to go to the database
to do the validation, you wouldn't be saving anything (if you could validate
the ID without connecting to the database then I'd do what you want to help
scaling the application).
I try designing things so that:
1. I only offer valid choices to the user (through combo boxes, using
SelectShuttle, etc.)
1a. I have the user to insert all valid values on the database
before he can
use the value (not all at once, I make an interface for every "table" that
will be used as source of information on other places), so I'd require the
user to load the database with countries before he loads it with cities
associated to those countries --- this is obtained by taking the DB to the 3rd
normal form (some denormalization for performance purposes is acceptable, but
it has to be *designed* not accidental)
2. I validate what I can on the application with regards to business
rules
(e.g. only integers, only floats, mandatory information filled, value ranges,
etc.)
3. The database validates some of the rules again (value range is one
where I
duplicate the validation -- just because I design my DB to be application
independent, otherwise I'd let the validation at the application level only to
save some load on the DB)
4. The database only accepts valid references (1:N, N:M associations
with the
requirement that referenced items exist on their tables -- PK there, FK on
associative tables)
5. I use lots of automation INSIDE the database, as stored procedures /
functions.
5a. This is specially true for audit information such as
modification
timestamps, logging the user who did the change, copying old information to
log tables, etc.
6. I have several "read only" classes in my model, referencing VIEWs on
my
DB. Those make my code simpler and make me benefit from DB cache, improving
performance (a JOIN there is much better than SELECT + loop on code)
This requires more SQL knowledge to maintain, but it has its benefits.
I chose to base all my applications on ONE database server. I don't care for
compatibility with other servers. In my case, I design my applications to
work with PostgreSQL, so I plan on using all the resources I can (arrays,
triggers, stored procedures, views, functions, etc.) and I don't worry if my
application will run with MySQL, DB2 or Oracle. And I plan so that I can do
maintenance straight from the DB CLI or using SQL scripts, without using the
application and without violating any of the business rules by accident.
If you are writing a database independent application -- people like the
buzzword "3-tier application" -- then you'd have to do what you were doing:
going to the DB to check if the value is valid and doing the validation all on
the application because if the DB doesn't support FK checks then you could end
up with invalid data inside the DB.
Summarizing: I'm from the team that believes that the DB should have code
inside it to guarantee good performance and business rules; I defend that the
DB should receive information with the correct information, but it should
validate them again so if the application can't detect invalid data without
going to the DB, then the DB should take care of that alone.
I think I wrote too much... Hope I didn't loose you and that I didn't make
you read my email 3 or more times to understand it. :-)
--
Jorge Godoy <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part.
