#sql #database #database-indexes
#sql #База данных #база данных-индексы
Вопрос:
У меня есть нормализованная таблица в базе данных — скажем
(ID, name, age)
Здесь каждая запись соответствует человеку, а ID является ключом этой таблицы.
Существует частый доступ к неключевым полям — эта таблица ищется по полю name достаточно часто для одной вещи.
Итак, для этого я могу поместить индекс в поле name, и, таким образом, таблица также индексируется в этом поле.
Технический директор говорит, что эта таблица должна быть разбита на N таблиц — по одной для каждого из неключевых полей (в данном случае N = 2):
(ID, name)
(ID, age)
Он предлагает это для быстрого доступа к запросам. При такой разбивке каждая из этих двух таблиц
идентификатор по-прежнему используется в качестве ключа, а таблицы не индексируются в другом поле.
На мой взгляд, это не обеспечивает быстрый доступ — даже замедляет его:
-
отсутствие индекса означает повторный поиск по всей таблице в запросе
-
дополнительный доступ к таблице, позволяющий получить всю строку исходной таблицы (имя и возраст), а не извлекать их обе из соответствующей строки (ов) при нахождении соответствующей строки (ов).
Чего здесь не хватает?
TIA
Комментарии:
1. Вы правы. Предлагаемое решение не дает никаких преимуществ.
2. спасибо — если вы напишете это как ответ, я соглашусь. Я считаю, что это полный ответ — искал проверку.
3. Пожалуйста, укажите, к какой базе данных вы обращаетесь. Возможно, это какой-то тип собственной базы данных, и, возможно, он что-то знает об этом, а мы с вами нет. Раньше я работал с собственной базой данных, которая считывала целые строки перед фильтрацией. Если вы говорите о нормальной современной СУБД, то я бы предположил, что ваш технический директор — клоун.
4. @Michael. M — старый добрый MySQL с гибернацией, больше ничего нет. не был уверен, что я сам что-то упускаю — это странно.
5. «При такой разбивке каждая из этих двух таблиц по-прежнему имеет идентификатор в качестве ключа, и таблицы не индексируются в другом поле». Какова логика, по которой не индексируются неключевые столбцы?
Ответ №1:
Ваши рассуждения абсолютно верны, и предлагаемое решение не дает никаких преимуществ и даже ухудшает ситуацию именно так, как вы описываете.
Добавление индексов к часто просматриваемым полям дало бы лучшие результаты, но в зависимости от метода поиска реализованные преимущества могут быть ограниченными. Например, поиск частичных совпадений ( name LIKE '%whatever%' ) может привести к неэффективному использованию индексов.
В зависимости от используемой вами базы данных могут быть доступны другие методы для ускорения работы, например, кэширование памяти, полнотекстовое индексирование и т.д.
Ответ №2:
Короткий ответ заключается в том, что это снижает производительность в целом и является плохим дизайном. Кроме того, вы должны поддерживать ограничения внешнего ключа, чтобы при необходимости его невозможно было удалить .. (Идентификатор, имя) без удаления (идентификатор, возраст). Эти ограничения FK добавят свои собственные накладные расходы. В качестве альтернативы вы могли бы отказаться от реализации FK, но тогда вы открываете набор данных для возможности несогласованных записей. Этот сценарий возможен с помощью обычных инструментов ORM, которые не будут писать функции для вас. С другой стороны, с помощью функций вы можете использовать транзакции и гарантировать, что оба проходят или завершаются неудачей одновременно. Это верно даже для записей. Что, если, например, Мэри Смит выйдет замуж и ее имя изменится на Мэри Уайт. Кроме того, нам нужно изменить ее возраст. Теперь, при предлагаемом дизайне, было бы разумно убедиться, что обе таблицы обновляются в одной транзакции БД, что добавляет сложности
Тогда возникает проблема обслуживания MySQL. Добавление большего количества таблиц, чем необходимо для проектирования, также затруднит усилия по обслуживанию и увеличит нагрузку на собственные затраты MySQL на обслуживание индекса.
Таким образом, помимо снижения производительности БД, это также снижает производительность разработчика из-за дополнительной бесполезной сложности.
Если производительность действительно является такой проблемой, а ваш набор данных действительно настолько велик, и вам действительно нужен быстрый поиск текста и т.д., То лучшим и широко используемым методом было бы использовать что-то вроде Sphinx.
Честно говоря, похоже, что он, возможно, читал что-то о сегментировании и совершенно неправильно понял, что он читал.