Какой из этих двух вариантов является более эффективным по времени загрузки для MySQL дизайна таблицы?

Question

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

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

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

В настоящее время существует около 40 полей, но это может быть изменено.

Существует страница «указатель», в которой перечислены около 10 полей для каждого учреждения. Поскольку это одна из наиболее часто используемых страниц сайта, с незначительными изменениями данных, кеширование является одним из факторов.

Страница "index" переходит на страницу со всеми подробностями. Для отдельных страниц организации данные будут поступать из двух таблиц, и будет либо два запроса к базе данных, либо запрос типа соединения.

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

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

Answer 1

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

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

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