Sven Rautenberg: Abbildung von Webhosting-Angeboten

Beitrag lesen

Moin!

(An dieser Stelle ist natürlich blöd, dass du alle unterschiedlichen Artikeltypen in einer Tabelle hast. Das Problem läßt sich über eine weitere Spalte "Typ" lösen, die n:1 verknüpft ist mit einer Tabelle "Artikeltypen", in der einer Artikeltyp-ID eine Artikeltypbezeichnung zugeordnet ist - ist aber für die Betrachtung hier irrelevant, sondern eigentlich nur interessant für die GUI).

Kannst Du das mal konkretisieren? Irgendwie peil ich das gerade nicht

typ:
id  name
1   domain
2   webspace

artikel:
id  typ  value  einzelpreis
1   1    DE     0.49
2   1    COM    0.99
3   2    100    0.99
4   2    200    1.49

Genau so. Grund: Wenn du eine Auswahlliste machen willst, in der du Megabytes auswählen willst, sollen da natürlich keine Domains drin vorkommen. Das ist also primär als Ordnungskriterium zu sehen, es hat vielleicht dann noch die Relevanz, dass du die DB befragen kannst, welche Bundles denn alles irgendwelche Domains enthalten (kann ja auch Bundles ohne Domains geben). Dann gehst du über den Typ 1 (domain) in die Artikel, kriegst alle IDs von Domains, gehst damit in die n:m-Verknüpfung, und von dort aus in die Bundles, und kriegst alle Bundles, die _irgendeine_ Domain im Angebot haben.

Mag für dich irrelevant sein, wenn alle Bundles eine Domain haben. :) Aber das System ist darauf vorbereitet.

Welchen Typ soll dann value haben - oder hast Du das anders gemeint?

value ist ein Textstring, der für den Menschen beschreibt, was der DB-Eintrag bedeutet.

Keine Sets, Enums oder sonstiges. :)

Wahlmöglichkeit bewerben, aber zwei verschiedene Bundles verwenden. Oder den Domaintyp ".de oder .com" wählen.

Ersteres scheidet aus, wenn ein Angebot 100 Domains jeweils wahlweise
DE oder COM enthält - soll ich dann 101 Bundles verwenden? :-)

Nein. Du hast ein Bundle "mit 100 Domains". Frage: Welche Domains? Nur .de-Domains? Dann verknüpfst du "Bundle 100 Domains" in der n:m-Tabelle mit dem Artikel ".de-Domain" - und da du einen Zähler für die Anzahl der Verknüpfungen anlegst, schreibst du da eine 100 rein. Damit weißt du: Das Bundle enthält 100 .de-Domains. Die "wahlweise .de/.com" Artikel ließen sich natürlich so auch verknüpfen. Dann zeigst du eben auf den "wahlweise"-Artikel.

Könnte man nicht auch eine Tabelle domains anlegen?

Man kann alle möglichen Tabellen anlegen. :) Die Kunst ist, genau die Tabellen anzulegen, die dem Problem weiterhelfen.

artikel_domains:
id  tld      quantity  fee
1   DE       1         0.49
2   COM      1         0.99
3   DE, COM  5         NULL

tld ist eine Enumeration und gibt die möglichen TLDs an, quantity die
Anzahl, sodass Datensatz 3 dem Kunden 5-mal die Wahl zwischen DE und
COM lässt. fee = NULL gibt an, dass das so keinen Preis hat und nur in
einem Bundle vorkommt.

Deine ENums sind ja Sets, und in Sets kannst du typischerweise nur 64 verschiedene, dafür aber beliebig kombinierbare Werte codieren. Hatte ich irgendwo im Thread schon geschrieben, dass das bei TLDs knapp werden könnte. Es ist "broken by design", ein Set oder Enum für etwas zu verwenden, von dem es prinzipbedingt unendlich viel geben kann. Und von TLDs kann es grundsätzlich beliebig viel geben. Verwende Enum für so Dinge wie "ja/nein", "männlich/weiblich", Benutzerrechte "lesen/schreiben/löschen/verschieben/kopieren/anmerken" (die werden einmal beim Design vorgegeben, ändern sich aber im Betrieb dann nicht mehr) etc. Für Sets gilt dasselbe (die sind bei Benutzerrechten wohl geeigneter).

- Sven Rautenberg

--
"Beim Stuff für's Web gibts kein Material, was sonst das Zeugs ist, aus dem die Sachen sind."
(fastix®, 13. Oktober 2003, 02:26 Uhr -> </archiv/2003/10/60137/#m338340>)