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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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