Привет народ. Обещанный пост

Все вы сталкивались с тем что при перечеслении нескольких таблиц в FROM
могут начаться тормоза. Так как серверу для поиска надо про шерстить, а потом объединить
таблицы вместе. Все описанное ниже рассмотрена на уровне добавления 1 поля, но к примеру у меня таких полей 10 в одной из таблиц дублирующих. Но иногда надо что то уникальное клиенту написать делаем JOIN и лопаем тормоза т. к. на всех не угодишь и таблицу не раз дуешь ради 1 клиента.

Пример:
Организации = Орг
Документы = Док(ОргИДпрод, ОргИДпок)
Склады = Ск
Товары = Тов
Товары на складе = ТовС(ДокИД, СкИД, ТовИД)

что бы нати был ли продан товар некой организации обычно пишем
from Док, ТовС, Тов, Орг ОргПок
если мы укажем товар и организацию сервер отработает махом
и дальше у сервера дилемма с какой стороны искать с Док или ТовС

и мы тут обычно идем ему на встречу и в таблице ТовС
добавляем дублирующие(избыточные поля) из таблицы Док
и в результате таблица
ТовС(ДокИД, СкИД, ТовИД, ОргИДпрод, ОргИДпок)
----достоинства
1.скорость вырастает в разы т. к. мы создадим индекс (ТовИД, ОргИДпок)
----недостатки
1.увеличивается база из за данных ОргИДпок
2.приходится вешать FK ключи т.к. вдруг чего c ОргИДпок
3.при некорректно написанном триггере может быть неточная информация в избыточных данных
решаемо ловлей блох
4.отслеживаем в ручную на триггерах
5.лишние UPDATE для зависящих таблиц
6.увеличивается база из за индекса но это оправдано(возможно не недостаток а необходимость)
7.Огромный недостаток на всех не угодишь и дублирующих полей не навтыкаешь

Я ПРЕДЛАГАЮ
Сделать это на уровне сервера, но в виде индексного поля
в нашем случае получается такая ситуация, чтобы быстро найти
информацию нам надо сказать серверу что нужен ключ(к синтаксису не придираться но чтото подобное)
CREATE INDEX idx ON MULTI (Док.ОргИДпок, ТовС.ТовИД)
что нам это дает
----достоинства
1.скорость вырастает в разы
2.нет недостатка 1
3.нет недостатка 2
4.нет недостатка 3
5.нет недостатка 4
6.нет недостатка 5
7.Появляется некая возможность для конкретного клиента создавать индексную связку не взирая на структуру базы разработчика. Индекс под ситуацию.
----недостатки
пака даже в голову не приходит

увеличение базы из за индекса недостатком считать нельзя в этом случае т.к. это необходимость
и эта необходимость гораздо меньше чем п.1+п.2+п.6 т.к. у нас останется только п.6

если скажете сервер же будет лопатить на один UPDATE обновляя индекс, а ведь мы это вручную делали в п.2, 4, 5
да к тому же мы это делали как бы сбоку. Сервер же может делать это на уровне ядра,
а там другие методы и возможности и я думаю там было бы по шустрей однако.

Dimitry SibiryakovЕвгений БолтикВсе вы сталкивались с тем что при перечеслении нескольких таблиц в
FROM могут начаться тормоза.
Нет. С этим сталкивались только те, кто ниасилил вкурить
http://ibase.ru/devinfo/dataaccesspaths.htm


А можно поподробней что именно вкурить ;) Статья огромна про что намек.

У меня с моими методами все летает. А делая избыточность ради скорости и зная, что серверу для этого надо, а ему надо немного ИНДЕКС для скорости. Я и решил предложить внести бы такую штуку для облегчения жизни всем. Особенно п.7 который может появиться после добавления этой реализации меня порадовал. Я пока не писал это предложения у меня и мысли в этом направлении не было.

Dimitry SibiryakovЕвгений БолтикА можно поподробней что именно вкурить ;) Статья огромна про что
намек.
На самом деле она вообще-то слишком мала. Её бы ещё раза в полтора развернуть... Вкуривать
надо целиком. От первой до последней строчки.


Судя по прочтенному "Содержание" я это давно вкурил ;)
Я иногда когда вижу дату создания своих файлов с SQL содержимым конца 90-х годов хочу сказать да не было такого. Но факты упрямая вещ.

И еще тебя не устраивает мое предложение по нововведению?

ТаблоидЧто даст это самый "CREATE INDEX idx ON MULTI (Док.ОргИДпок, ТовС.ТовИД)" ?
Конкретный скрипт по таблицам и их заполнению можно увидеть ?

Сразу оговорюсь я может что то упустил в синтаксисе. Пытаюсь рассказать мысль.
Нужно еще и связи указывать как FK.
CREATE INDEX idx ON MULTI (Док.ОргИДпок=Орг.ОргИд, ТовС.ТовИД=Тов.ТовИД)
Это даст серверу четкие данные что от чего зависит и
что в запросах/скриптах похоже для поиска подходящего индекса

1.Не надо будет создавать/добавлять избыточные поля ОргИДпрод, ОргИДпок
в таблице ТовС и отслеживать их изменение в случае изменения в таблице Док.
1.1.В первом случае без избыточности план был бы такой
Тов.ТовИмя, Орг.ОргИмя, Док.ОргИДпок, ТовС.ТовИД, (тут вроди еще чтото аж крышу срывает)
или по другому т.к. будет учтена селективность
1.2.Во втором случае т.к. есть поля избыточны план будет таким
Тов.ТовИмя, Орг.ОргИмя, ТовС.ТовИД, ТовС.ОргИДпок
план четкий согласно условию
1.3.Создание мульти индекса даст нам как раз наш план из 1.2. т.к. он будет удовлетворять условию
where Тов.ТовИмя = 'пила' and Орг.ОргИмя = 'рога и копыта' and
Док.ОргИДпок = Орг.ОргИд and ТовС.ТовИД = Тов.ТовИД
1.4.Поидее изза такой реализации можно просто описать индекс так
CREATE INDEX idx ON MULTI (Тов.ТовИмя=Тов.ТовИмя, Орг.ОргИмя=Орг.ОргИмя,
Док.ОргИДпок=Орг.ОргИд, ТовС.ТовИД=Тов.ТовИД)
такой индекс в плане станет 100%-ым хотя такое построение это перебор(бред), но имеет место быть
также он нужен не для сортировок, а для быстрого поиска данных

2.Попытался описать в п.1.ххх. Тяжко объяснять на пальцах можно по скайпу попробовать,
если объясняю туго.

Симонов ДенисА идея про мультииндекс - муть какая-то.

Ты пока не понял про что речь. ;) Я может не все полностью толком разложил по полкам.
Я про такие вещи не задумывался пока не столкнулся с выборками из нескольких таблиц в которых появились долее 200000 записей берем таблицы даже 200000, 200000, 2000, 20000 и наш запрос начинает виснуть в зависимости как растут первые 2 таблицы.
Если запрос прост как барабан вы не увидите необходимости в избыточности, но жизнь такова что мы подстраиваемся под мир в котором мы живем и что хочет аналитик. Результат наизнанку вывернутые данные и запросы к ним. :)

Таблоид,

вот файл базы http://www.sayan.ru/~bolt/sql/SK20130820.7z
будем говорить про T003 & T001

dimitrвоистину, не ведают они чего просят
не тебе одному в глубокие воды смотреть

Dimitry Sibiryakovфорумных постах...
Ты только не обижайся. я иногда перечитываю и думаю, что меня можно понять двояко. Либо наорал либо приласкал ;)

Симонов ДенисГениально! Вот скажи нафига здесь таблица RDB$DATABASE?

А ты когда писать и использовать сервер начал;)?
Спроси у создателя IB зачем так раньше надо было.
Другое дело многоль мы делаем чтобы переписать старое и отревизировать.
Что встречаю и до чего руки доходят то переписываю. СП поправил в Генераторе баз данных.

Симонов ДенисАга и ещё вот это left join D044 on 0 = 0, чтобы тормозило побольше. Теперь понятно, откуда у вас такие запросы на всякую фигню.

Меня иногда удивляет как люди додумывают, что это и для чего :).
Там где это вызывается всегда 1 строка для D002.D002_1 и некий набор данных для нее никогда не превышающий более 10 в основном 3. А используется для ввода данных но никак уж не для длинных и долгих запросов.
Ни когда не додумывайте, что хотел автор в большинстве случаев автор хотел не то про что мы подумали.
Или попробуйте найти смысл в том что увидели.
Я к примеру всегда смотря в чужой код пытаюсь найти просто что то новое, а как это используется мало волнует.