Hilfe bei DB-Modell (Aufgabenliste)

  • VB.NET
  • .NET (FX) 3.0–3.5

Es gibt 9 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Hilfe bei DB-Modell (Aufgabenliste)

    yo Leute,

    ich habe eine Frage zur Modellierung von folgendem Szenario:
    Entstehen soll eine Liste mit diversen Aufgaben welche je nach angemeldetem Benutzer angezeigt werden.
    Eine Aufgabe kann erstellt werden, wenn zB Benutzer A eine Erfassung abschließt. Hier bekommt Benutzer B diese in seine Liste um diese noch zu kontrollieren. (Beispiel)
    Es ist möglich die gewünschte Erfassung direkt aus dem Datagrid aufzurufen, da in der DB eine ID (Parameter ID1 Feld) dazu gespeichert wird.
    Nun gibt es aber unterschiedliche "Erfassungstypen". Bei der anderen Erfassung werden 2 IDs benötigt (Parameter ID1 und Paramater ID2 Feld).
    Bei der nächsten gibt es 3 Parameter usw.
    Mein derzeitiger Einfall dazu wäre:
    IDERFASSUNG_TYPUSER_VONID1ID2ID3
    (simple dargestellt)
    Was mir daran nicht gefällt, dass ID 2 und ID3 nur von bestimmten Erfassungstypen benötigt werden. ID1 bedeutet auch je nach Erfassungstyp etwas anderes.
    Wie modelliert man dazu solch eine Tabelle am Besten?

    lg
    ScheduleLib 0.0.1.0
    Kleine Lib zum Anlaufen von Code zu bestimmten Zeiten

    In einem Objektmodell würde ich eine Basisklasse Aufgabe nehmen und die Varianten daraus ableiten.

    Wie man aber solche Ableitungen in einem DB-Modell abbildet, will sich mir auf Anhieb auch nicht erschließen.
    Die Auslagerung in Stored Procedures oder in einen View verlagert dein Problem auch nur auf die Ebene der Datenbank.

    Aber du hast mich neugierig gemacht und ich bin gespannt, welche Antworten hier noch kommen.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Von der Anwendungsseite her wär es auch nicht das Problem. Jedoch gefällt mir es einfach nicht (Db-seitig) immer wieder solche "Parameterfelder" hinzuzufügen.
    Im Entity Framework CodeFirst gäbe es hier 3 Möglichkeiten (von Martin Fowler vorgestellt):
    1. Eine Tabelle mit allen Column. Hier würden natürlich einige der Columns leer bzw. NULL sein.
    2. Es gibt eine Master-Tabelle wo alle gleichen Spalten enthalten sind. Je Aufgabenbereich (wie es bei diesem Beispiel wäre) gibt es eine eigene Subtabellen mit einem Fremdschlüssel auf die Haupttabelle. Diese beinhaltet die spezifischen Felder
    3. Es gibt je Aufgabenbereich eine eigene Tabelle mit allen nötigen Feldern.

    Klar ist jetzt EF CF, aber so richtig anfreunden kann ich mich bei meinem Beispiel auch ned so richtig...

    lg
    ScheduleLib 0.0.1.0
    Kleine Lib zum Anlaufen von Code zu bestimmten Zeiten

    mir scheint, es gibt eine Aufgabenliste.
    Jede Aufgabe hat mehrere Teil-IDs.
    Und es gibt Benutzer.
    Jeder Benutzer hat mehrere Aufgaben.

    Datenmodell:
    Benutzer->Aufgabe->TeilId

    Die Bezeichnung Teil-ID ist sehr unglücklich, denn a) sagt sie nix aus, um was es geht bei der Aufgabe, und b) hat ID inne Datenbänkerei bereits eine eigene Bedeutung.

    Also du müsstest vor allem näher erläutern, was da geschehen soll:
    Werden da Autos auseinandergenommen, und bei einer Aufgabe müssen bestimmte Teile abgeschraubt werden?

    Und: Konzipier und programmier das besser erstmal ohne Datenbank - das ist noch so unklar, das wird sich noch zig mal ändern.
    Ich nehme an vier Views-Videos und ähnliches zum Thema "ohne Datenbank" ist dir bekannt?

    Ich erkläre den generellen Ablauf mal wie das ganze funktioniert:

    Fall 1:
    Bediener A speichert eine Umsatzerfassung (in frmUmsatzerfassung) und gibt diese frei -> für ihn somit abgeschlossen.
    In dem Moment wird eine Aufgabe erstellt damit das Controlling (sind 3 User) diese Umsatzerfassung nochmals kontrolliert.
    Bediener C (aus Controlling) sieht das in seiner Aufgabenliste. Nun hat er die Möglichkeit per Doppelklick die Form Umsatzerfassung (frmUmsatzerfassung) aufzurufen inkl. direkter Anzeige des gewünschten Umsatzes (ID der Umsatzerfassung; ID1 in der Aufgabentabelle)

    Fall 2:
    Bediener A erstellt eine Jahresvereinbarung (frmJahresvereinbarung). In dieser Vereinbarung verhandelt er bestimmt Konditionen. Es wird wieder abgeschlossen
    Es wird wieder eine Aufgabe für das Controlling erstellt.
    Bediener B (anderer Bediener aus Controlling) sieht das und kann auch hier per Doppelklick in die Jahresvereinbarung springen(ID der Jahresvereinbarung; ID1 in Aufgabentabelle). Zusätzlich soll die gewählte Konditionen (welche auch in der Aufgabenliste erscheint) direkt vorgewählt werden (ID in Konditionstabelle; ID2 in der Aufgabentabelle)

    Das ganze würde es auch noch mit 3 solch "ID-Spalten" geben.

    Das Datenmodell schwebt mir eher so vor.
    Aufgabe->AufgabeBediener (1:n) da eine Aufgabe an mehrere Benutzer adressiert sein kann.

    Es existiert bereits eine SQL-Server Datenbank im Hintergrund, aber das ist im Prinzip ja nicht relevant.

    lg
    ScheduleLib 0.0.1.0
    Kleine Lib zum Anlaufen von Code zu bestimmten Zeiten

    fichz schrieb:

    Es existiert bereits eine SQL-Server Datenbank im Hintergrund, aber das ist im Prinzip ja nicht relevant.
    Wie gesagt: Das ist hochrelevant. Denn dein Datenmodell wackelt noch, und da kannst du dann bei jeder Änderung die ganze DB neu aufziehen.

    und eine Aufgabe scheint mir nur einem Controller zugeordnet. Zunächst mal wird sie ohne Zuordnung erstellt, aber sobald ein Controller darauf doppelklickt, isses seine, und keines anneren.

    Ich sehe hier auch gar keine Entität "Aufgabe".
    Es gibt Jahresvereinbarungen und Umsatzerfassungen.
    Zwei verschiedene Entitäten, mit jeweils einem Bediener, der von vornherein feststeht, und einem Controller, der sie sich ggfs. herauspickt.

    Bediener->Umsatzerfassung<-Controller
    Bediener->Jahresvereinbarung<-Controller

    Auch wenn sowohl Umsatzerfassung als auch Jahresvereinbarung für den Controller eine Aufgabe darstellt, die er evtl. sogar gleichartig abarbeitet, kann man diese beiden Entitäten leider nicht in eine Super-Entität "Aufgabe" zusammenfassen.
    Scheint mir auch garnet vorteilhaft, denn wenn ein Controller sich eine Jahresvereinbarung schnappt, kriegt er sicherlich ein anneres Form zu sehen, als wenn er sich eine Umsatzerfassung vornimmt.

    Aber nochmal zum Vor-Thema "DatasetOnly": Inne Vorbemerkung zu Daten laden und speichern hab ich das nochmal ausargumentiert, weil das iwie ein schwer zu akzeptierender Gedanke zu sein scheint.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Genau da liegt ja jetzt mein Problem. Ich weiß nicht wie ich hier das DB-Modell dazu konzipieren soll.
    Zum Thema DB. Das Programm existiert bereits. Der Aufgabenpunkt soll halt dazukommen und das Arbeiten miteinander zu erleichtern (sitzen nicht alle im selben Raum).
    Gewünscht wird sich das halt genau so wie ich es zB in den beiden Fällen beschrieben habe.

    Die Aufgabenliste soll im Wesentlichen ja nur eine Hilfe für die einzelnen Bediener sein, um zu sehen welche Punkte von ihnen noch abgearbeitet werden sollen.
    Denn wird zB eine Umsatzerfassung nur gespeichert, jedoch noch nicht abgeschlossen, hat sie dem Controller nicht zu interessieren.
    Und da denk ich ist nur der Weg über solch einer Tabelle möglich.

    Das mit dem "DatasetOnly" teile ich die Meinung nicht zu 100%. Ich entwickle nicht auf einer produktiven Datenbank. Es gibt hier bei uns einen Test-SQL Server. Und hier kann ich das Datenmodell jederzeit ändern bzw. rücksichern. Abgesehen davon wird auch mit SPs, Functions und Views gearbeitet welche, soweit ich weiß, von einem Dataset nicht verwendet werden kann.

    lg
    ScheduleLib 0.0.1.0
    Kleine Lib zum Anlaufen von Code zu bestimmten Zeiten

    zu DatasetOnly: Wenn du ein klein Sample hättest, und ein Problem damit, du könntest es anhängen, und ich bastels dir um, dasses läuft. War gelegentlich so, dass so in 30 min zu lösen war, wo ein TE Tage vor gesessen hat.
    Mit deim SqlServer dahinter dieses eine der Optionen, die dir verschlossen sind.

    fichz schrieb:

    wird auch mit SPs, Functions und Views gearbeitet welche, soweit ich weiß, von einem Dataset nicht verwendet werden kann.
    Wie kommste da drauf? Dem Dataset ists doch egal, wies befüllt wird, das eröffnet ja grade die Chance, DatasetOnly zu arbeiten.
    Und dass euer Db-Zugriff so kompliziert vorgesehen ist (warum eiglich?), ist nur noch ein Grund mehr, das hintanzustellen.
    Aber es ist eiglich müßig, die Argumentation, auf die ich ja bereits verlinkt habe, immer wieder neu zu repetieren.

    Zum Datenmodell: Wie gesagt: Wie ich es sehe gibt es keine Entität "Aufgabe", und dein Datenmodell wird folglich nicht aufgehen, wenn du sone Tabelle mit aller Gewalt einführen willst.

    JahresVereinbarung und Umsatzerfassung benötigen nur jeweils 2 zusätzliche Spalten.
    Die eine verweist auf den Controller, und die annere sei ein DateTime, was eingetragen wird, wenn ein Controller fertig-kontrolliert hat.

    Um alle unerledigten Jahresvereinbarungen anzugugge setze einen Filter mit "ControllerID Is Null".
    Dito mitte Umsatzerfassungen.

    Kannst du das von mir vorgelegte Datenmodell denn nachvollziehen?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Hm der Weg in die mit den zusätzlichen Spalten in den anderen Tabellen ist ein interessanter Punkt.
    Das mit der ControllerID wird nicht funktionieren, weil es auch sein kann, dass die Aufgaben auch an "normale" Bediener gesendet werden können.

    Was mit jedoch einfallen würde wäre folgendes:
    Die Tabelle Aufgabe enthält keine ID Spalten mehr ->
    IDERFASSUNGS_TYPUSER_VON

    Jedoch erhalten die Tabellen Jahresvereinbarung und Umsatzerfassung eine neue Spalte mit der AufgabenID.
    Wenn ich das nun Objektorientiert lösen will hätte ich mir eine Basisklasse Aufgabe geschaffen mit Ableitungen des jeweiligen Erfasssungs-Typs. Die Fallunterscheidung wäre so oder so notwendig da ja unterschiedliche Forms aufgerufen werden sollen. In diesen Unterklassen ist der SQL-Query verjoint mit der relevanten Tabelle und ich würde so an alle relevanten Daten kommen um alles korrekt zu selektieren bzw. anzuzeigen.
    So zumindest meine Theorie.

    lg
    ScheduleLib 0.0.1.0
    Kleine Lib zum Anlaufen von Code zu bestimmten Zeiten

    also wenn ein Bediener auch Controller sein kann, brauchst/hast du eine Rechteverwaltung.
    Dann heisst der ForeignKey aber trotzdem ControllerID, und verweist halt auf einen User (und der muss Controller-Rechte haben, aber das sicherzustellen ist glaub Sache der Programmierung, nicht des Datenmodells)

    Also die User-Tabelle erhält primitivstenfalles noch eine Bool-Spalte "CanControl".
    Und man kann nicht mehr exakt von Bedienern und Controllern sprechen, sondern es gibt nur noch User, und manche dürfen eben auch controllen.

    Nochmal zu DatasetOnly: Guggemol Datenmodell geht nicht
    In paar Minuten mehrere eiglich ganz blöde Fehler gefunden, die selbst zu finden - auch mit Forum-Unterstützung - annähernd unmöglich wäre, denn a) wusste der TE kaum, wo suchen, und b) mussten erst alle Fehler gemeinsam behoben sein, bevor ein Fortschritt erkennbar wurde.
    Solch ist mit hinterlegtem SqlServer prinzipiell unmöglich.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

Facebook
Telefonspende