igorolv1) Нужно показать пользователю позицию загруженной страницы данных в вертикальной полосе прокрутки. ....
Хм. Excel вполне терпимо справляется с этой задачей. В целом - я согласен с тем, что здесь есть проблема. Но ее вес.. куда меньше, это уже из серии "жемчуг мелок".

igorolv2) Скорее дизайн-соображение: пользователь хочет иметь полный контроль над своими данными.
Я не очень понимаю, что Вы называете "полный контроль".

Пользователь, по моим представлениям, предпочитает приближаться к нужной цели методом последовательных приближений. То есть взглянуть на выборку, наложить фильтр, взглянуть на получившуюся выборку, усилить фильтр, отсортировать получившуюся выборку и наконец увидеть на первой странице нужную запись - примерно так. Это, конечно, чуть утрировано, и опытные пользователи справляются быстрее, но тем не менее, запрос первой страницы - очень типичная операция. Конечно, можно прокачать данные на клиента и дальше вертеть их там. Что здорово похоже на перенос функций сервера на клиента.

igorolv3) Есть некоторое подозрение, что при загрузке очередной порции данных сервер будет хоть чуть-чуть, но притормаживать:
Согласен. При этом следует иметь в виду, что пользователи сравнительно редко листают длинные выборки - хотя бывает. И определенно, большинство людей относится к ожиданиям "часто по чуть-чуть" куда терпимее, нежели к "редко, но долго". Практически существует комфортное время отклика системы на действия пользователя - где-то 0.1-0.3 секунды - и пока программа его выдерживает, пауза только на руку.

igorolvТут все-таки придется выполнять по запросу на каждое нажатие клавиши - а тут можно не успеть за пользователем.
Кстати, не согласен. Довольно типичное решение в такой ситуации - выполнить запрос, когда пользователь сделает паузу в наборе. Согласен, наличие полного набора данных на клиенте позволяет решить ситуацию лучше, но и с паузой получается вполне комфортно.

igorolv5) Дизайн-соображение: подозреваю, что как минимум некоторые пользователи предпочтут подождать пару секунд (но не более) при открытии формы, чем ждать по 0.3 секунды (которая может растянуться) при переходе с очередной сотни записей на другую.
Чуть выше я привел числа, полученные в первом же эксперименте. 0.25 секунды против 13.4 Не знаю пользователей, которые предпочтут второй вариант первому, особенно чтобы просмотреть первую страницу.

igorolv6) Не очень представляю, как постраничная загрузка может гармонично (как негармонично - вполне представляю :)) сочетаться с гридом, в котором есть древовидная колонка (ID - PARENT_ID).
Хм. Не понимаю разницы. Для иерархии единственное, что нужно - чтобы записи шли в специфическом порядке, в остальном - обычная выборка. В Oracle я сделаю это через CONNECT BY, в MSSQL вроде бы появился CTE с рекурсией. В обоих случаях - никаких проблем со страничной загрузкой.

Если Вы имеете в виду именно деревянную функциональность, неполное раскрытие, то лично я предпочитаю решать эту задачу через независимые запросы для отдельных узлов. Так и удобнее, и появляется возможность строить неоднородное дерево.

igorolvЕсли весь код общения с сервером из приложения находится, например, в хранимках, это дает достаточно сильную гарантию того, что кто-то из программистов не будет "подпольно" писать sql-код помимо этого хранилища.
Почему, собственно?

igorolv(Встречал я в таких "хранилищах" нечто вроде "select :строковый_параметр1 from :строковый_параметр2. хотя, такой "паттерн" вполне можно и в хранимку обернуть).
Есть такое. Неоднократно видел хранимки типа EXECUTE_SQL (Statement varchar). В MSSQL, если не ошибаюсь, даже есть такая стандартная, кажется sp_executesql.

igorolvПрограммиста довольно сложно удержать голым "регламентом" от чего-то вроде query.Text = "select A, B, C from Т".
.. причем независимо от того, выстроен ли интерфейс на хранимках или нет.

Лично я не люблю решать административно задачи, легко решающиеся технически. Прежде всего, я стараюсь держать разумных программистов, которых не нужно постоянно контролировать, достаточно объяснить, а от случайных неприятностей страховать на уровне кода: например, мой компонент сессии просто не позволит выполниться коду с установленным AutoCommit. Если потребуется, завтра я могу точно так же запретить выполнять через него все, кроме хранимок.

igorolvДаже если оставить вопросы возможности редизайна в стороне - хочется ЗНАТЬ "все ли sql-операции, используемые в системе компилируются В ДАННЫЙ МОМЕНТ?",
Хм. Мне казалось, что с этим у MSSQL проблема, разве нет? Хотя и в оракловом механизме есть не только плюсы, но и неудобства.

А вот насчет "хочется знать"... честно говоря, не хочется. Предпочитаю действовать так, чтобы не было причин сомневаться.

igorolvВсе это можно реализовать и НЕ на хранимых процедурах. Однако на хранимых процедурах все это ВПОЛНЕ МОЖНО реализовать.
Это перестает действовать как только появляется динамический SQL. А динамический SQL такая штука, что использовать его надо аккуратно и уместно, но как только он есть, тут же обнаруживаются чертовски уместные места.

no-userв этой дискуссии забыли упомянуть полезное свойство проекта на ХП - легкость создания Web приложений.
В принципе да. Хотя если не ошибаюсь, это верно только для "совсем невесомых" клиентов.

no-userЕсли ХП реализуют бизнес логику (а не insert - uptade),
То это чаще всего правильно в любом случае.

no-userЕсли толстый клиент активно использует для бизнес функций собственный SQL код, контролировать разработку двух клиентов (толстый+тонкий) непросто.
Скорее не соглашусь. Если разрабатываются два клиента, более чем естественно активно использовать в них общий код; собственно по-хорошему это должен быть скорее один клиент с двумя faces. При этом "собственный SQL код" никаких проблем не доставляет. Ситуация же "две нескоординированных команды разрабатывают два разных клиента к одному приложению" не представляется мне сколько-нибудь правильной.

no-userА где и как хранится этот код
Хм. Так же, как и во всех остальных случаях.

no-userи как две группы разработчиков его используют?
Как любую библиотеку или общий модуль.

no-userВозьмем, к примеру, две группы Дельфи и PHP кодеров.
Зачем мне нужны две эти группы в одном проекте? Специально, чтобы создать себе геморрой? Есть куда более простые способы сделать приложение с двумя мордами.

no-userЧто они делают с этим кодом, copy/paste в два разных приложения?
Нет, используют. Даже в такой извратной постановке задачу скорее всего можно решить (я не знаю возможности PHP и не возьмусь уверенно утверждать). Решение, скорее всего, будет примерно столь же извратным, как и постановка.

no-user
использование разработчиками интерфейсов только вызовов ХП решает две проблемы:
1) нельзя сделать одну бизнес операцию двумя разными способами: разработчик интерфейса может пользоваться лишь тем, что ему дали в руки
Использование общей библиотеки решает эту проблему как минимум не хуже.

no-user
2) документация: API к БД - это
- названия ХП типа orderCreate,orderSelect, ,orderItemAdd, orderItemUpdate
Не хочется усиливать беседу, ограничусь тем, что общая библиотека опять же - решает эту задачу как минимум не хуже.

no-userЕсли бизнес процедура не реализована в ХП - ее нельзя использовать (и разработчик интерфейса не может copy/paste чужой SQL код в свой PHP скрипт).
Хм. Вы другие языки знаете?

igorolvЭто если 0.1-0.3 секунды. А если программа начинает его НЕ выдерживать
Согласен.

igorolvА достаточно посмотреть на то, как предлагается реализовывать неполный фетч в MS SQL
Посмотрел. Честно говоря, меня это крайне удивило, поскольку по моим воспоминаниям, в форуме дельфи тема всплывала неоднократно, и вроде бы ответы не предусматривали таких сложностей.

Из всего названного в FAQ нормально выглядит только четвертый способ. Но судя по комментариям, он глючит :(

igorolvЯ и хотел указать, что в данном случае требуется специальный подход.
Там требуется не столько специальный подход, сколько непоследовательная навигация по дереву. Да, конечно, в этом случае страничное чтение малоосмысленно. Наверное, можно привести и другие примеры такого рода, например трассировка каких-нибудь проводок.

А чтение дерева отдельными запросами просто является лучшим решением по цена/качество. Сложность не слишком больше, а возможности возрастают очень значительно, трюков и геморроя становится куда меньше.

igorolv softwarerХм. Мне казалось, что с этим у MSSQL проблема, разве нет?
Самописное решение, прикрученное к сборкам и прогонам тестов.
Ну, самописное решение легко применить к чему угодно. Пожалуй даже к клиентскому коду легче; написать подпрограмму, которая пробежит по всем data module и сделает open каждому датасету наверное легче, чем вызвать каждую ХП с правильными параметрами (здесь мы пользуемся тем, что в датасетах, по крайней мере дельфовых, легко забить значения параметров в дизайн-тайме).

igorolvВ меня, все же, вселяет некоторое спокойствие знание, что все 200.000 строк серверного кода, при активном изменении различных таблиц, процедур и функций ВСЕГДА 1) компилируется 2) при запуске на mock-базе не ломается 3) проходит все тесты 4) соответствует принятым внутри группы sql-конвенциям.
Вы плавно переходите к тестированию и контролю качества. Тут уже ответ будет - прогоняем автоматизированные тесты, и проверяем не только компилируемость серверного кода, но и еще кучу вещей. Названная изначально проверка синтаксической корректности серверного кода оказывается далеко позади.

igorolvА динамический sql все же БЫВАЮТ ситуации когда работает неэффективнее статического.
Безусловно. Тут вопрос свободы выбора: то ли мы можем выбирать свободно, то ли скованы умениями ХП. В результате некоторые приходят к очень веселым (с моей точки) зрения вариантам вида


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

PL99Кстати, кроме, пожалуй, справочников, связанных с географическими пунктами или с оргструктурой предприятий других потребностей в организации дерева я не вижу.
Хм. В одном из проектов я имел дело с классификатором товарных позиций примерно на миллион позиций (точнее, их всего было порядка миллиона, меня интересовало намного меньше, тысяч тридцать). Для моей задачи для работы с ним хватало дерева, для миллиона вообще говоря дерева очень мало.

no-userМне что то кроме Java в голову ничего не приходит.
Во-первых, мелкософтовская линейка во главе с C#. Во-вторых, библиотеки на C подключаются к чему угодно (по крайней мере, я до сих пор не сталкивался с исключениями). К Java можно подключить любую dll, соответственно писать веб на яве, толстого клиента на чем угодно. Наконец, веб можно свалять и на дельфе; результат конечно будет не то чтобы выдающимся, но веб все равно хорошим не бывает.

no-userНеужто вы на java интерфейсы строите?
Не, это удовольствие не по мне. Хотя есть любители, и проект с такими требованиями, вполне возможно, я бы им и саутсорсил.

Guest 0310Можно конкретный пример, как это сделать постраничный вывод без больших затрат на Oracle? В самом общем виде.
Открыть курсор. Взять из него 50 записей. Когда потребуется, взять следующие 50 записей. Далее по индукции. Затрат совершенно никаких.

PL99Качество результата - вещь весьма спорная, и не раз обсуждалась на этом форуме.
Я не предлагаю его обсуждать. Я просто констатирую, что выбор подхода зависит от требуемого качества - в том числе от того, что понимается под качеством в конкретном случае.

PL99Мы опять вернулись к понятию "качество".
Да, но уже чуть в другом аспекте - том, где я (как технолог) являюсь пользователем и ставлю задачу.

Как факт, я сталкиваюсь с пожеланиями пользователей, реализация которых в концепции "все на ХП" приводит к ряду проблем, в том числе упомянутых в этом обсуждении. Как факт, я иногда стимулирую пользователей к таким пожеланиям, поскольку знаю, что они оценят предоставляемые удобства, и это даст существенную экономию в других вопросах (довольный пользователь - человек, с которым приятно и выгодно иметь дело. Поэтому имеет смысл уметь радовать его дешево). Поэтому лично для меня технология "все на ХП" как унифицированный подход, как заведомый выбор для любого проекта, неприемлима.

Я не очень понимаю о чем Вы. У меня использовалось дерево потому (и именно потому), что это было требованием пользователей к моему проекту. Классификатор в целом был фасетным, отнюдь не древовидным.

О качестве же универсальных решений я отзывался "всему свое место" - согласен, что это "не слишком восторженно". Насчет преимуществ и недостатков иерархического классификатора в бизнес-процессе не могу судить, мало сталкивался да и неинтересно особо.

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