Verknüpfte SQL-Server-Sichten in Access

Post by Lutz
Hallo!
Ich verknüpfe in meinen Access-Frontends (2003/2010) Tabellen und
Sichten aus dem SQL-Server (2005-2012)
Bei Tabellen ist das alles kein Problem, da werden die Informationen
über Primärschlüssel und Indizes ja übermittelt.
Wie sieht es aber bei verknüpften Sichten aus?
Macht es Sinn nach der Verknüpfung noch Primärschlüssel oder Indizes
anzulegen?
Angefangen hab ich damit, als es darum ging solche verknüpften Sichten
mit lokalen Access-Tabellen oder -Abfragen zusammenzubringen.
Da traten Performance-Probleme auf bzw waren solche gemischten
Abfragen nicht aktualisierbar wegen fehlender Schlüssel.
Kann ich diesen Vorteil problemlos nutzen oder muss ich aufpassen, daß
sich die lokalen und Server-Indizes nicht gegenseitig ausbremsen oder
behindern. Aufpassen muss ich zum Beispiel bei einem lokalen
Primärschlüssel - passt der nicht zu den Daten der verknüpften Sicht,
verschwinden auch schon mal Datensätze ...
Welche Erfahrungen bzw Empfehlungen habt ihr zu diesem Thema?
Danke euch schon einmal!
Lutz

Hallo Lutz,

es besteht i.d.R. keine Notwendigkeit, Indizes dynamisch anzulegen, im
Gegenteil.

Alle Basistabellen sollten einen Primärschlüssel besitzen und auch auf
alle Fremdschlüsselfelder wird ein Index gelegt. Zusätzlich sollte man
für die Felder einen Index erstellen, welche als Kriterien in 'WHERE'
Bedingungen benutzt werden. Bei den Indizes zwecks Sortierung muß man
etwas aufpasssen. Die Pflege des Indexes im Server bei einem
Update/Insert kostet Zeit und andererseits bietet es Vorteile, wenn nach
dem infrage kommenden Feld häufig sortiert wird. Hängt so ein bißchen
auch mit der Anzahl Datensätze und den Häufigkeit von Aktualisierungen
ab. Normalerweise fügt man hier auch einen Index hinzu. In einer Sicht
habe ich noch nie explizit einen Index angelegt und auch nicht gebraucht.

Ob die verwendeten Tabellen in einer Abfrage aktualisierbar sind, hat
auch etwas mit dem verwendeten Treibern und der Reihenfolge des
Einbindens der beteidigten Basistabellen zu tun, Stichwort
rechts-/linksseitig. Ist aber nicht so entscheidend, man kann ja immer
noch einen Insert/Update auf die zugrunde liegenden Tabellen machen.

Ulrich

Lars P. Wolschner

2013-11-21 19:02:40 UTC

Post by Lutz
Ich verknüpfe in meinen Access-Frontends (2003/2010) Tabellen
und Sichten aus dem SQL-Server (2005-2012)
Bei Tabellen ist das alles kein Problem, da werden die
Informationen über Primärschlüssel und Indizes ja übermittelt.
Wie sieht es aber bei verknüpften Sichten aus?

Indizes für Sichten, also gespeicherte Abfragen? Wie soll das
gehen?

Post by Lutz
Macht es Sinn nach der Verknüpfung noch Primärschlüssel oder
Indizes anzulegen?

Indizes kannst Du problemlos für echte Datenbanktabellen im Server
anlegen.

Post by Lutz
Angefangen hab ich damit, als es darum ging solche verknüpften
Sichten mit lokalen Access-Tabellen oder -Abfragen
zusammenzubringen. Da traten Performance-Probleme auf bzw waren
solche gemischten Abfragen nicht aktualisierbar wegen fehlender
Schlüssel.

Selbst richtige Datenbankserver können ganz schnell nicht mehr
aktualisieren, wenn durch irgendwelche Verknüpfungen eingebundene
Tabellen in der Sicht mitspielen. Ich habe sowas in VBA
realisiert, aber mein System kann sein Modell der
Tabellenbeziehungen auch Verbindungs-, also auch "Datenbank"-
übergreifend aufbauen und die möglicherweise abweichenden SQL-
Syntaxen auseinanderhalten. Es ist sehr umfangreich und
kompliziert.

Post by Lutz
Kann ich diesen Vorteil problemlos nutzen oder muss
ich aufpassen, daß sich die lokalen und Server-Indizes nicht
gegenseitig ausbremsen oder behindern. Aufpassen muss ich zum
Beispiel bei einem lokalen Primärschlüssel - passt der nicht zu
den Daten der verknüpften Sicht, verschwinden auch schon mal
Datensätze ...

Das ist mir so nicht verständlich, da müßtest Du mal genauer
erläutern, wie Deine Prüimärschlüssel in den Acces-Tabellen und
wie jene in den auf dem Server lagernden Tabellen sind.

Post by Lutz
Welche Erfahrungen bzw Empfehlungen habt ihr zu diesem Thema?

Access kann datenbankübergreifende Abfragen durchführen. Schnell
ist das nicht, denn Indizes der auf dem Server lagernden und mit
Access verknüpften Tabellen können dabei natürlich nicht genutzt
werden. Nur die auf dem Server befindlichen Sichten nutzen die
Indizes der ebenfalls auf dem Server befindlichen Tabellen.

Deshalb sollte man möglichst nur einfach gehaltene Sichten
einbinden, die evtl. schon die Filterung des größten Teils der
gewünschten Datensätze übernehmen. Das läuft dann auf dem Server
und Access muß weniger Datensätze verarbeiten. Nachteil: Bei
größeren Projekten explodiert die Zahl dieser Sichten, weil man
häufig verschiedene Filterungen und Sortierungen der gleichen
elementaren Tabellen(verbindungen) benötigt.

Post by Ulrich MÃ¶ller
Alle Basistabellen sollten einen Primärschlüssel besitzen und
auch auf alle Fremdschlüsselfelder wird ein Index gelegt.
Zusätzlich sollte man für die Felder einen Index erstellen,
welche als Kriterien in 'WHERE' Bedingungen benutzt werden.

Ersetze "Felder" durch "Feldkombinationen".

Post by Ulrich MÃ¶ller
Ob die verwendeten Tabellen in einer Abfrage aktualisierbar
sind, hat auch etwas mit dem verwendeten Treibern und der
Reihenfolge des Einbindens der beteidigten Basistabellen zu tun,
Stichwort rechts-/linksseitig. Ist aber nicht so entscheidend,
man kann ja immer noch einen Insert/Update auf die zugrunde
liegenden Tabellen machen.

... aber das ist natürlich fummeliger.

--
Mit freundlichen Grüßen
Lars P. Wolschner

Ulrich Möller

2013-11-21 19:23:05 UTC

Indizes für Sichten, also gespeicherte Abfragen? Wie soll das
gehen?

siehe http://msdn.microsoft.com/de-de/library/ms191432.aspx

Post by Lutz
Macht es Sinn nach der Verknüpfung noch Primärschlüssel oder
Indizes anzulegen?

Indizes kannst Du problemlos für echte Datenbanktabellen im Server
anlegen.

Das ist mir so nicht verständlich, da müßtest Du mal genauer
erläutern, wie Deine Prüimärschlüssel in den Acces-Tabellen und
wie jene in den auf dem Server lagernden Tabellen sind.

Primärschlüssel über Datenbanken zu verknüpfen gibt überhaupt keinen Sinn.

Post by Lutz
Welche Erfahrungen bzw Empfehlungen habt ihr zu diesem Thema?

Access kann datenbankübergreifende Abfragen durchführen. Schnell
ist das nicht, denn Indizes der auf dem Server lagernden und mit
Access verknüpften Tabellen können dabei natürlich nicht genutzt
werden. Nur die auf dem Server befindlichen Sichten nutzen die
Indizes der ebenfalls auf dem Server befindlichen Tabellen.
Deshalb sollte man möglichst nur einfach gehaltene Sichten
einbinden, die evtl. schon die Filterung des größten Teils der
gewünschten Datensätze übernehmen. Das läuft dann auf dem Server
und Access muß weniger Datensätze verarbeiten. Nachteil: Bei
größeren Projekten explodiert die Zahl dieser Sichten, weil man
häufig verschiedene Filterungen und Sortierungen der gleichen
elementaren Tabellen(verbindungen) benötigt.

Dafür gibt es WHERE und ORDER BY, die dann auf eine generelle Sicht
angewendet werden. Man legt nicht so ohne weiteres nur für
unterschiedliche Sortierungen eine neue Sicht an bzw. man verwendet
'Stored procedures' mit Parametern.

Ersetze "Felder" durch "Feldkombinationen".

... aber das ist natürlich fummeliger.

ja klar.

Ulrich

Lars P. Wolschner

2013-11-21 20:03:22 UTC

=?ISO-8859-15?Q?Ulrich_M=F6ller?=

Post by Lutz
Kann ich diesen Vorteil problemlos nutzen oder muss
ich aufpassen, daß sich die lokalen und Server-Indizes nicht
gegenseitig ausbremsen oder behindern. Aufpassen muss ich zum
Beispiel bei einem lokalen Primärschlüssel - passt der nicht
zu den Daten der verknüpften Sicht, verschwinden auch schon
mal Datensätze ...

Das ist mir so nicht verständlich, da müßtest Du mal genauer
erläutern, wie Deine Prüimärschlüssel in den Acces-Tabellen und
wie jene in den auf dem Server lagernden Tabellen sind.

Primärschlüssel über Datenbanken zu verknüpfen gibt überhaupt keinen Sinn.

Doch, das kann schon Sinn machen. Wenn man beispielsweise eine
Daten-MDB exportiert und deren Inhalt nachher zu Prüfzwecken
wieder mit dem übrigen Datenbestand verknüpfen möchte. Desgleichen
hat man auch gerne mal bei Migrationen.

Besonders häufig kommt das aber beim MSSQL-Server vor, nur daß die
Datenbanken hier als Katalog bezeichnet werden. Meistens wird
zuerst für jedes Projekt ein eigener Katalog verwendet; später
realisiert man dann, daß beispielsweise die Daten über Organisa-
tion und Personal auch in beinahe jedem anderen Projekt des
Unternehmens berücksichtigt werden müssen. Katalogübergreifende
Join-Ausdrücke sind zwar möglich, aber es lassen sich keine
katalogübergreifenden Fremdschlüsselbeziehungen hinterlegen. Und
in einer DAO-basierten Access-Anwendung wird für jeden Katalog ein
eigenes DAO.Database-Objekt fällig. Was für Dich "überhaupt keinen
Sinn ergibt", ist anderswo Alltag.

Access kann datenbankübergreifende Abfragen durchführen.
Schnell ist das nicht, denn Indizes der auf dem Server
lagernden und mit Access verknüpften Tabellen können dabei
natürlich nicht genutzt werden. Nur die auf dem Server
befindlichen Sichten nutzen die Indizes der ebenfalls auf dem
Server befindlichen Tabellen.
Deshalb sollte man möglichst nur einfach gehaltene Sichten
einbinden, die evtl. schon die Filterung des größten Teils der
gewünschten Datensätze übernehmen. Das läuft dann auf dem
Bei größeren Projekten explodiert die Zahl dieser Sichten, weil
man häufig verschiedene Filterungen und Sortierungen der
gleichen elementaren Tabellen(verbindungen) benötigt.

Dafür gibt es WHERE und ORDER BY, die dann auf eine generelle
Sicht angewendet werden. Man legt nicht so ohne weiteres nur für
unterschiedliche Sortierungen eine neue Sicht an bzw. man
verwendet 'Stored procedures' mit Parametern.

WHERE und ORDER BY werden dann aber durch Access ohne die Indices
der Servertabelle durchgeführt - das *kann* zu langsam sein.

Und stored prodedures sind trotz Parametrierungsmöglichkeit auch
stark chaosgeneigt. In der Praxis kommt man schnell an den Punkt,
an dem die gegebene Parametrierung plötzlich nicht mehr ausreicht
und zusätziche Parameter hermüssen. Das erfordert dann aber
meistens auch eine Anpassung aller anderen Aufrufer auf dem Server
und im VBA-Code. Und wenn das SQL in der stored procedure wegen
der Parametrierung erst noch zusammengesetzt werden muß, entfällt
sogar der Vorteil der "Vorkompilierung" der Abfrage.

--
Mit freundlichen Grüßen
Lars P. Wolschner

Siegfried Schmidt

2013-11-22 13:34:59 UTC

Post by Lars P. Wolschner
In der Praxis kommt man schnell an den Punkt,
an dem die gegebene Parametrierung plötzlich nicht mehr ausreicht
und zusätziche Parameter hermüssen. Das erfordert dann aber
meistens auch eine Anpassung aller anderen Aufrufer auf dem Server
und im VBA-Code.

Unnötig, dafür gibts Default-Parameter und überladene Funktionen, ersters
auch in VBA.

Post by Lars P. Wolschner
Und wenn das SQL in der stored procedure wegen
der Parametrierung erst noch zusammengesetzt werden muß, entfällt
sogar der Vorteil der "Vorkompilierung" der Abfrage.

Das hängt davon ab, welche der vielen Möglichkeiten zur Darstellung einer
serverseitigen Abfrage genutzt wird. Wenn sie nur aus Regeln besteht die
den späteren SQL-Ausdruck ändern, gibts keine Vorkompilierung und bei einer
materialized View ist der Server an dem Punkt längst vorbei.

Siegfried

Siegfried Schmidt

2013-11-22 09:40:22 UTC

Post by Lars P. Wolschner
Indizes für Sichten, also gespeicherte Abfragen? Wie soll das
gehen?

Aus Serversicht ist es nicht notwendig, dass ein Frontend mitbekommen
muss, dass etwas dass wie eine Tabelle aussieht und sich so verhält in
Wirklichkeit eine Sicht ist. Also kann das Frontend damit machen was
immer es für nötig hält, sich also auch einen lokalen Index bauen -
insbesondere wenn es aufgrund seiner Grid-Logik darauf angewiesen ist,
dass ein eindeutiger Schlüssel existiert.

Post by Lars P. Wolschner
Indizes kannst Du problemlos für echte Datenbanktabellen im Server
anlegen.

Problemlos ist das nicht, da Access beim Einbinden versucht die
bestehenden Indizes von Tabellen herauszubekommen und ein hartes Limit in
der Anzahl setzt. Bei Überschreitung geht es gar nicht anders, als
anstatt der Tabelle eine Sicht zu nehmen.

Post by Lars P. Wolschner
Selbst richtige Datenbankserver können ganz schnell nicht mehr
aktualisieren, wenn durch irgendwelche Verknüpfungen eingebundene
Tabellen in der Sicht mitspielen. Ich habe sowas in VBA
realisiert, aber mein System kann sein Modell der
Tabellenbeziehungen auch Verbindungs-, also auch "Datenbank"-
übergreifend aufbauen und die möglicherweise abweichenden SQL-
Syntaxen auseinanderhalten. Es ist sehr umfangreich und
kompliziert.

Normalerweise hinterlegt man entsprechende Regeln in den Sichten wenn man
eine Aktualisierung wünscht, denn interne Details der Datenstruktur haben
auf einem Frontend nichts zu suchen und schon gleich gar nicht müssen
aufwändige Details in einem spezizellen Frontend abgewickelt werden.

Post by Lars P. Wolschner
Das ist mir so nicht verständlich, da müßtest Du mal genauer
erläutern, wie Deine Prüimärschlüssel in den Acces-Tabellen und
wie jene in den auf dem Server lagernden Tabellen sind.

Ganz einfach: Access benutzt seine eigenen Indizes immer vorrangig, hat
bei eingebundnen Tabellen aber kein Chance, die Randbedingungen über
Contraints abzusichern. So ist es durchaus möglich, lokale
Primärschlüssel auf nicht eindeutige Spalten zu legen - mit den
entsprechenden Folgeproblemen.

Siegfried

Ulrich Möller

2013-11-22 15:05:28 UTC

Post by Lars P. Wolschner
Indizes für Sichten, also gespeicherte Abfragen? Wie soll das
gehen?

Post by Lars P. Wolschner
Indizes kannst Du problemlos für echte Datenbanktabellen im Server
anlegen.

Hallo Siegfried,

besser hätte man das nicht beschreiben können. Ich stimme dir vollauf zu.

Ulrich

Lars P. Wolschner

2013-11-22 18:36:36 UTC

Post by Lars P. Wolschner
Selbst richtige Datenbankserver können ganz schnell nicht mehr
aktualisieren, wenn durch irgendwelche Verknüpfungen
eingebundene Tabellen in der Sicht mitspielen. Ich habe sowas
in VBA realisiert, aber mein System kann sein Modell der
Tabellenbeziehungen auch Verbindungs-, also auch "Datenbank"-
übergreifend aufbauen und die möglicherweise abweichenden SQL-
Syntaxen auseinanderhalten. Es ist sehr umfangreich und
kompliziert.

Normalerweise hinterlegt man entsprechende Regeln in den Sichten
wenn man eine Aktualisierung wünscht, denn interne Details der
Datenstruktur haben auf einem Frontend nichts zu suchen und
schon gleich gar nicht müssen aufwändige Details in einem
spezizellen Frontend abgewickelt werden.

Normalerweise nutzt man einen Anwendungsserver, der "aufwendige
Details" auch nicht in einem Datenbankserver abwickelt wie Du es
anscheinend vorschlägst. Man muß sich nach Deinen recht
allgemeinen und pauschalen Aussagen wundern, warum die überhaupt
entwickelt wurden, wenn man doch alles mit ein paar "Regeln in
Sichten" oder Default-Parametern für stored procedures hinkriegt.

Wenn man nur über MS Access und einen MS SQL-Server verfügt, steht
man vor dem Problem, daß sich T-SQL nicht zur Realisierung
halbwegs realer Datenmodelle eignet so wie beispielsweise Oracles
voll ausgestattete, modulare und objektorientierte Programmier-
sprache PL/SQL. Schon mit VBA läßt sich wartbarerer Code erzeugen
als mit T-SQL und ich behalte mit meinem System immerhin noch die
Möglichkeit, den Datenbankserver zu wechseln.

Klar wäre ein Anwendungsserver und dazu passende Client-Software
die "richtige" Lösung, aber das Ausrollen einer neuen MS Access-
Anwendungs-*.mdb bzw. -*.accdb bekommt man gut genug gelöst; die
Erstellung wartbaren Codes dagegen ist ein sehr großes Problem,
für das man gewiß nicht zu T-SQL greift. Meine Güte.

--
Mit freundlichen Grüßen
Lars P. Wolschner

Siegfried Schmidt

2013-11-22 20:03:33 UTC

Post by Lars P. Wolschner
Normalerweise nutzt man einen Anwendungsserver, der "aufwendige
Details" auch nicht in einem Datenbankserver abwickelt wie Du es
anscheinend vorschlägst.

Das schlage ich nicht vor, die Implementation und Durchsetzung eines
Datenmodells ist die ureigenste Aufgabe eines Datenbankservers und nur er
verfügt über die Sprachmittel dies sicherzustellen.

Allein schon deshalb, weil es für die Integrität und Sicherheit der Daten
völlig egal sein MUSS, ob ein Zugriff auf über ein beliebiges Frontend,
ein Frontend mit speziellen Fähigkeiten, ein Serverwerkzeug oder einen
Applikationsserver erfolgt.

Das man von diesen Grundsätzen abweichen kann oder muss wenn die Systeme
an ihre Belastungsgrenzen kommen oder durch andere Zwänge steht auf einem
anderen Blatt.

Post by Lars P. Wolschner
Man muß sich nach Deinen recht
allgemeinen und pauschalen Aussagen wundern, warum die überhaupt
entwickelt wurden, wenn man doch alles mit ein paar "Regeln in
Sichten" oder Default-Parametern für stored procedures hinkriegt.

Bestimmt nicht um die Beschreibbarkeit von Sichten zu implementieren.

Post by Lars P. Wolschner
Wenn man nur über MS Access und einen MS SQL-Server verfügt, steht
man vor dem Problem, daß sich T-SQL nicht zur Realisierung
halbwegs realer Datenmodelle eignet so wie beispielsweise Oracles
voll ausgestattete, modulare und objektorientierte Programmier-
sprache PL/SQL.

Für eine gute Problemlösung braucht man Variablen, z.B. die Wahl des
passenden Werkzeugs. Beraubt man sich dieser Möglichkeit, muss man eben
die Schraube mit dem Hammer einschlagen - das bedeutet aber nicht dass
man dies immer so tun muss.

Post by Lars P. Wolschner
Schon mit VBA läßt sich wartbarerer Code erzeugen
als mit T-SQL und ich behalte mit meinem System immerhin noch die
Möglichkeit, den Datenbankserver zu wechseln.

Umd warum sollte man mit diesem Wissen jetzt ausgerechnet einen MS-SQL-
Server als bevorzugtes Werkzeug einsetzen wollen?

Siegfried

Lars P. Wolschner

2013-11-23 07:23:51 UTC

Post by Lars P. Wolschner
Normalerweise nutzt man einen Anwendungsserver, der "aufwendige
Details" auch nicht in einem Datenbankserver abwickelt wie Du
es anscheinend vorschlägst.

Das schlage ich nicht vor, die Implementation und Durchsetzung
eines Datenmodells ist die ureigenste Aufgabe eines
Datenbankservers und nur er verfügt über die Sprachmittel dies
sicherzustellen.

Nein, das ist falsch. Der Datenbankserver eignet sich vor allem
dazu, die Integrität der Tabellenbeziehungen und mengenbezogene
Eindeutigkeiten zu überwachen. Zum Datenmodell einer Anwendung
gehören aber auch noch viele andere Eigenschaften, wie etwa
Verhältnisse der Felder eines Datensatzes untereinander. Und kann
ein Datenbankserver datenbereichsbezogene Berechtigungen aufnehmen
und überwachen? Datenbankserver implementieren vor allem möglichst
performante Persistenz, sonst nichts.

Post by Lars P. Wolschner
Wenn man nur über MS Access und einen MS SQL-Server verfügt,
steht man vor dem Problem, daß sich T-SQL nicht zur
Realisierung halbwegs realer Datenmodelle eignet so wie
beispielsweise Oracles voll ausgestattete, modulare und
objektorientierte Programmier- sprache PL/SQL.

Für eine gute Problemlösung braucht man Variablen, z.B. die Wahl
des passenden Werkzeugs. Beraubt man sich dieser Möglichkeit,
muss man eben die Schraube mit dem Hammer einschlagen - das
bedeutet aber nicht dass man dies immer so tun muss.

Naja, im Leben hat man nun mal nicht immer die Variablen, die man
sich wünscht. Davon abgesehen würde die "übliche" Applikations-
serverlösung ja auch nur den MS Access-Client ändern: Im Extrem-
fall bliebe für den Endnutzerdesktop nur noch der Browser, während
die Applikationslogik vollständig durch die Programmierung des
Anwendungsservers implementiert würde.

--
Mit freundlichen Grüßen
Lars P. Wolschner

Ulrich Möller

2013-11-23 12:01:52 UTC

Post by Lars P. Wolschner
Normalerweise nutzt man einen Anwendungsserver, der "aufwendige

Post by Lars P. Wolschner
Details" auch nicht in einem Datenbankserver abwickelt wie Du
es anscheinend vorschlägst.

Das schlage ich nicht vor, die Implementation und Durchsetzung
eines Datenmodells ist die ureigenste Aufgabe eines
Datenbankservers und nur er verfügt über die Sprachmittel dies
sicherzustellen.

Hallo Lars,

ich muß hier leider widersprechen. Gelegentlich habe ich mit DB-Servern
zu tun, in denen eine komplette Industrieanlage/Fertigungsanlage als
Datenmodell hinterlegt ist, wie Siegrfried das schon beschrieben hat.
Das dort hinterlegte Regelwerk ist für die komplette Durchsetzung und
Überwachung aller möglichen Abläufe in der Anlage verantwortlich und
stellt die Datenintegrität sicher. Dieses sogenannte, zugegebenermaßen
sehr komplex Regelwerk ist wie in "Beton" gegossen und bringt manchen
Programmierer, der mit so einer DB arbeiten muß, leicht zur
Verzweiflung, weil er natürlich diese Regeln nicht übersteuern kann.
Könnte er das, währen Schäden in Millionenhöhe durch Produktionsausfall
oder schlichtweg durch Beschädigung der Anlage möglich.
Die "Action" in so einem Modell kommt dann von einem Anwendungsserver
und am Client werden dann Daten zur Überwachung angezeigt oder Aktionen
eingeleitet.

Du siehst, es gibt auch andere Szenarios und glaube mir, dort wird auch
nichts oop mäßiges verwendet. Das wäre viel zu langsam. VBA oder Basic
im Allgemeinen ist für die Client-Programmierung auch nicht zugelassen -
da wird man schon am Pförtner wieder abgewiesen. Gängige
Programmiersprachen sind C, C++, JAVA, Delphi und in letzter Zeit auch
ein wenig C#. Einen Access-Client habe ich dort noch nie gesehen.

Ulrich

Siegfried Schmidt

2013-11-23 13:11:35 UTC

Post by Lars P. Wolschner
Zum Datenmodell einer Anwendung
gehören aber auch noch viele andere Eigenschaften, wie etwa
Verhältnisse der Felder eines Datensatzes untereinander. Und kann
ein Datenbankserver datenbereichsbezogene Berechtigungen aufnehmen
und überwachen?

Natürlich, welche der dazu nötigen Eigenschaften vermisst du denn und
willst du dich wirklich auf die "Sicherheit" eines clientseitigen
Rechtesystems verlassen?

Post by Lars P. Wolschner
Datenbankserver implementieren vor allem möglichst
performante Persistenz, sonst nichts.

Es ist immer möglich solche eingeschränkte System zu bauen. Nur tun muss
man es nicht unbedingt.

Post by Lars P. Wolschner
Naja, im Leben hat man nun mal nicht immer die Variablen, die man
sich wünscht.

Also sorry. So wertvoll und alleinstehend ist ein SQL-Server-Software nun
wirklich nicht, dass man sich vorab auf ein ungeeignetes Exemplar
festlegen muss. Glücklicherweise gibt es genug Alternativen - wenigstens
solange man sich auf "Augenhöhe" eines MS-SQL-Servers bewegt.

Post by Lars P. Wolschner
Davon abgesehen würde die "übliche" Applikations-
serverlösung ja auch nur den MS Access-Client ändern: Im Extrem-
fall bliebe für den Endnutzerdesktop nur noch der Browser, während
die Applikationslogik vollständig durch die Programmierung des
Anwendungsservers implementiert würde.

Du hast es falsch verstanden. Die Implementation des kompletten
Datenmodells im DB-Server ist keine Einschränkung, sie *ermöglich* im
Gegenteil die parallele Verwendung beliebiger Frontends, *ohne* dass
deswegen für die Datensicherheit und -integrität kritische Programmteile
x mal erstellt und parallel gepflegt werden müssen. Dabei ist es völlig
egal, welche Applikationslogik(en) zum Einsatz kommen, alle haben die vom
Server zur Verfügung gestellten Schnittstellen zu nutzen und nicht selbst
zu wursteln.

Siegfried

Lutz

2013-11-22 08:42:35 UTC

Nochmal zur Veranschaulichung, was ich meine. Hab das Gefühl es ist noch
etwas unklar. Ich rede nicht von indizierten Sichten auf dem SQL-Server.
Es geht um ganz normale Sichten ohne eigene Indizes.

Diese verknüpfe ich im Access:

Do Until rs.EOF
sSrcSchema = Nz(rs!ObjSchema, "")
sSrcName = Nz(rs!ObjName, "")
sLocalName = Nz(rs!ObjAlias, "")
nSrcType = Nz(rs!ObjType, acTable)
sSrcPrimary = Nz(rs!ObjPK, "")

sSrcPath = sSrcSchema & "." & sSrcName
sPkIndexName = "PK_UI_" & sLocalName

CurrentDb.TableDefs.delete sLocalName

Set tdf = CurrentDb.CreateTableDef(sLocalName, 0&, sSrcPath, sConnect)
dbs.TableDefs.Append tdf
'Index zur Sicht erzeugen
If nSrcType = acQuery Then
If sSrcPrimary <> "" Then
sql = "CREATE UNIQUE INDEX " & sPkIndexName & " ON " & _
sLocalName & "(" & sSrcPrimary & ") WITH PRIMARY"
CurrentDb.Execute sql, dbFailOnError
End If
End If

rs.MoveNext
Loop

Im Abschnitt 'Index zur Sicht erzeugen' erstelle ich gegebenenfalls
einen lokelen PK auf das Objekt mit den Feldern aus sSrcPrimary (z.B.
"ID,NR")

Für Access ist die verknüpfte Sicht im Prinzip ein Tabellenobjekt. Da
sie nicht auf dem Server indiziert sind, haben sie nach dem Verknüpfen
keinerlei Schlüssel/Indizes.
Nutze ich dieses in einem Join einer Access-Abfrage dann kann es
vorkommen, daß diese durch fehlende Primärschlüssel nicht bearbeitbar
und als Formulardatenquelle nicht nutzbar ist.
Deshalb lege ich bei bestimmten Objekten einen lokalen PK im Access-FE
an, der natürlich auch zu den Daten passen muss.
Ich kann sie nun wie eine normale verknüpfte Tabelle benutzen.

Meine Frage war ob die Nutzung des lokalen Schlüssels und der
Ausführungsplan der Sicht auf dem Server sich gegenseitig eher behindern
oder ob das kein Problem darstellt?

Die sauberste Lösung wäre wahrscheinlich diese Sichten auf dem Server zu
inidizieren - allerdings muss ich dann mit Schemabinding arbeiten, was
Änderungen an den zugrundeliegenden Tabellen/Sichten verhindert bzw
erschwert. Dafür müsste ich mir dann eine effektive Lösung suchen ...

Lutz

-------------------------------------------------------
Ein vereinfachtes Beispiel:

CREATE VIEW dbo.a_digipen_aufkz
AS
SELECT
dbo.DB_AUFTRAG.ID, dbo.DB_AUFTRAG.AUFUSER, dbo.DB_AUFTRAG.KENNER + ' ' +
dbo.DB_AUFTRAG.ZAEHLER AS AUFKZ,
dbo.DB_PASSWD.NUTZ, dbo.DB_TERM_ANL.ANL_ID, dbo.DB_TERM_ANL.NR,
dbo.DB_TERM_ANL.BEZNR
FROM
dbo.DB_AUFTRAG LEFT OUTER JOIN
dbo.DB_TERM_ANL ON dbo.DB_AUFTRAG.ID = dbo.DB_TERM_ANL.AUF_ID LEFT OUTER
JOIN
dbo.DB_PASSWD ON dbo.DB_AUFTRAG.AUFUSER = dbo.DB_PASSWD.ID

Im Access:

Set tdf = CurrentDb.CreateTableDef("a_at_digipen_aufkz", 0&,
"dbo.a_at_digipen_aufkz", sConnect)

CurrentDb.Execute "CREATE UNIQUE INDEX PK_UI_a_at_digipen_aufkz ON
a_at_digipen_aufkz(ID) WITH PRIMARY"

Siegfried Schmidt

2013-11-22 10:00:54 UTC

Post by Lutz
Meine Frage war ob die Nutzung des lokalen Schlüssels und der
Ausführungsplan der Sicht auf dem Server sich gegenseitig eher
behindern oder ob das kein Problem darstellt?

Grundsätzlich ist das kein Problem. Nur wenn es zu langsam läuft schau dir
in den Logs die tatsächlich stattfindenen Abfragen an und suche dann einen
Ansatz zur Optimierung.

Wenn es die Zugriffsrechte erlauben kann es hilfreich sein, eine in einer
Sicht vorkommenden Spalte nicht direkt als Suchvorgabe zu verwenden,
sondern die dazugehörende Tabelle in einen Join mit der Sicht in die
Datenherkunft aufzunehmen.

Siegfried

KlausG

2013-11-27 11:04:28 UTC