Ух ты, столько плохих советов и мифов о дизайне в одном вопросе, трудно понять, с чего начать.
Это VLDB? Вы говорите о 100 туберкулезе, 100 о ГБ, 1-10 ГБ?
Это сверхвысокая производительность БД? Вам нужно выжать микросекунды?
Большинство советов склоняются к тем крайностям, когда вы можете нарушить несколько основных правил ради производительности.
В предыдущем плакате говорилось:
"Является ли документ действительным или
недействительный, это все еще документ, так что
имеет смысл для них всех быть
в той же таблице. "
Он был на правильном пути. И в этом отношении, является ли это обработанным или необработанным, это - также документ. Я сильно сомневаюсь, что первое разделение таблицы.
Затем он говорит,
"Наличие двух типов документов
вместе в одной таблице сделаем
ничего, кроме как замедлить ваши запросы
нет немедленной выгоды. "
Я понятия не имею, на чем основан этот совет. Если ваша СУБД поддерживает индексы, дополнительные данные будут иметь очень незначительные дополнительные затраты при определенных размерах вашего индекса, потому что ваше b-дерево становится на один уровень глубже. Если вы возьмете его утверждение в чистом виде, вы должны ограничить свою таблицу n строками и продолжать делать новые, потому что "больше данных в вашей таблице = медленные запросы" Я понятия не имею, почему люди упорствуют в этом понятии. Если у вас есть запросы, требующие полного сканирования таблицы для одного или другого типа, давайте поговорим о разделении, а не о новой таблице. Чтобы найти строку в таблице с миллиардными строками, требуется около 10 миллисекунд, чем в таблице с миллионными строками, потому что индекс, вероятно, будет только на один уровень глубже между этими двумя.
Другой плакат сказал:
"5-7 столбцов, которые не относятся к
недействительные документы NOT NULL, поэтому действительный
документы должны иметь их.
На мой взгляд, с таким количеством столбцов
пусто для недействительных документов, это
оправдывает другую таблицу. "
Я бы хотел, чтобы люди объяснили причины. КАК это оправдывает? На каком основании вы бы приняли это решение. 4 слишком много? Почему бы и нет? Но 5 это слишком много? Возможно, он предполагает, что вы используете древнюю СУБД с фиксированной длиной поля. Я не могу сказать. Если вы поместите пустые столбцы в конец строки, вы не заплатите за них. Посередине несколько лишних байтов. Если это ОГРОМНАЯ сделка, если вы действительно стараетесь сделать этот мультитабитный стол крошечным ... мы поговорим о вертикальном разделении ... не совсем новом столе. Поскольку вы будете увеличивать длину n% строк, вам нужно будет тщательно выбирать PCTFREE или как-то иначе это делает ваша база данных. Кроме этого, есть небольшие недостатки обнуляемых столбцов.
Итак, давайте поговорим обо всех недостатках трех таблиц.
Я предполагаю, что ваш стол выглядит так;
A surrogate PK column with a unique index.
A candidate key column with a unique index.
a few foreign keys to 'lookup' tables.
Several data fields.
the 5-7 nullable columns that are filled if a document becomes invalid.
Первая проблема заключается в том, что у вас будет 3 PK во всех таблицах, чтобы убедиться, что ключ уникален ... но нет объекта кросс-таблицы, который бы гарантировал уникальность во всех трех вместе взятых. Если вы не кропотливо подходите к коду, который перемещает данные из одной таблицы в другую, у вас может быть один и тот же документ дважды или более. Один раз в каждой таблице. Если у вас есть единственная таблица для Оригинала, обработанная и недействительная, то вы никогда не сможете этого сделать.
С тремя таблицами все ваши ограничения будут проверяться снова и снова. Когда вы выполняете вставку в исходную таблицу, проверяется PK, проверяется AK, проверяются FK, проверяются другие столбцы. В этих индексах есть место для всех новых индексов, что может привести к расщеплению блоков. Теперь вы обрабатываете файл и удаляете запись из исходной таблицы, все эти индексы удаляются, оставляя после себя пустое место. Ваша вставка в следующую таблицу снова переносит всю стоимость вашей первой вставки. Ваши индексы подвергаются действию, возможно, вызывают разбиение блоков, ваши PK, AK и FK все проверяются снова. Повторное полоскание для неправильной таблицы.
Теперь, что произойдет с вашей моделью данных, если вы примете эту парадигму, когда обнаружите, что бизнес нуждается в 4-м состоянии? Вы собираетесь добавить четвертую таблицу документов для тех, кто находится в состоянии отправки или отправке. В конце концов, новое отправленное состояние имеет 5-7 столбцов, которые не нужны другим государствам.
И есть много запросов, которые становятся понятными для написания и выполнения с несколькими таблицами, с одной таблицей они четкие, лаконичные и быстрые ... размер таблицы действительно будет влиять только на полное сканирование таблицы, которое мы пытаемся выполнить избегайте таблиц, подобных этим.
Я видел подобные системы. Один из основных оперативных запросов: «Где мой документ?»
Вам нужно найти 3 таблицы, чтобы найти ее состояние. Далее большинство людей создают представление UNION ALL для всех трех таблиц, чтобы облегчить множество подобных вопросов. Если другой автор думает, что ваши запросы замедляются с другими данными в вашей таблице, посмотрите, как они действительно замедляются, когда вы выполняете UNION ALL, чтобы выполнить то же самое. 1 индекс уровня 3, в отличие от 3 показателей уровня 2.
Пример / РЕДАКТИРОВАТЬ * * одна тысячи пятьдесят-два
Я работаю в торговой компании. Мы заключаем сделки с контрагентами . По бухгалтерским и юридическим причинам наша компания определяется как несколько компаний. Хорошо называть их Трейдинг, Холдинг, СП. Нашим контрагентам мы позвоним. JonesCo, SmithBarely, GoldSax.
Так что, если я считаю, что у внутренних компаний есть уникальный набор столбцов, а у контрагентов - уникальный набор столбцов. Вы бы сказали, что правильная нормализация вынудит их создать две таблицы. Итак, давайте сделаем это.
INT_CO_T
1 Торговая
2 Холдинг
3 СП
CNTR_PTY_T
1 JonesCo
2 SmithBarely
3 GoldSax
Теперь мне нужна таблица trade , где я отображаю транзакцию между нашей компанией (компаниями) и контрагентами
TRADE_T (Int_co_T.ID, Ctr_pty_T.ID, другие торговые столбцы)
Отлично.
Ой, Бизнес говорит, что СП будет заключать сделки с Трейдингом. Кстати, это очень распространенный сценарий, это происходит постоянно. Торговый дом будет называть эти сделки между книгами.
Теперь у меня есть два варианта. (Действительно три) но.
1 заключается в том, что я мог бы сделать что-то очень глупое и поместить JointVenture и Trading в таблицу Counterparty, чтобы моя таблица отображения все еще работала. Это приводит к кошмарным запросам, которые, я уверен, распознают те, кто участвует в этом разговоре. Или я могу создать отдельную таблицу сопоставления ... и это также приведет к созданию некоторых союзов, если я захочу увидеть все сделки определенной компании.
Третий и лучший способ - создать единую таблицу для контрагентов и внутренних компаний, которая называется Trading_entities или чем-то еще. Теперь мне нужна одна таблица сопоставления для отображения внутренних или внешних сделок. Я легко могу увидеть чистую позицию и чистую экспозицию с помощью одного запроса, двух таблиц. и т.д.
Если вы действительно зациклены на пустых полях, разделите эту таблицу по вертикали и используйте три таблицы. Но основная таблица будет иметь список и, что важнее всего, один ключ для любого подтипа участника торговли.