это не суррогатный ключ, точнее я написал про создание отдельного поля (тот же автоинкремент), которое и будет этим ключом, а UNIQUE INDEX это отдельное ограничение
ORDER BY type=val_3
что это значит? как по твоему представлению это должно работать?
Everything_is_bad, да, нам всем уже очень смешно.
Поэтому потрудитесь объяснить, что мешает вам добавить третье условие.
И в целом объяснить суть своих проблем.
Потому что ответ на вопрос, как удалить по трем параметрам как бы очевиден: удалять надо по трем параметрам, а не по двум
My1Name, так же как ты сейчас сделал where c двумя полями, к этому условию добавить третье, проблема так и не понятна, а UNIQUE INDEX это индекс, а не поле с которым работают.
а чем это отличается от варианта WHERE col_1=val_1 AND col_2=val_2 AND col_3=val3
Вы серьезно считаете, что порядок удаления записей ( ORDER by ...) имеет значение?
Удалять по ключу - несуществующее понятие. Удалять можно по некоему критерию (который в т.ч. может быть и комбинацией из нескольких других, более простых, критериев), в качестве какового может быть как выполнение некоего условия отбора, так и положение записи при некоей сортировке (последнее поддерживается далеко не всеми СУБД).
Vitsliputsli, Проектируется большая БД (в теори, высоконагруженная частотой запросов) с множеством разных таблиц. Необходимо оптимизировать скорость доступа к одной записи.
Проектируется большая БД (в теори, высоконагруженная частотой запросов) с множеством разных таблиц.
не выдумывайте искусственных проблем, постройте обычную БД в соответствии с реляционной теорией. А потом уже решайте просадки производительности из-за "высоконагруженности", если таковые возникнут.
Необходимо оптимизировать скорость доступа к одной записи.
Тогда обращайтесь к этой записи по primary key, а не через индексы. Либо суррогатный ключ, как уже предлагали, либо составной ключ (и то, в этом случае надо посмотреть какие типы данных у этих полей).
Ипатьев, правильный ответ, а точней ход мыслей, написал Everything_is_bad. Но, ответ с использованием суррогатного ключа - он (или она) так и не написал.
Как я писал выше, ответ с использованием суррогатного ключа не существует.
Обращение к строке в таблице происходит по полям, а не "по ключу".
Перед тем как называть других имбецилами, неплохо бы сначала самому узнать, как работают элементарные запросы
Проектируется большая БД (в теори, высоконагруженная частотой запросов) с множеством разных таблиц. Необходимо оптимизировать скорость доступа к одной записи.
Это искусственная проблема, т.к. проблемы по факту нет, но вы чтото хотите решить. Оптимизация это всегда жертва чемто ради чегото, поэтому нужно знать, что мы хотим улучшить, и чем готовы пожертвовать.
В общем случае, обращение по первичному ключу всегда быстрее, чем по полям, хоть с индексом, хоть без. Первичный ключ есть всегда, то что вы не создали соответствующее поле, просто лишает вас возможности к нему обратиться, MySQL создаст его сам.
А вопросы оптимизации чаще всего решаются проектированием БД, а не вставкой в запрос магической фразы "сделай все хорошо". Поэтому не будете менять структуру, не получите изменений.
Что вы подразумеваете под первичным ключом?
Говорите пожалуйста языком программирования. Я сам философ не хуже вас... Вы имеете ввиду PRIMARY KEY, UNIQUE KEY или что вы подразумеваете?
Проектируется большая БД (в теори, высоконагруженная частотой запросов)
нету primary key в этой таблице.
Я плакаль! За проектирование БОЛЬШОЙ и, по расчётам, ВЫСОКОНАГРУЖЕННОЙ, базы данных берётся человек, которому глубоко плевать на нормализацию, который вообще не анализировал предметную область и не собирался строить ER-диаграмму (и вообще не факт, что он знает, что это такое)... но его почему-то очень сильно волнует производительность одного сильно частного запроса.
По всем ощущениям автор - полный и абсолютный в этой области дилетант. А результат его работ предсказуем, и (если он срочно не перестроится и не начнёт глубоко изучать теорию) скорее всего будет весьма плачевен.
Как я писал выше, ответ с использованием суррогатного ключа не существует
Почему INSERT IGNORE по UNIQUE INDEX работает без проблем? Оно же делает фактически тоже самое...
В крайнем случае, создают дополнительное поле, которое содержит комбинированную информацию по нескольким полям ("суррогатный ключ"). И тогда это поле может выступать как PRIMARY KEY. Однако, мне этот вариант не очень нравится... Ключ под это поле нужно как-то сжимать. И я думаю MySQL это знает лучше меня.
Например, если у меня два поля типа INT (long) а третье CHAR, то чтоб их скомбинировать (тупо) нужно создать поле VARCHAR как минимум в три раза больше :/
Что вы подразумеваете под первичным ключом?
Говорите пожалуйста языком программирования.
Первичный ключ - это выражение, которое используется сервером для идентификации записи.
И Vitsliputsli абсолютно прав - он есть абсолютно всегда и в любой таблице. Если заданная пользователем структура таблицы не содержит явного указания на выражение первичного ключа и не позволяет выбрать таковой из имеющихся, то сервер самостоятельно генерирует скрытое 6-байтное поле первичного ключа и использует его.
My1Name, вы какой-то бред несёте. При чем тут insert? При чем тут какое-то комбинированное поле? У вас был детский вопрос, как указать в запросе не два поля, а три три. Вам ответили.
У вас был дурацкий вопрос, как удалить "по ключу". Вам ответили, что такого синтаксиса в SQL нет. БД сама использует ключи для оптимизации запросов, а к синтаксису они не имеют отношения.
Теперь у вас какие-то нелепые фантазии про первичные и суррогатные ключи. Вы считаете первичный ключ "философским понятием" и у вас опять нелепая фантазия про то, что для суррогатного ключа надо создавать зачем-то отдельное поле.
Не надо выставлять свое невежество напоказ так явно.
Ипатьев, да уже давно понятно всё про него, знаний минимум, гонора максимум, часто несет полную чушь, не способен воспринимать хоть какую критику, сразу виноваты все остальные, почему его банят только на время, а не навсегда, не понятно. А еще он иногда показывает свой реальный код))
Простой
