Database Reference
In-Depth Information
DRY - don't repeat yourself
This one means to try to implement any piece of business logic just once, and put
the code for doing it in the right place.
It may sometimes be hard, for example you do want to do some checking of your
web forms in the browser, but still do the final check in the database. But as a gen-
eral guideline it is very much valid.
Server programming helps a lot here. If your data manipulation code is in the data-
base near the data, all the data users have easy access to it, and you will not need to
manage a similar code in a C++ Windows program, two PHP websites, and a bunch
of Python scripts doing nightly management tasks. If any of them needs to do this
thing to a customer's table, they just call:
SELECT * FROM do_this_thing_to_customers(arg1,
arg2, arg3);
And that's it!
If the logic behind the function needs changing, you just change the function with no
downtime and no complicated orchestration of pushing database query updates to
several clients. Once the function is changed in the database, it is changed for all
users.
YAGNI - you ain't gonna need it
In other words, don't do more than you absolutely need to.
If you have a creepy feeling that your client is not yet well aware of what the final
database will look like or what it will do, it's helpful to resist the urge to design
"everything" into the database. A much better way is to do the minimal implement-
ation that satisfies the current spec, but do it with extensibility in mind. It is much
easier to "paint yourself into a corner" when implementing a big spec with large ima-
ginary parts.
