OOP Relationen
Moderator: Moderatoren
- Manfred
- Foren-Administrator
- Beiträge: 21165
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 206 Mal
- Danksagung erhalten: 67 Mal
OOP Relationen
Ich hätte da noch eine Frage.....
da man ja in Xbase++ objekorientiert programmieren kann, würde ich an dieser Stelle gerne einmal folgende Frage loswerden:
Wie weit treibt man es eigentlich mit der Klassenerzeugung und der Objektbildung? Gibt es da eigentlich irgendwelche Anleitungen drüber? Ich meine, ab wann lohnt es sich eurer Meinung eine Klasse und Instanz zu bilden und ab wann ist es unsinnig, oder vielleicht sogar Quatsch?
Um jetzt auch nicht einen neuen Thread zu eröffnen: (Ich hoffe ich habe es nicht schon irgendwo gefragt, konnte nämlich nichts finden)
wie weit treibt man es mit den Normalformen? Wie weit zerpflückt man eine DB in Unterdatenbanken, um sie später über Relationen oder wie auch immer mit einander zu verbinden? Wie sieht auch hier eure Einstellung dazu aus?
da man ja in Xbase++ objekorientiert programmieren kann, würde ich an dieser Stelle gerne einmal folgende Frage loswerden:
Wie weit treibt man es eigentlich mit der Klassenerzeugung und der Objektbildung? Gibt es da eigentlich irgendwelche Anleitungen drüber? Ich meine, ab wann lohnt es sich eurer Meinung eine Klasse und Instanz zu bilden und ab wann ist es unsinnig, oder vielleicht sogar Quatsch?
Um jetzt auch nicht einen neuen Thread zu eröffnen: (Ich hoffe ich habe es nicht schon irgendwo gefragt, konnte nämlich nichts finden)
wie weit treibt man es mit den Normalformen? Wie weit zerpflückt man eine DB in Unterdatenbanken, um sie später über Relationen oder wie auch immer mit einander zu verbinden? Wie sieht auch hier eure Einstellung dazu aus?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Martin Altmann
- Foren-Administrator
- Beiträge: 16502
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Hallo Manfred,
ohohoh - Du hast aber wirklich Talent, die "politisch brisanten" Themen anzuschneiden Das wird hier garantiert auch wieder so ein Mammut-Thread wie der mit den Index-Treibern
Also, eine grundsätzliche "Kochanleitung" bei dem Thema Normalisieren der Datenbanken gibt es nicht - das hängt immer vom Einzelfall ab!
Es muss gegeneinander abgewogen werden, wie möglichst effizient und platzsparend gearbeitet werden kann.
Zwei Extreme wären (anhand einer Adressdatei mit Anrede, Vorname, Nachname, Strasse, PLZ, Ort, Telefon) folgende:
Wenn Du ein spezielles Beispiel hast, dann können wir ja hier probieren, dafür eine Lösung zu finden!
Und zum Thema OOP: Ich arbeite zwar in der OOP, was die Dialogerstellung anbelangt, aber nicht unbedingt durchgehend mit Vererbung. Dies habe ich nur an zwei oder drei Stellen. Im Prinzip habe ich für jedes Fenster bei mir eine eigene Klasse. Ich persönlich finde, dass Anpassungen der Xbase-Parts einfacher in der objektorientierten Handhabung zu machen sind, als in der Funktionsorientierten - aber das ist sicherlich Geschmackssache!
Viele Grüße,
Martin
ohohoh - Du hast aber wirklich Talent, die "politisch brisanten" Themen anzuschneiden Das wird hier garantiert auch wieder so ein Mammut-Thread wie der mit den Index-Treibern
Also, eine grundsätzliche "Kochanleitung" bei dem Thema Normalisieren der Datenbanken gibt es nicht - das hängt immer vom Einzelfall ab!
Es muss gegeneinander abgewogen werden, wie möglichst effizient und platzsparend gearbeitet werden kann.
Zwei Extreme wären (anhand einer Adressdatei mit Anrede, Vorname, Nachname, Strasse, PLZ, Ort, Telefon) folgende:
- Gar keine Normierung: Alles steht in einer Tabelle - einfach zu handhaben, hoher Platzverbrauch
- vollständige Normierung: Es gibt eine Tabelle mit den Anreden, eine mit den Vornamen, eine mit den Nachnamen, eine mit den Strassen, eine mit Hausnummern (ist hier neu hinzugekommen), eine mit den PLZ, eine mit den Orten, eine mit den Vorwahlen (ist hier auch neu hinzugekommen). In der Übergeordneten Tabelle werden die Untertabellen einfach verknüpft und um die Telefonnummern (ohne Vorwahl) ergänzt. Insgesamt geringerer Platzverbrauch, aber schwerer zu handhaben.
Man stelle sich in diesem Szenario mal vor, eine Frau Müller heiratet und heißt jetzt Müller-Lüdenscheid! Würde man jetzt einfach in der Tabelle der Nachnamen den Namen ändern, würden alle anderen Müllers auf einmal auch so heißen!
Wenn Du ein spezielles Beispiel hast, dann können wir ja hier probieren, dafür eine Lösung zu finden!
Und zum Thema OOP: Ich arbeite zwar in der OOP, was die Dialogerstellung anbelangt, aber nicht unbedingt durchgehend mit Vererbung. Dies habe ich nur an zwei oder drei Stellen. Im Prinzip habe ich für jedes Fenster bei mir eine eigene Klasse. Ich persönlich finde, dass Anpassungen der Xbase-Parts einfacher in der objektorientierten Handhabung zu machen sind, als in der Funktionsorientierten - aber das ist sicherlich Geschmackssache!
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Manfred
- Foren-Administrator
- Beiträge: 21165
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 206 Mal
- Danksagung erhalten: 67 Mal
Hi Martin,
Holla,
die Sache mit dem Müller-Lüdenscheid, die macht mich jetzt auch ein wenig nachdenklich. Man könnte da aber einfach den Namen Müller-Lüdenscheid neu erfassen und dann der Dame zur Hochzeit neu zuordnen.
Dieses Beispiel, was Du anführst mit dem kompletten Zerpflücken, habe ich auch schon in der Praxis gesehen und hat bei mir allerdings ebenso ein Kopfschütteln hervorgerufen. Vorname und Nachnamen komplett zu trennen. Es muß dann ja auch eine Verknüpfungsdb parallel dazu erzeugt werden um später die Zuordnung hinzubekommen. x User zu 1 Nachnamen.
Nun, jetzt zur OOP.
Mich wundert ein wenig die Einstellung der Leute. Als ich vor ein paar Jahren anfing mich damit zu beschäftigen, kam immer wieder die einhellige Meinung: OOP ist prima, aber schweeeeer.
Jetzt frage ich mich: Wo ist das schwer?
Allerdings frage ich mich auch: Habe ich es dann überhaupt verstanden, wenn ich es als nicht so schwer empfinde?
Die Würze an der OOP liegt doch in der Vererbung!? Sollte denn dann wirklich nur eine Klasse/Instanz erzeugt werden, wenn man vor hat etwas zu vererben, oder auch wenn man einfach nur scharf auf die Kapselung des Objektes mit all seinen Variabeln, die man sonst immer wieder getrennt angeben muß in einzelnen Funktionen oder so ist?
Holla,
die Sache mit dem Müller-Lüdenscheid, die macht mich jetzt auch ein wenig nachdenklich. Man könnte da aber einfach den Namen Müller-Lüdenscheid neu erfassen und dann der Dame zur Hochzeit neu zuordnen.
Dieses Beispiel, was Du anführst mit dem kompletten Zerpflücken, habe ich auch schon in der Praxis gesehen und hat bei mir allerdings ebenso ein Kopfschütteln hervorgerufen. Vorname und Nachnamen komplett zu trennen. Es muß dann ja auch eine Verknüpfungsdb parallel dazu erzeugt werden um später die Zuordnung hinzubekommen. x User zu 1 Nachnamen.
Nun, jetzt zur OOP.
Mich wundert ein wenig die Einstellung der Leute. Als ich vor ein paar Jahren anfing mich damit zu beschäftigen, kam immer wieder die einhellige Meinung: OOP ist prima, aber schweeeeer.
Jetzt frage ich mich: Wo ist das schwer?
Allerdings frage ich mich auch: Habe ich es dann überhaupt verstanden, wenn ich es als nicht so schwer empfinde?
Die Würze an der OOP liegt doch in der Vererbung!? Sollte denn dann wirklich nur eine Klasse/Instanz erzeugt werden, wenn man vor hat etwas zu vererben, oder auch wenn man einfach nur scharf auf die Kapselung des Objektes mit all seinen Variabeln, die man sonst immer wieder getrennt angeben muß in einzelnen Funktionen oder so ist?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Martin Altmann
- Foren-Administrator
- Beiträge: 16502
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Hallo Manfred,
- diese verknüpfen dann mit dem entsprechenden Satz in der anderen Tabelle. Also nicht schwer und platzsparend (das Namensfeld ist natürlich länger als das Verknüpfungsfeld - 40 Zeichen gegen 10 Zeichen. Natürlich muss das Feld mit der Nummer auch in der Tabelle mit den Namen mitgezogen werden - aber bei mehreren mehrfach nutzbaren Nachnamen rechnet sich das dann schon)
Und das Trennen von Vor- und Nachnamen kann schon Sinn machen - es gibt ja schließlich auch genug Vornamen, die recht häufig sind (Thomas, Manfred, Martin, Wolfgang,...
Früher, als das Thema neu aufkam, gab es natürlich auch - wie bei allen neueren Themen - Berührungsängste. Da Du Dich in der Zwischenzeit mehr damit beschäftigt hast, fällt es Dir halt leichter, damit umzugehen.
Viele Grüße,
Martin
Nein - nicht man könnte, sondern man muss! Anders geht es nicht - und das ist genau das, was ich mit erhöhtem Aufwand meinte.Manfred hat geschrieben:die Sache mit dem Müller-Lüdenscheid, die macht mich jetzt auch ein wenig nachdenklich. Man könnte da aber einfach den Namen Müller-Lüdenscheid neu erfassen und dann der Dame zur Hochzeit neu zuordnen.
Jup - ist aber unkritisch. Du hast eine Tabelle, in der stehen nur NummernManfred hat geschrieben:Dieses Beispiel, was Du anführst mit dem kompletten Zerpflücken, habe ich auch schon in der Praxis gesehen und hat bei mir allerdings ebenso ein Kopfschütteln hervorgerufen. Vorname und Nachnamen komplett zu trennen. Es muß dann ja auch eine Verknüpfungsdb parallel dazu erzeugt werden um später die Zuordnung hinzubekommen. x User zu 1 Nachnamen.
- diese verknüpfen dann mit dem entsprechenden Satz in der anderen Tabelle. Also nicht schwer und platzsparend (das Namensfeld ist natürlich länger als das Verknüpfungsfeld - 40 Zeichen gegen 10 Zeichen. Natürlich muss das Feld mit der Nummer auch in der Tabelle mit den Namen mitgezogen werden - aber bei mehreren mehrfach nutzbaren Nachnamen rechnet sich das dann schon)
Und das Trennen von Vor- und Nachnamen kann schon Sinn machen - es gibt ja schließlich auch genug Vornamen, die recht häufig sind (Thomas, Manfred, Martin, Wolfgang,...
Nun, dass es Dir leicht fällt, heißt ja nicht notgedrungen, dass es auch allen anderen leicht fallen muß (bzw. dass es auch leicht ist)Manfred hat geschrieben:Nun, jetzt zur OOP.
Mich wundert ein wenig die Einstellung der Leute. Als ich vor ein paar Jahren anfing mich damit zu beschäftigen, kam immer wieder die einhellige Meinung: OOP ist prima, aber schweeeeer.
Jetzt frage ich mich: Wo ist das schwer?
Allerdings frage ich mich auch: Habe ich es dann überhaupt verstanden, wenn ich es als nicht so schwer empfinde?
Früher, als das Thema neu aufkam, gab es natürlich auch - wie bei allen neueren Themen - Berührungsängste. Da Du Dich in der Zwischenzeit mehr damit beschäftigt hast, fällt es Dir halt leichter, damit umzugehen.
Auch hier wieder die Regel: egal wie, Hauptsache es kommt raus, was rauskommen soll.Manfred hat geschrieben:Die Würze an der OOP liegt doch in der Vererbung!? Sollte denn dann wirklich nur eine Klasse/Instanz erzeugt werden, wenn man vor hat etwas zu vererben, oder auch wenn man einfach nur scharf auf die Kapselung des Objektes mit all seinen Variabeln, die man sonst immer wieder getrennt angeben muß in einzelnen Funktionen oder so ist? Wäre dann ein Array nicht vielleicht auch eine Möglichkeit?
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9345
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 100 Mal
- Danksagung erhalten: 359 Mal
- Kontaktdaten:
Man kann das zwar beliebig weit treiben, so daß man in einer Kundendatei z.B. schließlich nur noch IDs verwaltet, die andere Datenbanken/Tabellen referenzieren, aber man sollte die Wartbarkeit nicht außer Acht lassen. Es macht m.E. nur in Ausnahmefällen Sinn, sämtliche verfügbaren Nachnamen, Vornamen, Geburtsdaten usw. in abhängige Tabellen zu stopfen, da diese von der Person abhängen, und nur wenige Applikationen/Auswertungen vorstellbar sind, die z.B. alle erfaßten Vornamen, Nachnamen oder Geburtsdaten - unabhängig vom "Inhaber" - bewerten sollen. Wie gesagt, außerdem dürfte eine solche Datenbank mit Bordmitteln schwer wartbar sein, also wenn man "von außen" etwas prüfen möchte. Was Sinn macht, sind natürlich Tabellen z.B. für Orte, Postleitzahlen, Straßen, oder solche für Adressen, die "Kontakten" zugeordnet sind, aber auch das hängt von der Applikation ab. Es ist ja heutzutage nicht mehr so, daß man auf jedes verbrauchte Byte Speicherplatz schielen muß. Die "Kopfdaten" eines Kunden ändern sich i.d.R. nur einmal, nämlich im Kundendatensatz direkt, wohingegen z.B. die Änderung eines Straßennamens oder einer Postleitzahl o.ä. schon mehrere Kunden betreffen kann. Undsoweiter.
Zum Thema OOP vielleicht später was.
Zum Thema OOP vielleicht später was.
Herzlich,
Tom
Tom
- Martin Altmann
- Foren-Administrator
- Beiträge: 16502
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Hallo Tom,
Viele Grüße,
Martin
Ganz meine Rede!Tom hat geschrieben:aber man sollte die Wartbarkeit nicht außer Acht lassen.
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Manfred
- Foren-Administrator
- Beiträge: 21165
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 206 Mal
- Danksagung erhalten: 67 Mal
Hi Tom
ist jetzt später?Tom hat geschrieben:
Zum Thema OOP vielleicht später was.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- brandelh
- Foren-Moderator
- Beiträge: 15688
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Ich nutze was gerade am sinnvollsten ist
Hallo,
ich mache mir Gedanken, was mir in der jeweiligen Situation am besten nützt z.B.:
Ich bin Schreibfaul und habe keine Lust
zur schreiben, daher mache ich immer eine Funktion zum Start eines Fensters, welche das Fensterobject zurückgibt:
innerhalb der Funktion weiße ich dem Object alles zu was es braucht (Lage, owner, dem Menü das neue Fensterobject etc.)
ginge auch anders und ist nicht 'rein' aber sehr gemütlich
Nun habe ich eine DBF, mit Infos. Diese muß regelmäßig mit einer TXT Datei gefüttert werden, verschiedene Controlls wollen Infos daraus (nur lesen).
Ich könnte natürlich im ganzen Programm direkt darauf zugreifen, aber ich mache eine Class
so stelle ich im Programm sicher, dass es nur eine Verbindung zur DBF gibt, dass diese mit Schreibschutz geöffnet ist und habe alle Daten und Functionen an einem Ort.
Ich liebe es DB - Objekte zu haben, welche selbst auf sich aufpassen.
Das war auch das Beste an VO, der DBServer.
Was die Normalisierung angeht, habe ich schon gelesen, dass man eine SQL Datenbank so stark normalisieren kann, dass nichts mehr geht. Ohne geht es aber auch nicht.
Bei der Umstellung von vielen kleinen lokalen PC DBF auf einen zentralen Bestand hatten wir ein großen Problem die doppelten Datensätze zusammen zu führen (sind Peter Müller und Peter Mueller gleich ?), das gleiche tritt auf wenn man je Rechnung den Empfänger speichert, statt einen Verweiß auf diesen (neue Rechnungen haben eine andere Anschrift als die alten, gehören sie dem gleichen ?).
Ich überlege mir immer
1. Was gehört zusammen ?
-> Name, Vorname, Geburttag etc. sicherlich
-> Anschrift, Telefon, etc. da könnten eventuell mehrere nötig sein ?
-> Rechnungen, Autos etc. auf jeden Fall können mehrere existieren
-> Uniabschluß, gibt es zwar nur einmal aber nicht bei jedem !
-> Handballverein etc. nur zufällige Überschneidung
2. Liegt eine 1 : 1 Beziehung vor ?
-> 1 : 1 Beziehung und Pflichtfeld immer in gleiche Datei
-> 1 : 1 aber nur ab und zu ausgefüllt, überlegen
ob der zusätzlich nötige Index oder das oft leere Feld
für deine Applikation das kleinere Übel ist.
-> Falls eine Datei einen sehr langen Datensatz hat, die
Auswertungen sich meist aber auf wenige Felder beschränkt
und ein Index nicht hilfreich ist, könnte aus Performancegründen
eine Aufteilung in Betracht kommen.
3. Datei hat keine 1 : 1 Beziehung
-> immer aufteilen !
4. Der goldene Mittelweg ist den 'reinen Lehren' meißt vorzuziehen.
Tschüß
Hubert
ich mache mir Gedanken, was mir in der jeweiligen Situation am besten nützt z.B.:
Ich bin Schreibfaul und habe keine Lust
Code: Alles auswählen
oWin := MeinNeuestesFenster():New(oParent ... ):create()
Code: Alles auswählen
oWin : MyMeinNeuestesFenster()
ginge auch anders und ist nicht 'rein' aber sehr gemütlich
Nun habe ich eine DBF, mit Infos. Diese muß regelmäßig mit einer TXT Datei gefüttert werden, verschiedene Controlls wollen Infos daraus (nur lesen).
Ich könnte natürlich im ganzen Programm direkt darauf zugreifen, aber ich mache eine Class
Code: Alles auswählen
function MyDB()
static oMyDB
if oMyDB = NIL
oMyDB := _MyDB():new()
endif
return oMyDB
CLASS _MyDB
exported:
var nAlias // wird nach USE NEW mit ::nAlias := select() gefüllt
access method nAnz // lastrec
method TXT_Import
method AlleNamenAlsArray ...
so stelle ich im Programm sicher, dass es nur eine Verbindung zur DBF gibt, dass diese mit Schreibschutz geöffnet ist und habe alle Daten und Functionen an einem Ort.
Ich liebe es DB - Objekte zu haben, welche selbst auf sich aufpassen.
Das war auch das Beste an VO, der DBServer.
Was die Normalisierung angeht, habe ich schon gelesen, dass man eine SQL Datenbank so stark normalisieren kann, dass nichts mehr geht. Ohne geht es aber auch nicht.
Bei der Umstellung von vielen kleinen lokalen PC DBF auf einen zentralen Bestand hatten wir ein großen Problem die doppelten Datensätze zusammen zu führen (sind Peter Müller und Peter Mueller gleich ?), das gleiche tritt auf wenn man je Rechnung den Empfänger speichert, statt einen Verweiß auf diesen (neue Rechnungen haben eine andere Anschrift als die alten, gehören sie dem gleichen ?).
Ich überlege mir immer
1. Was gehört zusammen ?
-> Name, Vorname, Geburttag etc. sicherlich
-> Anschrift, Telefon, etc. da könnten eventuell mehrere nötig sein ?
-> Rechnungen, Autos etc. auf jeden Fall können mehrere existieren
-> Uniabschluß, gibt es zwar nur einmal aber nicht bei jedem !
-> Handballverein etc. nur zufällige Überschneidung
2. Liegt eine 1 : 1 Beziehung vor ?
-> 1 : 1 Beziehung und Pflichtfeld immer in gleiche Datei
-> 1 : 1 aber nur ab und zu ausgefüllt, überlegen
ob der zusätzlich nötige Index oder das oft leere Feld
für deine Applikation das kleinere Übel ist.
-> Falls eine Datei einen sehr langen Datensatz hat, die
Auswertungen sich meist aber auf wenige Felder beschränkt
und ein Index nicht hilfreich ist, könnte aus Performancegründen
eine Aufteilung in Betracht kommen.
3. Datei hat keine 1 : 1 Beziehung
-> immer aufteilen !
4. Der goldene Mittelweg ist den 'reinen Lehren' meißt vorzuziehen.
Tschüß
Hubert
Gruß
Hubert
Hubert