Доступ как интерфейс к SQL Server - ADO против DAO?

У меня есть проект, в котором Access 2003 будет использоваться в качестве интерфейса, а данные будут храниться в SQL Server. Access будет подключаться к SQL Server через связанные таблицы со всей логикой базы данных (хранимые процедуры, представления) в SQL Server.

При такой настройке было бы лучше использовать ADO или DAO в Access? Это просто вопрос предпочтений или еще один вариант подходит для Access в качестве интерфейса и SQL Server в качестве хранилища данных? Особенно при использовании связанных таблиц. Спасибо.


sql-server ms-access dao ado
person webworm    schedule 11.06.2010    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Напишите сквозные запросы в отличие от подхода с использованием связанных таблиц. Производительность будет значительно улучшена. Пишете приложение Access?

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

Изменить: Общий консенсус - это ADO для подключения к sql server / другим источникам и DAO для источников только mdb.

person buckbova    schedule 11.06.2010
comment
Сквозные запросы могут использоваться со связанными таблицами, они не исключают друг друга. - person webworm; 12.06.2010
comment
@webworm, проблема в производительности, а не в совместимости. Лучше делать запросы на максимально ограниченный объем данных, а не на всю таблицу. - person JeffO; 12.06.2010
comment
Связанные таблицы и сквозные запросы не исключают друг друга. Используйте связанные таблицы, где это возможно, и другие методы, когда этого требует перфорация. Тогда вы получите лучшее из обоих миров. Также с SQL Server локальные таблицы обычно не требуются. - person Tony Toews; 12.06.2010
comment
Ваша оценка консенсуса НЕПРАВИЛЬНА. В связанных таблицах ODBC вы используете ADO только для тех вещей, которые вы не можете сделать иначе или которые неэффективны. Это означает лишь случайное использование ADO (в основном для получения редактируемых наборов записей для вещей, которые иначе не выполняются, например, sprocs, возвращающие набор записей, и т. Д.). - person David-W-Fenton; 12.06.2010
comment
Джефф, ваше беспокойство по поводу всей таблицы довольно интересно. Вы один из тех, кто считает, что Access отключает всю таблицу каждый раз, когда вы открываете набор записей или форму? - person Tony Toews; 13.06.2010
comment
Чтобы понять, о чем говорит Тони, Access / Jet / ACE никогда не потянет ни весь MDB, ни всю таблицу , если вы не работали очень, очень усердно, чтобы сделать все совершенно неверно (например, нет индексации, выбор по выражению). - person David-W-Fenton; 14.06.2010
comment
@ Тони Тэйвс - Я уверен, что есть предел. Есть шанс уточнить? - person JeffO; 02.03.2011
comment
Джефф, о каком пределе ты говоришь? - person Tony Toews; 04.03.2011

arrow_upward
2
arrow_downward

Используйте MDB со связанными таблицами ODBC. Поскольку вы используете ODBC, вы подключаетесь через Jet, поэтому очевидно, что DAO является выбором по умолчанию для доступа к данным.

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

Короче говоря, вы создаете свое приложение SQL Server так же, как и приложение с чистым доступом (при условии, что вы создаете приложение с серверной частью Jet / ACE для эффективного извлечения данных, что должно быть несложно), и прибегаете только к серверу. -side или ADO, когда подход Access по умолчанию неэффективен или не дает желаемого результата (например, редактируемый набор записей в случае sprocs, возвращающих набор записей).

person David-W-Fenton    schedule 12.06.2010
comment
-1 Интерфейс Access для SQL Server не является файлом MDB (это файл ADP) - person Andomar; 12.06.2010
comment
Что? Пожалуйста, отмените голос против, так как вы ошибаетесь. MDB в качестве интерфейса к SQL Server через ODBC - это рекомендуемая конфигурация MS. MS уже почти пять лет отказывается от ADP с SQL Server в пользу MDB. Исходный вопрос касается DAO, и это сразу показывает, что ADP не рассматривается в первую очередь, поскольку DAO не работает в ADP, поскольку в нем нет Jet. - person David-W-Fenton; 13.06.2010
comment
Андмар - ADP не претерпевают каких-либо значительных улучшений в течение многих лет, может быть, даже десятилетия. У них тоже есть причуды. - person Tony Toews; 13.06.2010
comment
@ Дэвид-В-Фентон: Мой мозг обычно переключается из режима чтения в боевой режим после синтаксического анализа, вы просто ошибаетесь, но я позволю вам сомневаться;) - person Andomar; 13.06.2010
comment
Спасибо, что прочитали за содержание, вместо того, чтобы зацикливаться на стиле. - person David-W-Fenton; 14.06.2010

arrow_upward
-1
arrow_downward

DAO использовался для доступа к базам данных MDB из любого приложения COM. Я не верю, что он может даже подключиться к SQL Server.

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

person Andomar    schedule 11.06.2010
comment
Этот ответ неверен относительно фактов о DAO против ADO. ADO является не преемником DAO, но преемником ODBC. MS выдвинула ADO во временные рамки A2000, пытаясь отодвинуть ADO и ядро ​​базы данных Jet, но это не удалось (по очень очевидным причинам - это была чертовски глупая идея). Классический ADO мертв, его заменил ADO.NET, который, несмотря на внешнее сходство с классическим ADO, представляет собой совершенно другое животное. DAO - это интерфейс к ядру базы данных Jet / ACE, через который вы можете получить доступ практически к любому хранилищу данных на планете. - person David-W-Fenton; 12.06.2010
comment
@ Дэвид-В-Фентон: Насколько мне известно, преемником ODBC была OLE DB. ADO была оболочкой COM для OLE DB. Отодвинуть реактивный двигатель в сторону было очень хорошей идеей: реактивный двигатель был эффективным, но отвечал на многие вопросы неверно. - person Andomar; 12.06.2010
comment
Но MS изменила свое мнение и полностью посвятила себя дальнейшему развитию движка базы данных Jet, начиная с Access 2007. Это было никогда не было хорошей идеей для Access, хотя, конечно, Jet совсем не вписывалась в семейство средств разработки .NET. Любой, кто утверждает, что MS отказался от Jet с Access, читает статьи базы знаний, относящиеся к большему семейству инструментов разработки MS, и неправильно применяет свои рекомендации к Access, где Jet / ACE совсем не рекомендуется - он в значительной степени улучшается и продвигается. - person David-W-Fenton; 13.06.2010
comment
Что касается OLEDB vs. ADO, да, конечно, но это не меняет сути. ADO вообще не была преемницей DAO. Ваш ответ неверен, и его необходимо отредактировать или удалить. - person David-W-Fenton; 13.06.2010
comment
Microsoft долгое время продвигала отказ от DAO в пользу ADO; зачем еще они разработали ADP? Если бы они передумали в 2005 году, я бы не узнал об этом, мои пользователи все еще используют Access 2003. - person Andomar; 13.06.2010
comment
Что ж, ADO / OLEDB / ADO.NET, возможно, были заменой MS для DAO для его инструментов разработки после VB6, учитывая, что MS продвигала DAO / Jet как общий интерфейс данных с семейством инструментов VB (я не знаю, что они используются в их инструментах на основе C), поэтому я думаю, вы правы в этом смысле, но ADO / OLEDB сильно отличается от DAO. ADO, как и ODBC, представляет собой общий интерфейс абстракции базы данных, а DAO - это интерфейс для Jet / ACE, который обеспечивает доступ к другим источникам данных. Это большая разница, и почему ADO никогда не собирался заменять DAO в Access. - person David-W-Fenton; 14.06.2010
comment
ADP были разработаны как способ продолжить повестку дня корпоративных баз данных MS. Это не было чем-то полезным для будущего Access. Тот факт, что MS теперь не рекомендует ADP в пользу MDB / ACCDB с ODBC, показывает это, а также тот факт, что ADO перестала быть интерфейсом данных по умолчанию после A2000. ADP всегда были очень несовершенными (и постоянно меняющейся целью - каждая из трех версий имеет разные ошибки / ошибки, некоторые из которых являются регрессами), и это далеко не обещанное улучшение производительности (вот почему они теперь устарели). - person David-W-Fenton; 14.06.2010