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

Question

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

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

Вопросы:

• Это действительно так?плохо ли объединять таблицы там, где это необходимо, и тем самым сокращать объединения?

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

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

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

Answer 1

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

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

Answer 2

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

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

• Зависит от точной необходимости.

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

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