Someone Else I Wouldn't Hire

Ovid on 2005-10-06T15:52:37

I know it's probably not terribly nice to point out egregious cases of thoughtlessness, but someone linked to this as an example of why databases should just store data.

The thesis seems to be that FK and unique constraints shouldn't be in the database. Despite the fact that this was posted just a few days ago (this time I double-checked), this is an old idea. Why on earth does this foolish idea propogate? Are people not reading CJ Date and other authors? Are they not being taught the rules of normalization and, more importantly, why those rules are there? There are plenty of reasons why one needs to break rules but to break rules without understanding why is foolishness. Worse, the author of that link is trying to convince others to break rules the author doesn't understand.

This debate is as silly as the structured programming or goto debates. How is it that we still have developers who can't understand the benefits of data integrity? Of course, if I were ever to interview this person and not hire them on this basis, they would turn around and accuse me of "having drunk the Kool-Aid" or something similar and considered that a rational argument.

If you have one and only one (small) app that will ever write to the database, those constraints may never be noticed. It's sort of like omitting "strict" in a small script. However, once you have other apps or developers writing to a database, then those constraints will save your job or -- perversely -- lack of them may save your job as you take the unethical road to job security. Of course, "other developers writing to the database" might mean you next year when you've forgotten the code. Or if you're writing large-scale software for an application that requires five nines, no one wants to hear your excuse about why you didn't use FK constraints.

Naturally, as any good debater, the author addressed the issue of others writing to the database. I've no need to comment on it. It mocks itself.

As for the ongoing ‘the sky is falling’ discussion about what if some other device accesses the RDBMS, it’s the same dilemma as ‘what if some other person accesses our document, and starts changing it?’ There are ways to manage that. Yes, we’re always exposed, always vulnerable to all kinds of attacks, but that’s how life is. You should start getting used to it by now.

OK, OK, maybe I have no need to comment on it, but I will: oh no, oh no! We can't protect ourselves so we shouldn't try!

You know what, though? I used to be where that author is. It's a stage most of us go through and the fact that he tries to think about these things is a good sign. Maybe I would hire him -- next year.

---

I think you missed the really scary part

autarch on 2005-10-06T17:33:03

ranting begins ...

AFAICT, the author of the piece you linked is mostly reiterating arguments made by David Heinemeier Hansson, the Rails guy. This just confirms for me that Rails is not all that, particularly when it comes to an app with a "real" schema, where by "real" I mean complex, as in many tables and many relationships between the tables.

You work on Bricolage, so you know what dealing with a real schema is like, but most people develop apps with relatively simple data, AFAICT. In those cases, simplistic ORM mapping layers like what's in Rails or what Maypole provides work fine. They save you tons of manual labor, and you think it's the shiznit. Then those people try to apply the same style to a more complex schema, and suddenly that layer is not helping much at all, because you still have to hand code all the hard parts.

It's really scary to me that David won that Open Source Award for Rails, frankly. The vast majority of software developers don't understand data, AFAICT, which is worrying considering that our job generally centers around the manipulation, presentation, and storage of data!

Maypole not limited to simple schema

TeeJay on 2005-10-06T17:51:34

Maypole isn't limited to just simple schema - that is entirely defined by your model - if you want build a more complex schema its going to require more work than a trivial schema but thats unavoidable - using something like Tangram or DBIx::Class for your ORM should work fine so long as your model does what is asked of it by the Maypole Framework.

In fact in upcoming releases we are working hard to make sure it extends and scales well to more complex schema and models. If you've come accross a limitation email myself or the list.

word

lachoy on 2005-10-06T20:01:26

I posted a pointer to this on some forum today but I can't remember which... Anyway, I totally agree with you, and EVEN SCARIER than what Dave said is the guy who felt that the database should be storing all data without types, similar to SQLite (about halfway through the thread):

Actually, I would prefer if all the values entered in the database would be of a single data type — text. This is because, at the end of the day, the data is mostly meant for human consumtion, and we consume it as text.

Regardless of what fancy data type may be sitting in the database, once it hits your eyes, it is plain text (whether displayed on the screen, or printed on paper). Also, even if it’s supposed not to be consumed by humans, but only by machines, it still gets converted to plain text (typically, XML).

So I really see no other point in having any type, other than plain string, defined in the database, other than to leverage the power of declarative programming.

Wow!

Databases

davorg on 2005-10-07T09:18:44

You're right that this point is view is very worrying. It seems that "databases" is becoming one of those things that people expect to be easy to master because "you use them to built web sites - and all web stuff is easy, right?" So there large numbers of people out there building databases who have never heard of Ted Codd, the relational model or even normalisation. Last year I wrote about a particularly bad example I was cleaning up.

I found a lot of flaky database knowledge in the Ruby on Rails book. It seems to me that people like David Heinemeier Hansson don't know as much about database theory as they like to think they do. A lot of what they are saying won't scale well to a "real" (i.e. of real-world complexity) database system.

I should write up this stuff in more detail.

Re:Databases

Dom2 on 2005-10-07T12:22:41

In fairness, from what I can see, they're not trying to scale like that. Rails seems to be mostly concerned about the low end simplistic kind of stuff. You're going to run in to the limits of Active Record PDQ if you've a complex database you're trying to plug into. But that's exactly the same as Class::DBI. You've got to be aware of the tools you're using and what their limitations are.

-Dom