CREATE TABLE Box(
Id integer,
IdParent integer,
Remark VARCHAR(20)
);
ALTER TABLE Box
ADD PRIMARY KEY (ID);
ALTER TABLE Box
ADD FOREIGN KEY (IdParent)
REFERENCES Box
;
Те IdParent ссылается на вышестоящий ящик. Обычная иерархичная структура, загнанная в реляционную табличку.
Нужно выбрать рекурсивно, то есть получить некий бокс и все подбоксы, входящие в него на любую глубину ...
На том же IB это делается елементарно с помощью хранимой процедуры.
Можно ли получить эту рекурсивную выборку с таблицы аксеса с помощью ОДНОЙ sql комманды (или чего-то подобного, которое с клиенской программы можно дернуть с помощью ОДНОГО запроса)?
Сорри за немного странное желание. Вариант решения типа "пошли ты этот аксесс и возьми нормальную платформу", к сожалению не проходт....
Здравствуйте, IhorO, Вы писали:
IO>На том же IB это делается елементарно с помощью хранимой процедуры.
Ну так запросов то все равно несколько.
IO>Можно ли получить эту рекурсивную выборку с таблицы аксеса с помощью ОДНОЙ sql комманды
Ты бы обьяснил зачем, действительно очень странное желание.
IO>(или чего-то подобного, которое с клиенской программы можно дернуть с помощью ОДНОГО запроса)?
Можно, если добавить сервер приложений. Но ради чего такое городить?
Здравствуйте, IhorO, Вы писали:
IO>Нужен сабж, но с помощью одной sql комманды...
после долгих раздумий я пришёл к выводу, что такое не реализуемо через SQL, надо или рекурсивные запросы в приложении выполнять. либо менять структуру, либо переходить с аксесса на что-то другое
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, IhorO, Вы писали:
IO>>На том же IB это делается елементарно с помощью хранимой процедуры.
AVK>Ну так запросов то все равно несколько.
IO>>Можно ли получить эту рекурсивную выборку с таблицы аксеса с помощью ОДНОЙ sql комманды
AVK>Ты бы обьяснил зачем, действительно очень странное желание.
IO>>(или чего-то подобного, которое с клиенской программы можно дернуть с помощью ОДНОГО запроса)?
AVK>Можно, если добавить сервер приложений. Но ради чего такое городить?
Попытаюсь. Речь все же идет о среднем звене (это по поводу сервера приложений). Согласно ТЗ должна поддерживатся работа с несколькими движками, в тч с аксесс (остальные нормальные, серверные). Было принято решение попытаться сделать общий код, ну а отличия в SQL под конкретную платформу планируется решать с помощью наборов SQL шаблонов, которые уже разрабатываются под конкретную платформу. Результат обработки шаблона — одна или несколько SQL комманд,
передаваемых на сервер. То есть основная идея сводится к тому, что для поддержки новой платформы придется доработать только шаблоны, кода уже не трогать.
Сама структура базы даных довольно простая, поэтому идея многоплатформенности в части движков DB не есть уж очень бредовой. Но вот получилась загвоздка з рекурсивным обходом иерархической структуры (типа структуры директорий) в реалиционном предствалении (структура таблицы — см. мой перврначальный постинг) для тех движков, которые не поддерживают хранимых процедур.
Здравствуйте, IhorO, Вы писали:
IO>передаваемых на сервер. То есть основная идея сводится к тому, что для поддержки новой платформы придется доработать только шаблоны, кода уже не трогать.
Позравляю. В таких случаях обычно делают не текстовые шаблоны, а драйвера, с кодом. Так ошибочка у вас в дизайне.
IO> Сама структура базы даных довольно простая, поэтому идея многоплатформенности в части движков DB не есть уж очень бредовой. Но вот получилась загвоздка з рекурсивным обходом иерархической структуры (типа структуры директорий) в реалиционном предствалении (структура таблицы — см. мой перврначальный постинг) для тех движков, которые не поддерживают хранимых процедур.
В общем по хорошему надо переделывать дизайн, иначе вы опять на что нибудь напоретесь, на тот же MySQL к примеру. Ну а если очень хочется — напишите прокси (уж не знаю я чем вы там пользуетесь для доступа, наверное ADO), который будет ретранслировать запросы.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, IhorO, Вы писали:
IO>>передаваемых на сервер. То есть основная идея сводится к тому, что для поддержки новой платформы придется доработать только шаблоны, кода уже не трогать.
AVK>Позравляю. В таких случаях обычно делают не текстовые шаблоны, а драйвера, с кодом. Так ошибочка у вас в дизайне.
Ну как сказать. Лично я был сторонник такого подхода. Но рук. проекта решил идти другим путем. Если уж очень сильно говорить детали, то текстовые шаблоны — это слегка упрощенно. Там XSL трансформация и пт. Потому что с клиентов запросы идут по некоему текстовому протоколу... Скажем так, чего то тохоже на какой-то симбиоз IMAP и LDAP (это также не обсаждаемо, ибо это уже требования заказчика). Шеф решил, что сделать несколько трансформаторов из хорошо формализированного текста в набор секвел запросов по времени займет меньше времени, чем традиционная разработка специализованой прослойки для каждого движка (как я понимаю, эту вещь Вы зовете драйвером) .....
Здравствуйте, IhorO, Вы писали:
IO>Ну как сказать. Лично я был сторонник такого подхода. Но рук. проекта решил идти другим путем.
Ну что же — в следующий раз будет умнее.
IO> Если уж очень сильно говорить детали, то текстовые шаблоны — это слегка упрощенно. Там XSL трансформация и пт.
XSL трансформинг SQL выражений? Ну вы блин извращенцы.
IO> Шеф решил, что сделать несколько трансформаторов из хорошо формализированного текста в набор секвел запросов по времени займет меньше времени, чем традиционная разработка специализованой прослойки для каждого движка (как я понимаю, эту вещь Вы зовете драйвером) .....
Маньяк.
IO>Что по этому поводу можете сказать?
Могу предложить внести в шаблоны некие старт-стопные теги, что то вроде
<query>
query 1
</query>
<query>
query 2
</query>
которые позволят в шаблоне задавать несколько запросов и правила взаимодействия онных.
Здравствуйте, IhorO, Вы писали:
IO>Спасибо за диалог. Доложу шефу мнение независимого експерта
Вспомнил может быть похожую на вашу задачку. Она очень красиво легла в модель, где как бы эмулируется управляемая потоком данных машина.
Т.е. входные данные загонялись через фильтр, валидатор и парсер на некий конвеер, к которому последовательно были нацеплены соединенные ввиде графа обработчики (в нашем случае каждый обработчик жил в отдельном потоке, но данных у нас было много). Между обработчиками были управляемые буфера.
Удавалось делать в рамках этой схемы очень хитрые обработки.
Граф обработчиков редактировался визуально, более того, можно было за ним понаблюдать в процессе работы, как в пошаговом режиме так и на лету. Тут же можно было поменять параметры обработчкивов, перецепить связь и т.д. Здорово были заметны дырки в структуре, когда где то происходил затор. Видно сразу что надо оптимизировать. Впрочем у вас наверное скорость обработки некритична.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, IhorO, Вы писали:
IO>>Спасибо за диалог. Доложу шефу мнение независимого експерта
AVK>Вспомнил может быть похожую на вашу задачку. Она очень красиво легла в модель, где как бы эмулируется управляемая потоком данных машина.
О вот это уже красивая идея. Также заслуживает на внимание и мысль о прокси, но там несколько модифицировать нужно — часть запросов шлем прямо на сервер, часть особо хитро закрученых (случай с рекурсией) — на хардкодинговое отвлетвление (это я еще в линии, предложенной шефом, кручусь)....
на что-то другое
