|
Задавайте вопросы, мы ответим
Вы не зашли.
Допустим, есть таблица городов со следующими полями:
'id'=>'MEDIUMINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY COMMENT "id города"',
'country_id' => 'SMALLINT NOT NULL DEFAULT "0" COMMENT "id страны, к которой принадлежит город"',
'region_id' => 'SMALLINT NOT NULL DEFAULT "0" COMMENT "id региона, к которому принадлежит город"',
'name' => 'VARCHAR(64) NOT NULL COMMENT "Название города по MaxMind GeoIP"'
В этой таблице country_id и region_id являются FK, но при этом для оптимизации поиска не помешает составной индекс на оба поля. Возможно именно в этой таблице это лишнее, но похожие ситуации есть у более объёмных таблиц, и FK может быть больше двух. В итоге мы получаем 3 индекса, которые дублируют друг друга + уникальный индекс на поле name (куда ж без него), и у нас размер индекса становится больше данных, или около того 
Отсюда вопрос: на сколько это нормальная практика? Не хочется, чтобы индексы занимали места почти как данные всей таблицы. Убирать FK вроде тоже не совсем разумно.
Направьте плз на правильную структуру
Неактивен
То, что индексы могут занимать больше, чем данные - нормальная практика. Это может быть плохо, если таблицы перестанут помещаться на диск или сильно замедлятся операции INSERT и UPDATE. В каждом конкретном случае нужно решать, что важнее.
Использование FOREIGN KEY приводит к падению производительности, но это плата за согласованность данных (если требуется).
Неактивен
Ясно, спасибо.
Неактивен
rgbeast написал:
Использование FOREIGN KEY приводит к падению производительности, но это плата за согласованность данных (если требуется).
Потеря производительности только на запись ? Я так понимаю на чтение это не должно влиять ?
Неактивен
evgeny написал:
Потеря производительности только на запись ? Я так понимаю на чтение это не должно влиять ?
В основном только при обновлении. Увеличение объема таблицы может влиять и на скорость select, но обычно это не так существенно.
Неактивен
