MySql Foreign Key nötig oder unnötig

[OnDemand]

Guten Abend zusammen,

wir hatten grad eine kleine Diskussion zu folgendem Beispiel und folgende 2 Lösungen. Welche ist sinnvollste und warum? Bin gespannt ob ich auf dem Holzweg bin:

Es gibt einen Artikel:

- id
- name
- preis
- usw.

Jeder Artikel hat eine Besteuerung, entweder vollbesteuert oder ermäßigt (Die höhe der Steuer ist an der Stelle nicht relevant, da sie erst in einem anderen Programm länderspezifisch benötigt wird dann ist CH 7 und 4% und AT auch anders)

Sollte man nun eine weitere Tabelle einführen

tax_class
1, Ermäßigt
2. vollbesteuert

und die jeweile ID im Produkt speichern?

Ich habe folgendes gemacht:

//Artikeldaten wie id, preis usw

@Enumerated(EnumType.STRING)
private TaxEnum taxClass;

public enum TaxEnum {
    TAX_CLASS_FULL("Standardsatz"),
    TAX_CLASS_REDUCED("Ermäßigter Steuersatz");
    private String name;
  
    TaxEnum(String stringVal) {
        name = stringVal;
    }
    public String toString() {
        return name;
    }

    public static String getEnumByString(String code) {
        for (TaxEnum e : TaxEnum.values()) {
            if (e.name.equals(code)) return e.name();
        }
        return null;
    }
}

Ich setze dem Artikel einfach das Enum und speichere es ab. Dann steht in der DB TAX_CLASS_FULL zb statt der ID einer anderen Tabelle. Frisst vermutlich mehr speicher aber finde es unnötig eine separate Tabelle zu erstellen.

Was meint ihr?

 

[mihe7]

Dein enum ist auch eine ID und die "Tabelle" existiert außerhalb der DB. Kann man m. E. durchaus machen. Man verliert halt die Möglichkeit, den Anwender neue Werte hinzufügen zu lassen.

 

[OnDemand]

Danke. Gibt immer nur die beiden Möglichkeiten voll oder ermäßigt besteuert Daher sollte das nachträgliche anlegen kein Problem sein

 

[mihe7]

Das heißt nicht, dass eine zusätzliche Tabelle nicht sinnvoll sein kann. Wenn Du z. B. Queries hast, die ohne weiteres Zutun den Klartext enthalten sollen, womöglich noch in verschiedenen Sprachen, dann wird es ohne Tabelle schwierig