If you go for a single table, the coding of queries will be easier; but it may be slower rather than faster, depending on what the queries do and how much data there is. Obviously if a query has to return some items of each of the 5 different types it's going to be a 6-way join in the 6-table version, which is a lot more complex than the single table query in the one table version, and that complexity may make it slower. But if most of your queries don't access more than one type then most of teh joins are only two-way, and if most of them return only common attributes then most don't need a join, so perhaps only a small number of queries may be slower and a lot of queries may be faster. But if splitting out the common table into a separate table doesn't save enough space to to reduce the amount of IO, and the queries don't have to do scans but are can use index seeks, there isn't any performance gain from the split. Of course you can go to a two table model, one table for the common attributes and another for all the non-common attributes, which doesn't get the scan-saving of the six table model (if there is any such saving) but does get the space saving (if there is any such saving), and the the difference in complexity between that and the single table model is just a single inner join. As well, you can maybe (in either the two table or the six table model) mark the non-common attributes SPARSE, which might save enough space to be useful and doesn't do the kind of denormalisation that using an encoding for those columns into some serial form (lke XML) does (and thus avoids a lot of complexity and performance cost of using such an encoding). Personally I think I would go for a two-table solution, based on your answer's to Eirikur's four questions, because it looks as if most queries only look at the common attributes, but I have to admit that those four questions and their answers don't really tell me enough to make an informed choice.