in reply to (OT) Couple of Data Model Design Considerations
When you say that your design is "correct", what do you mean?
A design might be "correct" but violate first normal form. Conversely, it might be fully normalized but still fail to model the data accurately.
The "right" approach to your first issue depends on several things. Are there attributes that are rarely used? They might be candidates for placing in one or more side tables. How many attributes do you have?
Will the data be updated frequently ("transaction processing") or will it be mostly queried ("data warehouse") or will the usage be somewhere in the middle?
I would first model the data using only as many entities as necessary. Once you have a clean and clear model that describes the entities and their relationships, you can consider implementation details. Don't get too wrapped up in "optimization", as you may well not know clearly which characteristics you need to optimize for. There is not necessarily a single "correct" solution.
|
|---|