Vorgehensweise bei komplexen Datenmodell

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 14 Antworten in diesem Thema. Der letzte Beitrag () ist von Westerwälder.

    Vorgehensweise bei komplexen Datenmodell

    Finde nicht den richtigen Ansatz unterschiedliche Bedingungen im Datenmodell zu vereinen.
    Verwalte mit meinem Programm Mietobjekte. Komme aus einer ländlichen Region, da ist nicht leider ein Objekt wie das andere.
    In den vergangenen Jahren war dies alles überschaubar, da die Mieter einige Jahre in der Wohnung verweilten.
    Zunehmend ist ein häufiger Mieterwechsel, nicht mehr die Ausnahme.
    Es geht hier um die Festhaltung und Abrechnung der Nebenkosten.

    Habe jedem Verbrauchszähler im Objekt (Wasser, Strom, Gas usw.) eine Nummer vergeben.
    Speichere Verbrauch einmal unter Wohnung und nochmal unter Mieter.
    Soweit kein Problem.

    Beispiel Warmwasser:
    Haus A) versorgt durch wohnungsinterne Gastherne
    Haus B) versorgt durch zentrale Pelletsheitzung
    Haus C) versorgt durch eigenen E-Boiler

    oder gemeinschaftliches Aussenwasser (Gartenanschluss)
    Haus A) hat zwei Aussenanschlüsse mit Zähler
    Haus B) Differenz aus Gesamtverbrauch des Objektes minus Summe Verbrauch der Wohnungen
    Haus C) kein Aussenwasseranschluss vorhanden

    mit dem gemeinschaftlichen Strom sieht es nicht viel anders aus (Landleben halt)

    Was ist nun der richtige Weg,
    in dem Datenmodell vorweg alles zu spezifizieren, oder für jedes Objekt (Haus) eine eigene
    Routine zu erstellen?
    Die Antwort ist klar, kommt ein Objekt dazu, ist eine Programmierung erforderlich.
    Die andere Seite, es sind ja teilweise (pro Kosten-, Zählerstellen) zig Optionen möglich.
    Hier eine Sache falsch gewählt und alles geht schnell daneben.
    Ich als Entwickler weis welche Optionen ich wählen müsste um das richtige Ergebnis
    am Ende zu erhalten.
    Aber in wieweit kann man dies einem User zumuten?
    Vielleicht bin ich hier auch ganz auf dem Holzweg.
    Gruß Markus

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Westerwälder“ ()

    Vor zehn Jahren war die fruchtlose Suche nach einer kommerziellen Software, der Auslöser ein eigenes Programm zu entwickeln.
    Diese Spezifikationen wurden damals nicht angeboten (denke das sieht heute nicht viel besser aus).

    Edit:
    Denke übergebe dem Objekt, Kostenstellen und Verbrauchszähler eine, nenne sie mal Detailnummer.
    In diesem Fall müsste ich die Datentabellen jeweils nur um eine Spalte erweitern.
    In einer neuen Klasse die Detailnummer wieder lesbaren Variablen zuordnen.

    z.Bsp. Aussenwasser

    Detailnummer 1121
    1 = Aussenwasser
    1 = Ist zu berechnen
    2 = Gesamtverbrauch ./. Anzahl der Wohnungen
    1 = Kanal- und Niederschlagwasser ist zu berücksichtigen

    So oder so ähnlich
    Gruß Markus

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Westerwälder“ ()

    Ist das jetzt für Dich oder willst Du das Ganze vermarkten?
    Dein Screenshot sagt jetzt erstmal: Eine Abrechnung hat zwei Einstellmöglichkeiten. Jede Einstellmöglichkeit hat mehrere Optionen. Mehr seh ich erstmal nicht. Noch ist es also erstmal relativ leicht.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Jo stimmt - hätte nicht gedacht, dass man das so vereinheitlichen kann.
    Nennen wir also die beiden Einstellmöglichkeiten PreisTyp und VerbrauchErmittlungsTyp.
    Und dann kann man alle AbrechnungsArten über einen Kamm scheren.
    Ups - es handelt sich hierbei ja nur um Wasser-AbrechnungsArten.
    Heizung, Strom, Müll, BürgersteigReinigung,... ist noch nicht angeguckt.

    Nein, es liegt mir fern, was zu vermarkten. Wollte mal erfahren, was die Experten von der Vorgehensweise halten.

    Für Heizung habe ich schon was entwickelt, Strom wird wie die Wasserabrechnung laufen.
    Die restlichen Kostenstellen sind keine Verbrauchsstellen und können monatlich und nach Mietdauer abgerechnet werden.

    Hier Berechnung:

    VB.NET-Quellcode

    1. Private Function Verbrauchsermittlung(ByVal Verbrauchsmenge As Double, ByVal Verbrauchspart As MBC_Imob.CDetaildaten.CVerteilung,
    2. Optional ByVal Rundungsstellen As Integer = 2) As Double
    4. RVerbrauch = 0
    5. Verbrauch_IstAnteil = True
    7. With Verbrauchspart
    9. If .Verbrauch Then
    10. Verbrauch_IstAnteil = False
    11. RVerbrauch = Verbrauchsmenge
    12. End If
    14. If .Wohnungbewohner Then RVerbrauch = Verbrauchsmenge / IB.Mieter.Personenzahl
    15. If .Wohnungsanzahl Then RVerbrauch = Verbrauchsmenge / IB.Objekt.Detail.AnzahlWohnungen
    16. If .Wohnungsgroesse Then RVerbrauch = Verbrauchsmenge / IB.Wohnung.Kostenanteil
    17. If .Objektbewohner Then RVerbrauch = Verbrauchsmenge / IB.Objekt.Detail.Bewohner
    19. End With
    21. If Verbrauch_IstAnteil Then RVerbrauch = RVerbrauch * IB.Mieter.Mietmonate / 12
    22. RVerbrauch = Math.Round(RVerbrauch, Rundungsstellen)
    24. Return RVerbrauch
    26. End Function

    Bilder

    • Heizungabrechnung.png

      349,78 kB, 3.840×2.160, 84 mal angesehen
    Gruß Markus

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Westerwälder“ ()

    Da ich mit der Benennung der Codeteile meine Probleme habe, werde ich mal halbblind in den Raum, dass die Zeilen#9-#17 das Wort »Vererbung« flüstern. Und dass da was noch nicht ganz passt. Denn wie ist auszuschließen, dass ein Verbrauchspart (?) nicht Wohnungbewohner und Objektbewohner zugleich auf True hat? Aufpassen ist keine adäquate Antwort ;) Wenn es sich gegenseitig ausschließende Zustände sind, ist die Verwendung von mehreren Boolean-Properties unpassend und erweiterungswiderständlerisch.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Nun das zwei Proerties True sein können, wird ausgeschlossen indem die Zuweisung über RadioButton erfolgt. Kann man in Screenshot vielleicht nicht erkennen.
    Beim Lesen zerflücke ich die Detailnummer

    VB.NET-Quellcode

    1. Public Sub Initalisieren()
    3. Select Case Nummer
    5. Case "1"
    6. Verbrauch = True
    7. Wohnungsanzahl = False
    8. Wohnungsgroesse = False
    9. Objektbewohner = False
    10. Wohnungbewohner = False
    11. Case "2"
    12. Verbrauch = False
    13. Wohnungsanzahl = True
    14. Wohnungsgroesse = False
    15. Objektbewohner = False
    16. Wohnungbewohner = False
    17. Case "3"
    18. Verbrauch = False
    19. Wohnungsanzahl = False
    20. Wohnungsgroesse = True
    21. Objektbewohner = False
    22. Wohnungbewohner = False
    23. Case "4"
    24. Verbrauch = False
    25. Wohnungsanzahl = False
    26. Wohnungsgroesse = False
    27. Objektbewohner = True
    28. Wohnungbewohner = True
    29. Case "5"
    30. Verbrauch = False
    31. Wohnungsanzahl = False
    32. Wohnungsgroesse = False
    33. Objektbewohner = False
    34. Wohnungbewohner = True
    35. End Select
    37. End Sub

    Gruß Markus

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Westerwälder“ ()

    Sowas habe ich befürchtet. Und so sollte es eigentlich nicht laufen. Eine bessere Wahl ist ein Enum

    VB.NET-Quellcode

    1. Public Enum Zählerkriterium 'schlechte Benennung, da Umlaut und deutsch, aber das ist sekundär
    2. Verbrauch
    3. Wohnungsanzahl
    4. Wohnungsgroesse
    5. Objektbewohner
    6. Wohnungbewohner
    7. End Enum

    Aber x Booleans, die sich gegenseitig ausschließen, ist eine programmiertechnisch ungünstige Wahl.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Ich könnte noch typisiertes Dataset anbieten - post#2 revidiere ich - es scheint doch ziemlich einfach.
    Ein ganz klassischer Kandidat dafür.
    Bei Interesse empfehle ich die vier Views auf Video
    Mit korrekt gefügtem Dataset wird die Abrechnung zu dem, was sie eigentlich ist: Einfach nur paar Zahlen zusammenzählen und in den richtigen Datensatz schreiben.
    heut abend kannich auch mal was basteln.

    Wie gesagt, arbeite hier mit einer "Detailnummer"
    Benötige dazu nur eine weitere Spalte in der Datenbank.
    Weiterer Vorteil ist, das System ist flexibel und erweiterbar.
    Denke nun schon an den Ladestrom für das E-Auto eines Mieters in der Garage.

    Edit:
    Zu den Boolean-Properties,
    was muss passieren, das zwei auf True stehen können?
    Sehe die Gefahr nicht (RadioButton), zumindest kann der User dies nicht bewirken.
    Wenn doch, kann es nur ein Programmierfehler auslösen.
    Gruß Markus

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Westerwälder“ ()

    Westerwälder schrieb:

    Vielleicht bin ich hier auch ganz auf dem Holzweg.
    Ich glaub.
    Du brauchst keine Datenbank.
    Selbst wenn das Tool eine Multi-User-Anwendung wird, brauchst du erstmal keine Datenbank.
    Du brauchst ein vernünftiges Datenmodell.
    Die Konzepte, die ich bislang sehe, sehen mir nicht schlecht aus, und sind gut als typDataset umsetzbar.

    Aber die Frage ist, ob du dich auf diesen Weg machen willst.

    Die Datenbank gibt es bereits seit zehn Jahren.
    Das Thema Datenmodell/Dataset hatten wir beide schon öfters.
    Lese und Schreibe meine Daten manuell in eine Access-Datenbank.
    Mir gefällt einfach der Gedanke nicht, dass wenn ich mit einer
    festen Datenbankverbinung keine Änderung an einer Tabelle mehr
    vornehmen kann, bzw. für eine neue Spalte, eine neue Tabelle
    anlegen müsste.
    Gruß Markus

    Habe das nun soweit programmtechnisch realisieren können und schon tun sich neue Probleme auf.
    Soweit alles kein Problem wenn Mieter 12 Monate im Buchungs-/Kalenderjahr in der Wohnung verweilte.

    Beispiel nun:
    Haus A) Aussenwasser oder Aussenstrom = Summe Hausverbrauch minus (Summe der Wohnungen).
    Falls nun der Mieter im April auszieht?
    Zurückgreifen auf Durchschnittswerte der letzten Jahre,
    und wenn diese Vorgehensweise angestrebt wird, die Werte errechnen lassen oder jedes Jahr speichern?
    Ist sowas rechtlich gedeckelt?
    Macht keinen Spass mehr.
    Gruß Markus

Facebook
Telefonspende