Самая большая проблема в том, что ваши запросы становятся более сложными.Скажем, вы хотите найти все аккаунты с балансом более $ 10000 у владельца.В нормализованной БД это будет выглядеть примерно так:
select firstname, lastname, accountnumber, balance
from account
join customeraccount using (accountnumber)
join customer using (customernumber)
where balance>10000
Но с тремя полями accountnumber это становится
select firstname, latname, accountnumber, balance
from account
join customer on customer.accountnumber1=account.accountnumber
or customer.accountnumber2=account.accountnumber
or customer.accountnumber3=account.accountnumber
where balance>10000
Каждый запрос, который присоединяет Account к Customer, теперь усложняется, как это.
Рано или поздно кто-то напишет запрос, который не сможет проверить accountnumber3, или он попытается выполнить три теста, скопировав и вставив, и после копирования accountnumber1 два раза он забудет изменить один из них.Это ошибка, которую легко пропустить при чтении запроса.Если вы ошибетесь одним из трех сравнений, программа будет работать для всех клиентов, которые имеют только две учетные записи, но не смогут работать с клиентами, у которых есть три.Это проблема, которая может легко пройти тестирование.
Теперь вам нужно продумать, как именно работают объединения, когда один и тот же клиент имеет несколько учетных записей.Если у клиента есть два соответствующих аккаунта в каком-либо запросе, хотите ли вы, чтобы он появлялся один или два раза?
Возможно, вам нужно проиндексировать поле номера счета в клиенте.Теперь вам нужно три индекса вместо одного.Дополнительные затраты на базу данных.
Вы уверены, что максимум никогда не изменится?Потому что, если это когда-нибудь произойдет, теперь каждый из этих запросов, которые проверяют три слота, должен быть изменен, чтобы проверить четыре слота.Это может быть тонна работы.
Что вы получаете в обмен на всю эту боль?Автоматическое применение ограничения max-3.На один столик меньше.Возможно, вы получите лучшую производительность по некоторым запросам, потому что нужно объединить на одну таблицу меньше.С другой стороны, вы можете не получить более высокую производительность, в зависимости от многих деталей внутренней работы механизма базы данных и фактических данных.
В общем, я бы сказал, что это почти наверняка не стоит делать.Придерживайтесь нормализованной базы данных.
Я говорю по опыту.Я сделал что-то очень похожее на это однажды.У нас была база данных, в которой мы должны были записывать три типа «менеджеров» для каждой книги, опубликованной нашей организацией (№ 1, отвечающий за бюджетирование и администрирование, № 2, отвечающий за распространение, и № 3, отвечающий за содержание (т.е. редактор)Так как все три были разными, я создал три отдельных пункта. Огромная ошибка. Мне было бы гораздо лучше создать таблицу диспетчера книг с кодом типа и обеспечить выполнение только одного из каждого типа с помощью триггеров или кода.было намного проще. (Опыт позволяет вам принимать правильные решения. Опыт приобретается благодаря принятию неправильных решений.)