Hallo Forengemeinschaft,

ich habe hier mal eine grundlegende Frage.

Also wir haben hier in unserer Firma eine Windows 2003 SB-Server auf dem unter anderem ein Micrsoft-SQL Server installiert ist. Ich soll nun eine Anwendung entwickeln mit der unsere Mitarbeiter verschiedene Arbeitsabläufe erheblich beschleunigen können, siehe Telefonliste,Kreditoren überwachung, Kostenstellenanalyse usw. meine erste Idee war das ich diese Anwendung (bzw. die Datenbank der Anwendung) auf dem Microsoft-SQL Server mache. Wenn ich mich nun aber nicht falsch errinnere ist es doch so das wenn ich abfragen nur rein client seitig also von der workstation aus mache sehr traffic intensiv sind. Jetzt stellt sich mir die frage ist es dann nicht besser wenn ich die Firmensoftware in eine Client- und eine Serveranwendungen aufteile.

Quasie macht die Serveranwendung die SQL-Abfragen direkt auf dem 2003 Server und schiebt dann nur noch die Ergebnisse zur Clientanwendung. Die Clientanwendung schickt demzufolge dann auch nur noch die Abfragen und empfängt auch nur noch die reinen ergebnisse.

Meine Frage ist nun macht das denn sin. Ich bin über jedes bit glücklich das weniger übertragen wird. Da unsere Firma meherer Standorte in Deutschland hat die mit einer Standleitung verbunden sind (die stark ausgelastet ist) bin für andere Vorschläge sehr offen.

Generell ist eine C/S-Anwendung natürlich geschickter, vor allem aus Update-Gründen. Du brauchst im besten Fall nur den Server zu aktualisieren, die Clients haben kein Problem. Diese Konstellation ist besonders bei sehr vielen Clients und schlechten Verbindungen zu empfehlen. Im Gegensatz dazu steht der Aufwand. Denn Du musst die ganze Kommunikation selbst coden. Greift der Client direkt auf die Datenbank zu, brauchst Du Dich um das Protokoll dort nicht kümmern.
Du kannst also bei einer C/S-Architektur mit mindestens dem doppelten Aufwand rechnen.

Die Alternative dazu ist die direkte Verbindung. das bringt den Vorteil, dass Du z.B. auch keine so ausgefeilte Rechteverwaltung brauchst, denn das kannst Du per SQL-Server und AD größtenteils abdecken. Aber auch hier kannst Du optimieren und dafür sorgen, dass möglichst wenig Daten übertragen werden. Dazu musst Du nur so viele Funktionen wie möglich oder nötig in den SQL-Server integrieren, z.B. über Stored Procedures. Auch kann die richtige Datenbankmodellierung wahre Wunder bewirken. Wenn gar nichts mehr geht und intensive Berechnungen auf dem Client notwendig werden würden (z.B. Kostenanalyse) dann würde ich Dir empfehlen, regelmäßig laufende Skripts auf dem Server auszuführen, die die notwendigen Berechnungen durchführen und in entsprechend aufgeblähten Tabellen bereitstellen (nennt man meistens DataWareHouse ).

Um weitere Tipps geben zu können, müsste ich mehr wissen, z.B. wie die Leitungen aussehen und was abgefragt werden soll.

Danke erstmal für die schnelle Antwort.

So nun etwas mehr Daten zu dem Problem.

Es sind 4 Standorte und einer der Standorte ist die Hauptniederlassung.

Niederlassung A u. B haben eine MPLS 128 K-bit Priorisiert
Niederlassung C= MPLS-ADSL 768/128 nicht Priorisiert (Best offert)
Niederlassung D= 1 M-bit Priorisiert für die Niederlassungen A und. B

Die Leitung der Niederlassung a und b machen die größten Probleme. Da sie beinahe voll ausgelastet sind. Die Priorisierung teilt sich dort wie folgt auf.

1. Priorisierung ist für die Speditionssoftware (64 K-bit)
2. Priorisierung ist für die Sendungserfassung (32 K-bit)
3. die restlichen 32 K-bit werden für IP-Telefonie E-Mail Internet usw. genutzt. im schnitt habe ich also 8-32 K-bit zur Verfügung.

Über festgelegte Zeitfenster ist der E-Mailverkehr geregelt so das die Leitung nicht permanent mit Traffic belegt ist.

In der Niederlassung A sind es min. 8-15 User die auf das System zugreifen und in Niederlassung B sind es Max 20.

Die Kundendatenbank alleine wird ca. 30000 Kunden (ständig wachsend) beinhalten. Demzufolge auch die für die Kreditorenüberwachung und die Telefonliste etc.

Die Datenbankstruktur ist bereits so ausgelegt das die die Daten seqienziel auslesbar sind. Das heißt das bei der ersten abfrage werden nur Felder a,b,c gelesen und ausgewertet dann wird eine entsprechende Auswahl gesendet Verknüpfungen werden dann via Index angaben gesondert gelesen. So das nur ein Minimum an Datensätzen überhaupt erst übertragen werden. Ich habe bereits mit einigen Datenbanken test betrieben und bin auf die Problematik gestoßen das ich noch immer sehr große Datenmengen bekomme und die Abfragen zu lange dauern(bzw. die Übertragung der Ergebnisse). Der doppelte Aufwand sollte kein Problem sein da wie du sicherlich mitbekommen hast das Datenvolumen eine wesentlich größere Rolle spielt.

Die Zugriffskontrolle ist das geringere Problem da ich bereits einige Anwendungen geschrieben habe die auf die Useranmeldungen zugreifen und somit ist das unerheblich. Ich lege meine Benutzer bereits über eine eigens entwickelte Anwendung an da es mir so einfacher ist den Usern die entsprechenden Rechte für Ordner und Anwendungen zu zuweisen

Wenn du auch der Meinung bist das man so etwas über C/S Anwendung am besten regelt bitte ich dich um einige Anregungen für die Realisierung der Datenübertragung (ob Indy oder irgend welche andere Komponenten.) Ich habe bereits mit den von Delphi mitgelieferten Komponenten (TCP- Client/Server ) experimentiert doch denke ich das diese nicht die besten für eine solche Anwendung sind wie ist deine Meinung dazu?

Es besteht die möglichkeit auf dem Server wo die SQL Datenbankläuft ein PHP Server einzurichten und das Ganze Webseiten basiert zu machen Die PHP Script sind Server Seitig und werden auf dem Server ausgeführt es wird dann nachher nur die HTML Seite übertragen in der dann die Telefon liste etc. aufgeführt sein kann!

Wenn nicht alle daten von allen 30000 Kunden auf einmal anzeigen läst sonder geschickt mit where Klauseln arbeitet hält man den Träffic mindestens genauso gering wie bei einer C/S-Anwendung!

Außerdem bleibt das Problem der eigenen Syntax außen vor!

Und Php in verbindung mit SQL ist eigentlich ganz leicht!

OK, mit 32kBit siehts mit direkten Zugriff wirklich nicht besonders rosig aus. Aber je nachdem wieviel Daten Du immer übertragen musst, wirst Du Dich auch bei einer C/S-Architektur mit Wartezeiten auseinandersetzen müssen.
Die Alternative über PHP ist in diesem Fall nicht wirklich praktikabel, da ja in beide Richtungen Daten übertragen werden müssen. Und ich gehe nicht davon aus, dass die Anwender sich mit einer reinen Text-Oberfläche begnügen wollen, da sollte es schon ein bisschen Bedienerfreundlichkeit sein . Und ansonsten für jede Übertragung das ganze in 2 Programmiersprachen + SQL noch implementieren zu müssen halte ich nicht für besonders gut *g*.

Was mir eben noch eingefallen ist: Sollten die Daten nicht immer auf beiden Seiten absolut aktuell sein müssen und man Konflikte durch gemeinsamen Zugriff auf die gleichen Daten (also Änderungen) vermeiden können, dann gäbe es auch noch die Möglichkeit der Synchronisation. Will heißen, Du hast in A, B und der Hauptniederlassung einen SQl-Server und lässt diese sich nachts miteinander synchronisieren. Der Nachteil ist hierbei natürlich, dass Du nicht immer alle Daten absolut aktuell sind, Du musst dafür sorgen, dass Konflikte gelöst werden können und die Lizenzkosten sind höher. Dafür kannst Du aber beim Client mehr oder weniger aus dem vollen schöpfen und brauchst dort nicht viel zu optimieren.

Jetzt zur C/S: Ich bin im Moment selbst dabei so etwas in der Art zu machen, nur nicht beruflich . Mein Virtual Village (siehe Freeware-Sparte) ist auch ein C/S-Programm, ich habe nen Client, der sich zum Server bei mir zu Hause über DSL-Leitung verbindet. Im Hintergrund steht eine mysql-Datenbank. Die ganze Übertragung habe ich mit XML und den Indy-TCP-Komponenten geregelt. Meine Anfragen werden also in XML verpackt (ein Befehl mit evtl. Parameter), vom Server geparst und das Ergebnis wieder in XML verpackt zurückgeschickt (auch wieder ein Befehl mit den Ergebnisdaten). Das läuft auch ganz gut, selbst über diese kleine Leitung. Wenn Du dann noch eine Kompression einbaust (das habe ich jetzt nicht), dann dürftest Du auch mit 32k auskommen.

Der Vorteil meiner Befehlsorientierung besteht darin, dass ich eine sehr einfache Rechteverwaltung hinbekomme, mit der aber alles möglich ist. Das Problem bei der ganzen Sache ist dann, auf dem Server jeden Client in kürzester Zeit zu befriedigen. Ich habe das dann folgendermaßen gelöst:
Ich habe 2 Threads, einer enthält die ganzen Client-Daten, die verbunden sind und stellt den TCP-Server bereit. Er empfängt die Daten, prüft sie kurz und stellt sie dann in eine Queue.

Der andere Thread stellt das Herzstück dar. Dieser fragt die Queue laufend, ob neue Daten angekommen sind, wenn ja, werden diese verarbeitet. Der Knackpunkt bei der Sache ist die Überschneidung. Denn ab und zu braucht der Verarbeitungsthread natürlich weitere Daten aus der Client-Liste. Dieses habe ich über einen MultiReadExclusiveWriteSynchronizer gelöst, er bietet erweiterte Möglichkeiten zur Critical Section.

Erweitern könnte man das jetzt um eine weitere Queue, die die Antworten an den Client enthält, damit die Überschneidung geringer wird. Ein weiterer Vorteil bei mir ist, dass ich den Server sowohl unter Windows, als auch unter Linux erzeugen und laufen lassen kann. Sollte das für Dich relevant sein und Du es auch mit XML versuchen möchtest, kann ich Dich gleich darüber aufklären, dass Du da Probleme bekommen wirst. TXMLDocument kann man schon mal vergessen, da das einen X-Server unter Linux voraussetzt (bzw. die DOM-Implementationen davon). Das einzige was unter der Konsole läuft (was ich gefunden habe) ist XDOM. Ich habe mir daraufhin eine Wrapper-Klasse dafür geschrieben, die Aufrufe, die eigentlich für MSXML gedacht sind, auf XDOM ummappt (die Syntax von MSXML hat mir einfach gefallen und ich wollte auch nicht meine Anwendung umschreiben ). Sollte das für Dich relevant sein, kann ich evtl. diese Klasse Dir zukommen lassen.

Weitere Fragen? Fragen!

Hm also deine Ausführungen habe ich soweit verstanden. Die Idee mit der Synchronisation ist mir auch schon gekommen nur ist dieses nicht so ohne weiteres möglich da z.B. die Kreditorenüberwachung immer Aktuell sein muss. Denn es kann ja sein das die Niederlassung a und b am gleichen Tag einen Transport für Kunden C machen. Kunde C hat nun ein Kreditlimit von 20000€ das konto vom dem Kunden ist mit 19000€ Belastet jetzt kostet der Transport vom Kunden C bei Niederlassung a 800€ und der Transport von Niederlassung b 900€. Da ja nun die Daten nicht ständig aktuell sind bekomme ich erst einen Tagspäter mitgeteilt das der Kunde sein Kreditlimit überzogen hat. Das ist nicht praktikabel da bereits beim erfassen der Transportkosten die Kreditlimit Überschreitung angemahnt werden muss.

Also werde ich mich wohl dran machen und eine C/S Anwendung schreiben als erstes werde ich mich an das Server Konzept und die Befehlsverarbeitung machen. Und dann an die Verbindung zw. den beiden Systemen du sagst via INDY hm habe leiter noch net so sehr viel mit diesen Komponenten gearbeitet es wäre sehr nett wenn du mir sagen könntest welche Komponenten und was zu beachten ist. Ich weis hier im Forum gibt es sicherlich massen weise informationen dazu nur brauche ich einen Informationen welche Komponente ich nehmen muss und welche sachen in hinsicht auf die Komponenten zu beachten sind. Ich danke dir schonmal im voraus.

Also ich hab es mit den Indy-TCP-Komponenten (also Client und Server) gemacht. UDP ist wohl eher nicht zu empfehlen, da Du dort keine verbindungsorientierung hast und Pakete verloren gehen können. Außerdem kannst Du dann besser Transaktions-orientiert vorgehen.

Was bei den Indys etwas gewöhnungsbedürftig ist, ist dass jede Connection in einem eigenen Thread vom Server behandelt wird, d.h. Du musst in der Hinsicht die Synchronisation sicherstellen. Das nächste ist, dass Du auch den Empfang der Nachrichten beim Client selber machen musst, also immer wieder abfragen, ob neue Nachrichten da sind.

Du findest auch hier im Forum einige Fragen dazu. Bei speziellen Problemen kann ich oder jemand anders Dir auch evtl. mit Code weiterhelfen.

Besten Dank ich werde mich dann gleichmal ans coden machen danke für dein angebot ich werdee bei gelegenheit darauf zurück greifen.