Best practice für semistatische Teildaten?

verwendetes Datenbanksystem: <allgemein>

Hallo,
stellt euch mal vor, ihr sollt einen Webshop für einen Buchverlag entwickeln (ist nur ein Beispiel). So ein Buch gibt es entweder als gebundene Ausgabe, als Paperback oder als e-Book.
Ist es besser, für diese drei "Zustände" eine eigene Tabelle (deren Inhalt sich ja nie ändert!) in die DB zu setzen, um sie dann zu referenzieren?
Oder ist es nicht besser, solche Daten per code einzusetzen? Man definiert ein Enum mit eben diesen Werten und bindet es an eine DropDown-Liste. Der User wählt das Gewünschte aus und der entsprechende String (oder von mir aus auch ein Referenzwert) wird in die Tabelle book geschrieben.

Hi,

Von der dieser LookUp-Tabelle (so wirds in unserer Firma genannt) würde ich abraten. Alle anderen Konstrukte sind besser.

Mit einem Enum ist es immer schwierig. Ich würde ein Enum einsetzen wenn

• sich die Auflistung NIEMALS ändert. (Nur Sachen wie Geschlecht, Wochentag, o.ä. kann man sicher sein, dass es sich nicht ändert).
  oder
• die Auflistung wird AUSSCHLIEßLICH in diesem einen Code-Abschnit (Klasse, Assembly, etc.) verwendet (eine Änderung hätte keine Auswirkungen auf andere Code-Abschnitte).

Meistens gibt es aber noch bessere Möglichkeiten, die man Anwenden könnte: State-Pattern, Factory-Pattern (also verschiedene Typen für ), etc.

Gruß
Juy Juka

Auf die Idee, Patterns dafür zu benutzen, war ich noch gar nicht gekommen. Danke für den Tip, JuyJuka. =)

Moin,

Bei uns in der Firma haben wir das spielchen schon durch. Die Implementation läuft schon und ich könnte dir einen Teil der Assemblies anbieten (wenn du magst).

Gruß
Juy Juka

Ich würde ALLE Nutzdaten in der Datenbank halten. Erstens ist das System so einheitlich und jeder weiß, wo er die Daten findet. Zweitens bekommt man so keine Probleme, wenn man die Daten umformen, exportieren oder sonst was muss. Vielleicht sollen die Webshop-Daten ja irgendwann einmal turnusgemäß in ein Data Warehouse eingestellt werden. Wenn immer auf C#-Code angewiesen bin, um den Buchtyp in Klartext aufzulösen, habe ich mir selbst in Bein geschossen.

@JuyJuka
Da ich sowieo zur Zeit (unter anderem) auf der Pattern-Lernschiene bin, kommt mir das gerade recht. Je ein reales Beispiel für ein Factory- Pattern und ein State Pattern bitte. 🙂

@Rainbird:
Deine Einwände leuchten mir ein. Was aber wenn ich den Buchtyp gleich im Klartext in die Tabelle stelle? Würde es dann nicht nur einer nicht ganz durchnormalisierten DB entsprechen? Ich erinnere mich an die Worte meines ehemaligen Chefs beim DLR. Als ich ihm seinerzeit ein komplett normalisiertes DB-Konzept präsentierte, hielt er mir eine Standpauke. Die Essenz war, daß er das Modell für unnötig komplex hielt. Seine Sichtweise fand ich gar nicht verkehrt.
Ich meine, warum eine 16 Byte große GUID eintragen, die dann bei einer Query auch noch aufgelöst werden muß, wenn ich statt dessen auch einen maximal 9 Byte großen String einsetzen kann, der nicht aufgelöst werden muß?
Eure Meinung dazu?

Bei der normlisierung geht es nicht primär um Platzersparnis, sondern um
eine bessere Wartbarkeit und Erweiterbarkeit.

Eine SW nach MVP/MVC mit IOC und co ist bestimmt nicht einfacher
als eine normale Windowsforms Anwendung, aber ab einem gewissen
komplexitätsgrad ist sie schon deutlich einfacher zu warten/testen.

Eine SW nach MVP/MVC mit IOC und co

Ähm... kannst du das bitte mal auf Deutsch übersetzen? ?(

Nö, wenn du mit den Schlagworten nicht zurecht kommst, schlage sie selber nach,
das übt das suchen 😉

OK dann übersetze ich es mal:
Eine Short Wave (oder doch Software?) nach Model View Presenter/Model View Controller mit International Olympic Comittee... 😜
nein, Inversion of Control...bla bla
Schön, aber ist das jetzt pro oder contra Lookup-Tables?

Hi!

Ich würde dafür eine "Look-Up" Tabelle nehmen. Der Vorteil ist einfach, das man an einer Zentralen Stelle Daten hinzufügen oder Ändern kann, ohne den Quellcode anzufassen. Weiterhin stehen alle Daten in der Tabelle und können wunderbar für Reportings benutzt werden.

Aus meiner Sicht, spielt es eine untergeordnete Rolle, wenn das Datenbank-Modell durch die Normalisierung komplexer wird. Die Normalformen helfen ja nunmal dabei, dass Daten nicht redundant gespeichert werden. (Im Übrigen, große Applikationen wie z.B. SAP setzen auch "Lookup-Tabels" ein)

Danke für die vielen guten Tips. Ich habe mich jetzt für Lookup-Tables entschieden. Dazu habe ich noch eine "best practice"-Frage:
Ich bleibe mal bei dem Beispiel Buchtyp. Dieser Typ soll ja nur einmal vorkommen. Kann ich diese Tabellenzeile dann nicht gleich zum PK machen, oder ist es doch besser eine ID als PK zu benutzen.
Also so
ID uniqueidentifier <- PK
BookType nvarchar(20)

oder so
BookType nvarchar(20) <- PK

Was ist besser und warum?

Hi!

Also ich würde immer eine ID als Primär-Schlüssel nehmen!

Der Vorteil ist, das du durchaus mehre Spalten haben kannst, die du durch den PK ansprichst.

ID uniqueidentifier <- PK
BookTypeDE nvarchar(20)
BookTypeEN nvarchar(20)

Desweiteren lassen sich Spalten mit Zahlen besser sortieren, als mit Zeichen.

Wenn man den Speicherplatz zwischen int und char vergleicht, wird man auch feststellen, das ein int weniger platz braucht (oder täusche ich mich?)

Ich würde überhaupt keinen uniqueidentifier nutzen, da der imho hier keinen Sinn macht sondern nur in Systemen, wo Datenbank zyklisch zusammengespielt werden in eine universelle Datenbank. Wenn dem nicht so ist, würde ich als PK einen INT nehmen. Ob Autoincremental oder nicht ist da nicht relevant.

Als zusätzliche UNIQUE Spalte (Name) würde ich einen varchar nehmen, der dir erlaubt im Code über klare Namen zu suchen. Referenziert wird aber über die ID später. Weitere Spalte ist bei mir immer Description, welche dem User im GUI angezeigt wird. Der hat primär nichts mit dem Namen zu tun. Will der User eine Umformulierung, dann machst du ein Update in der DB. Hauptdache ID und NAME bleiben unverändert. Weitere Spalten sind je nach Bedarf auch noch möglich.

ID int,
Name varchar(50) UNIQUE
Description varchar(100)
...

Dann baust du dir noch eine WrapperKlasse NameToId, die dir die Id zu einem Namen liefert. Dann hast du eigentlich alles, was du brauchst, und bleibst ziemlich flexibel auf Änderungswünsche.