On 27/01/2010, at 12:20 PM, Cameron Barrie wrote:
...yes I do use foreign key constraints in my rails projects).
However I think I'm just uninformed.
I don't think so. Here's what I wrote recently in the Agile Databases
list in response to someone whose codesmiths wanted to serialise
data into blobs, instead of using a relational structure. The rest of
the responses on the thread are worthwhile too. The thread starts
here: <http://tech.groups.yahoo.com/group/agileDatabases/message/2525>.
Note that this discussion is in an enterprise context where there are
data people and software people defending turf, but most of the chat
applies to cloud databases as well.
Clifford Heath.
The applications architects want to store serialized value objects
[so] they no longer need to keep evolving database schemas
Data always has a structure, which can be represented in a schema.
A system built using a soft schema (or as I call them, metaschemas)
stores the true schema in the code. You cannot avoid the underlying
existence of structure in your data; so the discussion is purely about
where the schema should be represented.
If the data architects make the database schema too hard to work
with, perhaps by themselves being too hard to work with, the coders
will try to avoid that. As a data architect, you need to work hard to
ensure that changes to the database are as easy to make as possible,
given all the dependencies on that data (which you should be aware of).
However, you also often must work hard at educating coders about
*why* the true schema should belong to the database, and not to the
code. Unfortunately there is a great rush to build metaschemas in the
industry, and not many of the reasons for it are justified. All the
excitement
about cloud databases for example would dampen a little if people
understood what they're sacrificing to get "into the cloud".
and no longer need to build data access layers as the product evolves.
That's simply not true. They just use a different access layer
(serialisation)
which may be more to their taste. It's often less robust too; will the
system
cope with all possible old revisions of a serialised object's record?
What
guarantees are there that the old formats get upgraded correctly? What
will the coders do when they find the need to query data based on
content
that's hidden inside one of these serialised objects? By hiding the true
schema in your code, do you even know where to look to be able to
answer these questions?
Since this is less work, they can be more agile.
It's less work in the short term, but builds up to a cataclysm in the
long
term. The agile teams can of course respond by building a new system
to replace the old one, and make a bunch of new mistakes while fixing
the old ones. But it's more likely that they'll respond by merely
being in
different employment when the crunch comes, or blaming the clients for
changing the requirements "too much". Seen that many times... This is
not truly Agile behaviour; it's just laziness and hubris passed off
under
the banner of agility.
The validation issues are not so compelling in that they include
data types in the serialization, so a uint is always a uint etc.
Self-typing data solves the lexical/syntactic problem of determining
what the
data are, but can never solve the semantic issue; what do they *mean*.
If you don't manage the data semantics closely by detecting and
correcting
errors at every stage (and especially every evolution), your
repository will
spiral out of control.
This task is what RDBMS is designed to do. It's difficult, and RDBMS
don't
always make it as easy as it should be, but it absolutely must be done.
Your developers are just looking for a way to avoid doing it properly
at all,
and to do what they must do using their preferred tools, instead of
the proper
tools.
Hint: The tool that manages the data is the tool that must enforce
constraints.
Other constraints they argue are quite well enforced within the
application.
Until someone writes a second application, and a third, etc. Or the
team changes
or forgets why all those constraints were there.
--
You received this message because you are subscribed to the Google Groups "Ruby or
Rails Oceania" group.
To post to this group, send email to rails-ocea...@googlegroups.com.
To unsubscribe from this group, send email to
rails-oceania+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rails-oceania?hl=en.
