Одно из ключевых преимуществ ADO как превосходного интерфейса для баз данных заключается в его гибкости. Однако при написании приложений гибкость ADO предоставляет пользователю больше возможностей «случайно прострелить себе ногу». Нужно помнить о том, что некоторые вещи делать не следует . Несколько примеров применения ADO приведены в сети по адресу НЛ
http://www.microsoft.com/data/techmat/htm.Грех 7. Игнорирование собственного поставщика OLE DB.
Можно использовать ADO как с собственным поставщиком OLE DB для SQL Server, так и с поставщиком OLE DB для ODBC. Однако, когда есть возможность выбора, слишком велик соблазн продолжить пользоваться старыми версиями DSN (Data Source Names) и соответствующими драйверами. Собственный поставщик OLE DB для SQL Server намного эффективнее старых версий и, кроме того, обеспечивает доступ к таким новым услугам и средствам, как SQL Server IRowsetFast и набор строк LinkedServer.
Грех 6. Применение наборов записей вместо хранимых процедур.
Хотя ADO позволяет легко обрабатывать запросы и выполнять обновления с помощью объектов Recordset, все же хранимые процедуры ADO обеспечивают существенный выигрыш в производительности, поскольку для них составляется план исполнения с привлечением кэша. Помимо этого, хранимые процедуры снижают интенсивность трафика в сети за счет организации обработки пакета операторов SQL в течение одного вызова.
Грех 5. Перекладывание на ADO обязанностей по выявлению параметров хранимых процедур.
ADO в состоянии динамически обнаружить параметры хранимой процедуры, используя метод Refresh коллекции параметров. При наличии такой возможности казалось бы можно не задавать в коде явным образом объект Parameter. Это допустимо на этапе разработки, но при промышленной эксплуатации кода следствием подобной небрежности станут многочисленные ненужные обращения к серверу.
Грех 4. Использование объектов Recordset для всех обновлений.
Безусловно, применять объекты Recordset для обновления базы данных легко и приятно. Но этот метод связан с открытием курсора, а это приведет к дополнительным затратам ресурсов. Обновление баз данных с использованием непосредственно операторов SQL (а еще лучше, с применением хранимых процедур), конечно же, более эффективно, особенно при множественных операциях вставки, обновления и удаления.
Грех 3. Применение независимых соединений для объектов Command и Recordset.
Еще одним свойством ADO, излишнее увлечение которым может быть не во благо, является способность объектов Recordset и Command создавать собственные объекты соединения. Как правило, в типовых сетевых приложениях повторное многократное открытие и закрытие соединений значительно менее эффективно, чем использование одного существующего объекта Connection. В списке исключений из этого правила на первом месте стоит разработка приложений для Web, когда желательно изолировать соединения для каждой Web-страницы.
Грех 2. Использование ресурсоемких курсоров, когда в этом нет необходимости.
ADO поддерживает четыре типа курсоров: «только вперед», статический, ключевой и динамический. Конечно, курсор типа «только вперед», называемый также шлангом, наиболее эффективен и связан с наименьшими накладным расходами. Зачастую возникает искушение воспользоваться более удобными, но и более ресурсоемкими курсорами, такими как ключевой или динамический. Однако, если стоит задача обеспечить лишь базовые возможности просмотра, следует подумать – а стоит ли прибегать к таким мощным средствам?
Грех 1. Использование заданного по умолчанию размера кэша для объекта ADO Recordset.
Свойство CacheSize объекта Recordset задает число строк, которое SQL Server ищет при запуске из ADO процедуры sp_cursorfetch, обращающейся к курсору на стороне сервера. Если использовать заданное по умолчанию значение 1, то это может снизить эффективность работы, поскольку вызовет слишком много обращений к серверу.