Какой лучший дизайн базы данных: больше таблиц или больше столбцов?

Question

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

Он утверждал, что этот дизайн был более эффективным и гибкий. Возможно, он более гибкий, но я не могу комментировать его эффективность. Даже если он более эффективен, я думаю, что эти выигрыши могут быть перевешиваны дополнительной сложностью.

Итак, есть ли существенные преимущества для большего количества таблиц с меньшим количеством столбцов за меньшее количество таблиц с большим количеством столбцов?

Answer 1

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

1. Фавор нормализации. Денормализация - это форма оптимизации со всеми необходимыми компромиссами, и поэтому к ней следует подходить с отношением YAGNI.
2. Убедитесь, что код клиента, ссылающийся на базу данных, достаточно развязан от схемы, при переработке которой не требуется существенная редизайн клиентов.
3. Не бойтесь денормализовать, когда он обеспечивает явное преимущество в производительности или сложности запросов.
4. Использование представлений или нисходящих таблиц для реализации денормализации, а не денормализации ядра схемы, , когда это позволяет использовать объем данных и сценарии использования.

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

Answer 2

Это зависит от вашей базы данных. Например, MS SQL Server предпочитает более узкие таблицы. Это также более «нормализованный» подход. Другие двигатели могут предпочесть это наоборот. Мейнфреймы, как правило, попадают в эту категорию.

Answer 3

Я бы рассмотрел нормализацию как первый шаг, поэтому города, округа, штаты, страны были бы лучше как отдельные столбцы ... сила языка SQL вместе с сегодняшними СУБД позволяет вам группировать ваши данные позже, если вам нужно просмотреть его в другом, ненормированном виде.

Когда система разрабатывается, вы можете подумать о «ненормализации» какой-либо части, если увидите это как улучшение.

Answer 4

Я думаю, что баланс в этом случае. Если имеет смысл поставить столбец в таблицу, тогда поместите его в таблицу, если это не так, тогда нет. Подход ваших коллег определенно поможет нормализовать базу данных, но это может быть не очень полезно, если вам нужно объединить 50 таблиц, чтобы получить нужную вам информацию.

Я думаю, что мой ответ будет, используйте ваше лучшее суждение.

Answer 5

Это не похоже на вопрос о таблицах/столбцах, но о нормализации. В некоторых ситуациях высокая степень normalization («больше таблиц» в этом случае) хороша и чиста, но для получения релевантных результатов обычно требуется большое количество JOIN. И с достаточно большим набором данных это может привести к снижению производительности.

Jeff wrote Немного об этом относительно конструкции StackOverflow. См. Также сообщение Джеффа на Dare Obasanjo.

Answer 6

Есть преимущества, имеющие таблицы с меньшим количеством столбцов, но вы также должны взглянуть на ваш сценарий выше, и ответить на следующие вопросы:

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

Answer 7

Есть много сторон к этому, но с точки зрения эффективности применения мотытные столы могут быть более эффективными в разы. Если у вас есть несколько таблиц с кучей столбцов каждый раз, когда db, чтобы выполнить операцию, у него есть шанс сделать блокировку, больше данных будет недоступно на время блокировки. Если блокировки переходят на страницу и таблицы (ну, надеюсь, не таблицы :)), вы можете увидеть, как это может замедлить работу системы.

Answer 8

Имеются огромные преимущества для запросов, используя как можно меньше столбцов. Но сама таблица может иметь большое количество. Jeff также говорит об этом.

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

Answer 9

База данных с несколькими таблицами намного более гибкая, если любая из этих отношений один к одному может стать от одного до многих или многих в будущем. Например, если вам нужно хранить несколько адресов для некоторых клиентов, это намного проще, если у вас есть таблица клиентов и таблица адресов. Я не могу видеть ситуацию, когда вам может понадобиться дублировать некоторые части адреса, но не другие, поэтому отдельные таблицы адресов, городов, состояний и почтовых индексов могут быть немного выше.

Answer 10

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

Я не вижу преимущества наличия таблицы города, если только города сами по себе не являются объектами, которые вас интересуют в приложении. Или, если вы хотите ограничить количество городов, доступных вашим пользователям.

Подводя итог, решения, подобные этому, должны принять приложение непосредственно в рассмотрение, прежде чем вы начнете снимать эффективность. ИМО.

Answer 11

Я бы поспорил в пользу большего количества таблиц, но только до определенной точки. Используя ваш пример, если вы разделили информацию своего пользователя на две таблицы, скажем, USERS и ADDRESS, это дает вам гибкость в отношении того, чтобы иметь несколько адресов для каждого пользователя. Одним из очевидных применений этого является пользователь, у которого есть отдельные адреса фактурирования и доставки.

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

Answer 12

Как и все остальное: от этого зависит.

Нет жесткого и быстрого правила относительно количества столбцов и подсчета столбцов.

Если вашим клиентам необходимо иметь несколько адресов, то для них имеет смысл отдельная таблица. Если у вас есть повод для нормализации столбца City в свою собственную таблицу, то это тоже может пойти, но я этого раньше не видел, потому что это поле свободной формы (обычно).

Стол тяжелый, нормализованный дизайн эффективен с точки зрения пространства и выглядит «учебником-хорошим», но может стать чрезвычайно сложным. Это выглядит хорошо, пока вы не должны сделать 12 объединений, чтобы получить имя и адрес клиента. Эти проекты не являются автоматически фантастический с точки зрения производительности, который имеет наибольшее значение: запросы.

Избегайте сложностей, если это возможно. Например, если клиент может иметь только два адреса (не сколь угодно много), тогда имеет смысл просто держать их всех в одной таблице (CustomerID, Name, ShipToAddress, BillingAddress, ShipToCity, BillingCity и т. Д.).

Here's Jeff's post по теме.

Answer 13

Полностью нормализованный дизайн (т. Е. «Дополнительные таблицы») является более гибким, более простым в обслуживании и позволяет избежать дублирования данных, что означает, что ваша целостность данных будет намного проще в обеспечении соблюдения.

Это мощные причины нормализации. Сначала я хотел бы нормализовать, а затем только denormalize конкретных столов после вы видели, что производительность стала проблемой.

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

Answer 14

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

Если какой-либо из столбцов может быть пустым, вам нужно будет поместить каждый столбец с нулевым значением в свою собственную таблицу с внешним ключом в основную таблицу, чтобы нормализовать его. Это общий сценарий, поэтому для более чистого дизайна вы, вероятно, добавляете больше таблиц, чем столбцы в существующие таблицы. Кроме того, добавив эти необязательные атрибуты в свою собственную таблицу, им больше не нужно будет разрешать нули, и вы избегаете множества проблем, связанных с NULL.

Answer 15

Хм.

Я думаю, что это мойка и зависит от вашей конкретной модели дизайна. Определенно исключайте объекты, у которых есть больше чем несколько полей, в свою собственную таблицу, или сущности, чья макияж, скорее всего, изменится по мере изменения требований вашего приложения (например, я все равно буду выставлять адрес из-за того, что у него столько полей, но я 'd особенно сделайте это, если бы вы подумали, что вам нужно будет обрабатывать адреса других стран, которые могут иметь другую форму. То же самое касается телефонных номеров).

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

Answer 16

Когда вы создаете свою базу данных, вы должны быть как можно ближе от значения данных и НЕ использовать ваши приложения!

Хороший дизайн базы данных должен выдерживать более 20 лет без изменений.

Клиент может иметь несколько адресов, это реальность. Если вы решили, что ваше приложение ограничено одним адресом для первого выпуска, это касается дизайна вашего приложения, а не данных!

Лучше иметь несколько таблиц вместо нескольких столбцов и использовать представление, если вы хотите упростить свой запрос.

В большинстве случаев у вас будет проблема с производительностью с базой данных о производительности сети (цепочный запрос с результатом одной строки, нулевой столбец, который вам не нужен, и т. Д.), А не о сложности вашего запроса.

Answer 17

Во-первых, нормализовать ваши таблицы. Это позволяет избежать избыточных данных, предоставляя вам меньше строк данных для сканирования, что улучшает ваши запросы. Затем, если вы столкнетесь с точкой, в которой вы соединяетесь с нормализованными таблицами, заставляют запрос обрабатывать долгое время (дорогостоящее предложение соединения), денормализовать там, где это необходимо.

Answer 18

Приятно видеть так много вдохновляющих и хорошо обоснованных ответов.

Мой ответ будет (к сожалению): это зависит.

Два случая: * Если вы создаете datamodel, который должен использоваться в течение многих лет, и, возможно, он должен обладать многими последующими изменениями: перейдите к большему количеству таблиц и меньше строк и довольно строгая нормализация. * В других случаях вы можете выбирать между более таблицами или менее таблицами - больше строк. Специально для людей, относительно новых для субъекта, этот последний подход может быть более интуитивным и легким для понимания.

То же самое относится к выбору между объектно-ориентированным подходом и другими параметрами.