Anfänger Entwurfsfrage: Jedes Jahr neue Tabelle?

[Pieper]

Guten Morgen,
eine Anfängerfrage zum Entwurf DB für Nebenkostenabrechnung mit Access:
Planung: Über die Serienbriefeigenschaft von Word soll unter Zugriff auf eine kleine Access DB die Nebenkostenabrechnung erstellt werden.
Dazu habe ich die Tabellen Wohnung, Mieter, mietet, Nebenkosten, umgelegtAuf.
Nebenkosten enthält dann u.a. die Kosten des abzurechnenden Jahres. Diese Daten sollen aber auch später verfügbar sein (Beispielsweise für Streitigkeiten über die Abrechnung). Als Lösung fällt mir dann nur ein, jedes Jahr eine neue Tabelle Nebenkosten zu erstellen, also etwa Nebenkosten_2021, Nebenkosten_2022 usw.
Dann muss ich aber jedes Jahr auch wieder die Anfragen anpassen, neues Formular erstellen usw. Finde ich sehr unpraktisch - wie löse ich das intelligenter?
Für Hinweise dankend
Wilhelm

 

[Kampfgummibaerlie]

mal so auf die schnelle...

create table nebenkosten(betrag numeric not null, datum date default now()::date not null);
insert into nebenkosten(betrag, datum) values ('200', '2022-01-01');
insert into nebenkosten(betrag, datum) values ('200', '2022-01-01');
insert into nebenkosten(betrag, datum) values ('200', '2023-01-01');
select sum(betrag) from nebenkosten group by to_char(datum, 'YYYY');

bei mir kommt raus:

sum
200
400

möchtest du das ca. so machen? oder bin ich am falschen zweig?

EDIT:
vl noch angenehmer für die handhabung (habe 2x den obrigen code ausgeführt, deshalb doppelte menge)

select sum(betrag), to_char(datum, 'YYYY') as jahr from nebenkosten group by to_char(datum, 'YYYY');

es kommt raus:

 sum | jahr
-----+---------
 400 | 2023
 800 | 2022

 

[dabadepdu]

Als Lösung fällt mir dann nur ein, jedes Jahr eine neue Tabelle Nebenkosten zu erstellen, also etwa Nebenkosten_2021, Nebenkosten_2022 usw.

Das würde man niemals machen. Den Grund hast Du selbst genannt, Du musst alle Programme, Formulare, Reports für jedes Jahr neu machen (oder "hinterm Vorhang" die Quelldaten austauschen oder bei jahresübergreifenden Auswertungen noch verrücktere Mechanismen einsetzen)
Die Lösung ist ziemlich einfach. Die "Dimension", die Du in Form separater Tabellen abbilden möchtest, hier das Jahr, nimmst Du als Spalte zusätzlich auf.
Das mal so ganz grob als "Idee". In Anführungsstrichen, weil es weniger eine Idee als das Standardvorgehen in solchen Fällen ist. Idee als Schupser in die richtige Richtung.

 

[Pieper]

Sehr freundlich Eure Hinweise, danke.
@dabadepdu: Mich hatte abgehalten. "Abrechnungsjahr" als Attribut/Spalte mit aufzunehmen, dass dann immer wieder dasselbe Datum enthalten ist, fand ich redundant. Aber wenn ich das praktisch sehe, eigentlich kein Problem, sieht sinnvoll aus, mach ich so.

@Kampfgummibaerlie: Den Code könnte ich doch in einem Update-Formular verwenden, wenn im nächste Jahr neue Werte für die einzelnen Nebenkostenpositionen eingetragen werden müssen, danke!

Ist halt fast 30 Jahre her, dass ich mal mit DB hobbymäßig gearbeitet habe. Und leider ist der Kopf auch nicht mehr so schnell und aufnahmefähig wie damals. Aber ich versuchs weiter!

Nochmals Dank an Beide!

 

[ukulele]

Der Abrechnungsstichtag ist ggf. redundant, das Abrechnungsjahr kann aber als Spalte herhalten.

In einer perfekten Ausführung würde man vermutlich weiter gehen und einen Fremdschlüssel nehmen der auf eine Tabelle "Abrechnungen" zeigt die einen Start- und einen Endzeitpunkt führt sowie ihrerseits auf eine Tabelle "Mieter" zeigt. So könnte man dann z.B. unterjährige Mieterwechsel sauber abbilden. Die Sparvariante davon: Abrechnungsjahr + Mieter + eventuell Zeitanteil in Monaten oder sowas.

 

[castorp]

date default now()::date

Kleine Anmerkung:
das würde ich als datum date default current_date schreiben.

 

[castorp]

Mich hatte abgehalten. "Abrechnungsjahr" als Attribut/Spalte mit aufzunehmen, dass dann immer wieder dasselbe Datum enthalten ist, fand ich redundant.

Für jedes Jahr eine neue Tabelle anlegen ist viel schlechter. Wenn Dich aber wirklich nur das Jahr und niemals das komplette Datum interessiert, dann speichere das als Zahl, am besten mit einem Check Constraint, z.B.:

abrechnungsjahr integer not null check (abrechnungsjahr between 2000 and 2100)

Die Grenzen (2000 bis 2100) kannst Du ja nach Deinen Bedürfnissen anpassen.

ukulele hat aber noch einen guten Punkt gebracht: falls Du auch unterjährig bzw. nur Teile eines Jahres abrechnen musst, dann wäre vielleicht ein Zeitraum (von/bis) besser geeignet.
Das könnte man z.B. durch zwei Datumsspalten (von/bis) modellieren (in Postgres würde ich ein Spalte vom Typ daterange verwenden, damit man auch überlappende Zeiträume verhindern kann)

 

[Pieper]

.. gute Idee [Abrechnungsjahr = Integer], hab ich gleich umgesetzt.

Andere Frage noch: Habe drei option-buttons für die aktuell drei verschiedenen Abrechnungsjahre in einen Rahmen gepackt, aber keiner ist aktiviert (in der Mitte schwarz gefüllter Kreis).
Lässt sich auch nicht beim Anklicken aktivieren, aber die RecordSouce wird im Eventhandler geändert.
Sehe hier auch kein Attribut, um das Aussehen der options zu ändern.
Hat evtl. jemand einen Hinweis?

 

[dabadepdu]

Mach lieber eine Auswahlliste, die aus einer Tabelle gespeist wird. Sonst musst Du jedes Jahr am Formular rumklöppeln.

 

[Pieper]

@dabadepdu: Danke, wird so realisiert