¿Qué significa 'nativo' en el contexto de dos tecnologías relacionadas?

Question

El escenario en cuestión se relaciona con el motor de base de datos Microsoft Jet . La afirmación fue que la tecnología de acceso a datos Data Access Objects (DAO) es "nativa" para Jet , la implicación es que crear un objeto a través del modelo DAO es 'superior' a hacer lo mismo a través del código SQL ejecutado desde dentro en Microsoft Access interfaz de usuario.

Además, se afirmó que si no se podía crear algo a través de DAO, entonces, por definición, no es 'nativo' para Jet.

Para mí, esta definición de 'nativo' parece estar fuera de lugar. Hay una serie de objetos Jet que, por razones históricas y políticas de Microsoft, se omitieron o solo se implementaron parcialmente en DAO (restricciones CHECK , tipos de datos de ancho fijo, el DECIMAL tipo de datos, tipos de datos comprimibles, etc.) pero se incluyeron en el SQL de Jet idioma de definición de datos ( DDL). La intuición sola me dice que Jet SQL DDL debe considerarse 'nativo' al motor Jet.

Entonces, mi pregunta es: ¿por qué una tecnología aparentemente externa (DAO) se considera "nativa" y otra tecnología aparentemente interna (SQL DDL) se considera "no nativa"? ¿Debo preocuparme por si algo es 'nativo' o no?

Answer 1

Tal vez me equivoque aquí, pero siempre lo entendí así:

• el motor de base de datos MS Jet es, por todos los medios, un motor de base de datos (con poca potencia o no)
• es " nativo " La interfaz con el mundo exterior es un dialecto SQL

mientras que:

• DAO es una de las capas de abstracción de la base de datos de Microsoft, diseñada para su uso en un entorno COM como VBA o secuencias de comandos de Windows
• fue desarrollado con Access (que puede verse como una interfaz de usuario / herramienta de informes para MS Jet, ya que MS Jet puede existir sin MS Access), y está muy integrado con MS Jet y MS Access, sin embargo, es en la misma categoría donde ADO estaría en

Answer 2

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.