Ein Zugriff "gespeicherte Abfrage" ist mehr als eine Ansicht in SQL Server (wobei "mehr" nicht bedeutet, dass es besser ist oder nicht). In SQL Server haben Sie den SQL-Text und den Ausführungsplan, der eine Sicht definiert.Sie können auch zusätzliche Informationen wie Beschreibungstext oder benutzerdefinierte Variablen mit benutzerdefinierten Werten hinzufügen, die keinen Einfluss auf die Ansicht selbst haben.
In Access arbeiten Sie mit QueryDef-Objekten, die tatsächlich die "gespeicherten Abfragen" sind, sie enthalten viel mehr als nur den SQL-Text, der nur eine Eigenschaft des QueryDef-Objekts ist. Zum Beispiel können Sie Parameter mit der PARAMETERS-Klausel definieren, die ähnlich zu @ -Variablen in gespeicherten Prozeduren/Funktionen von SQL Server verwendet werden kann. Dies ist etwas, das für SQL Server-Ansichten nicht existiert. Natürlich hat ein QueryDef-Objekt auch einen gespeicherten Ausführungsplan. Aus diesem Grund empfiehlt Microsoft auch, einen QueryDef als doc.RecordSource anstelle eines dynamischen SQL-Befehls an der gleichen Stelle zu verwenden. Das JET/ACE-Abfrageoptimierer-Ergebnis kann auch mit einigen Registry-Tricks sichtbar gemacht werden, es ist nur nicht Teil der Access-GUI, so dass die meisten Leute nicht wissen, dass es auch einen Ausführungsplan hat. QueryDef-Objekte enthalten auch Formatierungseigenschaften, Beschriftungen, die in der Datenblattansicht angezeigt werden, Definition von Suchvorgängen für Comboboxen, ODBC-Verbindungszeichenfolgen und vieles mehr, Sie finden sie alle in der Access-Hilfe.
Also Access QueryDefs enthält eine Menge, die nur die Anzeige des Ergebnisses betrifft, die für ein Frontend, das Sie mit Access entwickeln können, sinnvoll ist, aber sie haben nicht sehr viele Vorteile im Vergleich zu SQL Server-Ansichten. Ein einfacher Unterschied ist die SQL-Sprache: Unabhängig vom verwendeten Backend arbeiten Sie mit Access SQL und dieses SQL ist wirklich ein sehr einfaches SQL. T-SQL auf SQL Server zum Beispiel ist eine sehr mächtige SQL-Sprache, in der Sie viel mehr tun können - zum Beispiel können Sie eine hierarchische Struktur wie eine Stückliste mit einer SQL-Anweisung abfragen, mit der Sie nicht arbeiten können Greifen Sie auf SQL zu, da T-SQL rekursives SQL verwenden kann. In Access wäre es nur mit Hilfe von VBA-Funktionen in Access SQL möglich, was die gesamte Abfrage sehr verlangsamt.
Natürlich kann ein QueryDef-Objekt in Access auch sogenannte "Pass-Through-Queries" verwenden, die d. H. T-SQL direkt ausführen, ohne Access SQL zu verwenden. Da der SQL-Text jedoch lokal in Access gespeichert wird, wird er in SQL Server als dynamisches SQL gehandhabt, da der Text bei jeder Ausführung gesendet wird und SQL Server keine gespeicherte Ansicht dafür besitzt. Dadurch gehen alle Vorteile einer gespeicherten Ansicht verloren. Es ist besser, sie zu vermeiden oder sie nur zum Ausführen gespeicherter Ansichten, Funktionen oder gespeicherter Prozeduren in SQL Server zu verwenden.
Ein QueryDef-Objekt ist außerdem ein DAO-Objekt und das bedeutet, dass Sie immer mit DAO-Datentypen arbeiten. Daher werden die Daten auch bei einer Pass-Through-Query immer von SQL Server (oder natürlich anderen Datenbank) -Datentypen in DAO-Datentypen konvertiert.
Einfachere Bereitstellung wie oben erwähnt: Es gibt keinen großen Unterschied bei der Verwendung einer View oder QueryDef in Access, wenn beide für Frontend-Zwecke wie die RecordSource-Eigenschaft eines Formulars verwendet werden. Der Grund dafür ist, dass sowohl QueryDef als auch View im Frontend implementiert werden müssen, QueryDef muss lokal geändert werden, die View kann im Backend geändert werden, ist aber in den meisten Fällen mit dem Frontend als verknüpfte Tabelle verknüpft Sie müssen diesen Link im Frontend löschen und bei Änderungen der Ansicht neu erstellen, so dass Sie auch das Frontend erneut bereitstellen müssen. Deshalb bevorzuge ich persönlich ADPs anstelle von ACCDBs, da ich in ADPs direkt mit der Ansicht und in Access arbeite nicht mit irgendeinem QueryDef, also reicht hier eine Änderung im Backend aus, um es im Frontend widerzuspiegeln). Unabhängig davon müssen Sie das Frontend auch neu implementieren, wenn Sie einen Feldnamen in der Ansicht ändern, die Sie im Frontend verwenden.
Es ist eine andere Sache, wenn Sie die Ansicht nur im Back-End verwenden, um Daten für andere Back-End-Zwecke wie die Verwendung in einer gespeicherten Prozedur oder einer anderen Ansicht zu sammeln. Wenn sie nicht mit dem Frontend verbunden sind, müssen Sie das Frontend nicht erneut bereitstellen. Wie bei gespeicherten Prozeduren und Funktionen gilt dies auch für Ansichten, bei denen Sie schnell etwas im Backend ändern können, wenn Sie etwas korrigieren müssen, das das Frontend nicht direkt betrifft. Das heißt, wenn Sie zwei Textfelder mit einem "" verknüpfen."mit einem Alias-Namen und jemand sagt Ihnen, dass es jetzt ein" - "sein muss, Sie können einfach die Ansicht ändern und es ist fertig, nichts im Frontend zu ändern (wenn Sie keine weitere Logik im Frontend haben, nach der Sie suchen müssen der Punkt)
SELECT * "buchstabiert die Feldliste" ist in der Tat, was eine SQL Server-Ansicht tut, das Problem ist: Es speichert eine Liste der Felder des Tabellenobjekts, die Sie in der SELECT zu dem Zeitpunkt verwenden Speichern Sie die Ansicht. Aber es speichert diese Feldliste nicht sichtbar. Wenn Sie den SQL-Text der Ansicht öffnen, sehen Sie immer nur das "*", nicht die Feldliste, die die Ansicht gespeichert hat. Dies ist ein großes Problem in SQL Server als Sie würden erwarten, dass es alle Felder auflistet, die die Tabelle zu jeder Zeit hat (das macht Access in einem QueryDef-Objekt mit SELECT *.) Selbst wenn Sie ein Werkzeug wie die kostenlose SQL-Suche von RedGate verwenden, würden Sie diese Ansicht nicht als Sie finden habe die Feldliste im SQL-Text nicht, so dass der Feldname eines geänderten Tabellenfeldes nicht gefunden werden kann.
Im Allgemeinen vermeiden Sie die "SELECT *" wo immer möglich, da es mehr Probleme erzeugt, als dass es einen Vorteil hat. Verwenden Sie immer die Liste der Felder, die Sie wirklich als Ergebnis möchten. In Access werden diese Feldnamen automatisch geändert, wenn Sie den Feldnamen in einer Tabelle ändern (wenn Sie in den Access-Optionen AutoRename aktiviert haben), können Sie in SQL Server nach allen Objekten mit einem bestimmten Feld suchen und diese ändern.
Eine Ausnahme wäre, wenn Sie ein CTE in SQL Server verwenden, wo das letzte SELECT alle Felder der vorherigen SELECTs im CTE auswählt. Hier ist es kein Problem, das Sternchen zu verwenden, da die Feldnamen in den vorherigen SELECTs derselben Abfrage aufgeführt werden (sollten). Aber im Allgemeinen ist es besser, es häufiger zu vermeiden, als es für Produktionszwecke zu verwenden.
Dies sind nur Beispiele für Unterschiede zwischen beiden, es gibt viel mehr wie oben erwähnt (indizierte Ansichten, Sicherheitsmodell) oder etwas wie Schemanamen, aber das sollte Ihnen ein Bild geben.