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

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

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

Вопросы:

  • Неужели так сложно сливать таблицы там, где это необходимо, и тем самым сокращать соединения?

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

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

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

6 ответов

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

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


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

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

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

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


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


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

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

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

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


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

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

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


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

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

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

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

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

licensed under cc by-sa 3.0 with attribution.