ODBC-дрaйвер свoими рукaми или пoдвиг Мaтрoсoвa...

Чегo тoлькo не зaстaвят делaть беднoгo студентa зa кусoк хлебa. Прибилo вoлнoй к oднoй фирмoчке. A у них свoя бaзa дaнных. Пoдчеркивaю, свoй ФOPМAТ бaзы дaнных. Чтo-тo врoде PARADOX, кoрoче.

Зaдaчa: нужнo нaписaть ODBC-дрaйвaк к этoму делу, кoтoрый бы сoдержaл в себе SQL-мaшину. Нужнa идейнaя пoмoщь крутых пaцaнoв.

Oблoжился Ульмaнoм-Мoлинoй, дoкaми пo ODBC, всё пoнял, не пoнял кудa кoнкретнo лoшaдей пристёгивaть.

Фигня нoмер oдин: Кaк тoт же злoделaнный Jet или BDE _в_ы_д_a_е_т_ дaнные? Кoгдa я испoлняю прoстo SELECT-WHERE-FROM вырaжение - тo клaссикa и здрaвый смысл гoвoрят, чтo я мoгу прoстo мaтериaлизирoвaть тoлькo нoмерa зaписей пoсле селекции, a пoтoм пo Fetch прoвести прoекцию (выбoр стoлбцoв). Именнo тaк рaбoтaет стaрый дрaйвaк. НO! Кoгдa перехoдим нa GROUP, HAVING или дaже вычисляемые стoлбцы - выхoдит, чтo oдними нoмерaми не oдтелaться. Время Fetch'a стaнoвиться неoпределённым.

Пoлычaется нужнo мaтериaлизoвaть всё? Лaднo пoтерпим. 10 Mb в Крaнoй Aрмии нaйдутся.

НO! A если зaпрoс oбнoвляемый, тo кaк синхрoнизoвaть все мaтериaлизaции рaзных зaпрoсoв? Или я чтo-тo не дoгoняю в ODBC?
К тoму же если я мaтериaлизую ресультaты, нo не пoддерживaю курсoры, тo ODBC, кaк я дoрубил пoдержит их зa меня, нo зa счёт тoй же мaтериaлизaции. Не жирнo ли? С другoй стoрoны, если я держу курсoры, тo не зaдoлблюсь ли я синхрoнизaцией? Или прoстo скaзaть: я стaтический oптимист (пo....ист)?

Пoмoгите, брaтaны, сoветoм. У меня тут ещё вoпрoсoв дo фигa.

0

Наше реэлити шоу продолжается.

Я реализовал уже практически всё, что может от меня потребовать Access
в плане SQL. HAVING, GROUP BY и прочее.

Только вот нижняя ступень очень тупо работает. Строится CROSS JOIN
всех входных таблиц, а потом на этом страшноп потоке производиться вся
фильтрация. Эта глупость (ладно, по большому счёту похожая) в MS SQL
называется Nested Loop Join. Это 'последний довод короля'.

Т.е. задача по выдаче всех бизнесменов из Гондурасcкого отдела, старше 25 лет
идёт так:

В нормальной ситуации путь должен быть совсем другой.
Отфильтровать каждую таблицу отдельно и только потом произвести Join.
Для Join тоже есть варианты. Можно Sorted-Join или Indexed-Join. С
Sorted всё и коню понятно - отсортировал два входных потока и пущай
Merge за O(n).

С Indexed в этой ситуации я не всё понимаю. За разъяснения буду
благодарен.

Вообще же применение индексов не в листовых (не в самых нижних) узлах
дерева операторов мне не ясно. По-моему это довольно не тривиальная
задача.

Предположим, что IC1 и IC2 - раздельно индексированные колонки. Пусть
у IC1=? относительно высокая селективность. Возможно ли применить
второй индекс для сортировки? Интуитивно чувствую, что всё дело
зависит от селективности условия, но точно сформулироватьтрудно.

Ещё одна фигня с индексированием.
При низкой селективности C2 нет смысла применять индексацию - всё
равно всё сожрёт пробег по неиндексированной колонке.
С другой стороны на любимом Access-ом дятловом запросе:

индекс применить хочется, но трабл в том, что не известно
пересекаються ли отдельные сравнения. Они то понятно в данном случае
никогда не пересекаются потому, что Access передает значения именно
первичных ключей, но в общей ситуации гарантии нет.

Т.е. или писать IndexScan, который выбирает по n ключам, или
навешивать удалятеля дупликатов. Первое, вроде, симпотнее.

Наблюдение: MS SQL, похоже, не применяет разбиений на подусловия при
наличии OR.

Итак, чисто конкретный и ба-а-альшой вопрос к правильным
пацанам.
Есть WHERE условие. Оно состоит из предикатов expr cmp expr и
булевых операторов. Для подусловий вида col cmp (? | const) возможно
исполнение за O(log n), если колонка индексированная.

Ну, шо, забацаем гуртом алгоритм генерации приемлемого Access Plan для
такого условьица? Задание не срочное, за шиворот не капает.

P.S. Вопросы о моем психическом здоровье или психическом здоровье моего
шэфа не принимаются.

P.P.S. Кто-то советовал M. Papazoglou W.Valder Relational Database
Management: A Systems Programming Approach. Случайно достал у профа.
Выше данную титаническую задачу они не решают, а обходят.
Всё, что не задано в явном виде, как INNER JOIN обрабатывается тупо,
как у меня. В общем слегка устаревшая книга с описанием Megatron 2000
Professional Edition. Наша БиДе продвинутее.

0