Zentrale Adressdatenbank

[Vaultboy]

Hallo liebes Forum,


wir haben in unserem Unternehmen über die Jahre verschiedene Datenbanken angehäuft , die unterschiedliche Aufgaben erfüllen, die für die jeweilige Abteilung relevant sind. In den Datenbanken sind natürlich auch Adressdaten hinterlegt. Nun ist es so, dass Datenbank A Person A führt und Datenbank B auch Person A führt, aber mit unterschiedlichen Adressen. Will Abteilung C die Adresse haben , stellt sich die Frage, welcher Datensatz ist denn aktuell?
Die Idee ist, eine zentrale Adressdatenbank zu erstellen, die für Anschreiben und weiß der Geier was verwendet wird.
Die bestehenden Datenbanken holen sich dann zukünftig die Adressdaten des jeweiligen Datensatzes direkt aus der zentralen Adressdatenbank und nicht aus "eigener Datenhaltung". Dies würde natürlich bedeuten, dass die Datenbanken (liegen alle auf MS SQL Server 2008 r2) umgestrickt werden müssen, eben damit sie sich die Stammdaten aus der Adress-DB holen.
Wie würdet Ihr sowas angehen? Angefangen habe ich schonmal damit, dass ich eine Datenbank entworfen habe die eben Stammdaten von Personen und Instituten führt, dazu gepackt habe ich eine Gruppenverwaltung für Veteilerlisten bspw. Dann habe ich die Adressdaten aus der bisher größten Datenbank genommen und dort importiert. Diese werden durch eine Mitarbeiterin bereinigt.
Doch wie kriege ich es nun hin das die Personalverwaltungsdatenbank (oder welche auch immer) nun diese Stammdaten aus der AdressDB enthält? Evtl. über nen Trigger der die Adressdatensätze in der Personaldatensätze aktualisiert, sobald ne Änderung in der AdressDB eintritt? Wie würdet Ihr sowas machen?

Gruß Vaultboy

[Bernhard Geyer]

Ich würde sowas nicht selbst stricken sondern hier ein fertiges CRM-System einführen. Die "Altsysteme" bekommen dann täglich den Adressbestand des führenden CRM-Systems geliefert (sollte mit relativ wenig Code machbar sein), jedoch änderungen dürfen dort nicht mehr vorgenommen werden.

[Vaultboy]

Das CRM selbst löst aber gar nicht mein Problem sondern es geht ja nicht um das Instrumentarium (ich habe da ja schon selbst was entwickelt) sondern um das Anbinden der vorhandenen Datenbank an die neue Quelle. Ich müsste die ganzen Strukturen der einzelenen DBs ändern und da frage ich mich, wie kann man sowas mit dem geringsten Aufwand machen?

[O. Helper]

Ich würde in den anderen Datenbank ein View auf die zentrale Adressdatenbank einrichten.
Über einen vollqualifizierten Bezeichner kann man problemlos Datenbank-übergreifend selektieren, entsprechende Berechtigungen vorausgesetzt.

[highlight=SQL]
SELECT *
FROM [Databank].[Schema].[Tabelle]
[/highlight]

[Vaultboy]

Bei einer View hätte ich nur das Problem, dass ich nicht schreiben kann oder gibts da ne Möglichkeit?

[ebis]

Bei einer View hätte ich nur das Problem, dass ich nicht schreiben kann oder gibts da ne Möglichkeit?

Solange die View nur eine Tabelle referenziert
[HIGHLIGHT="SQL"]BEGIN TRAN;
CREATE TABLE Test
( ID INT IDENTITY (1,1)
, Test NCHAR(4)
);
GO
CREATE VIEW TestView AS
SELECT ID, Test FROM Test
GO
SELECT * FROM TestView;
INSERT INTO TestView (Test) VALUES ('Test');
SELECT * FROM TestView;
ROLLBACK[/HIGHLIGHT]

[Vaultboy]

OK, aber eine Tabelle reicht mir in dem Fall leider nicht.
WAs haltet Ihr davon:

Ein Export aus einer bestehenden Datenbank wird in die ZADB importiert dabei nehme ich die ID mit. Auf der Alt-datenbank richte ich einen Trigger ein der bei Aktualisierung der Adresse die Änderungen in die ZADB mit übernimmt. Durch mitnahme der ID ist auch die Eindeutigkeit gewährt, dass ich keinen anderen Datensatz verändere.

Wie sieht es da mit der Performance aus, ist ein Trigger nicht auch ziemlich rechenlastig?

[Bernhard Geyer]

Wie sieht es da mit der Performance aus, ist ein Trigger nicht auch ziemlich rechenlastig?

Solange du keinen mist im Trigger programierst und dein Firma nicht 100.000 MA's hat so das 1.000.000 Kundendatensätze pro Tag geändet werden und du keinen 10 Jahre alten Server einsetzt solltet du dir darüber keine Gedanken machen müssen.

[Vaultboy]

Nee der Server ist ein Cluster aus IBM 3650 und es sind viellt 100.000 DS bei 100 Benutzern.

Aber ist dieser Weg auch sinnvoll?

[openshinok]

Spannendes Thema...

Ich habe ein ähnliches Problemchen, bei mir sollen Firmenübergreifend die gleichen Kunden in der WaWi markiert werden. So dass man sich auf die andere Gesellschaft beziehen kann wenn man auch einen Auftrag beim Kunden platzieren möchte^^

Is ja schon interessant wenn du das mit dem Trigger machst welche Systeme alles Daten ändern dürfen. Abgleich in eine Richtung oder in beide Richtungen. Jede Software ist alleine lauffähig und hat vermutlich auch die Möglichkeit Daten zu ändern. Entweder sperren (User muss Anwendungen wechseln für Adressänderung, schlecht) oder es klappt automatisch....

[hwoess]

Änderungen in einer egal wie komplexen View sind machbar, wenn man einen INSTEAD-OF-Trigger verwendet

bye,
Helmut

[Thomas Rith]

Interessantes Thema. Ja. Aber ne Sche.. - Arbeit...

Wir hatten das vor 2 Jahren auch... Wir hatten ca. 8 Datenpools und wollten SAP einführen. Das Problem ist, die ganzen Adressen wieder auf einen Nenner zu bringen. Wir haben damals mit Uniserv (http://www.uniserv.com) zusammengearbeitet. Die haben uns die Daten alle bereinigt (auch alle Adressen ansich postalisch korrekt gemacht, sodass keine manuelle Arbeit nötig ist) und Dubletten kenntlich gemacht. Dann haben sie uns den Bestand geliefert, auch mit allen ALTEN IDs aus den 8 Pools. Damit kann man dann neue und alte IDs abgleichen.

So, danach hat unsere Firma beschlossen, das wir nur noch Adressen in SAP pflegen und diese als "Einbahnstraße" nach draußen gehen und alle angeschlossenen Systeme damit versorgt werden.