Are relations slower than a big, inefficient table? 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 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.