Or an even simpler approach of 'if it aint broke, don't fix it'. Particularly in legacy systems where documentation is out of date or missing and some code does things you don't necessarily understand, just don't touch it.
-----Original Message----- From: ProFox profox-bounces@leafe.com On Behalf Of Ted Roche Sent: Saturday, 16 June 2018 7:47 PM To: profox@leafe.com Subject: Re: Database design
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.
-- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com
[excessive quoting removed by server]