On Sat, Jun 16, 2018 at 12:53 AM, Man-wai Chang changmw@gmail.com wrote:
You are supposed to design the ER using the best normal form, at least according to school textbooks! :)
But you don't just design it once, you design the perfect logical design, then you design a physical design that takes into consideration real-world issues such as storage and performance. So, logically, all fields might fit in one table, but realistically, you might decide to store less-used or overly large data in a separate 1:1 table.
In this case, there's a 1:1 table that *COULD* be folded back into the original. You have to evaluate the cost of migration: rewriting the code, writing the migration, supporting customers with both schemas in production out in the field, against the benefits. In a lot of cases, a legacy design is best left as is. "Things are the way they are because they got that way."
Usually the situation is the opposite: an attribute once included in the table needs to be extracted for a 1:M relationship because the client told you "There's NEVER more than a primary and alternate contact" and that turns out not to be the case after a while, or the business changes.