Here is a guideline that I once wrote and that is often ignored (at least I have no fallacies about my ability to influence people :-)) ...

Do not combine data definitions together into a single instantiable entity when an analysis of the managed environment indicates that they can or should be defined as separate entities. Do not do this even if current scenarios indicate that it is permissible, since a future release will invalidate this decision, your model design and its instances.

The preceding guidelines are clearly about defining a general and extensible model, and not about how it is stored or used. In those spaces, the programmer needs to do whatever is necessary. But, don't confuse implementation and performance issues with general model design. Combining model entities together in an implementation given usage patterns against a store, or separating an entity apart into 2 database tables to prevent sparse tables, are reasonable design choices. But, taking an optimized, physical storage design as a general and reusable model definition is rarely workable (actually, I want to say "never" but I was told to "never say never").

Each usage of a model likely has its own queries, implementation and storage requirements, and necessary data - and hence will dictate different storage patterns. A “common” model is designed to carry and interchange data for many scenarios, and across several products and stores. It is unlikely to be useful (e.g., optimized) as a physical storage definition, for any of the scenarios or stores.

This thinking is what motivated the distinction between logical and physical model definitions. However, usually and unfortunately, people get consumed with the physical store and forget about conceptualization and abstractions. Don't do this!