Hi!
Ich wollte einige Funktionen, die JVerein so nicht unterstützt, in openOffice machen.
Um mir lange Abfragen auf Felder der JVerein-interne Tabelle „BEITRAGSGRUPPE“ zu ersparen, wollte ich A) diese um 2 Felder erweitern (ein Flag sowie eine Kurzbezeichnung) - alternativ B) eine zusätzliche Tabelle z.B. „BEITRAGSINFO“ mit einer Relation auf „BEITRAGSGRUPPE“ anlegen.
Beides funktioniert (soweit ich das übersehe, stört sich JVerein nicht an der Erweiterung) - bin mir aber nicht sicher, ob der Lösungsweg auch zukunftsträchtig ist.
Heiner, was meinst Du?
Gibt es Alternativ-Lösungsvorschläge?
Gruß Joe
Datenbank-Internas
Moderator: heiner
-
heiner
- Administrator
- Beiträge: 4509
- Registriert: Freitag 30. Oktober 2009, 16:44
- JVerein-Version: aktuelle Entwicklerversion
- Betriebssystem: W10
- Kontaktdaten:
Re: Datenbank-Internas
Hallo Joe,
klar kannst du die Tabellen erweitern. Allerdings musst du damit leben, dass es bei Weiterentwicklungen evtl. Probleme geben könnte.
Was genau willst du eigentlich machen?
Heiner
klar kannst du die Tabellen erweitern. Allerdings musst du damit leben, dass es bei Weiterentwicklungen evtl. Probleme geben könnte.
Was genau willst du eigentlich machen?
Heiner
PS: Denkt daran, eure Vereine unter viewforum.php?f=3 vorzustellen.
Re: Datenbank-Internas
Hallo Heiner,
Abhängig von der Beitragsgruppe muss ich für einige Mitglieder personalisierte Dokumente ausstellen. Nun könnte ich z.B. in das Feld „Bezeichnung“ der Tabelle „BEITRAGSGRUPPE“ irgendwelche kryptischen Kennungen eingeben, diese dann in openOffice (OO) auswerten, umcodieren und einen entsprechenden Klartext ausdrucken.
Viel einfacher geht‘s aber mit einem zusätzlichen Feld (Spalte) in der Tabelle „BEITRAGSGRUPPE“. Dieses habe ich mit OO angelegt und ausgefüllt, und kann nun sehr einfach mit der Serienbrief-Funktion die Dokumente erzeugen.
Die Möglichkeit, durch direkten Datenbankzugriff Auswertungen extern (z.B. über OO) durchführen zu können, finde ich geradezu genial. Ich kenne JVerein noch zu wenig, meine aber trotzdem, in der daraus resultierenden Anpassbarkeit liegt eine der Stärken des Programms. Funktionieren wird das aber nur, wenn sich die Struktur der Datenbank nicht allzu oft ändert.
(Klar wird es Anpassungen geben müssen, z.B. werden ab 2014 „Kontonummer“ und „Bankleitzahl“ überflüssig. Eine externe Auswertung bedarf dann aber sowieso einer Anpassung...)
Mitgliederbezogene Zusatzinfo kann man ja recht einfach und komfortabel über die Zusatzfelder bei den Mitgliedern eingepflegen. Unwesentlich schwieriger wirds, wenn die Zusatzinfo z.B. an der Beitragsgruppe klebt. Wie oen beschrieben gehts aber. JVerein bedarf noch nicht mal einer individuellen Anpassung, nur sollte eben sichergestellt sein, dass bei einer Umorganisation der Datenbank „benutzerdefinierten Datenfelder“ in die neue Struktur mitkopiert werden.
Meine eigetliche Frage hierzu:
Was passt besser ins Konzept und ist eher persistent:
- Zusatzfeld in eine bestehende Tabelle (so wie oben beschrieben)
- Neue Tabelle verknuepft ueber eine Relation (so wie bei den Tabellen "MITGLIED" und "ZUSATZFELD")
Gruß Joe
Abhängig von der Beitragsgruppe muss ich für einige Mitglieder personalisierte Dokumente ausstellen. Nun könnte ich z.B. in das Feld „Bezeichnung“ der Tabelle „BEITRAGSGRUPPE“ irgendwelche kryptischen Kennungen eingeben, diese dann in openOffice (OO) auswerten, umcodieren und einen entsprechenden Klartext ausdrucken.
Viel einfacher geht‘s aber mit einem zusätzlichen Feld (Spalte) in der Tabelle „BEITRAGSGRUPPE“. Dieses habe ich mit OO angelegt und ausgefüllt, und kann nun sehr einfach mit der Serienbrief-Funktion die Dokumente erzeugen.
Die Möglichkeit, durch direkten Datenbankzugriff Auswertungen extern (z.B. über OO) durchführen zu können, finde ich geradezu genial. Ich kenne JVerein noch zu wenig, meine aber trotzdem, in der daraus resultierenden Anpassbarkeit liegt eine der Stärken des Programms. Funktionieren wird das aber nur, wenn sich die Struktur der Datenbank nicht allzu oft ändert.
(Klar wird es Anpassungen geben müssen, z.B. werden ab 2014 „Kontonummer“ und „Bankleitzahl“ überflüssig. Eine externe Auswertung bedarf dann aber sowieso einer Anpassung...)
Mitgliederbezogene Zusatzinfo kann man ja recht einfach und komfortabel über die Zusatzfelder bei den Mitgliedern eingepflegen. Unwesentlich schwieriger wirds, wenn die Zusatzinfo z.B. an der Beitragsgruppe klebt. Wie oen beschrieben gehts aber. JVerein bedarf noch nicht mal einer individuellen Anpassung, nur sollte eben sichergestellt sein, dass bei einer Umorganisation der Datenbank „benutzerdefinierten Datenfelder“ in die neue Struktur mitkopiert werden.
Meine eigetliche Frage hierzu:
Was passt besser ins Konzept und ist eher persistent:
- Zusatzfeld in eine bestehende Tabelle (so wie oben beschrieben)
- Neue Tabelle verknuepft ueber eine Relation (so wie bei den Tabellen "MITGLIED" und "ZUSATZFELD")
Gruß Joe
heiner hat geschrieben:Hallo Joe,
klar kannst du die Tabellen erweitern. Allerdings musst du damit leben, dass es bei Weiterentwicklungen evtl. Probleme geben könnte.
Was genau willst du eigentlich machen?
Heiner
-
heiner
- Administrator
- Beiträge: 4509
- Registriert: Freitag 30. Oktober 2009, 16:44
- JVerein-Version: aktuelle Entwicklerversion
- Betriebssystem: W10
- Kontaktdaten:
Re: Datenbank-Internas
Hallo Joe,
kannst du nicht die IDs der Beitragsgruppen, die dich besonders interessieren in deinem Programm merken und dann über die IDs abfragen? Warum muss es ein zusätzliches Feld sein?
Wie bereits geschrieben, kannst du gerne die Datenbank erweitern. Es gibt aber immer wieder Notwendigkeiten, die Datenbankstruktur anzupassen. Ansonsten wäre der Zähler der Datenbankversion nicht so hoch. Bei der Weiterentwicklung von JVerein kann ich keine Rücksicht auf individuelle Erweiterungen nehmen. Es ist so schon genug Arbeit. Wenn dann noch die Abstimmung mit allen Individualisten dazu käme, würde ich nicht mehr fertig. Ich hoffe auf dein Verständnis.
Heiner
kannst du nicht die IDs der Beitragsgruppen, die dich besonders interessieren in deinem Programm merken und dann über die IDs abfragen? Warum muss es ein zusätzliches Feld sein?
Wie bereits geschrieben, kannst du gerne die Datenbank erweitern. Es gibt aber immer wieder Notwendigkeiten, die Datenbankstruktur anzupassen. Ansonsten wäre der Zähler der Datenbankversion nicht so hoch. Bei der Weiterentwicklung von JVerein kann ich keine Rücksicht auf individuelle Erweiterungen nehmen. Es ist so schon genug Arbeit. Wenn dann noch die Abstimmung mit allen Individualisten dazu käme, würde ich nicht mehr fertig. Ich hoffe auf dein Verständnis.
Heiner
PS: Denkt daran, eure Vereine unter viewforum.php?f=3 vorzustellen.
Re: Datenbank-Internas
Hallo Heiner,
dein Argument verstehe ich vollkommen: Individuelle Erweiterungen sollten wirklich nicht sein. Diese würden ein Programm wie JVerein sehr schnell unübersichtlich machen.
Daher: 100% agree !
Gruß Joe
PS:
Ab meinem Posting vom 18. November 2013 sollte der Thread eher als Hinweis verstanden werden, wie JVerein durch einen Datenbank-Erweiterung sehr elegant ein externes Programm wie OO noch besser unterstützen könnte. Vermutlich wäre daher der Threat auch besser in „Wünsch dir was!“ aufgehoben ...
Vermutlich wäre der Threat aber besser in „Wünsch dir was!“ aufgehoben ...
<speculative>
Wegen Mitglieder -> Zusatzfelder besteht wohl schon ein Mechanismus, nicht näher definierte (so man will individuelle) Felder in eine neue Datenbankversion zu migrieren. Ich stochere etwas im Nebel, könnte mir aber denken, dass die Zusatzfelder genau deshalb in eine externe Tabelle gewandert sind; es ist vermutlich einfacher, die Tabelle „ZUSATZFELDER“ einfach beizubehalten, und statt dessen die Relation zu „MITGLIED“ wieder herzustellen.
Bestimmt ist die Idee noch nicht ganz ausgegoren, aber falls ich nicht ganz falsch liege, könnte man dieses Verfahren zum Prinzip erheben:
Neben einer Tabelle „MITGLIED“ stände eine „ZUSATZFELDER“ (== UserDefined_MITGLIED)
neben einer „BEITRAGSGRUPPE“ stände eine „UD_BEITRAGSGRUPPE“
usw.
</speculative>
dein Argument verstehe ich vollkommen: Individuelle Erweiterungen sollten wirklich nicht sein. Diese würden ein Programm wie JVerein sehr schnell unübersichtlich machen.
Daher: 100% agree !
Gruß Joe
PS:
Ab meinem Posting vom 18. November 2013 sollte der Thread eher als Hinweis verstanden werden, wie JVerein durch einen Datenbank-Erweiterung sehr elegant ein externes Programm wie OO noch besser unterstützen könnte. Vermutlich wäre daher der Threat auch besser in „Wünsch dir was!“ aufgehoben ...
Vermutlich wäre der Threat aber besser in „Wünsch dir was!“ aufgehoben ...
<speculative>
Wegen Mitglieder -> Zusatzfelder besteht wohl schon ein Mechanismus, nicht näher definierte (so man will individuelle) Felder in eine neue Datenbankversion zu migrieren. Ich stochere etwas im Nebel, könnte mir aber denken, dass die Zusatzfelder genau deshalb in eine externe Tabelle gewandert sind; es ist vermutlich einfacher, die Tabelle „ZUSATZFELDER“ einfach beizubehalten, und statt dessen die Relation zu „MITGLIED“ wieder herzustellen.
Bestimmt ist die Idee noch nicht ganz ausgegoren, aber falls ich nicht ganz falsch liege, könnte man dieses Verfahren zum Prinzip erheben:
Neben einer Tabelle „MITGLIED“ stände eine „ZUSATZFELDER“ (== UserDefined_MITGLIED)
neben einer „BEITRAGSGRUPPE“ stände eine „UD_BEITRAGSGRUPPE“
usw.
</speculative>