It's not just the amount of data that determines performance, it's also the number and kind of transactions. If all do is 10 simple selects a day, I agree, performance is not an issue. If you need to do 10,000 queries an hour, performance is an issue, even if you have only 270 products. Then not doing the join can certainly be noticeble.

I've been a DBA in a previous job. My response to the original question is "the article contains not enough information to say whether the DBA is right or not". What (s)he says certainly does have merit. But it depends on a lot of things whether the performance gain is noticeble or not. How many selects? How many updates? How many concurrent users accessing the tables? How much cache? What else is going on? It requires an awful lot of knowledge, not only from the strategies of your database server but also from which transactions are going to be performed to say which will give the best performance. Perhaps only realistic testing can tell the difference. And then you still need to make the trade-off between performance and clean design. Note that the drawback (I could make a typo when inserting something) can be overcome in several ways. One could make an insert trigger that rolls back the transaction if an illegal category is inserted. Or one uses a list of constants in the code, or one makes a layer between application(s) and the database that does the actual creation of SQL - and never have applications touch the database directly. The layer could exists of some libraries (modules), but it could also exists of stored procedures. Or some combination.

-- Abigail