Что означает "родной" в контексте двух взаимосвязанных технологий?

Question

Сценарий, о котором идет речь, относится к сильно оклеветанному Ядро базы данных Microsoft Jet.Утверждение состояло в том , что Объекты доступа к данным (DAO) технология доступа к данным является "родной" для Jet, подразумевается, что создание объекта с помощью модели DAO "превосходит" выполнение того же самого с помощью SQL-кода, выполняемого изнутри в Microsoft Access пользовательский интерфейс.

Более того, утверждалось, что если вы не можете создать что-либо с помощью DAO, то по определению это не является "родным" для Jet.

Мне это определение "туземца" кажется неуместным.Существует ряд объектов Jet, которые по историческим и политическим причинам Microsoft были исключены из DAO или лишь частично реализованы в DAO (CHECK ограничения, типы данных фиксированной ширины, DECIMAL тип данных, сжимаемые типы данных и т.д.), Но были включены в SQL Jet язык определения данных (DDL).Одна только интуиция подсказывает мне, что Jet SQL DDL следует считать "родным" для реактивного двигателя.

Итак, мой вопрос заключается в следующем:почему технология, кажущаяся внешней (DAO), должна считаться "родной", а другая технология, кажущаяся внутренней (SQL DDL), должна считаться "неродной"?Должен ли я беспокоиться о том, является ли что-то "родным" или нет?

Answer 1

Может быть, я здесь ошибаюсь, но я всегда понимал это так:

• ядро базы данных MS Jet - это, безусловно, ядро базы данных (с недостаточной мощностью или нет).
• его "родной" интерфейс для внешнего мира - это диалект SQL

принимая во внимание , что:

• DAO - это один из уровней абстракции базы данных Microsoft, предназначенный для использования в среде COM, такой как VBA или Windows scripting
• он был разработан с Access (который можно рассматривать как инструмент пользовательского интерфейса / отчетности для MS Jet, поскольку MS Jet может существовать без MS Access) и тесно связан как с MS Jet, так и с MS Access, тем не менее, он относится к той же категории, к которой относится ADO

Answer 2

На мой взгляд, этот вопрос на самом деле размещен не совсем добросовестно - он полностью адресован мне и комментариям, которые я делал в ответ на ваши комментарии.Я уже ответил на все вопросы в другом месте, но просто для того, чтобы внести ясность, позвольте мне вкратце рассказать историю Jet.

Jet был представлен в начале 90-х годов вместе с Access.Между версиями 1 и 2 MS приобрела Foxpro и внедрила ее технологию "Rushmore" в Jet.Где-то в этот период времени MS разработала DAO в качестве интерфейсного уровня для Jet.Я точно не знаю, существовал ли DAO когда-либо как что-либо иное, кроме уровня интерфейса данных, который использовал Jet для всего доступа к данным, но именно так это выглядело для меня.Jet был довольно хорошим выбором для этого, поскольку с ODBC и устанавливаемыми ISAMS он мог заставить практически любой из распространенных на тот момент форматов баз данных выглядеть и вести себя в вашем приложении так же, как выглядели и вели себя собственные данные Jet.В те дни на рынке настольных баз данных доминировала dBase, ее разновидности и Paradox.Все это были движки настольных баз данных, а не серверные базы данных.Доступ к серверным базам данных обычно осуществлялся через ODBC, но в то время это было не так уж важно для разработчиков приложений для настольных баз данных.Jet довольно хорошо справлялся с подключением к источникам данных ODBC и довольно эффективно использовал их, хотя иногда допускал ошибки (и именно поэтому в Jet был введен ODBCDirect, который обходил некоторые аспекты механизма обработки данных Jet).

Сейчас, параллельно с появлением Access / Jet / DAO, Visual Basic был популярным продуктом для разработки приложений для Windows, а до расцвета Интернета VB был самым широко используемым языком программирования в мире.DAO и Jet предоставили разработчикам VB интерфейс для всех видов хранилищ данных, а инструменты разработки VB были хорошо интегрированы с ними.Таким образом, после ODBC DAO стал ключевым уровнем интерфейса данных MS, использующим Jet engine для работы со всеми видами данных.

Естественно, это имело свои проблемы, а также было очень ограничено тем, что Jet / DAO (и VB) были инструментами, ориентированными на рабочий стол.К середине-концу 90-х годов MS пыталась превратиться из поставщика программного обеспечения для настольных компьютеров, настольных ОС и инструментов разработки в поставщика корпоративного программного обеспечения.Итак, MS потребовалось разработать более надежные интерфейсы передачи данных, что-то вроде ODBC для серверов баз данных, но со всеми современными функциями, которые предлагались новыми серверными базами данных.OLEDB был ответом на это с ADO в качестве интерфейсного слоя поверх OLEDB (точно так же, как DAO является интерфейсным слоем поверх Jet).В то время как целью DAO было предоставить доступ к множеству хранилищ данных через Jet database engine, OLEDB был более нейтральным уровнем интерфейса данных, таким как ODBC, уровень абстракции базы данных, а ADO был интерфейсом к этому нейтральному уровню интерфейса данных.

Что касается "родного" DDL, то фактом является то, что до Jet 4 поддержка SQL DDL была очень слабой.То есть, существовали функции Jet, которые не поддавались управлению с помощью SQL DDL.Вместо этого вам пришлось использовать DAO для управления этими функциями.В то время как Jet Database Engine Programmer's, безусловно, включает примеры DDL наряду с примерами DAO, примеры DAO способны сделать намного больше, потому что Jet DDL SQL никогда не поддерживал все функции баз данных Jet.

Поломка, которая кажется такой запутанной, произошла из-за внутренней политики MS.К 1999 году, когда MS представила Access 2000 (с новой версией Jet 4.0), MS хотела отказаться от DAO в пользу ADO.MS сделала ADO уровнем интерфейса данных по умолчанию в Access, даже когда не имело смысла использовать ADO (т. Е. вашим хранилищем данных был Jet).В рамках этой работы MS не стала полностью обновлять DAO, чтобы включить поддержку всех новых функций Jet 4 - вместо этого они вложили свои усилия в этом направлении в ADO.Результатом стало то, что собственный уровень интерфейса данных Jet, DAO, не поддерживал функции Jet, предлагаемые нейтральным к базе данных уровнем интерфейса ADO.Это было, на мой взгляд, особой формой придурковатости со стороны Microsoft.MS намеренно не обновляла уровень собственного интерфейса Jet, чтобы заставить вас использовать неродной интерфейс.Итак, вместо DAO-> Jet вам пришлось использовать ADO-> OLEDB-> Jet, даже для некоторых вещей, которые были собственными аспектами ядра базы данных Jet (например, для некоторых типов данных для полей).

Цель Microsoft состояла в том, чтобы полностью уничтожить DAO и, по сути, уничтожить сам Jet.Они хотели, чтобы клиенты перешли на SQL Server.

Но произошло несколько вещей.Во-первых, ADO, основанный на COM, не мог очень хорошо вписаться в .NET, и поэтому классический ADO на основе COM в конечном итоге был заброшен и ADO.NET создан, чтобы занять его место.Сходства между ADO и ADO.NET довольно поверхностны и основаны на совершенно разных моделях взаимодействия с данными, с ADO.NET будучи почти полностью разработанным вокруг идеи отключенных данных, в то время как ADO таковым не являлся (хотя он, безусловно, поддерживал определенные виды отключенного доступа к данным).

Из-за того, что ADO вылетел в трубу, у MS образовалась дыра в середине продуктовой линейки.Классический разработчик VB или Access developer не увидел бы особой пользы в .NET, потому что вся модель доступа к данным не подходила.Таким образом, к выпуску Access 2002 MS изменила курс и вернула DAO на его место в качестве уровня интерфейса данных по умолчанию для данных Jet (и всех других хранилищ данных, с которыми Jet мог работать через, например, ODBC и т.д.).К сожалению, в то время как MS теперь отвергала ADO для использования с Jet, они не решили исправить поврежденную версию DAO, которая прилагалась к нему.Возможно, они этого не сделали, потому что к этому моменту было принято решение подключить существующий Jet 4 к движку базы данных, принадлежащему Access development group.В конечном итоге это стало ACE и, по сути, является Jet 4.5.Была выпущена новая версия DAO (хотя и немного замаскированная под удобное для пользователя название "Microsoft Office 12.0 Access database engine Object Library", в то время как теперь DLL называется ACEDAO.DLL).Я не знаю, в какой степени функции, отсутствующие в DAO 3.6 (версия Jet 4), были добавлены в версию DAO ACE.Я не знаю, потому что я не потребность ни одна из этих функций, так что я даже не знаю, что это такое.

В любом случае, на данный момент продолжается разработка Jet (нам обещали, что Jet 4 - это конец) и встроенного в него уровня интерфейса передачи данных (DAO, который, как нам также обещали, был мертв).Эта текущая разработка теперь находится в группе приложений Access в Microsoft (в отличие от Windows, где ранее поддерживался Jet 4).

Корпорация Майкрософт добавила режимы совместимости в Access для использования того, что они называют режимом SQL ANSI-92.Предполагается, что это позволит вам писать SQL, который "совместим" с диалектом SQL SQL сервера.Ну, он поддерживает несколько вещей (вы можете использовать подстановочные знаки SQL Server и использовать () для производных таблиц вместо screwy от Jet [].Как псевдоним), но не очень близок к TSQL.Но за пределами Access единственный способ использовать этот режим SQL "ANSI-92" - это использовать ADO для подключения к Jet.Сам DAO по-прежнему использует старый диалект SQL от Jet.Это показывает, что Jet не обеспечивает поддержку этого режима сам по себе, но он обеспечивается слоями выше Jet.