Referential integrity vs. PHP list box?

Anon

This is a DB theory question.

I have a database that gets populated (among other things) by the choices a user makes via some list boxes on a form.

One particular list box forces the user to choose his town or city, based upon the predefined list box selection. (I am limiting the user to a specific county for this app, and do not want bogus cities or towns being entered, hence the list box).

Now then, I have also defined a relationship in the DB such that bogus cites also cannot be entered. For example, if somehow the town of "Dillas" were entered instead of "Dallas" the DB loudly complains and rejects the entry. The thing is, it's not possible to make this entry error by forcing the user to select from the list box.

My question is then, is this relationship inside the DB unecessary then? Can I safely delete it? Or can anyone think of a good reason to keep this relationship even tho the list box is enforcing this integrity by default?

neuromancer

It should NEVER be the applications job to maintain data in a database, I always use FK, Error checking in stored procedures and "rule" constraints to keep my data intact.

Initially all my apps tried to do it at the application level, but there is too much room for error (Even though you should attempt to catch common errors before sending trash to the DB, IE cap the first letter of someones name if you can)

rrijnders

Your list box is only enforced at the browser level. There is nothing to stop some malicious user (or competitor) from trying to trash your db by copying your form HTML and modifying it to send bad data.

Keep your data checks as close to the db as possible.

IMHO

-- Rich Rijnders
-- Irvine, CA US

Anon

Yes, I see I am being naive here. I always try to do my data validation as close to the DB as possible. And I hadn't thought of malicious "users" out there. In that sense, I am being naive. Good point!

I will plan on keeping the referential rules in place, just as a backup against bad data creeping in. I was trying to "simplify" my data model, but as this shows, sometimes the simplest is not the best. We still have the real world to deal with, in all its complexities.

If anyone has any further input on this topic I am all ears! As the old saying goes, "Fool me once, shame on you. Fool me twice, shame on me."