Inoffizielles deutsches Xbase-Forum

Hi,
da ich in der letzten Zeit etliches mit SQL mache und merke, wie es mich von Tag zu Tag mehr fasziniert, würde ich gerne mehr umstellen von DBF auf SQL. Allerdings habe ich ein Projekt, bei dem ich überhaupt nicht weiß, wie man das umsetzen kann. Folgendes ist gegeben:
Es gibt ein Verzeichnis in dem x- Teilnehmer stehen. Jeder Teilnehmer hat wiederum x- Unterverzeichnisse in denen DBF stehen. Diese Verzeichnisse werden pro Teilnehmer und Jahr immer mehr.
Bisher ist es so, das man jeden Teilnehmer und jedes dazugehörige Jahr anwählen kann und auch muß. Dann wird einfach die Teilnehmernummer und das Jahr in den Verzeichnisnamen/Dateinamen geschraubt und schon paßt alles. Es wird also jedes Jahr ein neuer Zweig erstellt.
Aber wie löst man sowas mit einer SQl DAtenbank? Hat man dann auch "unendlich" viele Tabellen in einer Datenbank, oder wie geht man sowas an?

Diese aussagekräftigen Verzeichnisnamen kann man im Namespace unterbringen. Der ergänzt sozusagen den Namen einer Tabelle um eine Art Postleitzahl (namespace.tabellenname). Jeder Namespace (in PostGres heißt das "Schema") kann die gleichen Tabellenamen enthalten, und eine Datenbank kann beliebig viele Namespaces/Schemas kennen. Standard und Default ist "public", das muss man auch nicht angeben. Ein Tabellenname ohne Namespace ist in "public" zu suchen. (Cool wäre übrigens, wenn die PGDBE auf diese Weise automatisch vorherige Ordnerstrukturen reflektieren könnte, aber das kann sie leider nicht.) Mehr zu Schemas bei PostGres hier: https://www.postgresqltutorial.com/postgresql-schema/

Oder man setzt ein Merkmal, eine Tabellenspalte - und hat die Tabelle nur einmal. Diese Tabellenaufteilung, die Du betreibst, hat man ja früher aus Platz- und Geschwindigkeitsgründen gemacht. Wenn man das Verzeichnis zu einem Merkmal macht, also zum Inhalt eines Tabellenfeldes, hat man ein dauerhaftes Kriterium für ein SELECT. Der Vorteil dieser Vorgehensweise: Wenn man will, kann man innerhalb einer Tabelle auf die Daten mehrerer Merkmalsausprägungen zugreifen.

Die dritte Möglichkeit ist der Tabellenname selbst, der halt ergänzt wird (001mitarbeiter, 002mitarbeiter usw.). Das ist letztlich ja auch das, was man in einer Ordnerstruktur macht. Es gibt eigentlich keine Ordner, keine Fächer oder so. Dateien teilen sich Merkmale im Namen, die aber anders als die Namen selbst verwaltet werden und ein paar schicke Möglichkeiten bieten, und wir stellen uns das als Ordner vor. Aber "c:\pps\001\mitarbeiter_gehaltsdaten.dbf" und "c:\pps\002\mitarbeiter_gehaltsdaten.dbf" liegen nicht in bestimmten Schubladen (001, 002), die Unterschubladen (von "pps") sind, sondern im Extremfall direkt nebeneinader - der Pfad ist genau genommen ein Teil des Namens. Das kann man in einem SQL-Server auch machen.

es bedeutet jetzt aber auch, das sich der Dateiaufwand nicht reduziert, sondern direkt in der Datenbank untergebracht wird. Das war ja auch meine Frage, ob es dann so weiter gemacht wird nur das der Server sich dann um alles kümmert. (pauschal ausgedrückt)

Wenn Du das, was Dateiname und -pfad im Moment aussagen, in einem Feld unterbringst, das bei SELECTs auf die dann fragliche eine Tabelle berücksichtigt wird, aber auch bei UPDATEs, dann verändert sich dieser Aufwand marginal, aber der Dateiverwaltungsaufwand fällt deutlich geringer aus. Du gewinnst die Möglichkeit, mit einem Fingerschnipp übergreifende Auswertungen zu fahren oder Daten gleichzeitig anzubieten, die vorher unterschiedliche Speicherorte hatten.

hm, also mache ich aus einem Tabellenamen kunden dann 2020.kunden für das Vorjahr und benutze dann kunden weiterhin für das aktuelle Jahr? z.B.?

hm,
ich hoffe ich verstehe das jetzt.
Ich habe also unter PG z.B. die Struktur:
oben, den Server selbst
dann des weiteren die Datenbank(en)
dann innerhalb der Datenbank(en)
den Namen der Datenbank(en)
innerhalb der jeweiligen Datenbank
mehrere Bäume aber auch
Das/Die Schema(s)
public beinhaltet alles automatisch erstmal und kann direkt ohne weiteres angesprochen werden
dann können da weitere Schemas von mir untergebracht werden
Jedes Schema enthält dann eigene Tabellen, die spezifisch über den Schemenamen angesprochen werden müssen.
Wenn dem so ist, dann bin ich bis hier erstmal dabei.
Es kann jetzt für übergreifende Pauschaldaten in dem Daten sind, die alle betreffen der Zugriff auf die Tabelle über public.xxx gemacht werden, oder pauschal über xxx. Public wird ja standardmäßig genutzt, wenn nichts angegeben wird.
OK, ich möchte das jetzt für eine mandantenfähige Verwaltung nutzen. Ich lege für jede Mandantennummer ein Schema an und habe dann somit alles getrennt. Klingt auch logisch. Was mache ich aber, wenn es pro Mandanten Unterordner für die einzelnen Jahre gibt und gleichzeitig aber auch Tabellen, die oberhalb der Jahre stehen, die die Pauschaldaten für den Mandanten erhalten? Schema in Schema geht ja wohl nicht, oder?

Du brauchst Dir wegen der Datengröße keine Sorgen machen und somit auch die ganzen Jahre in einer Tabelle halten. Evtl ein Feld mit Jahr und dann eine View, welche nur vom aktuellen Jahr auswählt.

es geht in erster Linie darum, ein altes, fertiges Projekt zu migrieren.

Was soll/darf am alten Programm angepasst werden, damit es mit einem SQL-Server funktioniert?
Muß es PostGres sein oder kann es auch der ADS sein?

es wäre schön wenn es der Postgres wäre, der wird ja noch weiter gepflegt. Aber ADS wäre auch interessant, hast Du eine Idee?
Aber wenn dann nur mit einer Anmeldung nicht andauerndem Wechsel zwischen den DDs z.B.

Manfred hat geschrieben: ↑Do, 08. Jul 2021 17:08Es gibt ein Verzeichnis in dem x- Teilnehmer stehen. Jeder Teilnehmer hat wiederum x- Unterverzeichnisse in denen DBF stehen. Diese Verzeichnisse werden pro Teilnehmer und Jahr immer mehr.

Da bei der Anmeldung (?) immer genau einen Teilnehmer und ein Jahr angibt, verstehe ich es so, dass das Programm auch nur in genau einem der vielen Unterverzeichnisse auf die DBF-Dateien zugreift. Ist das richtig und sind es in jedem Unterverzeichnis die gleichen Dateien (gleiche Struktur)?

es kann im Programm selbst das Jahr und der Teilnehmer gewechselt werden. Ohne jweilige Neuanmeldung
Und ja, alle Dateien die in Unterverzeichnissen stehen, haben die gleiche Struktur. Wäre ja sonst blöde sie in Unterverzeichnisse zu packen, wenn es nicht der Fall wäre.

Manfred hat geschrieben: ↑Do, 21. Jul 2022 17:21 es kann im Programm selbst das Jahr und der Teilnehmer gewechselt werden. Ohne jeweilige Neuanmeldung

Du erwähnst extra "ohne jeweilige Neuanmeldung". Damit meinst Du, dass bei erstmaligem Aufruf z.B. einmalig ein Passwort eingegeben werden muß, danach aber nicht mehr? Wobei das meines Erachtens für die Migration nicht wichtig ist.

Ich würde dann wie folgt vorgehen:
1) auf ADS festlegen
2) weiterhin mit DBF-Tabellen arbeiten
3) Aus den vielen Verzeichnissen ein Verzeichnis machen und jede DBF-Tabelle zusätzlich mit den Feldern Teilnehmer und Jahr ausstatten
4) Beim Öffnen der Tabellen Funktionen einsetzen, die mit Hilfe des Teilnehmers und Jahres die zugehörigen Datensätze herausfiltern.

Momentan sehe ich keine großen Probleme bei der Umsetzung. Das müsste zumindest testweise innerhalb einer Woche zu schaffen sein. Wobei ich den Quellcode natürlich nicht kenne...

nachdem ich mir das ganze System nochmal angeschaut habe, fiel es mir wie Schuppen aus den Haaren. Alle Dateien haben schon im Namen die entsprechende Unterscheidung drin. Kundennummer und das Jahr. Das heißt, ich muß nur alle in ein Verzeichnis kopieren und dann in ein einziges DD übernehmen. es werden halt nur sehr viele Einzeldateien. Das dürfte aber eigentlich kein Problem sein, oder?

Es ist halt die Frage, wie viele Einzeltabellen es sind. Ich hatte mal den Fall, das es ca. 150.000 Tabellen waren. Das war definitiv nicht händelbar .
Was spricht denn gegen meinen vorherigen Vorschlag?

so weit ich Dich verstanden habe, möchtest Du die einzelnen Tabellen um Felder erweitern um dann zu unterscheiden!?
meine jetzige Idee müßte gar nichts ändern. Nur alles zusammenkopieren. Und so wie ich das sehe kann ich sogar die Verzeichnisstruktur teilweise so lassen, wie sie ist. Im DD steht dann das Unterverzeichnis mit drin.
Ich werde das jetzt einmal ausprobieren und schauen ob es klappt, oder wo noch geschraubt werden muß.
Im Idealfall bleibt dann im Ablauf alles so wie es ist, ich darf nur nicht mehr die verzeichnisse angeben, weil die speziellen Dateien ja alle im gleichen Verzeichnis stehen. Aber vielleicht kommt mir ja noch eine bessere Idee, beim Ausprobieren.

PS: was heißt nicht handlebar? Die menge als solche dürfte doch kein Problem sein, oder? Der ADS muß ja in meinem Falle immer nur 2-3 Dateien öffnen. Es ist halt nur eine große Menge in EINEM verzeichnis.

Ich hab ein ADD mit ADT Tabellen als Projekt übernommen. Da sind ca 3000 einzeltabellen enthalten. Im ARC kann man das gar nicht mehr öffnen, weil der eine Ewigkeit benötigt alle Metadaten einzulesen. Ich sprech da von ca 20 Minuten

OK, mit dem Architekten würde ich da weniger oft dran gehen. Hauptsache der ADS hat da keine Probleme mit. Dürfte aber auch nicht, weil ja immer nur wenige benutzt werden.

Der ARC baut einen Treeview auf...das dauert leider.

VDBU hat das Problem übrigens nicht...