Gemeinsame Datenbank

[Art_hur]

Hi Leute,

sorry für meine späte Rückmeldung - mich hat es ziemlich "ausgerußt", ich war letztendlich eine Weile im Krankenhaus - was meine Prioritäten komplett neu geordnet hat. Das Projekt hat ein Kollege übernommen, ich hatte aber noch keine Gelegenheit, ihn dazu zu befragen.

@SQL-Rookie:
So richtig ist meine Frage noch nicht beantwortet - allerdings würde mich Dein Ansatz schon interessieren ...

Ciao Arthur

[SQL-Rookie]

Hi Leute,
@SQL-Rookie:
So richtig ist meine Frage noch nicht beantwortet - allerdings würde mich Dein Ansatz schon interessieren ...

Ciao Arthur

Hallo,Artur!

Also, im Prinzip hast Du ja bereits alles, was Du brauchst.
Ich gehe davon aus, dass der SQL Server in dem von Dir angesprochenen VPN eingebunden ist.

Wichtig ist nun, dass der Netzwerkzugriff vom SQL Server aktiviert ist (das ist meines Wissens standardmäßig bei der Express Version nicht der Fall)

http://msdn.microsoft.com/de-de/libr...v=sql.90).aspx


Nun musst Du in Deiner Anwendung nur noch den Connectionstring auf die Datenbank des Servers(SQL Server Instanz) setzen, und schon hast Du die Verbindung.

Server=myServerName\myInstanceName;Database=myData Base;User Id=myUsername;Password=myPassword;


Je nach Datenvolumen würde ich Dir raten, die Daten nicht mit einem SELECT direkt aus der Tabelle zu lesen sondern über eine Stored Procedure eine Vorselektion zu treffen, um nur die Daten über die Leitung zu schieben, die angefordert werden.

Das muss man dann mal testen, ob die Performance ausreicht. Bei mir funktioniert es einwandfrei.

Alternativ bliebe dann noch der Weg über Replikation. Aber ich würde erstmal probieren, ob die Performance des beschriebenen Weges ausreicht.

[hwoess]

Warum eine stored procedure zur Vorselektion? Es genügt, wenn man eine richtige WHERE-Klausel hat. Es wird ja das Statement zum Server geschickt, der zerlegt das Statement in einzelne Schritte und geht dann noch mit dem Optimizer drüber und dann liefert er das Ergebnis über die Leitung zurück. Da kommt immer nur das zurück, was man im SQL-Statement anfordert, nicht mehr und nicht weniger.

bye,
Helmut

[SQL-Rookie]

Warum eine stored procedure zur Vorselektion? Es genügt, wenn man eine richtige WHERE-Klausel hat. Es wird ja das Statement zum Server geschickt, der zerlegt das Statement in einzelne Schritte und geht dann noch mit dem Optimizer drüber und dann liefert er das Ergebnis über die Leitung zurück. Da kommt immer nur das zurück, was man im SQL-Statement anfordert, nicht mehr und nicht weniger.

bye,
Helmut

Wenn das so ist, dann bin ich bisher einem Irrtum erlegen. Ich meinte bis dato, eine SP ist schneller. Wieder was dazu gelernt ...

[defo]

Wenn das so ist, dann bin ich bisher einem Irrtum erlegen. Ich meinte bis dato, eine SP ist schneller. Wieder was dazu gelernt ...

Das ist ein verbreitetes Missverständnis.
Was braucht Zeit beim Datenzugriff durch den Client?
Das sammeln der Daten serverseitig
und
die Übertragung der Daten zum Client.


Eine SP die serverseitig Daten sammelt UND verarbeitet (und vielleicht noch ein kleines Ergebnis an den Client schickt) ist unschlagbar schnell. Das liegt nicht daran, das hier exklusive Zugriffsmethoden verwendet werden, sondern es liegt in der Natur der Sache.
Ein View, der ebenfalls Daten sammelt, aber keine Verarbeitung durchführt, kann ebenfalls schnell sein, weil durch geeignete Einschränkungen nur kleine Ergebnismengen aufgebaut und zum Client übertragen werden.
Ein Selectstatement ist dem View performancemäßig vergleichbar, es liegt lediglich nicht vorbereitet und benannt auf der Datenbank.

[SQL-Rookie]

Das ist ein verbreitetes Missverständnis.
Was braucht Zeit beim Datenzugriff durch den Client?
Das sammeln der Daten serverseitig
und
die Übertragung der Daten zum Client.


Eine SP die serverseitig Daten sammelt UND verarbeitet (und vielleicht noch ein kleines Ergebnis an den Client schickt) ist unschlagbar schnell. Das liegt nicht daran, das hier exklusive Zugriffsmethoden verwendet werden, sondern es liegt in der Natur der Sache.
Ein View, der ebenfalls Daten sammelt, aber keine Verarbeitung durchführt, kann ebenfalls schnell sein, weil durch geeignete Einschränkungen nur kleine Ergebnismengen aufgebaut und zum Client übertragen werden.
Ein Selectstatement ist dem View performancemäßig vergleichbar, es liegt lediglich nicht vorbereitet und benannt auf der Datenbank.

Vielen Dank für die Erläuterung.

Ich hab bisher immer gedacht, dass beim SELECT Statement zuerst alle Daten auf den Client übertragen werden und dann am Client erst die WHERE Klausel verbeitet wird. Ich bin mir ziemlich sicher, dass ich das mal irgendwo im www gelesen habe. Vor diesem Hintergrund habe ich etliche SP in meiner DB angelegt. Nun denn, jetzt ist es so ...

Eine SP auf dem SQL Server hat aber auch den Vorteil, dass, wenn im SELECT mal eine Änderung nötig ist, muss ich nicht erst die Applikation updaten, sondern kann das zentral auf dem Server. Evtl. wäre darüber nachzudenken, statt einer SP eine View zu nehmen. Damit hätte man dann eine strikte Trennung (View und SP) und das ganze wäre übersichtlicher.

[hwoess]

Ein überlegenswerter Punkt wäre da eher ein "prepared statement". Stored procedures holen ihren Geschwindigkeitsvorteil eigentlich genau dadurch, dass sie nur einmal kompiliert werden und bei jeder weiteren Verwendung der execution plan schon vorhanden ist. Klingt gut, ist es aber nicht immer. Wenn nämlich der execution plan auf Test- oder Startdaten beruht, kann das später, wenn mehr Daten in der Datenbank sind, komplett schlecht performen, wenn der execution plan mit ganz anderen Voraussetzungen erstellt wurde. Deswegen gibt es bei den stored procs auch das WITH RECOMPILE.

bye,
Helmut

[SQL-Rookie]

Ein überlegenswerter Punkt wäre da eher ein "prepared statement".

Hallo, Helmut!

Danke für die Erläuterung.
Das mit den Prepared Statements ist mir völlig neu, aber scheint ja genau für diesen Zweck zu sein.
Mal zwei Rückfragen:

1. Muss die "prepared" Eigenschaft beim ersten Aufruf auf true gesetzt werden und dann auf false? Das wäre aber umständlich, oder?

2. Über die Stored Procedures habe ich einen guten Überblick im Management Studio. Aber wie sehe ich die Prepared Statements? Kann ich die auch im im Management Studio verwalten, oder muss ich immer über die Anwendung die prepared statements pflegen.

(irgendwie blöd ausgerdückt, aber ich hoffe, Du verstehst mich)

Danke
Marco

[hwoess]

Das mit den prepared statements findet in der Applikation statt und da kann nichts mit dem Management Studio getan werden.
Das ist eher so: du hast in deiner Anwendung eine Liste mit Aufträgen und wenn man einen Auftrag auswählt werden automatisch in einer Tabelle darunter die einzelnen Positionen angezeigt. Dazu verwendest du ein SQL-Statement in der Form "select * from positionen where auftragsnummer = @Nummer". Der Server hat also immer das Gleiche zu tun, es ändert sich nur die Auftragsnummer. Wenn man das Statement zuerst "prepared", dann kompiliert der Server das Statement und merkt sich das mit dem Parameter und schickt der Anwendung sowas wie ein SQL-Handle zurück. Die Anwendung schickt, wenn man dann das Statement das nächste mal aufruft, statt dem Statement das Handle und den Parameterwert an der SQL-Server und der braucht jetzt nichts mehr zu kompilieren sondern kann sofort den Ausführungsplan hernehmen, setzt den Parameterwert ein und ab geht die Post. Die Ergebnismenge kann zwar nicht schneller übertragen werden, aber wenn das Statement etwas komplexer und die Ergebnismenge klein ist, dann merkt man das schon ziemlich im Zeitverhalten.
Eine Query bleibt dann solange "prepared", bis man im Statement selber etwas ändert, dann wird der Handle verworfen und wieder das gesamte Statement an den Server geschickt.

bye,
Helmut

[tömmel]

Stored procedure bestechen u.a. auch dadurch, dasmm immr 'ran kommt' - ist auch manchmal ganz nützlich...