On Sat, Jun 16, 2018 at 12:53 AM, Man-wai Chang <[email protected]> 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. -- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CACW6n4sGPLQ79SPqxbeg-mbPh81ycXQHR+EzCNyJ=5zpnhq...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
