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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

Это звучит не так, как вопрос о таблицах/столбцах, а о нормализации. В некоторых ситуациях высокая степень normalization (в этом случае "больше таблиц" ) хороша и чиста, но обычно это занимает большое количество СОЕДИНЕНИЙ, чтобы получить соответствующие результаты. И с достаточно большим набором данных это может привести к снижению производительности.

Джефф написал немного об этом относительно дизайна StackOverflow. См. Также сообщение Джеффа на Dare Obasanjo.

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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

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

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

Здесь сообщение Jeff по теме.

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

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

Ответ 12

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

Ответ 13

Хм.

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

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

Ответ 14

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

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

Ответ 15

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

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

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

Ответ 16

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

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

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

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

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

Ответ 17

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

Ответ 18

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

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

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

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