You know, this sounds a lot like the arguments between static typing and dynamic typing...
- Korny On Wed, Jan 27, 2010 at 12:59 PM, Clifford Heath <[email protected]>wrote: > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<rails-oceania%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > -- Kornelis Sietsma korny at my surname dot com kornys on twitter/fb/gtalk/gwave www.sietsma.com/korny "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of" -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
