А зачем дважды мучать SELECT проверки ? Предлагаю подредактировать пример:


Если требуется и в результате присутствия ошибок заносить верные данные в другую таблицу, то с скрипта нужно просто убрать IF.

Насчет проверок - в принципе смотря что и зачем проверяется. Если просто проверяются значения полей, то тут самое удобное воспользоваться от case в селектах для примитивных условий до проверяющих функций. Кстати в данном случае приведения примера лично я считаю особого выигрыша запроса у курсорного варианта не будет - в обоих случаях сервер проведет table scan - причем для варианта с запросом скорее всего table scan будет проведен дважды по таблице из за использования функции Len(), а в случае полного перебора таблицы курсором получится всего один раз. Так что тут как ни странно в данном случае наоборот - курсор будет быстрее.

Ну тут как всегда все относительно :) Например если предположить, что на таблицы tab3 и tab2 существуют триггеры на добавление, то вариант с запросом однозначно будет быстрее, так как эти триггеры при запросе будут вызваны по одному разу для каждой таблицы и можно будет спокойно обработать весь набор вставленных записей с Inserted одним запросом. В случае же курсора получится, что триггера будут вызываться столько раз, сколько записей в обрабатываемой таблице, что в случае какой то сложной обработки в триггерах приведет к существенному замедлению. Плюс стоит учитывать особенности каждой СУБД - например я сейчас работаю в Sybase ASA, где можно создавать индексы на системные функции, т.е. там спокойно можно создать индекс на Len(Field1) и соотвествующе избавиться от TABLE SCAN, перейдя на INDEX SCAN. Плюс как ни странно, но за свою практику проектирования БД я сто процентно убедился, что частенько приходится логику и структуру БД подгонять под конкретные требования клиентских приложений, причем под Access это одно, под Delphi - другое. Единственный инструмент, который на моей памяти может работать с "чистой" структурой БД, без логики, специально ориентированной на него - это Power Builder, но к сожалению у нас он распостранен только в крупных конторах, предпочитающих западное ПО.

Так что мое личное мнение, что тут дело не сколько в курсорах, запросах и т.д., а в правильном понимании поставленной задачи архитектором БД, ее правильным решением с учетом самого ТЗ и использования сред разработки клиентских приложений. Например в приведенном в данном топике примере сразу возникает закономерный вопрос - зачем таблицу с данными разбивать на 2 таблицы, с правильными и ошибочными данными ? Не легче ли сделать просто таблицу с ключевым полем ID записи и в нее занести коды верных или ошибочных данных. Причем опять же, что лучше, стоит решать исходя из постановки задачи, чего меньше бывает в исходной таблице - верных или ошибочных записей. Если меньше ошибочных, то значит таблицу делаем для них:

В итоге мы всегда можем быстро получить верные данные:

и ошибочные записи:

В итоге мы имеем всего один table scan по таблице Tab1, не занимаем лишнего места в БД двумя дублирующими записями таблицами вместе с основной , соотвествующе не делали лишних накладных расходов по физической записи на диск данных этих таблиц, ну и всегда сможем быстро получить правильные и ошибочные записи, так как оптимизатор MSSQL будет использовать алгоритм сканирования первичного ключа таблицы Errors, а если там не так много записей, то фактически и вообще первым же запросом загоним ее в кэш MSSQL и уже в дальнейшей серии нужных нам запросов будем работать с ее копией в памяти.

Так что дело только в проектировании, знание релляционных основ, умение думать на SQL и мыслить абстрактно применительно к множествам.

P.S. Я в этом плане за название не "Курсорная болезнь", а "Алгоритмическая болезнь", которой очень часто подверженны программисты, привыкшие алгоритмически обрабатывать множества данных путем разбиения процесса обработки данных на серию мелких пошаговых алгоритмов. Особенно этой болезни насколько я знаю подверженны многие программисты, привыкшие пошагово работать с наборами данных: дельфийцы, фокспрошники, парадоксники и т.д. В этом плане программистам Access должно быть легче, так как изначально Jet-движок Access был настоящим SQL-движком и им более привычны понятия манипулирования данными с помощью запросов.

incold
Большое спасибо :)

Я тут как бы оказался случаным гостем, по приглашению Varan , но в принципе темы проектирования БД для всех СУБД одинаковы, а вопрос оказался для меня интересным :) Мне кажется надо почаще такие вопросы выносить в форум "Проектирование БД", а то получается, что мы с вами живем на просторах одного сайта и почти никогда не пересекаемся, каждый обитая только в пределах своего рабочего форума. Я лично например очень частый гость и наблюдатель форума mssql, не смотря на то, что уже давно работаю не на нем, а Sybase ASA, и не только потому, что у этих СУБД много похожего, а именно из за обсуждаемых там вопросов и оригинальных решений, которые легко потом переводятся в плоскость собственной платформы разработки. Как говориться, своя каша конечно хорошо, но и не грех посмотреть, как коллеги других форумов кашу готовят :)