Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Нужен совет по большой базе
|
|||
|---|---|---|---|
|
#18+
Давайте не офтопить. У меня FK, ссылающийся на словарь. Естественно, что никаких on delete cascade и on update cascade там нету, но индекс создаётся. Можно ли отказаться от создания этого индекса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2015, 09:10 |
|
||
|
Нужен совет по большой базе
|
|||
|---|---|---|---|
|
#18+
ArtDenУ меня FK, ссылающийся на словарь. Естественно, что никаких on delete cascade и on update cascade там нету, но индекс создаётся. Можно ли отказаться от создания этого индекса?Нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2015, 11:19 |
|
||
|
Нужен совет по большой базе
|
|||
|---|---|---|---|
|
#18+
ArtDenDimitry SibiryakovА проверки, по-твоему, должны идти натуралом при операциях с мастер-таблицей? А разве для проверок недостаточно индекса pk, на который это поле ссылается?FK проверяется как при изменениях дочерней таблицы, так и при изменениях родителя. О чем тебе и говорят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2015, 11:20 |
|
||
|
Нужен совет по большой базе
|
|||
|---|---|---|---|
|
#18+
Да, похоже от индекса не обойтись. Жалко. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2015, 11:35 |
|
||
|
Нужен совет по большой базе
|
|||
|---|---|---|---|
|
#18+
ArtDenДа, похоже от индекса не обойтись. Жалко. Повторяю ещё раз, медленно: если таблица справочника не изменяется (изменяется очень редко), то ты можешь вообще не создавать FK, а целостность контролировать триггерами. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2015, 11:47 |
|
||
|
Нужен совет по большой базе
|
|||
|---|---|---|---|
|
#18+
ArtDenВ таблице- миллиарднике есть поле, которое ссылается на словарь . . . Да, похоже от индекса не обойтись. Жалко.Не шутите с миллиардом. Это серьёзное число записей для нынешних версий ФБ, тем более что дальше там будет и полтора, и два млрд. Разбейте эту таблицу на 10 штук. Во всех пропишите FK на master-таблицу ("словарь"). Индексы по ним будут иметь меньшую глубину и затраты на их обновление при DML будут меньше. Поиск РР в этих таблицах также будет идти быстрее. Изменения таблиц реализуйте через обновляемую вьюху (решение о том, какую именно таблицу обновлять, должно приниматься в триггере этой вьюхи). А в приложении уже должна использоваться именно эта вьюха, а не таблицы. Короче - эмуляция секционирования :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2015, 11:54 |
|
||
|
Нужен совет по большой базе
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovArtDenДа, похоже от индекса не обойтись. Жалко. Повторяю ещё раз, медленно: если таблица справочника не изменяется (изменяется очень редко), то ты можешь вообще не создавать FK, а целостность контролировать триггерами. Достаточно, чтобы не менялся первичный ключ в словаре и не удалялись из него записи. Вставка, изменение не ключевых полей - все это не нарушает ссылочной целостности и допустимо. Если этого нет, FK можно прибить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2015, 10:02 |
|
||
|
Нужен совет по большой базе
|
|||
|---|---|---|---|
|
#18+
В общем, пока оставлю как есть. Не хочу городить различные костыли там, где проблему можно попытаться решить другим способом. Тем более что на тестовой базе пока сильных тормозов на "разогретой" базе не замечено при >700 млн. записях в 2-х больших таблицах, причём идёт непрерывная репликация с 10-ю филиалами каждые 10 секунд. Правда в тестовую базу сейчас не пишутся блобы, но думаю они расклад не сильно изменят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2015, 10:10 |
|
||
|
|
start [/forum/topic.php?fid=40&msg=38940015&tid=1562891]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
174ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 16ms |
| total: | 283ms |
| 0 / 0 |
