Структура базы данных - Чтобы присоединиться или не присоединиться

Question

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

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

Вопросы:

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

• Должны ли мы начать смотреть на горизонтальное разбиение? (в сочетании с таблицами слияния)

• Есть ли лучший способ свернуть таблицы, чтобы позаботиться о взаимоотношениях «многие ко многим»?

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

В обратном порядке:

• Забудьте об этом. Используйте базу данных. Люди saynig «делают это в приложении» довольно часто являются теми, кто не осведомлен о количестве работ, которые собираются писать в базах данных.

• В зависимости от конкретной необходимости.

• В зависимости от конкретной необходимости. OLTP (обработка транзакций) - подходит для обычной формы. OLAP (аналитическая обработка) - перейдите на правильную звездную диаграмму и денормализовать, чтобы получить оптимальную производительность. Смешанный - забудьте об этом. Не работает для более крупных установок, потому что теории разные ... за исключением случаев, когда вы создаете базу данных OLTP, а затем используете специальную базу данных куба OLAP (которой у mySQL нет).

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

Если вы указали внешние ключи (вы установили внешние ключи, не так ли?) И имеете правильные места в ваших запросах, 10-15 соединений должны быть легко обработаны базой данных. Особенно с таким количеством строк. У меня есть запросы с таким количеством подключений к таблицам с миллионами строк, и они работают нормально.

Обычно лучше разделять данные, чем денормализовать.

Что касается деноминации, не делайте этого, если вы не разработали стратегию сохранения денормализованных данных в синхронизации с родительской таблицей.

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