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

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

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

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

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

Я предполагаю, что мой ответ будет таким, как вы думаете.

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

Джефф написал немного об этом, что касается дизайна StackOverflow. См. Также сообщение Джеффа, на которое ссылается Не бойся Обасанджо.

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

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

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

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

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

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

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

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

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

Я бы поспорил в пользу большего количества таблиц, но только до определенного момента. Используя ваш пример, если вы разделили информацию о вашем пользователе на две таблицы, скажем, ПОЛЬЗОВАТЕЛИ и АДРЕС, это дает вам гибкость, позволяющую иметь несколько адресов для каждого пользователя. Одно очевидное применение этого - пользователь, у которого есть отдельные адреса для выставления счетов и доставки.

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

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

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

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

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

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

Вот пост Джеффа по теме.

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

Это веские причины для нормализации ситуации. Я бы предпочел сначала нормализовать, а затем денормализовать только таблицы специфическийпосле, вы видели, что производительность становится проблемой.

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

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

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

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

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

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

Хм.

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

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

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

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

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

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

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

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

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

Я бы ответил (к сожалению): это зависит от обстоятельств.

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

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