Siemargllockyпропущено...

совершенно не факт, кстати.
Современные оптимизаторы учитывают FK при построении планов запросовЯсное дело. FK же тянет за собой индекс. Индекс обслуживать надо всегда, а вот будет ли он эффективно использоваться в работе - не факт.

FK может существовать без индекса, но это скорее нонсенс.
оптимизатор учитывает не индекс, а именно FK, упрощая соединения путём выбрасывания ненужных таблиц

Siemargllockyпропущено...

оптимизатор учитывает не индекс, а именно FK, упрощая соединения путём выбрасывания ненужных таблицИнтересно бы увидеть пример, если не реальный, то хотя бы принцип.

Дурацкий пример, но навскидку не придумывается, а вспоминать лень



план если есть FK



План если нет FK
StmtText

Siemargllocky, ОК.

Т.е. просто нет двойной работы - уже проверенное с помощью FK при вставке данных один раз, при множественных запросах потом повторной проверки не требует.
Не только.
FK дает понятие о том, что может быть, а чего "не может быть в принципе", по итогу из сложных запросов выпадают (сокращаются) промежуточные (и ненужные для этого конкретного запроса) таблицы, план становится проще, выполнение - быстрее.

Особенно хорошо это видно при использовании "обобщенных view для представления полных данных".

MasterZiv
> FK дает понятие о том, что может быть, а чего "не может быть в принципе", по
> итогу из сложных запросов выпадают (сокращаются) промежуточные (и ненужные для
> этого конкретного запроса) таблицы, план становится проще, выполнение - быстрее.

Чёто ты гонишь. FK можно создать и после вставки данных, данные при этом не
будут соответствовать ограничению, реализуемому FK. Запросы при этом должны
выдавать РЕАЛЬНЫЕ данные, а не то, что могло бы быть, если бы FK существовал
в БД всегда.

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



Ну, насчет "гонишь" - это не ко мне.
Что касается вас, дражайший, то почитайте на тему trusted foreign keys, а также не предмет опций созданий FK (check/nocheck)

Что касаемо "никогда не слышал", то вот из того о чем я никогда не слышал - можно целую библиотеку составить. Не сомневаюсь, что это справедливо и в Вашем случае.

MasterZiv > И хотелось бы знать, на опыте какой именно СУБД Вы выдвигаете категорическое
> утверждение вида "иначе и не бывает".

Да хоть MSSQL, хоть MySQL. Только где ты там видел "утверждение вида "иначе и не
бывает" ?


Матчасть изучатьне пробовали? Так, смеха ради

авторWITH CHECK | WITH NOCHECK
Specifies whether the data in the table is or is not validated against a newly added or re-enabled FOREIGN KEY or CHECK constraint. If not specified, WITH CHECK is assumed for new constraints, and WITH NOCHECK is assumed for re-enabled constraints.

If you do not want to verify new CHECK or FOREIGN KEY constraints against existing data, use WITH NOCHECK. We do not recommend doing this, except in rare cases. The new constraint will be evaluated in all later data updates. Any constraint violations that are suppressed by WITH NOCHECK when the constraint is added may cause future updates to fail if they update rows with data that does not comply with the constraint.

The query optimizer does not consider constraints that are defined WITH NOCHECK. Such constraints are ignored until they are re-enabled by using ALTER TABLE table CHECK CONSTRAINT ALL.


Первое выделение - насчет "не бывает"
Второе - насчет "никогда не слыхал, чтобы оптимизатор".

pkarklinSQL BigotИспользование "этой штуки" нужно, если надо что-то делать\проверять перед или после манипуляций с записью.

Для этого не нужны триггеры уровня записи.
Хотя иногда чертовски удобны.

pkarklinSQL BigotКлассический(?):журнал всех(в том числе и неудачных) попыток манипуляций с записью без включения аудита.

Можно расшифровать термин "неудачных"?
С роллбэком
но тут, видимо, нужнее не row-level-trigger, а автономные транзакции