Peter Thomassen: Abbildung von Webhosting-Angeboten

Beitrag lesen

Hallo Sven!

Verstanden. Der Vorteil liegt wohl darin, dass ich die Trennzeichen
nicht mehr brauche.

Genau. Du kannst dadurch mehr Fragen von der Datenbank beantworten lassen, bzw. die Beantwortung ist wesentlich unaufwendiger, weil Indices zum Zuge kommen können.

Klärst Du mich mal kompakt über Indizes auf?

Der Nachteil liegt darin, dass ich auf Anhieb
nicht weiß, wie man bei Angebotsänderungen nachvollziehen kann, wann
was aktuell war (beim anderen Ansatz würde ich dafür einfach eine
Spalte timestamp verwenden).

Sollte man dann noch x:y:<timestamp>:timestamp einfügen - oder wie?

Willst du historische Daten speichern? Dann wird die Sache nochmal wesentlich komplizierter. Grundsätzlich gilt: Die Datenbank spiegelt den derzeit aktuellen Zustand wider.

Weshalb? Ich würde eine Tabelle mit Timestamp zur Verknüpfung von
Kundendatenbank und Angeboten erstellen, um Verträge zu beschreiben. Nun muss ich doch bei der Rechnungsstellung berücksichtigen, welches
Angebot der Kunde damals wahrgenommen hat.

In Wirklichkeit ist tld eine Enumeration, da COM, NET, ORG dasselbe
kosten. Oder würdest Du das auch wieder anders machen, d.h. für jede
Domainendung einen Datensatz anlegen und tld wirklich zum String
machen, mit den Wert de || com für die Wahlmöglichkeit zwischen DE und
COM verwenden?

Enumerationen? Oder Sets?

Sets, sorry.

Sets hingegen sind zahlenmäßig begrenzt auf (bei MySQL) 64 Stück = 64 Bit. Es gibt aber mehr als 64 TLDs, also sorgst du an dieser Stelle unnötig für eine absehbare Begrenzung, die dich später ärgern wird.

Mit Sets kannst du aber in der Tat elegant "com, net, org" in einen Datensatz packen, und auch "com oder de" läßt sich so abbilden - einfach alle TLDs in den Datensatz reinpacken, die erlaubt sind. Die Begrenzung der möglichen TLDs wirkt aber IMO zu stark negativ.

Ich weiß, bloß ist mir nichts anderes eingefallen ... :-)

Danke,
Peter