Архив форумов ЦИТФорума

[KAMBI]

Как пройти таблицу SQL c первой записи до последней (построить цикл) ?

[and3008]

-

[U-gene]

Там цикл (в том или ином виде) является оптимальным решением. Можно даже сказать, что без цикла (в том или ином виде) там никак не обойтись. Средствами SQL это решается с использованием курсоров.

[and3008]

-

[Valera]

-

[U-gene]

Что-то с трудом верится. ИМХО цикл в том или ином виде обязательно вылезет.

А можно привести пример для таблицы хотя бы с 2-3мя строками? Чтоб оно сделало так

исходная таблица (ID, факт)
1 1
2 3
3 5


результат (ID, нарастающий итог)
1 1
2 4
3 9

,а потом объяснить, как этот запрос с GROUP и с поздазапросом (НЕ МЕНЯЯ ЕГО!) можно применить к таблице с произвольным и заранее неизвестным числом строк?

[Борис]

SELECT ид0 AS ид, SUM(факт1) AS итог
FROM
(SELECT табл0.ид AS ид0, табл0.факт AS факт0, табл1.ид AS ид1, табл1.факт AS факт1
FROM таблица AS табл0, таблица AS табл1
WHERE табл0.ид <= табл1.ид)
GROUP BY ид0;

[Борис]

-

[U-gene]

[Борис]

Вообще-то эта проблема шире, чем сканирование SQL-таблицы и, тем более, вопроса нарастающих итогов. Проблема в том, что SQL полагается способным решить все вопросы, связанные с таблицами. И по синтаксису действительно трудно найти задачу, для которой не подберется запрос, решаюший его. Но решение многих, если не большинства, заключается не в автоматическом отыскании (эффективного) алгоритма (а это объявляется целью языка SQL), а в большей скорострельности сервера базы данных по сравнению с клиентским компьютером. Здесь я не согласен с and3008 13-05-2003 23:14. Пересматривать нужно не ожидания от SQL, а сам SQL. Вот пример плохого использования SQL:

пусть есть таблицы таблИнфо(идСправ0, идСправ1), таблСправ0(ид, имя), таблСправ1(ид, имя). Как SQL рекомендует расшифровать кода в таблИнфо? Вот как:

SELECT таблСправ0.имя AS имя0, таблСправ1.имя AS имя1
FROM таблИнфо, таблСправ0, таблСправ1
WHERE таблИнфо.идСправ0=таблСправ0.ид AND таблИнфо.идСправ1=таблСправ1.ид

(или вариант с JOIN). И это действительно выполняется крайне быстро (особенно при наличии индексов по полям "ид"). Но где это выполняется? Это выполняется на сервере! А затем (огромная!) таблица (имя0, имя1) передается по медленным каналам связи. А клиенту это нужно не на сервере, а на своем компьютере. И получается, что по времени отклика было быстрее перекачать справочники и информационную таблицу, и на месте у клиента собрать требуемую таблицу! Конечно, можно сказать, что можно сделать так:

SELECT таблСправ0.ид, таблСправ0.имя
FROM таблСправ0
WHERE таблСправ0.ид IN (SELECT DISTINCT таблИнфо.идСправ0); с сохранением в локальной таблице

затем

SELECT таблСправ1.ид, таблСправ1.имя
FROM таблСправ1
WHERE таблСправ1.ид IN (SELECT DISTINCT таблИнфо.идСправ1); с сохранением в локальной таблице

затем

SELECT * FROM таблИнфо; с сохранением в локальной таблице

А уж затем задать локально

SELECT таблСправ0.имя AS имя0, таблСправ1.имя AS имя1
FROM таблИнфо, таблСправ0, таблСправ1
WHERE таблИнфо.идСправ0=таблСправ0.ид AND таблИнфо.идСправ1=таблСправ1.ид


Но при таком варианте где *автоматическая* оптимизация? Есть и другие нестыковки, но не буду перечислять все, так как это достаточно крупная тема.

[and3008]

Согласен, что нельзя тупо доверять оптимизатору запросов. Согласен, что много зависит от задачи.
Но я не согласен, что надо писать такие запросы, результат которых огромный и тянется на клиента. В 90% случаев это не нужно. Никто не будет просматривать более 100 записей. Исключения, естественно, составляют отчеты.

Лично я против переноса бизнес-логики на клиента. Это чревато ошибками и нестабильностью. По возможности максимальная часть логики должна выполняться на сервере.

[Борис]

Возражения против переноса бизнес-логики на клиента основаны на предположении о том, что все (не просто все, а абсолютно все) операции может сделать сервер. Такое предположение верно вообще, но не в частных случаях его реализации. А эти частные случаи составляют абсолютно все реализации и состоят в том, что вся требуемая работа в целом делится на типы (работа с БД, управление подключенной аппаратурой, формирование аналитических графиков и т. д.), и на каждый тип создается *отдельный* сервер, которые, кстати, часто разносятся (по разным причинам) на разные, порой далеко отстоящие друг от друга, машины. Поэтому вопрос коммуникаций крайне важен для эффективной работы в целом, а он просто "не замечается" при реализации сервера БД. Полагается, что это в принципе другая задача, не имеющая отношения к собственно вопросам управления данными. Но это не так. Сами по себе данные не нужны, если их нельзя эффективно использовать, а использование их как раз и является задачей их предоставления *другим* программам. Такой "другой" программой может быть в частности просто программа просмотра данных начальником, в которой действительно просмотр более ста записей не работа, а мучение. Но такой программой может быть и генератор фильма, и генератор чертежа, да что угодно. И для них нужны будут огромные таблицы (команд, данных, объектов и т. д.). Мы, кстати, постоянно видим результат такого неучета требований быстрого отклика системы в целом. Это то, что каждая программа, использующая мало-мальски сложные данные, имеет свою базу данных, хотя очевидно, что оптимальным решением было бы задачу хранения этих данных отдать серверу БД, а самой программе решать исключительно вопросы алгоритмов обработки. Но сегодняшние решения требуют или размещать все на одном компьютере, или делать собственную БД для прикладной программы.

PS. Эта тема вышла за рамки исходного вопроса, поэтому предлагаю завершить ее обсуждение, либо вынести как новую тему.