DAO против ADO в HTA по беспроводной сети

1. Если единственная причина, по которой вам нужен DAO, - это сжатие базы данных, вы можете использовать DAO для этого и использовать ADO для всего остального. Вы не ограничены использованием только ADO или DAO.

2. Самым большим преимуществом использования ADO является то, что когда придет время, будет проще перейти на SQL Server Express. Вам следует сделать это раньше, чем позже, поскольку SQL Server Express предлагает все преимущества баз данных MSAccess без недостатков. SQL Server Express бесплатен и легко справится с размером системы, который вы предлагаете.

Базы данных Access легко повреждаются в многопользовательской среде, особенно когда задействована беспроводная сеть. Если вы беспокоитесь о потере преимуществ работы в MSAccess, вы все равно можете подключиться к SQL Server с помощью связанных таблиц и таким образом работать с базой данных SQL Server Express.

Вы также можете использовать JRO для сжатия файла MDB. Он будет включен в любую последнюю версию MDAC, установленную по умолчанию в системах XP и более поздних версий. Установка Access не требуется.

Чтобы ответить на ваши конкретные вопросы:

1) Я бы выбрал ADO только потому, что он более актуален, и тот же API можно использовать в других видах сценариев, таких как доступ к LDAP / ActiveDirectory, чтение папок файловой системы, чтение почты MAPI и работа с другими типами полу- структурированные текстовые файлы, такие как текст фиксированной ширины и CSV. Это не особенно лучше для среды программирования HTA, но, возможно, вам лучше изучить более широко применимый API. Я также считаю, что с этим API проще работать, но я начал с него и только позже работал над некоторыми старыми проектами DAO.

2) Одно из возможных преимуществ, которое предоставляет ADO, - это отключенные наборы записей, которые могут иметь преимущество или, по крайней мере, предлагать некоторые архитектурные альтернативы при настройке беспроводной сети. Вы открываете набор записей, а затем отключаете его, чтобы можно было работать с данными в памяти, но не оставлять соединение с базой данных открытым. Затем в более позднее время вы можете повторно подключиться и обновить базу данных. Кроме того, вы можете работать в полностью автономном стиле, управляя таблицами как локальными файлами XML или ADTG.

Вы можете заставить DAO работать с VBScript, но это странное сочетание. В целом, ADO имеет наибольший смысл.

Еще одно преимущество ADO заключается в том, что он поддерживает RDS через DCOM или HTTP. Это можно использовать для преодоления многих ограничений Jet MDB, используемых через общий доступ к файлам, таких как повреждение ненадежных сетей и клиентов. Это также сокращает объем трафика по сети, повышая производительность. Кроме того, он предлагает средний уровень, на котором могут «жить» бизнес-объекты, и все это может быть посредником с помощью COM +, где это применимо.

Конечно, у вас больше нет возможности использовать простую сеть P2P и общий файловый ресурс для размещения базы данных. RDS необходим сервер для размещения процесса и запуска движка Jet, который больше не нужно запускать в каждой клиентской системе. Это означает, что вы можете использовать хранимые процедуры Jet, которые выполняются на сервере, разгружая больше клиентской обработки и сетевого трафика. Хотя эта эксклюзивная технология ADO / Jet 4.0 OLE DB Provider не такая сложная, как T-SQL или другие альтернативы, она предлагает ощутимые преимущества, которых нельзя получить с помощью DAO.

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

Однако использование RDS требует большей инфраструктуры и опыта, чем простой файловый ресурс. Вы могли бы также изучить младшую версию SQL Server.

В общем, я бы рекомендовал использовать утилиту jetcomp.exe для сжатия и восстановления поверх любого DAO или JRO. Это дает ряд преимуществ.

Если вы можете позволить себе использовать приложение HTA с Access вместо более производительной платформы, я бы сказал, что вам следует использовать самый простой для вас api. В вашем случае узким местом никогда не будет абстракция доступа к БД. Тем не менее, DAO действительно стар.