Datenmodell mit nullables

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

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

    Datenmodell mit nullables

    Hallo,

    ich habe dieses Datenmodell, die Fragezeichen markieren die Spalten, die Null-Werte enthalten können und so wie es momentan ist auch können müssen. Abhängig vom Status werden diese Spalten Null oder nicht Null sein.


    Ist das ein korrektes Modell oder muss ich das weiter aufteilen?

    Viele Grüße

    Es kommt auf den hinterlegten Datentyp an und Du kannst festlegen, was der Nullwert ist und was passiert, wenn versucht wird, Null/Nothing zu hinterlegen. Von daher: »kommt drauf an …«
    »Alternativort« klingt nach String.
    Klar könntest Du auch eine Untertabelle für Alternativort machen. Oder überhaupt für Ort. Aber damit könnte es auch insgesamt komplizierter werden.
    Was genau ist FailStat?
    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.

    Es gibt einen Status für eine erfolglose Umpositionierung. Nur dann gibt es einen FailStat, dieser sagt widerum etwas über den Grund des Misserfolgs aus.
    Objekorientiert gedacht müsste man ja sagen "Ein Wagen hat einen FailStat", aber ein Wagen hat nur einen FailStat wenn Status = x
    Dafür mache ich auch noch eine zweite Statustabelle bzw. kommt da einfach eine zweite Bedeutungsspalte in die Statustabelle. Dann müsste ich da aber auch einen Fremdschlüssel anlegen und der würde ja nicht mehr Null erlauben für FailStat

    Warum ist der Datentyp relevant? Die Typen sind string und smallint.

    Naja die Spalten haben einfach in manchen Fällen keine Bedeutung, ich könnte einen leeren String hinterlegen respektive -1, aber dadurch ändert sich die Situation ja nicht, oder?

    Die Orte sind zahlreich und dynamisch, eine Tabelle dafür wäre sicher aufwendig zu pflegen und umfangreich.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Haudruferzappeltnoch“ ()

    @Haudruferzappeltnoch Deine Fälle würde ich per Enum beschreiben, das kann man ggf. in Dein smallint packen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Statt einen Failstat würde ich einen Status* setzen, bei dem 0 = alles in Ordnung bedeutet. Und Alternativort: Leerstring oder, wenn Status ungleich 0, dann was anderes.

    * oh, eine Spalte namens Status hast Du ja schon. Was hat dann Status wieder für eine Bedeutung?
    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.

    Status des Wagens, ein Status kann zum Beispiel die erfolglose Umpositionierung sein, diese kann aber mehrere Gründe haben.
    Vielleicht mache ich einfach einen Status für jede mögliche erfolglose Umpositionierung.

    Dasselbe Prinzip für einen Ort ist allerdings utopisch. Auf der anderen Seite ist eine Alternative ja auch verständlicherweise optional

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

    Hm, schwierig, jetzt noch weiterhelfen zu können, weil das noch diffus klingt. Wenn Dir absolut klar ist, wann Status verwendet wird und wann Failstat, dann ok. Aber wenn nicht, dann ja: Dann muss Dein Datenmodell noch präzisiert werden. Kannst ja die Gesamtsituation erklären. Ich hab selbst schon oft erlebt, dass ich einen (Start)Post schreibe (und damit ein Thema im Forum anfangen will) und während des Schreibens, vor allem bei der präzisen Beschreibung des Problems und des Wunschverhaltens ist es mir wie Schuppen aus den Haaren gefallen und mir wurde klar, was ich machen muss.
    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.

    Ein Wagen hat immer Maße einen Status und einen Standort.
    Für manche Stati wird der Standort per GPS ermittelt, welches nicht immer genau richtig ist. In solchen Fällen gibt es einen Alternativort, der wenn er nahe dem GPS-Standort liegt wahrscheinlich der echte Standort ist.
    Manchmal stimmen diese Standorte überein und manchmal liegen sie so weit auseinander, dass natürlich das GPS gewissermaßen mehr recht haben muss.

    Für andere Stati ist der Standort stattdessen fest und der Hintergrund von Alternativort verliert sich. Diese Standorte könnte ich zu Eigenschaften des Status machen statt eine Eigenschaft von Wagen. Dann sind aber die Abstellorte in WagenTab auch Nullable, weil für die entsprechenden Stati einfach Ort genommen wird, der ja dann auch Nullable ist. Also das Splitten ist wohl eher keine gute Idee.

    Nenn mal bitte ein Beispiel. Ich blicke grad den Unterschied zwischen Abstellort, Alternativort, Ort und Status nicht.
    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.

    Wenn es einen Ort und genau einen AlternativOrt gibt, dann kann man das mw. mit 2 Spalten machen.
    Allerdings halte ich von nullable Strings garnix, weil ich finde, 'kein Ort' ist für die Datenverarbeitung besser ausgedrückt durch genau "" statt mal duch dbNull, mal "" oder mal dieses oder das.
    Nullable String ist nur nötig, wenn "" noch was anderes aussagen soll als 'nichts' - also so gut wie nie.

    Ansonsten für manche Datenbänker wohl etwas eigentümlich, dass AbstellOrt eine Wagen-Eigenschaft ist. Der verändert sich ja ständig.
    Ein Datenbänker würde wohl eine Abstell-Historie anlegen (weisst ja, Sammelwut...).

    Übrigens sehe ich da wieder Plural-Tabellen-Benamung - was mir auch ein Graus ist. Was soll das sein, ein "Stati"?
    Da generiert dir das Dataset für deinen Code die fabelhafte Navigations-Property myWagen.StatiRow. Aber es ist kein Stati, es ist eine Status.
    Bei Wagen eher unproblematisch, da weiss man nicht, obs Singular oder Plural ist.

    Weiters würde ich den FK unbedingt nach Schema F benennen, also wenn die Tabelle Status heisst, deren PK ID, dann heisse ein Fremdschlüssel auf Status.ID StatusID.
    Dann erkennt man die Relation inklusive 1 und n sogar ohne das typDataset vor Augen.
    Der FK soll nicht Status heissen, und auch nicht StatiID.

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

Facebook
Telefonspende