Как справиться с ростом столбца широких, плоских столов

Question

Как бы вы справились с этим? Я взял на себя ответственность за существующее приложение (VB6) и базу данных, которая была написана в 1999 году. Дизайн базы данных довольно «плоский», то есть основные таблицы довольно широкие (более 100 столбцов), и разработчики продолжали прибегать к дополнительным столбцам, чтобы конец таблицы. Это привело к появлению в столбцах большого количества нулей, поскольку они не имеют прямого отношения к первичному ключу.

Я подумываю разделить основную таблицу, чтобы абстрагироваться от лет и лет «взрыва колонны». Я уверен, что новые поля будут добавляться по мере появления новых требований.

Таким образом, вопрос в том, что по мере необходимости новых полей вы продолжаете увеличивать ширину существующей таблицы? Или вы ОСТАНАВЛИВАЕТЕ расширение существующей таблицы и разбиваете ее на отдельную вспомогательную таблицу, в которой будут размещаться новые поля, создавая тем самым отношение 1 к 1? Если бы вы разбили основную таблицу, какой была бы ваша схема именования ?

Давайте предположим, что для этого примера у меня есть таблица «Выкупа» с 150 полями. Какое хорошее название для новой таблицы 1-к-1? 'ForeclosureExtended'? ForeclosureOtherInfo '?

Кстати, есть представления и хранимые процедуры, которые необходимо изменить для поддержки любых новых таблиц, но это неизбежно в любом случае при добавлении столбцов.

заранее спасибо за любые мысли.

Answer 1

Если вы не очень смелый, приложение очень маленькое / простое, или есть серьезные проблемы с производительностью, не исправляйте схему. Если это не сломано, не исправляйте это.

Просто создайте новую таблицу ForeclosureExtended, как вы предлагаете, с тем же ключом и начните добавлять столбцы. Или, вы можете создать правильные таблицы с сгруппированными столбцами, когда появляются новые столбцы. В любом случае, если схема такая плохая, держу пари, что код очень хрупкий.

Answer 2

Почему вы чувствуете, что у вас есть проблемы? На мой взгляд, легче иметь дело с одной таблицей, которая имеет много столбцов, чем с тонной более узких таблиц и всех связанных представлений, которые вам нужно поддерживать.

Answer 3

80% времени ваши нули имеют определенные шаблоны.

Эти шаблоны определяют подклассы вашей таблицы. В вашем случае они будут подклассами Foreclosure.

Ваше разбиение должно основываться на этих отношениях подкласса.

Скажем, например, что некоторые Foreclosure экземпляры имеют несколько полей, связанных с судебным разбирательством, которые почти все заполнены. А другие Foreclosure экземпляры имеют поля легального разбирательства, полностью заполненные нулями.

У вас есть два класса. Вам необходимо выяснить отношения между ними - они являются подклассом суперкласса или они являются подклассами другого суперкласса?

Здесь рассказывается, как разбить таблицу, чтобы сделать полезные вещи.

• У вас могут быть правильные отношения подкласса суперкласса

• Возможно, вы нашли вещь (LegalProceeding), которая должна была быть отдельной таблицей все время. Он не должен был быть постоянно включен в Foreclosure. Это замечательно распространено.

Теперь у вас есть несколько вариантов реляционной реализации.

• Один из распространенных вариантов - поместить все подклассы в одну массивную таблицу с большим количеством нулей. Это то, что у вас есть сегодня, и оно не работает.

• Один из вариантов - разделить две таблицы отношений подкласса на одноранговые узлы, дублируя общую информацию.

• Один из вариантов - иметь таблицу суперкласса с необязательной ссылкой FK на дополнительную информацию в подклассе.

• Один из вариантов - иметь таблицу подклассов с обязательной ссылкой FK на информацию о суперклассе.