Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Foreign keys: теория...
|
|||
|---|---|---|---|
|
#18+
То что по примари key формируется индекс - это понятно... Но вот если в другой таблице использует этот key в качестве foreign key и мы теперь пытаемся удалить запись из примари таблицы. Сервер выкидывает сообщение об ошибке - это понятно... Но как он узнает, что в во второй таблице есть уже запись ссылающаяся на первую таблицу? Строится ли неявный индекс по полю со ссылкой на первую таблицу для второй таблицы или производится полное сканирование? Зачем мне это нужно знать: можно ли безболезненно вводить "лишние" ключи и ссылки без потери производительности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2001, 03:32 |
|
||
|
Foreign keys: теория...
|
|||
|---|---|---|---|
|
#18+
При создании связи между таблицами, поле таблицы, составляющее FK явно не индексируется, это нужно сделать самому. А на счет производительности, могу сказать вот что. У меня работает довольно большая база. При чем к таблице со справочником продукции через FK привязано более 80 таблиц. И вот что я заметил, чем больше таблиц привязываеш, тем дольше идет процесс удаления записей. И это понятно, ведь сервер должен проверить все связянные таблицы на наличие записей. Так что я всегда индексирую поля, составляющие FK. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2001, 04:18 |
|
||
|
Foreign keys: теория...
|
|||
|---|---|---|---|
|
#18+
>Зачем мне это нужно знать: можно ли безболезненно вводить "лишние" ключи и ссылки без потери производительности? Ключи не могут быть лишними, если ключ лишний, значит это ошибка проектирования, что как сами понимаете есть плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2001, 05:07 |
|
||
|
Foreign keys: теория...
|
|||
|---|---|---|---|
|
#18+
ключ таки может быть "лишним", если он несет неявную/вспомогательную нагрузку. конечно, в конечном итоге это проистекает из-за ошибок проектировная но на уже готовой базе иначе может выхода и не быть... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2001, 05:43 |
|
||
|
Foreign keys: теория...
|
|||
|---|---|---|---|
|
#18+
2:pkarklin понял, спасибо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2001, 05:45 |
|
||
|
Foreign keys: теория...
|
|||
|---|---|---|---|
|
#18+
>ключ таки может быть "лишним", если он несет неявную/вспомогательную нагрузку. Какую, какую нагрузку? Нда... Вот про первичные ключи слышал, алтернативные тоже слышал, даже про внешние знаю..... а вот о лишних слышу в первый раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2001, 07:18 |
|
||
|
Foreign keys: теория...
|
|||
|---|---|---|---|
|
#18+
2Genady: я может быть не селен в терминологии... ситуация: есть таблица с процентными ставками, таблица с договорами и таблица с магазинами. ставки связаны с магазинами (причем неявно, через таблицу партнеров), магазины с договорами. далее формируется отчет, где в селекте необходимо что-то посчитать используя нужный процент для нужного магазина. Теперь если из таблицы процентов удалить какую-то запись то в отчет не будет считаться процент. Что я делаю - завожу в договорах дополнительное поле и делаю foreign key на таблицу процентов. В результате если запись в процентах уже где-то используется, то удалить ее сервер не даст... Я где-то не прав? И как назвать вот такой вот foreign key, кроме как лишний? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2001, 11:56 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32013489&tid=1825639]: |
0ms |
get settings: |
6ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
50ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 366ms |

| 0 / 0 |
