Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Verknüpfte SQL-Server-Sichten in Access
22 views
Skip to first unread message
Lutz
Nov 21, 2013, 4:39:51 AM11/21/13
to
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
--
news.albasani.net
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
--
news.albasani.net
Ulrich Möller
Nov 21, 2013, 7:29:57 AM11/21/13
to
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
Nov 21, 2013, 2:02:40 PM11/21/13
to
=?ISO-8859-15?Q?Ulrich_M=F6ller?= <knob...@usenet.arcornews.de>:
> Am 21.11.2013 10:39, schrieb Lutz:
>> Ich verkn�pfe in meinen Access-Frontends (2003/2010) Tabellen
>> Wie sieht es aber bei verkn�pften Sichten aus?
Indizes f�r Sichten, also gespeicherte Abfragen? Wie soll das
gehen?
>> 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.
>> Angefangen hab ich damit, als es darum ging solche verkn�pften
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.
>> Kann ich diesen Vorteil problemlos nutzen oder muss
>> ich aufpassen, da� sich die lokalen und Server-Indizes nicht
>> 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.
>> 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.
> 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,
> 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
> Am 21.11.2013 10:39, schrieb Lutz:
>> 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.
>>
>> Bei Tabellen ist das alles kein Problem, da werden die
>> Wie sieht es aber bei verkn�pften Sichten aus?
Indizes f�r Sichten, also gespeicherte Abfragen? Wie soll das
gehen?
>> 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.
>> 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.
>> zusammenzubringen. Da traten Performance-Probleme auf bzw waren
>> solche gemischten Abfragen nicht aktualisierbar wegen fehlender
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.
>> Kann ich diesen Vorteil problemlos nutzen oder muss
>> 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.
>> Welche Erfahrungen bzw Empfehlungen habt ihr zu diesem Thema?
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.
> 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".
> 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.
--
Mit freundlichen Gr��en
Lars P. Wolschner
Lutz
Nov 22, 2013, 3:42:35 AM11/22/13
to
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"
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
Nov 22, 2013, 4:40:22 AM11/22/13
to
Lars P. Wolschner schrieb:
> 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.
> 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.
> Selbst richtige Datenbankserver kï¿œnnen ganz schnell nicht mehr
> aktualisieren, wenn durch irgendwelche Verknï¿œpfungen eingebundene
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.
> 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
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
> 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.
> 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.
> 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-
> realisiert, aber mein System kann sein Modell der
> Tabellenbeziehungen auch Verbindungs-, also auch "Datenbank"-
> Syntaxen auseinanderhalten. Es ist sehr umfangreich und
> kompliziert.
Normalerweise hinterlegt man entsprechende Regeln in den Sichten wenn man
> kompliziert.
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.
> 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
Siegfried Schmidt
Nov 22, 2013, 5:00:54 AM11/22/13
to
Lutz schrieb:
> 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
> 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?
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
Ulrich Möller
Nov 22, 2013, 10:05:28 AM11/22/13
to
besser hï¿œtte man das nicht beschreiben kï¿œnnen. Ich stimme dir vollauf zu.
Ulrich
Lars P. Wolschner
Nov 22, 2013, 1:36:36 PM11/22/13
to
Siegfried Schmidt <usen...@shivasoft.de>:
> Lars P. Wolschner schrieb:
>> Selbst richtige Datenbankserver k�nnen ganz schnell nicht mehr
>> aktualisieren, wenn durch irgendwelche Verkn�pfungen
> 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.
> Lars P. Wolschner schrieb:
>> 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-
>> in VBA realisiert, aber mein System kann sein Modell der
>> Tabellenbeziehungen auch Verbindungs-, also auch "Datenbank"-
>> 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
>> kompliziert.
>
> Normalerweise hinterlegt man entsprechende Regeln in den Sichten
> 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.
Siegfried Schmidt
Nov 22, 2013, 3:03:33 PM11/22/13
to
Lars P. Wolschner schrieb:
> 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.
> Man muￜ sich nach Deinen recht
> allgemeinen und pauschalen Aussagen wundern, warum die ï¿œberhaupt
Bestimmt nicht um die Beschreibbarkeit von Sichten zu implementieren.
> 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
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.
> Schon mit VBA lￜￜt sich wartbarerer Code erzeugen
Umd warum sollte man mit diesem Wissen jetzt ausgerechnet einen MS-SQL-
Server als bevorzugtes Werkzeug einsetzen wollen?
Siegfried
> Normalerweise nutzt man einen Anwendungsserver, der "aufwendige
> Details" auch nicht in einem Datenbankserver abwickelt wie Du es
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.
> 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.
> 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
> voll ausgestattete, modulare und objektorientierte Programmier-
> sprache PL/SQL.
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.
> 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
Nov 23, 2013, 2:23:51 AM11/23/13
to
Siegfried Schmidt <usen...@shivasoft.de>:
> Lars P. Wolschner schrieb:
>> Normalerweise nutzt man einen Anwendungsserver, der "aufwendige
>> Details" auch nicht in einem Datenbankserver abwickelt wie Du
>> es anscheinend vorschl�gst.
> 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.
>> Wenn man nur �ber MS Access und einen MS SQL-Server verf�gt,
>> steht man vor dem Problem, da� sich T-SQL nicht zur
> des passenden Werkzeugs. Beraubt man sich dieser M�glichkeit,
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.
> Lars P. Wolschner schrieb:
>> Normalerweise nutzt man einen Anwendungsserver, der "aufwendige
>> Details" auch nicht in einem Datenbankserver abwickelt wie Du
>
> 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
> Das schlage ich nicht vor, die Implementation und Durchsetzung
> eines Datenmodells ist die ureigenste Aufgabe eines
> 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.
>> 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
>> beispielsweise Oracles voll ausgestattete, modulare und
>> objektorientierte Programmier- sprache PL/SQL.
>
> 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
> bedeutet aber nicht dass man dies immer so tun muss.
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.
Ulrich Möller
Nov 23, 2013, 7:01:52 AM11/23/13
to
Am 23.11.2013 08:23, schrieb 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.
>
Hallo Lars,
>>> 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.
>
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
Nov 23, 2013, 8:11:35 AM11/23/13
to
Lars P. Wolschner schrieb:
> Zum Datenmodell einer Anwendung
> gehï¿œren aber auch noch viele andere Eigenschaften, wie etwa
> Verhï¿œltnisse der Felder eines Datensatzes untereinander. Und kann
Natï¿œrlich, welche der dazu nï¿œtigen Eigenschaften vermisst du denn und
willst du dich wirklich auf die "Sicherheit" eines clientseitigen
Rechtesystems verlassen?
> 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.
> 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.
> 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
> 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?
> 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.
> Naja, im Leben hat man nun mal nicht immer die Variablen, die man
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.
> 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
0 new messages