2010-11-22 11 views
2

AKTUALISIERT 2010-11-25Wie mehrere Benutzer Zugang DBs auf einen einzigen SQLServer db

Ein Vermächtnis Stand-alone-Anwendung (A1) neu erstellt wird als Web-Anwendung (A2) migrieren.

A1 ist in Delphi 7 geschrieben und verwendet eine MS Access-Datenbank zum Speichern der Daten. A1 wurde an ~ 1000 aktive Benutzer verteilt, die wir während des Builds von A2 nicht kontrollieren können.

Die Datenbank hat ~ 50 Tabellen, von denen einige Benutzerdaten enthalten, von denen einige Vorlagendaten enthalten (die nicht kopiert werden müssen); 3-4 dieser Benutzertabellen sind größer (< 5000 Datensätze), der Rest ist klein (< 100).

Sobald A2 "live" ist, sollten Benutzer von A1 nach A2 migrieren können. Ich suche nach einem Vergleich der Szenarien dazu.

Eine Option besteht darin, ein eigenständiges Update-Tool für diese Benutzer zu entwickeln, und dieses Update-Tool über Webservices mit der A2-Datenbank zu kommunizieren. Eine andere Option ist, Benutzern zu erlauben, ihre Access db (~ 15 MB) -Datenbank auf unseren Server zu laden, irgendeine Art von SSIS-Paket (vielleicht über Nacht) auszuführen, um dies in A2 für diesen Benutzer zu bekommen, und die Access db zu löschen nachher.

Fehle ich Optionen? Welche Option ist "am besten" (ich verstehe, dass dies etwas subjektiv sein kann, aber hoffentlich können die Vor- und Nachteile des Szenarios zumindest deutlich gemacht werden).

Ich mache gerne ein Community-Wiki, wenn es so gewünscht wird.

UPDATE 2010-11-23: Es wurde vorgeschlagen, dass eine Variante des Szenarios 1 darin bestehen würde, dass das Aktualisierungstool/die Anwendung direkt mit der Produktionsdatenbank kommuniziert. Ist das machbar?

UPDATE 2011-11: Inzwischen ist dies in Produktion genommen worden. Benutzer laden die .zip-Datei hoch, in der sich die .mdb befindet, die entpackt und an einem sicheren Ort abgelegt wird. Ein nächtlicher SSIS-geplanter Job kommt mit und verschiebt die Daten in Staging-Tabellen, die dann durch SP in die Produktion verschoben werden.

+5

Meinst du es gibt 1000 dstinct Kopien von A1, jede mit ihren eigenen Daten? –

+0

@iDevlop: Ja, das tue ich. – Tobiasopdenbrouw

+0

@iDevlop: und natürlich werden von diesen Datenbanken nur die Daten importiert, die tatsächlich für jeden Benutzer benutzerdefiniert sind: generische/allgemeine Daten werden nicht transportiert. – Tobiasopdenbrouw

Antwort

2

Ich würde mich dazu neigen, die komplette Datenbank hochzuladen und die Konvertierung auf dem Server auszuführen.

In beiden Fällen müssen Sie ein Konvertierungsprogramm schreiben. Die eigentliche Frage ist, wie viel von der Conversion Sie auf den Computern der Kunden bereitstellen und ausführen. Ich würde diesen Teil so einfach wie möglich halten, d. H. Nur den Upload. Auf diese Weise können Sie, wenn Sie während der Konvertierung Fehler oder unerwartete Daten finden, einfach den Server aktualisieren und müssen Ihr Konvertierungsprogramm nicht erneut bereitstellen.

Die Gesamtmenge an Daten Sie sprechen werden, ist nicht zu groß zum Hochladen, und es klingt wie die meisten es auf jeden Fall hochgeladen werden müssten.

Wenn Sie ein Konvertierungsprogramm lokal installieren, benötigen Sie eine Möglichkeit zur Wiederherstellung einer Konvertierung, die auf halbem Wege angehalten hat. Das kann viel komplizierter sein, als einfach einen Upload der Access-Datenbank neu zu starten.

Sie geben auch nicht an, dass die Webdienste nach der Konvertierung benötigt werden. Der Aufwand, diese Dienste zusammenzustellen und sie während der Conversions in Betrieb und sicher zu halten, wäre weitaus mehr als eine einfache Upload-Anwendung oder ein Webformular.

Ein weiterer Faktor ist, wie schnell Ihre Kunden konvertieren würden. Wenn einige von ihnen die aktuelle Anwendung für einen bestimmten Zeitraum ausführen, müssen Sie möglicherweise Ihre Konvertierungsanwendung aktualisieren, da sich die Serverdatenbank im Laufe der Zeit ändert. Wenn Sie die Datenbank hochladen und die Konvertierung auf dem Server ausführen, muss nur das Serverkonvertierungsprogramm aktualisiert werden. Es besteht kein Risiko, dass ein Kunde das Konvertierungsprogramm herunterlädt, aber erst nach der Aktualisierung der Serverdatenbanken ausführt.

Wir haben einen ähnlichen Fall, in dem wir die Konvertierung auf dem Server ausführen. Wir haben eine Webseite erstellt, auf der der Benutzer seine Dateien hochladen kann. In diesem Fall wird für die neue Anwendung nichts bereitgestellt. Der einzige Nachteil ist, dass der Benutzer die richtige Datei auswählt. Wenn Sie ein Webformular für den Upload verwenden, können Sie den Dateinamen für den Benutzer aufgrund von Sicherheitseinschränkungen nicht vorab auswählen. In unserem Fall wussten wir, wo sich die Datei befand, aber die Kunden nicht. Wir geben auf der Upload-Seite Anweisungen für die Benutzer an, um ihnen zu helfen. Sie können dies vermeiden, indem Sie eine kleine Desktop-Anwendung schreiben, um den Upload für die Benutzer durchzuführen.

Der einzige Nachteil sehe ich eine Server-basierte Konvertierung zu schreiben, ist einige Ihrer Vorlage Daten werden hochgeladen, die nicht benötigte ist. Das ist sowieso eine kleine Menge an Daten.Pros

Server: - Keine Notwendigkeit, erneut bereitstellen die Umwandlung aufgrund von Fehlern, unerwartete Daten oder Änderungen an der Server-Datenbank - Einfacher zu sichern (möglicherweise), gibt es nur einen Zugangspunkt - der Upload . Natürlich akzeptieren Sie Kundendaten in Form einer Zugangsdatenbank, so dass Sie immer noch nicht darauf vertrauen können.

Server Nachteile: - Hochladen nicht benötigte Schablonendaten

Desktop-Profis: -? Ich habe Probleme mit jedem

Desktop-Cons kommen: - Kann mehrere Versionen benötigen

eingesetzt

Als direkt an einen Server-Datenbank zu sprechen. Ich habe eine Anwendung, die direkt mit einer gehosteten Datenbank kommuniziert, um die Erstellung von Webdiensten zu vermeiden. Es funktioniert gut, aber wenn ich die Chance hätte, würde ich diesen Weg nicht mehr nehmen. Das Internet wird regelmäßig gelöscht und die SQL-Provider erholen sich nicht sehr gut. Wir haben unsere Kunden geschult, nur um es erneut zu versuchen, wenn das passiert. Wir haben dies getan, um die Erstellung von Web-Services für unsere Desktop-Anwendung zu vermeiden. Wir verweisen nur auf die IP-Adresse in der Serververbindungszeichenfolge. Es gibt eine ganze Reihe von Sicherheitsgründen, diesen Weg nicht zu gehen - wir waren mit unserer Sicherheitseinrichtung und möglichen Risiken zufrieden. Am Ende war der Kompromiss, die Desktop-Anwendung ohne Änderungen zu verwenden, nicht wert, ein instabiles Produkt zu haben.

+1

Vielen Dank dafür. Wie es ist, wird dies wahrscheinlich das Kopfgeld bekommen. – Tobiasopdenbrouw

2

Da ein neuer Datenbankserver wahrscheinlich einer der Standard-Datenbank-Engines in der Branche ist, warum nicht in Betracht ziehen, die Access-Anwendung mit diesem Datenbankserver zu verknüpfen? Auf diese Weise können Sie einfach Ihre Daten auf diese Weise an SQL Server senden.

Ich bin mir nicht wirklich sicher, warum Sie sogar vorschlagen würden, eine Reihe von Web-Services für eine Datenbank-Engine zu verwenden, wenn der Zugriff eine ODBC-Verknüpfung zu dieser Datenbank-Engine unterstützt. Ein möglicher Upgrade-Pfad wäre also, einfach eine neue Anwendung im Zugriff zu erstellen, die im selben Verzeichnis wie die aktuelle Datei (und Anwendung) der aktuellen Datei abgelegt werden muss. Anschließend kann diese Anwendung beim Start alle Tabellen mit der vorhandenen Datenbank verknüpfen, außerdem wird ein Vorverbindungssatz von Tabellen zum Datenbankserver geliefert. Dies wird viel weniger Arbeit beim Aufbau einer Art von Web-Services-Ansatz sein. Ich nehme an, dass ein Teil davon darin besteht, wo die Datenbankserver gehostet werden, aber in den meisten Fällen, vielleicht während der Migrationsperiode, lässt sich der Datenbankserver irgendwo ausführen, wo jeder Zugriff darauf hat. Und viele Web-Provider erlauben jetzt externe Links zu ihrer Datenbank.

Es ist auch nicht klar, dass auf dem Datenbank-Server-System werden Sie separate Datenbanken für jeden einzelnen erstellen, oder wie Sie in Ihrem Titel vorschlagen, es wird alles in einer Datenbank platziert werden.Da es in einer Datenbank gespeichert wird, wird während des Upsizing eine zusätzliche Spalte hinzugefügt, die den Benutzerstandort identifiziert oder wie auch immer Sie die einzelnen Datenbanken unterscheiden möchten.

Wie einfach diese Art der Migration sein wird, hängt vom Schema und Datenbanklayout ab, das die Entwickler für das neue System verwenden. Hoffentlich und offensichtlich hat es Bestimmungen für jeden Benutzer oder Standort oder wie auch immer Sie planen, jeden einzelnen Benutzer des Systems zu unterscheiden. Ich schlage daher keine Webdienste vor, schlage aber vor, Tabellen aus der Access-Anwendung mit der SQL Server-Instanz (oder dem von Ihnen ausgeführten Server) zu verknüpfen.

+1

Die Legacy-App (A1) ist eine Delphi-App über der Benutzer-DB. (* 1000, wenn alle Benutzer berücksichtigt werden). Ihr Vorschlag würde beinhalten, die Delphi-App zu ändern (neue Version erforderlich oder Update-Hilfsprogramm, wie ich es in Option 1 vorschlage), das müsste dann für Benutzer erstellt und bereitgestellt werden). A1 ist (wahrscheinlich) nicht in einer vertrauenswürdigen Umgebung (soweit die neuen Anwendungsserver betroffen wären - sollte A1 direkt eine Verbindung herstellen dürfen?), So dass direkte Verbindungen zur Produktionsdatenbank problematisch sind. Individuelle Migrationen sollten nach dem Projekt durchgeführt werden. Und ja, eine Datenbank für alle, aspnet Mitgliedschaft für Benutzer-IDs. – Tobiasopdenbrouw

2

Wie dies am besten geschieht, hängt von der referenziellen Integrität und den Geschäftsregeln ab, die erzwungen werden müssen, falls solche vorhanden sind. Gibt es zum Beispiel die Möglichkeit von Duplikaten, wenn die Datenbanken zusammengeführt werden? Ich nehme an, sie werden von Ihrer etwas kryptischen Aussage zusammengeführt: "Und ja, eine Datenbank für alle, aspnet Mitgliedschaft für Benutzer-IDs".

+1

Ja, die Datenbanken werden zusammengeführt. Es sollte keine Gefahr von Duplikaten bestehen (in den Quell-DBs gibt es keine und das Hinzufügen von Benutzer-IDs verhindert Duplikate nach dem Zusammenführen).Die access db hat keine Beziehungen/Verweise definiert (es wird in der A1 App behandelt), das neue System wird ORM (Teleriks OpenAccess) mit richtig definierten Assoziationen verwenden. – Tobiasopdenbrouw

+2

Nur um klar zu sein, sagst du, dass jede der 50 Tabellen haben wird eine "Spiegel" -Tabellendefinition in der zusammengelegten Datenbank, und dass jede der Spiegeltabellen eine zusätzliche Spalte enthält, um die Quelle der Daten zu identifizieren, die in sie importiert wird (dh Quelle-1 bis Quelle ~ 1000), und diese zusätzliche Spalte wird Teil eines mehrteiligen Primärschlüssels in all diesen 50 Tabellen? Wenn dem so ist, folge ich nicht, wenn Sie sagen, dass "generische, gemeinsame Daten nicht transportiert werden". – Tim

+0

Ja, die benutzerspezifischen Daten (die eine Teilmenge der 50 Tabellen sind) werden in der von Ihnen angegebenen Weise transportiert. Die "generischen" oder "Template" -Daten (die übrigen Tabellen), die zur Erstellung der benutzerspezifischen Daten verwendet werden, sind bereits in der A2-Datenbank vorhanden und müssen nicht transportiert werden. – Tobiasopdenbrouw

2

Wenn Sie keine Kontrolle über die 1000 Benutzer von A1 haben, wie werden Sie sie alle auf A2 konvertieren?

Haben Sie darüber nachgedacht, ihnen eine SQL Server Express-Datenbank zu geben, auf die sie aktualisieren können, und sie die Webanwendung auf ihren eigenen Servern hosten lassen?

+1

Ich brauche nicht alle, um sie in A2 umzuwandeln - diejenigen, die weiterhin Legacy A1 verwenden möchten, können dies tun. Der SQL-Server express/hosting auf seinem eigenen Server ist eine interessante Lösung, aber der Kunde möchte mehr direkte Kontrolle und redaktionelle Fähigkeiten erlangen (einer der Treiber, um an einen zentralen Ort zu gelangen). – Tobiasopdenbrouw

Verwandte Themen