MSSQL Server mit 100 Clients

[Bernhard Geyer]

Zitat von Uwe Raabe:

Ein Sperren des Datensatzes zur Bearbeitung würde ich persönlich nicht realisieren. Das bringt mehr Probleme als es löst.

Es wird immer auf dem Anwendungsfall ankommen.
Wenn es normal ist das z.B. 1 Stunde auf einen Datensatz gearbeitet wird, wird man sich keine Freude machen, wenn der User erst nach 1 Stunde mitbekommt das seine Arbeit "für die Katz ist".
Ein Mergen der Änderungen wird für die meisten Nutzer zu komplex sein um Sie praktikabel zu Nutzen.

[Uwe Raabe]

Zitat von Bernhard Geyer:

Es wird immer auf dem Anwendungsfall ankommen.

Sicher.

Zitat von Bernhard Geyer:

Wenn es normal ist das z.B. 1 Stunde auf einen Datensatz gearbeitet wird, wird man sich keine Freude machen, wenn der User erst nach 1 Stunde mitbekommt das seine Arbeit "für die Katz ist".

Genauso wird der zweite Benutzer vielleicht knatschig, weil er seine Mini-Änderung eine Stunde lang nicht unterbringen kann. Wenn dieser andere Client eine Applikation ist, die nur ein eh automatisch verwaltetes Statusfeld aktualisieren will, kann das schon erhebliche Auswirkungen auf den Betriebsablauf haben.

Richtig spanned wird es dann, wenn zu dem Datensatz noch etliche abhängige Datensätze gehören, die womöglich noch alle mit gesperrt werden müssen.

Zitat von Bernhard Geyer:

Ein Mergen der Änderungen wird für die meisten Nutzer zu komplex sein um Sie praktikabel zu Nutzen.

Da stimme ich dir zu. Aus meiner Erfahrung sind aber in der Regel nur nicht-relevante Felder betroffen, da die Sachbearbeiter meistens nicht-überlappende Daten ändern. Hier kann man durch anwendungsspezifisches Setzen der ProviderFlags für jedes Feld schon einen Großteil der Kollisionen vermeiden. Das erfordert natürlich ein umfassendes Wissen über die Beziehungen der einzelne Felder untereinander. In der Praxis kommen dann echte Kollisionen kaum noch vor.

[timog]

Zitat von Uwe Raabe:

Hier kann man durch anwendungsspezifisches Setzen der ProviderFlags für jedes Feld schon einen Großteil der Kollisionen vermeiden.

Stichwort ProviderFlags bei FireDAC (wie ist das bei AnyDAC?): TUpdateMode (Wiki) im Auge behalten. In den Tokyo FireDACs steht der TUpdateMode z.B. im Standard auf upWhereKeyOnly - ein upWhereAll oder upWhereChanged wäre je nach Anforderung zu überlegen.

[trifid]

Die Frage war:
"Was ist hier der beste Ansatz, damit gegenseitiges Blockieren u.ä. verhindert wird ?"
Vielleicht hilft eine Diskussion über eine Architktur der Anwendung hier weiter, bevor man den Datenbankserver schlecht redet.

[jobo]

Zitat von trifid:

Vielleicht hilft eine Diskussion über eine Architktur der Anwendung hier weiter, bevor man den Datenbankserver schlecht redet.

Architekturfragen wurden bereits einige angesprochen.
Was meinst Du mit "schlechtreden"?
Eine Architektur lässt sich ohne Betrachtung der Servereigenschaften/-fähigkeiten nur unzureichend diskutieren.
Die Frage wäre m.E. eher, ob der TE zu seiner Frage noch ein paar Details liefert.

[Delphi.Narium]

Eventuell hilft auch erstmal eine grobe fachliche Beschreibung dessen, was realisiert werden soll.

Dann muss man sich das erforderliche Transaktionshandling mal anschauen.

Welche Datenmenge liegt insgesamt vor?
Wieviele Daten werden in welchem Zeitraum verändert?
Wie groß ist überhaupt die Wahrscheinlichkeit, dass bei Änderungen Konflikte auftreten? (Gemeinsam zu bearbeitende Schnittmenge?)

100 Clients, die hauptsächlich lesend auf die Daten zugreifen, dürften kaum das Problem sein.
100 Clients, die permanent alle Daten ändern, wohl schon eher.
Wo dazwischen müssen wir hier konkret die 100 Clients einordnen?

Jeder Client sollte soviel Daten wie nötig zeitgleich vorhalten und so wenig wie möglich.
Alles, was zur Änderung benötigt wird, sollte möglichst kurz auf dem Client vorgehalten werden.

[Hobbycoder]

In einem sehr großen Projekt vom mir habe ich das so gelöst, dass ich in den datenrelevanten Tabellen ein Feld vorgesehen habe, in welchem der aktuelle Username hinterlegt wird, welcher den Datensatz gerade zum Bearbeiten geöffnet hat.

Das hat für mich 3 Vorteile:

1. Bei eventuellem späterem Wechsel auf eine andere DB muss ich im Code wenig ändern und bin auch nicht davon abhängig, wie das in der DB gelöst ist.
2. Da ich den Datensatz eh für die Anzeige lesen muss, zeige ich dem User "vor" dem Bearbeiten an, dass dieser Datensatz nicht bearbeitet werden kann. (Lesen ich aber möglich)
3. Ich zeige ihm an welcher User diesen Datensatz blockiert, dann weiß er an wen er sich wenden muss und läuft nicht fragend von Büro zu Büro.

Um Probleme zu vermeiden wird beim Programmstart und beim Programmende alle Einträge des Users in besagtem Feld gelöscht, also alle Datensätze, die evtl. noch belegt sind, freigegeben.

Und zu guter Letzt gibt es im Programm dann noch eine Funktion einen evtl. fälschlich (durch Programmabsturz / Windows-Absturz / Stromausfall / etc.) belegten Datensatz manuell freizugeben, mit dem Hinweis wer zuletzt speichert hat gewonnen.

Damit fahre ich seit mehr als 10 Jahren in dieser Anwendung sehr gut und ohne Probleme für die User oder die Daten, bei bis zu 50 User und einigen 100.000 Datensätzen.

Ich muss aber dazusagen, dass ich nicht mit DB-Controls wie DBGrid etc. arbeite, sondern ausschließlich mit TObjectList's welche die Daten per Query lesen und schreiben.

[TigerLilly]

1) Selects immer(!) mit WITH NOLOCK
2) Transaktionen möglichst kurz und klein halten
3) Commit niemals dem User überlassen
4) Pro Tabelle einen PK (no na) und ein Feld SERIAL, das bei jeder Änderung durch den User von der Software hochgezählt wird. Beim Update kann man dann die Where Klausel auf den PK und eben dieses Feld beschränken, mit einem Index da drauf geht das auch flott.
5) Record vs Page vs Table Locking und Lock Escalation verstehen
6) Deadlocks verstehen

Das wars. MSSQL Server mit 100 Clients ist seit v2000 kein Problem.

[arnof]

Zitat von Bernhard Geyer:

Zitat von Uwe Raabe:

Ein Sperren des Datensatzes zur Bearbeitung würde ich persönlich nicht realisieren. Das bringt mehr Probleme als es löst.

Es wird immer auf dem Anwendungsfall ankommen.
Wenn es normal ist das z.B. 1 Stunde auf einen Datensatz gearbeitet wird, wird man sich keine Freude machen, wenn der User erst nach 1 Stunde mitbekommt das seine Arbeit "für die Katz ist".
Ein Mergen der Änderungen wird für die meisten Nutzer zu komplex sein um Sie praktikabel zu Nutzen.

Man sollte es auch so einstellen, das nur die geänderten Felder gespeichert werden und auch nur hier nach einem Konflikt geschaut wird. D.h. in der Praxis können mehrere Personen den gleichen Datensatz bearbeiten. Einer macht den Katalogtext, der andere die Preise, der nächste vielleicht Bilder.

So kann man den Mehrbenutzerzugriff auch realisieren. Wenn natürlich mehrere User das gleiche Feld bearbeiten (z.B. Preis) und auch noch was unterschiedliches reinschreiben, dann ist das natürlich Sinnfrei .....

Ansonsten muss man das aus vom Datenbankaufbau berücksichtigen: z.B. Bemerkungen, hier könnten gleichzeitig mehrer Benutzer was reinschreiben wollen, dann muss man den aufbau z.B. über eine 1zun Beziehung machen ......