CleanCode-Unklarheit MySQL Enum/3.Normalf. -> C#-Auswertung

Moin,

entschuldigt meine evtl. etwas schwammig formulierten Titel.

In MySQL ist es in einer Tabelle erforderlich das mehrere fixe Werte eingetragen werden können.
z. B. Status {StatusFoo, StatusBar} und Bliblablubb {BlaFoo, BlaBar, Blablubb}

Diese werden in C# abgefragt und sollen ausgewertet werden.
Welche Form wäre dem CleanCode gerecht?

switch(status){}
enum Status {StatusFoo, StatusBar} 
Wie erreriche ich das save die Status zugeordnet und abgefragt werden können?
Per ID und 3. Normalform? 

Danke für Hinweise oder Ideen

Falls ich mich undeutlich ausgedrückt habe, bitte Nachfragen!

Die Beschreibung sagt aktuell nicht viel aus bzw. ist diese nicht verständlich.
Über was für Werte sprechen wir hier?
Wenn du in deinem Code einfach Enums hast, dann kannst du die Werte einfach in einer int Spalte speichern.

Wenn die Werte dann auch Verknüpft sind, dann hast du ein Enum mit Flags Markierung.
Dabei werden die Werte im Code auf Bit Ebene Verknüpft und landen in einem Feld.
Beim auslesen muss dann nur der Int wieder in das Enum umgewandelt werden.

Oder meinst du mit festen Werten, dass diese in einer anderen Tabelle hinterlegt und in einer zweiten referenziert werden?
Dann musst du, wie von dir schon bemerkt, über eine ID auf die erste Tabelle verweisen.
Hier wäre eine klarere Beschreibung hilfreicher.

T-Virus

Ich seh den Zusammehang von 3NF oder gar Clean Code hier nicht.

Enums werden prinzipiell auf DB Ebene als Ganzzahl (int, byte) dargestellt, außer wenn man sich für eine Custom Serialization.
Will man dass ein Enum mehrere Werte annehmen kann, muss dies zusätzlich als Flag markiert werden. Aber auch hier bleibt es technisch eine Ganzzahl (im Endeffekt dann ein Power of Two Bitfield: 1, 2, 4, 8, 16...).

Clean Code schreibt hier nichts vor.

Wie erreriche ich das save die Status zugeordnet und abgefragt werden können?
Per ID und 3. Normalform?

Das ist dann kein Enum mehr, sondern eine Entity Relation.

Ja, ich habe mich "etwas" holprig ausgedrückt.

In meinem Projekt brauche ich mehrere Modi (Pro UserRole) welche in einer Tabelle gespeichert werden (ab als Enum/Set oder 3. Normalform)
Diese müssen aber auch abgefragt werden. Die Daten werden also in der Klasse UserRole gespeichert und müssen später abgefragt werden.

Als enum wären das:

enum ProgramStatusBehavior {Automatik, Manuell, Beides} 
enum ErstellungsModi {Sendungserstellung, Ladelistenerstellung}

Recht einfach.

Man kann dann entweder den String des Enum/Set nehmen oder die ID (der Normalisierung) und für ein SwitchCase, If, whatever...
Es geht mir nicht darum wir ich ein SwitchCase bastel, eine Verzweigung im Code muss halt eindeutig die Modi abhandeln.

Mit Strings solltest du da nicht arbeiten.
Wenn du deine Einträge im Enum mal umbenennst, funktionieren diese nicht mehr bzw. hast du plötzlich unbekannte Werte in der DB.

Im Endeffekt sieht das aber nach einem Enum ohne Flags aus.
In dem Fall reicht die Speicherung der Werte in einer Spalte.
Da diese nicht dynamisch, also z.B. durch Benutzer angelegt/verwaltet werden, reicht hier eine int Spalte für den Wert.

T-Virus

Kurze Frage nach dem Use Case: willst Du hier eine eigene Art von Claim Based Authorization umsetzen; also Permissions einer Rolle?
Wenn ja, was ich da zumindest raus lese, dann solltest Du mit Entity Relations arbeiten und mit dem entsprechenden Verhalten von Claims. Bei Security eigene Dinge zu erfinden ist meistens keine gute Idee. Behalte standards bei, dann ist das auch einfach zu verstehen, wenn mal neue Leute ins Projekt kommen oder Dinge erklärt werden sollen.

Das heisst:

UserRole als Entity
UserRoleClaim als Entity (typischerweise mit Type und Value)
UserRoleClaimAssoications (n:m Tabelle von UserRole und UserRoleClaim).

ClaimTypes sind ein konstanter String-Wert, mit dem dann die Permission in der App abgefragt werden kann.

Selbst wenn es keine Permission Claims sind, so kannst Du jede Art von Anforderungen über ein Custom Claim Namespace relational umsetzen.
Der statische Zugriff im Code erfolgt immer über den konstanten String-Wert.

http://schemas.mycompany.com/myappname/identity/claims/modi.

Beispiele dazu: System.Security.Claims.ClaimTypes Class

Willst Du den Enum-Weg beibehalten, so sagt der Aufbau von

enum ProgramStatusBehavior {Automatik, Manuell, Beides}

Dass das so eigentlich nicht die Idee ist. "Beides" wäre ein klassischer Fall von Flags.

Demnach Normalisiert und ID (und Namen) abfragen und ne Runde switchcasen...

Claim Based Authorization und co - sagt mir gar nichts...

Ja, die UserRoles zielen darauf ab ein Login und daraufhin die UserRoles abzufragen (ist n JSON-Array) 
Ob da mehr an Sicherheit reinkommt ist Chefsache...

Zitat von echdeneth

Demnach Normalisiert und ID (und Namen) abfragen und ne Runde switchcasen...

Ich habe das anders verstanden: Die Enum-Werte als int in der Tabelle speichern und (eventuell mit einer Converter-Klasse) im Programm passend umwandeln.

Zitat von echdeneth

Ob da mehr an Sicherheit reinkommt ist Chefsache...

Der Chef hat davon keine Ahnung. Deswegen ist es unsere Aufgabe als Entwickler ihm das klar zu machen. 😛

Zitat von echdeneth

Claim Based Authorization und co - sagt mir gar nichts..

Dann fehlen hier Grundlagen. Gerade bei Security ist das dürftig.
Da ist tatsächlich euer Chef in der Verantwortung, dass ihr das Engagement habt, euch (selbst) weiterzubilden.

Claims sind nicht nur Permissions, sondern jede Art von Identity Property, was Du hier offenbar hast.
Solltest also nun erstmal Zeit nehmen Dich hier einzulesen, statt selbst was (schlechteres) zusammen zu puzzlen...

Das würde dann auch quasi unter "Clean Code" ⇒ Standards fallen.

Ja, die UserRoles zielen darauf ab ein Login und daraufhin die UserRoles abzufragen (ist n JSON-Array)

User Roles sind im Code immer unbekannt. Im Code sind nur Claims bekannt.
Claims können Permissions sein, oder auch einfache Mechanismen. Selbst Profilinfos wie LinkedIn Url, Twitter und Co sind einfach nur Claims mit eigenen ClaimTypes.

Unnötig das selbst zu bauen, wenn es dafür Standards und Best Practises gibt.

Ob da mehr an Sicherheit reinkommt ist Chefsache...

Nein, das ist wiederum Deine Aufgabe. Sowohl die Recherche wie auch die Umsetzung.
Du verantwortest das, nicht Dein Chef. Deswegen bist Du der Dev, nicht Dein Chef.

Habe es leider nicht geschafft zu erläutern was ich benötige.

Zu "Claims" und "Claim Based Authorization" leider kein Tutorial gefunden wo das verständlich erklärt wird. 
In allen Fällen wird ein (gefühlt) mehrjähriges .NET Studium und Erfahrung vorrausgesetzt. Wissen für bereits Wissende, nicht Wissensuchende.
Ich habe nicht den geringsten Schimmer wie ich dies verwende. Ohne dies ist das Thema bestenfalls abstrakt/theoretisch.

Also: Nutzername+PW → Claimdingens...

Zudem hängt dies mit ASP.NET zusammen welches ich nicht verwende.

UserRoles sind bei uns eine Sammlung von Daten die Nutzerspezifisch sind z.B.: FTP Zugänge/PW, Adresse, E-Mail-Zeugs, Lieferantenbesonderheiten usw. welche bei passenden Passwort/Username abgefragt werden können. Keine "UserRoles" um Claim Zusammenhang.

Zitat von echdeneth

Habe es leider nicht geschafft zu erläutern was ich benötige.

Zu "Claims" und "Claim Based Authorization" leider kein Tutorial gefunden wo das verständlich erklärt wird.

https://en.wikipedia.org/wiki/Claims-based_identity

Und wenn ich die Google Suche verwende, dann sehe ich sehr viele Treffer mit Tutorials, Erklärungen und Beispielen verschiedenster Identitätsanbietern.

A claim is a statement that one subject, such as a person or organization, makes about itself or another subject. For example, the statement can be about a name, group, buying preference, ethnicity, privilege, association or capability. The subject making the claim or claims is the provider. Claims are packaged into one or more tokens that are then issued by an issuer (provider), commonly known as a security token service (STS). ^[2]

Zudem hängt dies mit ASP.NET zusammen welches ich nicht verwende.

Nö. Claims sind nur Teil des generischen "Identity Konzepts", völlig egal was Du für ein Framework oder Technologie verwendest.
In ASP.NET Core Identity ist das nur schon alles fertig eingebaut, weil es ein "Identity Standard" ist, der schon fast 20 Jahre existiert.
Mehr dazu unter zB Identity Metasystem Interoperability Version 1.0 OASIS Standard 2009

Claims können alles mögliche sein: Berechtigungen, Profilinformationen, Feature Flags... alles.
Es ist einfach nur eine Entity Relation zwischen Usern/Rollen und Claims.

Hat jemand Rolle A, dann kommen n Claims mit, hat jemand auch/oder Rolle B, dann kommen nochmal n Claims mit.
Claims können aber auch direkt am User hängen (zB eben Profil-Infos wie Twitter Profil, Punkte, Ränge...)

Siehe meine Info oben:

UserRole als Entity
UserRoleClaim als Entity (typischerweise mit Type und Value)
UserRoleClaimAssoications (n:m Tabelle von UserRole und UserRoleClaim).

In allen Fällen wird ein (gefühlt) mehrjähriges .NET Studium und Erfahrung vorrausgesetzt. Wissen für bereits Wissende, nicht Wissensuchende.

Deswegen ist es immer besser, wenn man dazu schreibt, was der Use Case ist.
Dann müssen a) die Helfer nicht raten und b) die Leute, die das .NET Studium abgeschlossen haben, können Dir mit standardisierten Lösungen helfen / Dich darauf hinweisen.

Zitat von echdeneth

UserRoles sind bei uns eine Sammlung von Daten die Nutzerspezifisch sind z.B.: FTP Zugänge/PW, Adresse, E-Mail-Zeugs, Lieferantenbesonderheiten usw. welche bei passenden Passwort/Username abgefragt werden können. Keine "UserRoles" um Claim Zusammenhang.

Das Claimdingens passt eigentlich sehr gut zu eurem Szenario. Im von Abt verlinkten Wikipedia-Eintrag ist das ganz gut erklärt.
Das kannst du z.b. mit Active Directory machen. Dann bekommst du dann die meisten Sachen, die du oben angeführt hast umsonst dazu.