MySQL « Помогите правильно выбрать тип поля для построения индекса
Уже есть:
- разные поставщики товаров предоставляют свои каталоги продукции, рубрики, характеристики и пр. информацию в различных форматах (Excel, различные структуры XML и пр.)
- на каждый формат существует провайдер данных, который сохраняет данные в соответствии со структурой в различных БД/таблицах БД (здесь много ручной работы манагеров и пр.)
Далее все эти таблицы должны интегрироваться в одну БД с четкой структурой, но везде для связанности данных используются разные ключи, где-то id=T1, где-то id="TabletPC" (объектов много - не только товар/категория/характеристика). Возникает проблема формирования ключей:
1) Либо делать более сложные механизмы, которые будут переводить все ключи к integer виду
2) Либо не париться и просто хешировать любые ключи как строки ну и т.д.
К сожалению не могу разбить вопросы по топикам по этому задам сразу несколько:
Посоветуйте как лучше организовать и насколько скажутся на производительности ключи из хешей (и если это не слишком критично то какую функцию кеширования лучше использовать с учетом 100000 строк в таблице для избежания коллизий)?
PS Важно то, что performance не является узким местом
PSS БД MySQL
Чтобы правильно понимать можно посмотреть кусочек метаописания одного из каталогов с учетом md5 хешей
Пример
1 ответов
индексы по строкам значительно медленее нежели индексы по int. Но все зависит непосредственно от окружающих факторов. Если у Вас Большие объемы данных и скорость выборки по ним критична, то естественно лучше помучиться и привести все первичные ключи к типу int (bigint) unsigned autoincrement, если скорость выборки не так критична, то можно строить индекс и по строке (хешу). В случае если, например, Вам необходимо не только вставлять данные в результирующую БД, но и обновлять, то можно добавить справочную таблицу соответствия ключей, в которой первое поле будет Ваш новый ключ, а вторым полем - старый. В этом случае более тяжелый индекс по строке вы будете использовать только на момент загрузки данных, а в самом приложении сможете использовать более быстрый ключ по int (bigint).