Table nach Datum filtern

[jedi]

@jobo
Genau so ist mein Vorgehen.
Ich habe alle Daten in einer einzigen Tabelle und wähle die entsprechenden Altersgruppen über Filter (Berechnung aus Feld Geb_Tag und Diff zum 31.12., da Stichtag der Altersgruppe immer der 1.1. des laufenden Jahres ist) zur Anzeige und Druck aus.
Da ich wie schon angeführt viele jahresbezogene Daten habe will ich selbst die jahresbezogenen Daten in keine Zusatztabelle auslagern, sondern erstelle am Jahresende automatisch eine neue Mitgliedertabelle für das laufende Jahr durch Übernahme der Mitgliederdaten ohne jahresbezogene Daten z.b Mitglieder_2010, Mitglieder_2011 usw.. Somit arbeite ich immer nur mit dem aktuellen Mitgliederstand, kann jederzeit aber auf alte Daten zurückgreifen.

[p80286]

Zu meinem Verständnis,
Du hast eine Tabelle, in der alle Daten enthalten sind.
Für jedes Kalenderjahr befindet sich in dieser Tabelle ein volltändiger Mitgliedersatz.

Falls dies so ist,
dann ist das Design schon suboptimal.

aus der hohlen Hand
Deine Datenbank sollte mindestens zwei Tabellen haben,
a) Mitglieder
b) Mitgliedsdaten

wobei in der Mitglieder-Tabelle mindestens Name und Eintritts und Austrittsdatum enthalten sein sollten. Da ist es völlig unproblematisch festzustellen wer am 4.5.2009, vom Janur bis Juni 2008
oder wann auch immer Mitglied war.

Gruß
K-H

[jedi]

@p80286
Hallo,
so ähnlich war mein 1. Ansatz.
Ein paar weitere Informationen dazu, warum ich diesen Ansatz dann allerdings wieder verworfen habe:

(meine Denkweise kann natürlich auch völlig falsch sein!)

Ich muss die Mitgliedertabelle auch jährlich wieder an eine neue Zusatzdatentabelle anhängen, da sich 80% der dort geführten Daten jährlich ändern (entsprechend der jährlich beantragten Berechtigungen ändern sich die Art, Höhe und Bezeichnung des Mitgliedsbeitrages, die Ausstellungsnummern und das Ausstellungsdatum der Berechtigungsausweise und ähnliche Daten. Da ich diese Daten aber bis zu 5 Jahre zurück weiterhin vorhalten muss, kann ich diese Tabelle also nicht überschreiben sondern muss eine neue Tabelle erstellen (oder ein weiteres Zuordnungsjahr in der Tabelle dann einfügen um die Daten getrennt zu halten). Damit wird diese Tabelle dann aber sehr umfangreich.
Deshalb war mein Ansatz, gleich alle Daten in einer Tabelle zu führen, die dann allerdings jährlich auch neu erstellt werden muss.

[sx2008]

Zitat:

Zitat von jedi (Beitrag 1204597)

(meine Denkweise kann natürlich auch völlig falsch sein!)

Ja :) dir fehlt noch etwas Erfahrung im Datenbankdesign.
Also, wenn es in einer Datenbank zwei (oder mehr) Tabellen gibt, die in ihren Feldern komplett übereinstimmen, dann ist etwas faul am Design.
Denn es ist ja jederzeit möglich, die Datensätze aus den beiden Tabellen in eine einzige Tabelle zu verfrachten und zusätzlich ein weiteres Datenfeld aufzunehmen.

Es gibt zu dieser Regel eigentlich nur eine Ausnahme:
Performanceprobleme - bei hoher Datenmenge im GByte-Bereich muss man manche Tabellen in mehrere Tabellen zerlegen.
Man nennt das horizontale Partitionierung und man braucht das nur bei wirklich sehr vielen Datensätzen.


Auf dein Problem bezogen heisst das du braucht z.Zt. min. 3 Tabellen
* Mitglieder (pro Mitglied ein Datensatz)
* Beitraege (pro Mitglied und Jahr ein Datensatz)
* Konditionen (pro Jahr ein Datensatz)

Mit SQL ist es kein Problem die Daten die Daten aus mehreren Tabellen zu verknüpfen und unerwünschte Datensätze (z.B. alles was nicht zum Jahr 2013 gehört) auszufiltern.

Über die Datenmenge brauchst du dir keine Gedanken machen.
Es ist z.B. kein Problem in einer Access-Datenbank (150MB) alle Orte (~40000) und alle Strassen (~1,4 Mio) von Deutschland zu speichern und jede Adresse innerhalb 0,8s zu finden.

[p80286]

Da gäbe es mehrere Möglichkeiten, es kommt halt auf die Daten an
Mitgliederdaten:

Code:

ID
PersID
von
bis
Eigenschaft1,Eigenschaft2,.....

oder aber Du hast eine Tabelle mit den "Eigenschaften"
und verknüpfst Mitglieder und Eigenschaften über eine eigene Tabelle

Code:

MitgliederTable
MitgliedID
Name,Vorname, Adresse.....


LinkTable
ID
MitgliedID
EigenschaftID
von
bis

EgenschaftenTable
EigenschaftID
Eigenschaft

kommt natürlich auf deine konkreten Daten an, ggf sind noch ein paar Tabellen nötig, aber Dein jetziger Ansatz führt früher oder später in eine böse Sackgasse.
(das mit der "Normalisierung" war kein Scherz!)

Gruß
K-H

[jedi]

Zitat:

Ja dir fehlt noch etwas Erfahrung im Datenbankdesign.

Das stimmt!
@sx2008
@p80286
Ich glaube auch das Problem in meiner Denkweise gefunden zu haben. Der Grundgedanke bei der Entwicklung war einfach nur: Verwaltung der Daten für "jetzt", nächstes Jahr einfach Tabelle kopieren und neue Daten hinzufügen. Somit verwende ich unter einem "Dach" (Datenbank) pro Jahr eine Tabelle, die keinen Bezug zur Tabelle des Vorjahres hat. Für einen "echten" Datenbankprogrammierer vermutlich eine unmögliche Situation, für mich aber ein Anfang. Ich werde mich bessern!
Für mich war die Datenbank einfach nur ein "Container" der einzelnen Tabellen, während die "jährliche Tabelle" für mich die eigentliche "Datenbank" dargestellt hat. Deshalb sind meine Betrachtungen immer in Richrung "Tabelle" gegangen und nicht in Richtung übergreifende Datenbank.

Da das Problem mit dem Datum nun erst einmal gelöst ist läuft mein Programm entsprechend meiner Vorstellungen und ich kann mich von meiner Access-Version verabschieden (Dort habe ich die Datenbank einfach jedes Jahr kopiert und unter neuem Namen gespeichert, deshalb vermutlich auch meine denkweise in Bezug einer neuen Tabelle pro Jahr!).
Ich werde mich allerdings jetzt (parallel zur jetzigen Variante) mit Euren Lösungsansätzen mal ausführlich beschäftigen, mein "Datenbankverständnis" etwas auffrischen und das Programm umgestalten und hoffe bei weiteren Fragen auf Eure Hilfe. Eure Beiträge haben mir wirklich sehr geholfen.

Nochmals besten Dank für die Unterstützung!