Static typing won that one, right? Everyone's using Haskell? mark off in his magical FP wonderland
On Wed, Jan 27, 2010 at 1:34 PM, Korny Sietsma <[email protected]> wrote: > 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]. >> 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. > -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda -- 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.
