Нормализовать базу данных или нет? Таблица только для чтения MyISAM, производительность является основным приоритетом (MySQL)

Question

Я импортирую данные в будущую базу данных, в которой будет одна статическая таблица MyISAM (будет считываться только из). Я выбрал MyISAM, потому что, насколько я понимаю, это быстрее для моих требований (у меня совсем нет опыта работы с MySQL / SQL).

Эта таблица будет иметь различные столбцы, такие как столбцы ID, Имя, Пол, Телефон, Статус ... и Страна, Город, Улица. Теперь вопрос заключается в том, следует ли мне создавать таблицы (например, Country: Country_ID, Country_Name) для последних 3 столбцов и ссылаться на них в основной таблице по идентификатору (normalize ... [?]) Или просто сохранять их как VARCHAR в главная таблица (с дубликатами, очевидно)?

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

Будет ли поиск по столбцам "Страна", "Город" и / или "Улица" (и, возможно, по другим столбцам в том же поиске) быстрее, если я просто использую VARCHAR?

РЕДАКТИРОВАТЬ: таблица имеет около 30 столбцов и около 10 м строк.

Answer 1

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

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

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

Answer 2

Я постараюсь дать вам нечто большее, чем обычный ответ "Это зависит".

# 1 - все быстро для маленьких N - если у вас меньше 100 000 строк, просто загрузите его ровно, индексируйте его, как вам нужно, и переходите к чему-то с более высоким приоритетом.

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

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

Так что это действительно сильно зависит от вашего профиля данных (ширина строки и количество строк) и моделей использования.

Answer 3

У меня не намного больше, чем обычный ответ "Это зависит", к сожалению.

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

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

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