I've been asked in my job to violate the first normal form (repeating groups across columns, using empty / null values) several times, "for the sake of computer processing power". In a nutshell, a "student" table should have at least 8 empty fields (e.g telephones: telephone1, telephone2, telephone3...) instead of my suggestion - a "telephone" table which holds a telephone number (and possible other metadata) and the foreign key is the student id number. My boss says that it's better to store them that way because "there are less CPU cycles and that matters in web platforms", instead of using relations. I say that, in the worst of cases, it's negligible.

In that example, using relations (suppose that the tables are filled with lots of records in a medium-sized webapp) is notably slower than using that kind of table schema?

  • I believe it would actually be faster to do as your boss says, but you have the possibly excruciating task of ensuring you don't get update anomalies. But it could create much more cpu work if you ever need to change a piece of data that is common to the table (ala change the area code for all the phone numbers...) – Patrick Mar 15 '11 at 2:39
  • 3
    I seriously doubt, on modern hardware, provided you indexed your foreign keys that the extra CPU would even be measurable, especially on the other side of a web server. At my site we have normalized tables and serve well north of 50,000 hits/sec without breaking a sweat. Tell your boss to stick to golf and leave the technical decisions to you! – Gaius Mar 15 '11 at 5:57
  • 1
    @Patrick Do you believe that it's considerably faster or just marginally faster? And I think just as @Gaius - on modern hardware, even if it's "faster", the gain of speed and durability of hardware is negligible. – AeroCross Mar 16 '11 at 0:09
  • 1
    I think the speed improvement is inconsequential. Only if you have massive datasets and are doing ridiculous joins would you see any noticeable difference in performance. – Patrick Mar 16 '11 at 1:19

I don't see how anyone could make such a statement without having some actual facts to back it up. If your queries are CPU bound, then you should look to find ways to reduce that bottleneck.

It sounds as if your boss feels that a denormalized database will perform best, but I don't know enough about your application to say if that is right or not. What will be the expected number of deletes, updates, and inserts for this table?

I would expect that such a denormalized design may result in a reduced amount of CPU time but would expect that your disk I/O would increase. And physical reads from disk will be much more expensive than a CPU cycle, so perhaps your boss has a very specific metric to meet (CPU) and as a result wants a very specific design? If so, I would simply build what is asked for and keep metrics on CPU cost for the queries being run. If you see an increase in time then you may want to suggest some design changes.

In fact, it is probably a good idea to get a list of all the metrics your boss wants to see, and track those over time.

  • The thing is that he's old school - in his days (20 years?) perhaps that WAS important, as he proposes, but today's hardware and software is much, much powerful, and it is, by design, faster that way. It's tough to deal with someone like this, though, because he has more power, and the empirical (but outdated) "fact" that it IS faster, and it should be considered that way. – AeroCross Mar 16 '11 at 0:11
  • 1
    understood. try getting him to list the metrics (CPU, disk I?O) that he wants measured, and what he sees as acceptable. then simply measure those items and when things go awry you could offer some alternatives. that way you can get a better design deployed without a fight; just let his design prove itself over time. it's a win-win, actually. – SQLRockstar Mar 16 '11 at 2:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.