“native”是什么意思？ 在两种相关技术的背景下意味着什么？
该场景与备受诟病的 Microsoft Jet 数据库引擎有关。 断言是数据访问对象 (DAO) 数据访问技术是 Jet 的“原生”技术，这意味着通过 DAO 模型创建对象比通过在 Microsoft Access 用户界面。
此外，有人断言，如果您无法通过 DAO 创建某些东西，那么根据定义，它就不是 Jet 的“原生”。
对我来说，“本土”的这个定义似乎是错误的。 由于历史和 Microsoft 政治原因，有许多 Jet 对象在 DAO 中被省略或仅部分实现（CHECK 约束、固定宽度数据类型、DECIMAL 数据类型、可压缩数据类型等），但已包含在 Jet 的 SQL 数据定义语言 中（ DDL）。 直觉告诉我，Jet SQL DDL 应该被视为 Jet 引擎的“原生”。
所以我的问题是：为什么一种看似外部的技术 (DAO) 会被视为“本机”，而另一种看似内部的技术 (SQL DDL) 会被视为“非本机”？ 我应该为某些东西是否是“本地”或其他东西而烦恼自己吗？
The scenario in question relates to the much-maligned Microsoft Jet database engine. The assertion was that the Data Access Objects (DAO) data access technology is 'native' to Jet, the implication being that creating an object via the DAO model is 'superior' to doing the same via SQL code executed from within in the Microsoft Access user interface.
Furthermore, it was asserted that if you couldn't create something via DAO then by definition it is not 'native' to Jet.
To me, this definition of 'native' seems to be misplaced. There are a number of Jet objects which, for historical and Microsoft political reasons, were omitted from or only partially implemented in DAO (CHECK constraints, fixed-width data types, the DECIMAL data type, compressible data types, etc) but were included in Jet's SQL data definition language (DDL). Intuition alone tells me that Jet SQL DDL should be considered 'native' to the Jet engine.
So my question is: why would a technology seemingly external (DAO) be considered 'native' and another technology seemingly internal (SQL DDL) be considered 'non-native'? Should I be troubling myself over whether something is 'native' or otherwise?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我看来，这个问题并不是真诚地提出的——它完全是针对我和我针对你的评论而发表的评论。 我已经在其他地方回答了所有问题，但为了把事情说清楚，让我概述一下 Jet 的历史。
Jet 在 90 年代初与 Access 一起推出。 在版本 1 和版本 2 之间，MS 收购了 Foxpro，并将其“Rushmore”技术整合到 Jet 中。 在此期间，MS 开发了 DAO 作为 Jet 的接口层。 我不知道 DAO 除了使用 Jet 进行所有数据访问的数据接口层之外是否还存在过，但在我看来，它就是这样的。 Jet 是一个相当不错的选择，因为通过 ODBC 和可安装的 ISAM，它可以使几乎任何当时常见的数据库格式在您的应用程序中的外观和行为与本机 Jet 数据的外观和行为相同。 那时，桌面数据库市场由 dBase 及其变体和 Paradox 主导。 这些都是桌面数据库引擎，而不是服务器数据库。 对服务器数据库的访问通常是通过 ODBC 进行的，但当时对于桌面数据库应用程序开发人员来说并不是那么重要。 Jet 能够很好地连接到 ODBC 数据源并非常有效地利用它们，尽管有时会出错（这就是 ODBCDirect 被引入 Jet 的原因，这将绕过 Jet 数据处理引擎的某些方面）。
现在，与 Access/Jet/DAO 的兴起同时，Visual Basic 成为通用 Windows 应用程序开发的热门产品，在 Web 蓬勃发展之前，VB 是世界上使用最广泛的编程语言。 DAO 和 Jet 为 VB 开发人员提供了访问各种数据存储的接口，并且 VB 开发工具与它们很好地集成。 因此，继ODBC之后，DAO成为MS的关键数据接口层，利用Jet引擎处理各种数据。
当然，这有其问题，而且也有很大的限制，因为 Jet/DAO（和 VB）都是面向桌面的工具。 到了 90 年代中后期，MS 试图从桌面软件、桌面操作系统和开发工具提供商扩展到企业软件提供商。 因此，MS 需要开发更强大的数据接口，例如用于数据库服务器的 ODBC，但具有较新的服务器数据库提供的所有现代功能。 OLEDB 就是这个问题的答案，ADO 作为 OLEDB 之上的接口层（就像 DAO 是 Jet 之上的接口层一样）。 虽然 DAO 的目标是通过 Jet 数据库引擎提供对大量数据存储的访问，但 OLEDB 是一个更加中立的数据接口层，如 ODBC（数据库抽象层），而 ADO 是该中立数据接口层的接口。
关于“原生”DDL 的问题，事实上，在 Jet 4 之前，对 SQL DDL 的支持非常差。 也就是说，Jet 的某些功能无法通过 SQL DDL 控制。 相反，您必须使用 DAO 来控制这些功能。 虽然 Jet 数据库引擎程序员当然包括 DDL 示例和 DAO 示例，但 DAO 示例能够执行更多操作，因为 Jet DDL SQL 从未支持 Jet 数据库的所有功能。
看似如此令人困惑的崩溃是由于微软内部政治造成的。 到 1999 年，当 MS 推出 Access 2000（带有新版本的 Jet 4.0）时，MS 希望淘汰 DAO，转而使用 ADO。 MS 将 ADO 设为 Access 中的默认数据接口层，即使使用 ADO 毫无意义（即，您的数据存储是 Jet）。 作为这项工作的一部分，MS 并没有完全更新 DAO 以纳入对 Jet 4 所有新功能的支持，而是将这方面的努力投入到 ADO 中。 结果是 Jet 的本机数据接口层 DAO 缺乏对数据库中立接口层 ADO 提供的 Jet 功能的支持。 在我看来，这是微软的一种特殊形式的混蛋行为。 MS 故意不更新 Jet 的本机接口层，以迫使您使用非本机接口。 因此，您必须使用 ADO->OLEDB->Jet，而不是 DAO->Jet，甚至对于 Jet 数据库引擎本机方面的某些内容（例如字段的某些数据类型）也是如此。
微软的目标是彻底消灭 DAO，实际上就是消灭 Jet 本身。 他们希望客户迁移到 SQL Server。
但发生了很多事情。 其一，基于 COM 的 ADO 无法很好地适应 .NET，因此经典的基于 COM 的 ADO 最终被放弃，而 ADO.NET 被创建来取代它。 ADO 和 ADO.NET 之间的相似之处非常表面，并且基于完全不同的数据交互模型，ADO.NET 几乎完全围绕断开连接的数据的思想进行设计，而 ADO 则不然（尽管它确实支持某些类型的断开连接）数据访问）。
随着 ADO 的消失，微软的产品线中间出现了一个漏洞。 传统的 VB 开发人员或 Access 开发人员不会在 .NET 中看到太多好处，因为整个数据访问模型不适合。 因此，到了 Access 2002 的发布时，MS 改变了方向，将 DAO 放回到原来的位置，作为 Jet 数据的默认数据接口层（以及 Jet 可以通过 ODBC 等使用的所有其他数据存储）。 不幸的是，虽然 MS 现在不赞成将 ADO 与 Jet 一起使用，但他们并没有选择修复随之而来的 DAO 的缺陷版本。 也许他们没有这样做，因为此时已经决定将现有的 Jet 4 分叉为 Access 开发小组拥有的数据库引擎。 它最终成为 ACE，并且从所有意图和目的来看，它都是 Jet 4.5。 发布了新版本的 DAO（尽管对其用户友好的名称进行了一些伪装，即“Microsoft Office 12.0 Access 数据库引擎对象库”，而 DLL 名称现在为 ACEDAO.DLL）。 我不知道 DAO 3.6（Jet 4 版本）中缺少的功能在多大程度上被添加到 DAO 的 ACE 版本中。 我不知道，因为我不需要任何这些功能，所以甚至不知道它们是什么。
无论如何，在这一点上，Jet（我们被承诺 Jet 4 是终结）和它的原生数据接口层（DAO，我们也被承诺已经死了）的开发正在进行中。 这项正在进行的开发现在由 Microsoft 的 Access 应用程序小组负责（与之前维护 Jet 4 的 Windows 不同）。
Microsoft 在 Access 中添加了兼容模式以使用他们所谓的 ANSI-92 SQL 模式。 这应该允许您编写与 SQL Server 的 SQL 方言“兼容”的 SQL。 嗯，它支持一些东西（您可以使用 SQL Server 通配符并使用 () 来表示派生表，而不是 Jet 的扭曲的 [].As Alias），但与 TSQL 不太接近。 但在 Access 之外，使用这种“ANSI-92”SQL 模式的唯一方法是使用 ADO 连接到 Jet。 DAO 本身仍然使用 Jet 的旧 SQL 方言。 这表明 Jet 本身并不提供对此模式的支持，而是由 Jet 之上的层提供支持。
This question is not really posted in good faith, in my opinion -- it's entirely directed at me and the comments I've been making in reponse to your comments. I've already answered all the issues elsewhere, but just to make things clear, let me outline the history of Jet.
Jet was introduced in the early 90s along with Access. Between version 1 and 2, MS acquired Foxpro and incorporated its "Rushmore" technology into Jet. Somewhere along this time frame, MS developed DAO as the interface layer to Jet. I don't know for a fact that DAO ever had an existence as anything other than a data interface layer that used Jet for all data access, but that's how it looked to me. Jet was a rather good choice for this since with ODBC and installable ISAMs, it could make just about any of the then-common database formats look and behave in your app in the same way native Jet data looked and behaved. Back in those days, the desktop database market was dominated by dBase and its variants and Paradox. These were all desktop db engines, not server databases. Access to server databases was generally through ODBC, but was not at that time all that important to desktop db application developers. Jet managed fairly well to connect to ODBC data sources and utilize them pretty efficiently, though it would sometimes make mistakes (and this is why ODBCDirect was introduced into Jet, which would bypass certain aspects of Jet's data processing engine).
Now, parallel to the rise of Access/Jet/DAO, Visual Basic was the hot product for generalized Windows app development and before the flourishing of the Web, VB was the most widely-used programming languages in the world. DAO and Jet provided VB developers with an interface to all sorts of data stores, and the VB development tools were well-integrated with them. Thus, after ODBC, DAO became MS's key data interface layer, utilizing the Jet engine to work with all kinds of data.
Naturally, this had its problems and was also very limiting in that Jet/DAO (and VB) were all desktop-oriented tools. By the mid-to-late 90s MS was attempting to expand from a provider of desktop softwares, desktop OS's and development tools to an enterprise software provider. So, MS needed to develop more robust data interfaces, something like ODBC for database servers, but with all the modern features that newer server databases offered. OLEDB was the answer for this with ADO as the interface layer on top of OLEDB (just as DAO is the interface layer on top of Jet). While the goal of DAO was to provide access to lots of data stores via the Jet database engine, OLEDB was a more neutral data interface layer like ODBC, a database abstraction layer, and ADO was the interface to that neutral data interface layer.
On the question of "native" DDL, it is a fact that before Jet 4 there was very poor support for SQL DDL. That is, there were features of Jet that were not controllable via SQL DDL. Instead, you had to use DAO to control those features. While the Jet Database Engine Programmer's certainly includes DDL examples alongside the DAO examples, the DAO examples are able to do a lot more because the Jet DDL SQL never supported all the features of Jet databases.
The breakdown that seems to be so confusing came about because of internal MS politics. By 1999, when MS introduced Access 2000 (with the new version of Jet, 4.0), MS wanted to retire DAO in favor of ADO. MS made ADO the default data interface layer in Access even when it made no sense to use ADO (i.e., your data store was Jet). As part of this effort, MS did not fully update DAO to incorporate support for all the new features of Jet 4 -- instead they put their efforts on this front into ADO. The result was that Jet's native data interface layer, DAO, lacked support for Jet features that the database neutral interface layer, ADO, offered. This was, in my opinion, a particular form of douchebaggery on Microsoft's part. MS was intentionally not updating Jet's native interface layer in order to force you into using the non-native interface. So, instead of DAO->Jet, you had to use ADO->OLEDB->Jet, even to for some things that were native aspects of the Jet database engine (such as some data types for fields).
Microsoft's goal was to kill off DAO entirely, and really, to kill off Jet itself. They wanted customers to move to SQL Server.
But a number of things happened. For one, ADO, which was COM-based, could not fit in very well with .NET, and therefore, classic COM-based ADO ended up being abandoned and ADO.NET created to take its place. The resemblences between ADO and ADO.NET are quite superficial and are based on completely different models of data interaction, with ADO.NET being almost entirely designed around the idea of disconnected data, while ADO was not (though it certainly supported certain kinds of disconnected data access).
With ADO going out the window, MS had a hole in the middle of its product line. The classic VB developer or Access developer was not going to see much benefit in .NET, because the whole data access model didn't fit. Thus, by the release of Access 2002, MS had reversed course and put DAO back in its place as the default data interface layer for Jet data (and all the other data stores Jet could work with via, e.g., ODBC, etc.). Unfortunately, while MS was now deprecating ADO for use with Jet, they didn't choose to fix the crippled version of DAO that went with it. Perhaps they didn't do this because by this point the decision had been made to fork the existing Jet 4 into a database engine owned by the Access development group. This eventually became the ACE and is, for all intents and purposes, Jet 4.5. A new version of DAO was released (though disguised a bit with its user-friendly name being "Microsoft Office 12.0 Access database engine Object Library" while the DLL name is now ACEDAO.DLL). I don't know the degree to which the features missing in DAO 3.6 (the Jet 4 version) have been added to the ACE version of DAO. I don't know because I don't need any of those features so don't even know what they are.
In any event, at this point, there is now ongoing development on Jet (we'd been promised that Jet 4 was the end) and on the data interface layer native to it (DAO, which we'd also been promised was dead). This ongoing development is now within the Access application group at Microsoft (as opposed to Windows, where Jet 4 was previously being maintained).
Microsoft has added compatibility modes in Access to use what they call ANSI-92 SQL mode. This is supposed to allow you to write SQL that is "compatible" with SQL Server's SQL dialect. Well, it supports a few things (you can use the SQL Server wildcards and use () for derived tables instead of Jet's screwy []. As Alias), but isn't very close to TSQL. But outside of Access, the only way to use this "ANSI-92" SQL mode is to use ADO to connect to Jet. DAO itself still uses Jet's old dialect of SQL. This shows that Jet is not providing support for this mode itself, but it's being provided by layers above Jet.
也许我错了，但我总是这样理解：
，而：
Maybe I'm wrong here, but I always understood it like this:
whereas: