17.12.2008, 21:37
Hier mein Statement zu dem Vorschlag:
Ich stimme in den meisten Punkten mit GMT überein. Eine neue Datenbank erstellen mit so einer Funktion halte ich für Quatsch. Das kann man sinnvoller so lösen wie GMT das herausgearbeitet hat. Für einzelne Spieler, Schiedsrichter etc.: warum nicht!?
Beim Einzel-Import von Objekten kann man vielleicht die Import-Funktionen nutzen, die es bereits gibt. Nur die Abfrage der hier sogenannten Master-DB läuft logischerweise anders. Technisch sollte das kein Problem sein.
Auch die Zusammenfassung von Datenbanken gibt es schon. Hier könnte jeder eine eigene Master-DB aus den gewünschten/benötigten (WebDB-fähigen) DBs zusammenstellen.
Es kam häufiger mal die Frage auf, wie das ist mit zwei gleichzeitig geöffneten Datenbanken, weil DFS das ja nicht zulässt. Aus meiner Sicht sind das zwei paar Schuhe. Nämlich Anwendung (DFS) auf der einen und Datenbank (VMD) auf der anderen Seite. DFS kann ja sinnvollerweise nur eine DB gleichzeitig anzeigen, warum sollten dann zwei gleichzeitig geöffnet werden können? Trotzdem ist es kein Problem auf eine andere DB zuzugreifen (OLE, ODBC, ADO). Ein Export nach XML oder ähnliches und nachfolgender Import: das kann's eigentlich nicht sein. Mit den vorgenannten Techniken kann ich Tabellen auch aus "fremden" Datenbanken verlinken oder zumindest ansprechen.
Ansonsten gibt es vielleicht noch ein paar grundsätzliche Fragen:
Soll der User die DB auswählen können oder arbeitet man mit einem festen Namen? (an dieser Stelle spreche ich auch nur vom Programmieraufwand, nicht von der Machbarkeit).
Gibt es eine "feste, offizielle" Master-DB oder soll der User sich die Master-DB aus den gewünschten (und von ihm benötigten) Datenbanken selbst zusammenstellen (dürfen)?
Wie viel Aufwand will Volker in so eine Funktion stecken. Mit Suchmasken, Ergebnismasken etc. kommen da schnell ein paar Tage zusammen. Oder ist es ok, wenn der User die gewünschte ID zuvor in der anderen DB ausfindig gemacht hat und dann in seiner DB nur die ID zum Import eingibt? Letzteres begeistert mich nicht wirklich, weil hier wieder die Komponente "man kann nur einmal DFS gleichzeitig öffnen" ins Spiel kommt. Das gäbe unter Umständen ein ziemliches Hin und Her.
Ich stimme in den meisten Punkten mit GMT überein. Eine neue Datenbank erstellen mit so einer Funktion halte ich für Quatsch. Das kann man sinnvoller so lösen wie GMT das herausgearbeitet hat. Für einzelne Spieler, Schiedsrichter etc.: warum nicht!?
Beim Einzel-Import von Objekten kann man vielleicht die Import-Funktionen nutzen, die es bereits gibt. Nur die Abfrage der hier sogenannten Master-DB läuft logischerweise anders. Technisch sollte das kein Problem sein.
Auch die Zusammenfassung von Datenbanken gibt es schon. Hier könnte jeder eine eigene Master-DB aus den gewünschten/benötigten (WebDB-fähigen) DBs zusammenstellen.
Es kam häufiger mal die Frage auf, wie das ist mit zwei gleichzeitig geöffneten Datenbanken, weil DFS das ja nicht zulässt. Aus meiner Sicht sind das zwei paar Schuhe. Nämlich Anwendung (DFS) auf der einen und Datenbank (VMD) auf der anderen Seite. DFS kann ja sinnvollerweise nur eine DB gleichzeitig anzeigen, warum sollten dann zwei gleichzeitig geöffnet werden können? Trotzdem ist es kein Problem auf eine andere DB zuzugreifen (OLE, ODBC, ADO). Ein Export nach XML oder ähnliches und nachfolgender Import: das kann's eigentlich nicht sein. Mit den vorgenannten Techniken kann ich Tabellen auch aus "fremden" Datenbanken verlinken oder zumindest ansprechen.
Ansonsten gibt es vielleicht noch ein paar grundsätzliche Fragen:
Soll der User die DB auswählen können oder arbeitet man mit einem festen Namen? (an dieser Stelle spreche ich auch nur vom Programmieraufwand, nicht von der Machbarkeit).
Gibt es eine "feste, offizielle" Master-DB oder soll der User sich die Master-DB aus den gewünschten (und von ihm benötigten) Datenbanken selbst zusammenstellen (dürfen)?
Wie viel Aufwand will Volker in so eine Funktion stecken. Mit Suchmasken, Ergebnismasken etc. kommen da schnell ein paar Tage zusammen. Oder ist es ok, wenn der User die gewünschte ID zuvor in der anderen DB ausfindig gemacht hat und dann in seiner DB nur die ID zum Import eingibt? Letzteres begeistert mich nicht wirklich, weil hier wieder die Komponente "man kann nur einmal DFS gleichzeitig öffnen" ins Spiel kommt. Das gäbe unter Umständen ein ziemliches Hin und Her.