Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday October 06, 2005
10:52 AM

Someone Else I Wouldn't Hire

[ #27047 ]

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.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Someone Else I Wouldn't Hire 5 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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, simpl
  • 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 em
    --

    @JAPH = qw(Hacker Perl Another Just);
    print reverse @JAPH;

  • 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.

    R

  • 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 [perl.org] I was cleaning up.

    I found a lot of flaky database knowledge in the Ruby on Rails book. It
    • 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

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.