Нужно ли создавать базу данных с как можно меньшим количеством таблиц?

52

Должны ли мы создать структуру базы данных с минимальным количеством таблиц?

Должно ли оно быть спроектировано таким образом, чтобы все оставалось в одном месте, или можно иметь больше столов?

В любом случае это повлияет на что-нибудь?

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

РЕДАКТИРОВАТЬ

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

Спасибо всем за ответы.

Шахиир
источник
15
Минимальное количество таблиц простое, просто сериализовать целое в master_table (имя_таблицы, имя_колонки, тип_колонки, идентификатор_строки, значение).
Инка
что? я не понимаю
Шахир
12
Поскольку каждое поле в базе данных определяется комбинацией имени таблицы, имени столбца, первичного ключа и значения, вы всегда можете уменьшить количество таблиц, денормализовав в одну таблицу, в которой хранится только это. Не очень полезно, но вполне возможно.
Инка
ну, я просил ради знания, и если что-то менее полезно, чем существующее, зачем его менять? Я имею в виду, что это даст хоть какое-то улучшение? производительность например?
Шахир
1
@Hamza: Это может обеспечить улучшенную производительность. Это действительно зависит от конкретных обстоятельств. Там не почти достаточно информации здесь для нас , чтобы дать конкретный ответ.
FrustratedWithFormsDesigner

Ответы:

155

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

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

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

FrustratedWithFormsDesigner
источник
107
+1:If your major concern is quantity of tables, you should probably not be designing database systems.
Джоэл Этертон
9
Следствие: таблица базы данных не занимает [много] дополнительного пространства. Это данные, которые занимают место. Нормализация = больше таблиц = меньше повторений = меньше используемого пространства. Стараясь свести к минимуму количество таблиц, вы не только ставите под угрозу дизайн, но и фактически тратите пространство . Этот «настольный гольф» просто плохой, если только некоторые столы не являются буквально избыточными.
Aaronaught
1
+1, хотя я не думаю, что мы знаем достаточно, чтобы сказать, что в его случае правильное число равно 8, поскольку мы не можем сравнивать схемы (оригинал может лучше выдерживать больший объем транзакций, чем приложение в настоящее время, для пример)
Адам Робинсон
2
@Hamza: Хорошо, так что он может иметь хорошие PHP навыки и хорошие навыки базы данных, и что проект может потребовать как - но не делают предположение о том, что наличие одного автоматически подразумевает другое. Многие разработчики могут иметь один навык, но не другой.
FrustratedWithFormsDesigner
4
@ Том Андерсон - Тогда вы все равно не должны проектировать системы баз данных.
Джоэл Этертон
71

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

Адам Кроссленд
источник
3
english.stackexchange.com/questions/495/less-vs-fewer Не для того, чтобы превратить это в дискуссию, но вот интересная дискуссия на тему «меньше» против «меньше», включая ее происхождение, из английского языка SE , так как это, кажется, вас в восторг, ребята;)
Кори
17

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

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

Майкл К
источник
4
В нормализованной модели данных да, это лучший подход, однако, если база данных предназначена для создания отчетов или главным образом для доступа к чтению, тогда денормализованные «сведенные» таблицы будут работать лучше на больших наборах данных. В этом случае меньшее количество таблиц приведет к меньшему количеству объединений и лучшей производительности.
maple_shaft
2
@maple Абсолютно согласен. Вы должны профилировать, чтобы определить, какие наборы данных должны быть сгруппированы, поэтому IMO вам нужно начать нормализовать. YMMV, эксперты, вероятно, могут сделать это изо всех сил :) У Джеффа есть пост о денормализации, который вы также можете найти интересным.
Майкл К
1
Хороший и лаконичный пост, я читал этот раньше! Иногда вы можете использовать лучшее из обоих миров. Если отчетность не должна быть на 100% в режиме реального времени, тогда следует поддерживать две схемы, одна из которых является нормализованной транзакционной схемой для использования в приложениях, а другая - денормализованной схемой, которая регулярно транслируется и настраивается для предоставления доступа к данным.
maple_shaft
1
Более подробная информация по теме с объяснением схемы звезды: publib.boulder.ibm.com/infocenter/rbhelp/v6r3/…
maple_shaft
1
@maple_shaft, я согласен, что базы данных отчетов часто деномализованы для производительности, но я не ожидаю, что студент или младший программист получат разрешение на это. Я знаю, что, конечно, я бы не позволил обрабатывать мои хранилища данных тем, кто не обладал проверенным опытом.
HLGEM
7

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

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

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

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

HLGEM
источник
Google разработал BigTable и намеренно исключил объединения, поскольку он не распараллеливается.
Ли Райан
2
@ Ли Райан, BigTable - это особый случай, который НЕ подходит для большинства бизнес-приложений, так как целостность данных не является большой проблемой. Google не нужно очень много сложных бизнес-правил для поиска. Держу пари, что их корпоративное финансовое приложение не использует BigTable. Тем не менее, большинство бизнес-приложений, которые имеют большие базы данных, на самом деле могут использовать объединения и работать хорошо, если разработчик осведомлен. Корпоративные базы данных имеют множество способов повысить производительность (включая разбиение) и, таким образом, не нужно терять функции целостности данных в реляционной базе данных.
HLGEM
+1 для вас, @HLGEM, и за ответ, и за комментарий; многим разработчикам стыдно прыгнуть на подножку базы данных документов, потому что они думают, что "join = slow", только чтобы пойти и попытаться решить реляционные проблемы, которые были решены реляционными базами данных 20 лет назад.
Адам Робинсон
5

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

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

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

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

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

Нил Баттерворт
источник
2

Минимальное количество столов поражает меня как особая цель.

Конечно, было бы неплохо сократить схему с 20 таблиц до 8 (если все сделано правильно, это может уменьшить объединения и повысить производительность, удалить неиспользуемые столбцы и т. Д.), Но это может также усложнить понимание и улучшить работу в будущем.

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

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

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

Джон Хопкинс
источник
0

Номер не важен. Дизайн есть. Посмотрите на некоторые системы там. Magento, PHPBB и т. Д. Они имеют десятки таблиц в своих системах и работают просто отлично.

Райан-стрит
источник
0

Наряду с проблемами нормализации и производительности вы можете использовать «для этого потребуется другая таблица» в качестве способа управления областью применения. Эта функция потребует новой таблицы и все время, энергии и усилий для проектирования, создания, тестирования, управления обновлениями и всего прочего кодирования. Добавить 5 полей в существующие таблицы (где это уместно) гораздо проще, чем таблицы из 5 столбцов.

JeffO
источник
0

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

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


источник
0

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

Я не буду вдаваться в подробности, но я думаю, что тот факт, что количество таблиц может влиять на производительность, является одной из причин, по которой были изобретены базы данных noSQL, такие как Cassandra, Mongo и Google BigTable (sic!), и именно поэтому они поощряют денормализацию данных (и, следовательно, избегают большого количества таблиц / коллекций и т. д.).

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

Я не говорю, что простой факт наличия x-таблиц в схеме обязательно сделает ее медленнее, чем схема с x / 2-таблицами все время, но есть определенные контексты, в которых это может привести к замедлению из-за дополнительные операции, необходимые для объединения данных во всех этих таблицах. Продолжая это, я также не думаю, что можно сказать, что «любое количество таблиц и крайняя нормализация данных никак не влияют на производительность».

Дракон Шиван
источник
0

Дядя Боб будет утверждать, что Море проще.

Смотрите http://c2.com/cgi/wiki?FearOfAddingTables

«хороший дизайн обычно упрощается добавлением таблиц»

Я считаю, что почти все сущности имеют множество ко многим, что требует большего количества таблиц.

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

Нил Макгиган
источник
-2

Тогда ответ ДА.

Но зависит, каково истинное значение «минимального» количества таблиц.

Например (анти-пример).

Если у меня есть следующие объекты

  1. пользователи
  2. клиенты

и оба имеют одни и те же состояния (поля), и тогда нет никаких ограничений безопасности, это более подходит для создания одной таблицы

  1. table_persons

скорее две разные таблицы

  1. table_users
  2. table_customers

минус в том, что в table_persons нам нужно будет добавить новое поле (type_of_person).

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

  1. table_persons

в двух таблицах

  1. table_info_persons
  2. table_extra_info_persons

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

Магеллана
источник
эй, ваш ответ очень нагляден и помогает, спасибо
Shaheer
2
Это дает мне воспоминания о моем первом корпоративном приложении и о базе данных за ним, и о том, какой большой кошмар сделал DBA из-за того, что он был нацистом в подобных вещах. Я бы никогда не объединил клиентов и пользователей, которые являются совершенно разнородными бизнес-объектами.
-1: пользователи и клиенты имеют разные поля; Если не в этот момент, они будут иметь в какой-то момент в будущем. Таким образом, они заслуживают отдельных таблиц.
Sjoerd
1
@Sjoerd, @Chris: Хотя это часто бывает, это не всегда так. Такие вещи зависят от приложения. При этом я согласен с мнением. Слишком часто разработчики баз данных видят «общие имена полей», что означает, что это одни и те же данные. Это становится особенно легко сделать, когда вы сначала смотрите на базу данных из ORM (другими словами, назад). Хотя концепции ОО могут быть смоделированы в базе данных, базы данных - это строки и отношения, а не объекты .
Адам Робинсон
1
+1 за "базы данных - это строки и отношения, а не объекты", я добавлю его в мои любимые цитаты!
Шахир