Was bedeutet "native" bedeutet im Kontext von zwei Verwandte Technologien?

Question

Das Szenario in Frage bezieht sich auf den viel geschmähten Microsoft Jet-Datenbank-engine.Die Behauptung war, dass die Data Access Objects (DAO) data access technology ist 'native' Jet, die impliziert, dass das erstellen eines Objekts über das DAO-Modell, ist 'superior', um das gleiche zu tun, die über SQL-code ausgeführt, in dem Microsoft Access user interface.

Außerdem wurde geltend gemacht, dass, wenn Sie könnte nicht etwas schaffen, über DAO-dann ist es per definition keine 'native' zu Jet.

Für mich ist diese definition von "einheimischen" zu sein scheint fehl am Platz.Es gibt eine Reihe von Jet-Objekte, die für die historische und Microsoft politischen Gründen wurden ausgelassen oder nur teilweise umgesetzt, so DAO - (CHECK Einschränkungen, fixed-width Datentypen, die DECIMAL Daten, die Art, komprimierbare Daten-Typen, etc.), sondern waren in Jet-SQL data definition language (DDL).Intuition allein sagt mir, dass die Jet-SQL-DDL-sollte als 'native', um die Jet-engine.

Also meine Frage ist:warum würde eine Technologie scheinbar externe (DAO) als 'native' und andere Technologie scheinbar interne (SQL-DDL) als 'non-native'?Sollte ich mich beunruhigend über die Frage, ob etwas 'native' oder anders?

Answer 1

Vielleicht bin ich falsch hier, aber ich verstand es immer wie folgt aus:

• die MS Jet Datenbank-Engine ist auf alle Fälle eine Datenbank-Engine (untermotorisiert oder nicht)
• es ist „native“ Schnittstelle zur Außenwelt ist ein SQL-Dialekt

während:

• DAO ist eine Datenbank-Abstraktionsschichten von Microsoft, die für die Verwendung in einer COM-Umgebung wie VBA oder Windows Scripting
• wurde mit Access entwickelt (die bei als Benutzerschnittstelle / Reporting-Tool für MS Jet angesehen werden kann, da MS Jet ohne MS Access existieren kann) und ist stark mit sowohl MS Jet und MS Access gebündelt, doch es ist in der gleichen Kategorie, in der ADO wäre in

Answer 2

Diese Frage ist nicht wirklich gepostet, in gutem glauben, in meine Meinung-es ist völlig auf mich gerichtet und die Kommentare, die ich gemacht habe in Antwort auf Ihre Kommentare.Ich habe bereits beantwortet alle Fragen, die anderswo, aber nur, um die Dinge klarzustellen, lassen Sie mich skizzieren Sie die Geschichte von Jet.

Jet eingeführt wurde in die frühen 90er Jahre zusammen mit dem Zugang.Zwischen version 1 und 2, MS erworben Foxpro und integriert seine "Rushmore" - Technologie in Jet.Irgendwo in diesem Zeitrahmen, MS entwickelt, DAO die Schnittstelle Schicht zu Jet.Ich weiß nicht, für eine Tatsache, DAO je eine Existenz als etwas anderes als ein Daten-interface-Schicht, verwendet Jet-für alle Daten zugreifen, aber das ist, wie es aussah auf mich zu.Jet war eine ziemlich gute Wahl für diese da mit ODBC-und installierbare ISAMs, es könnte nur über die damals verbreitete Datenbank-Formate Aussehen und Verhalten Ihrer app in der gleichen Weise native Jet-Daten geschaut und benommen.Zurück in jenen Tagen, die desktop-Datenbank-Markt wurde dominiert von dBase und seine Varianten und Paradox.Diese waren alle desktop-db-engines, die nicht-server-Datenbanken.Zugriff auf server-Datenbanken sind in der Regel durch ODBC, war aber zu dieser Zeit nicht so wichtig, desktop-db-Anwendung Entwickler.Jet gelang ziemlich gut, die Verbindung zu ODBC-Datenquellen und nutzen Sie ziemlich effizient, obwohl es manchmal Fehler machen (und dies ist der Grund, warum ODBCDirect eingeführt wurde, in Jet, das umgehen würde, bestimmte Aspekte der Jet-Datenverarbeitungs-engine).

Nun, parallel zum Anstieg der Access - /Jet - /DAO, Visual Basic wurde die heiße Ware für generalisierte Windows-app-Entwicklung und vor der Blüte im Web, VB, war der am häufigsten verwendeten Programmiersprachen in der Welt.DAO und Jet zur Verfügung gestellt VB-Entwicklern mit einer Schnittstelle zu allen Arten von Daten speichert, und das VB-Entwicklung-tools waren gut integriert.So, nach der ODBC, DAO, wurde MS-Schlüssel-Daten-interface-Ebene, unter Verwendung der Jet-engine arbeiten mit allen Arten von Daten.

Natürlich, das hatte seine Probleme und war auch sehr einschränken, dass die Jet - /DAO - (und VB) waren alle desktop-tools.Bis Mitte der 90er Jahre MS war versucht zu erweitern, die von einem Anbieter von desktop-Software, desktop-Betriebssysteme und Entwicklungs-tools, um eine enterprise-software-Anbieter.So, MS benötigt, um zu entwickeln, mehr stabile Daten-Schnittstellen, so etwas wie ODBC für Datenbank-Server, aber mit all den modernen Funktionen, die neuere server-Datenbanken angeboten.OLEDB-war die Antwort für diese mit ADO als die interface-Schicht auf der Oberseite des OLEDB (genauso wie DAO der interface-Schicht auf der Oberseite der Strahl).Während das Ziel der DAO war Sie Zugriff auf viele Daten speichert, die über die Jet-Datenbank-engine OLE DB-war ein neutraler Daten-Schnittstelle Schicht, wie ODBC, eine Datenbank-Abstraktionsschicht, und kurzerhand wurde die Schnittstelle zu, die neutralen Daten-Schnittstelle Schicht.

Auf die Frage, "native" DDL, es ist eine Tatsache, dass, bevor Sie Jet 4 es war sehr schlechte Unterstützung für die SQL-DDL.Das heißt, es wurden Funktionen von Jet, wurden nicht steuerbar via SQL-DDL.Stattdessen mussten Sie DAO verwenden, um die Kontrolle über diese Funktionen.Während die Jet Database Engine Programmer ' s sicherlich umfasst DDL Beispiele neben der DAO-Beispiele, die DAO-Beispiele sind in der Lage zu tun, viel mehr, weil die Jet-DDL-SQL-nie unterstützt alle Funktionen, die von Jet-Datenbanken.

Die Panne scheint zu sein, so verwirrend zustande kam, da der interne MS Politik.Von 1999, als MS eingeführt Access 2000 (mit der neuen version von Jet 4.0), MS wollte in den Ruhestand DAO zu Gunsten von ADO.MS gemacht ADO den Standard-Daten-interface-Schicht im Zugriff, auch wenn es machte keinen Sinn, ADO (d.h., Ihre Daten zu speichern, war Jet).Als Teil dieser Anstrengungen ist, dass MS nicht vollständig zu aktualisieren DAO zu integrieren, die Unterstützung für die neuen features der Jet-4-stattdessen setzten Sie Ihre Bemühungen an dieser front in ADO.Das Ergebnis war, dass die Jet ' s native data interface layer, DAO, fehlte die Unterstützung für Jet-features, dass die Datenbank neutral interface layer, ADO angeboten.Dies war, meiner Meinung nach, eine Besondere form von Schwachsinn, die Microsoft Teil.MS wurde absichtlich nicht aktualisieren Jet native interface layer, um ihn zu zwingen, Sie in die Verwendung der nicht-native interface.So, anstelle von DAO->Jet, Sie zu nutzen hatten, ADO->OLE DB->Jet, sogar für einige Sachen, die native Aspekte der Jet-Datenbank-engine (wie einige Datentypen für Felder).

Microsoft ' s Ziel war, zu töten, DAO vollständig, und wirklich, zu töten, Jet selbst.Sie wollten die Kunden zu bewegen, um SQL Server.

Aber eine Reihe von Dingen passiert ist.Zum einen, ADO, wurde die COM-basierte, konnte nicht passen sehr gut mit .NET, und darum, klassische COM-basierte ADO endete als aufgegeben und ADO.NET geschaffen, um Ihren Platz einzunehmen.Die resemblences zwischen ADO und ADO.NET sind Recht oberflächlich und basieren auf völlig unterschiedliche Modelle der Daten-Interaktion, mit ADO.NET fast vollständig entwickelt, um die Idee der getrennten Daten, während ADO, war nicht (obwohl es sicherlich unterstützt bestimmte Arten von getrennt-data-access).

Mit ADO gehen aus dem Fenster, MS hatte in der Mitte ein Loch von seine Produkt Linie.Die klassische VB-Entwickler oder Access Entwickler war nicht zu sehen, viel profitieren .NET, da der gesamte Daten-access-Modell nicht passen.So, durch die Freisetzung von Access 2002, MS aufgehoben hatte, natürlich und setzen DAO wieder an seinen Platz, als die Standard-Daten-interface-Schicht für Jet-Daten (und alle anderen Daten, speichert Jet könnte Arbeit mit per, z.B. ODBC, etc.).Leider, während MS war jetzt veralteten ADO für die Verwendung mit Jet, die Sie nicht wählen, um fix die verkrüppelte version von DAO, die mit ihm gingen.Vielleicht ist Sie das nicht tun, weil von diesem Punkt die Entscheidung Gabel die bestehende Jet 4 in eine Datenbank-engine im Besitz der Access-Entwicklung-Gruppe.Dies wurde schließlich das ass und die ist, für alle Absichten und Zwecke, Jet 4.5.Eine neue version von DAO veröffentlicht wurde (obwohl verkleidet sich ein wenig mit seiner benutzerfreundlichen Namen "Microsoft Office 12.0 Access database engine Object Library" während der DLL-name ist jetzt ACEDAO.DLL).Ich weiß nicht, bis zu welchem Grad die Eigenschaften fehlen, die in DAO 3.6 (Jet 4-version) wurde Hinzugefügt, um die ACE version von DAO.Ich weiß nicht, weil ich nicht müssen alle diese Funktionen, so gar nicht wissen, was Sie sind.

In jedem Fall, an diesem Punkt, es ist jetzt die kontinuierliche Entwicklung Jet (wir hatten versprochen, dass die Jet 4 wurde das Ende) und über die Daten-Schnittstelle Schicht native zu (DAO, die würden wir auch versprochen worden war tot).Diese Weiterentwicklung ist nun innerhalb der Access-Anwendung-Gruppe bei Microsoft (im Gegensatz zu Windows, wo Jet 4 wurde bisher nicht erhalten).

Microsoft hat Hinzugefügt Kompatibilität Modi in Access zu verwenden, wie Sie es nennen, ANSI-92 SQL-Modus.Dies soll Ihnen ermöglichen, SQL-Code schreiben, der "kompatibel" mit SQL-Server-SQL-Dialekt.Auch, es unterstützt ein paar Dinge (Sie können die SQL Server-Platzhalter und verwenden () für abgeleitete Tabellen anstelle von Jet ' s screwy [].Als Alias), ist aber nicht sehr nah an TSQL.Aber außerhalb von Access, die einzige Möglichkeit, um dieses "ANSI-92 SQL-Modus ist die Verwendung von ADO-Verbindung zu Jet.DAO selbst verwendet noch Jet alten Dialekt von SQL.Dies zeigt, dass der Jet ist keine Unterstützung für diesen Modus selbst, aber es ist zur Verfügung gestellt durch die Schichten oberhalb Jet.