Abbildung von Webhosting-Angeboten

[Sven Rautenberg]

Moin!

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?

Ein Index ist eine schnelle Suchtabelle, in der die Datenbank sucht, welche Datensätze aufs Kriterium passen. Die Alternative zum Index wäre, jeden Datensatz tatsächlich einzulesen und auf Übereinstimmung zu prüfen. Sowas ist üblicherweise langsamer, als der Index.

Wenn du die ODER-Verknüpfung für ".de oder .com" in die DB legst, und dann beispielsweise alle Bundles mit ".de-Domain" herausfinden willst, dann fallen in diese Abfrage sowohl "nur .de" als auch alle "oder"-Kombinationen.

Mit einem Set kannst du sowas machen. Da sind Bits gesetzt, nach denen die DB einzeln suchen kann. Sie würde also in diesem Fall nur nach dem ".de"-Bit suchen. Und das könnte tatsächlich per Index funktionieren (wenn der Index das unterstützt).

Wenn du die Domain-Angabe aber beispielsweise in einem Textfeld untergebracht hast, indem du "de" und "de||com" und "info||de||com||net||org" in einzelnen Datensätzen gespeichert hast, dann mußt du mit LIKE '%de%' suchen - und ein % am _Anfang_ des Suchstrings bedeutet: Full Table Scan. Kein Indexzugriff, die DB muß die gesamte DB einlesen und durchsuchen, um zu finden. Das ist schlecht.

Natürlich hängt "schlecht" von der Größe der Tabelle ab. Kleine Tabellen sind trotzdem schnell durchsucht. Aber die Kombination mit anderen Tabellen machts. Du wirst mit Sicherheit JOINs benutzen, um die DB abzufragen. Und dabei helfen Indices enorm, Performance zu bekommen.

Das Problem ist das "wahlweise" in der Geschichte. Das solltest du tatsächlich irgendwie anders auffangen. Es ist eklig.

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.

Tja, aber was ist, wenn sich der Preis eines Artikels ändert. Sagen wir, die .de-Domain wird billiger. Für die _aktuellen_ Preise deiner _Angebote_ ist das relevant, also änderst du (mit Timestamp) den Datensatz ".de-Domain" im Preis.

Dadurch berechnen sich möglicherweise alle definierten Bundles neu - zumindest kriegst du aber eine Liste ausgegeben, welche Bundles dieses Element enthalten und neu berechnet werden müßten.

Was deine Kunden angeht: Die arbeiten nicht mit den aktuellen Artikelpreisen, sondern mit den vertraglich festgelegten Preisen. Dazu mußt du ohnehin den zum Vertragsabschluß festgelegten Preis irgendwo speichern.

Du hast dabei eigentlich nur zwei Ansatzpunkte:
1. Einfach.
2. Umfangreich.

1. Du hast für die aktuellen Angebote deine Tabelle mit den Artikeln, und für geschlossene Verträge (bei denen sich der Kunde ja beispielsweise auch für eine konkrete der Wahlweise-Domains entschieden hat) hast du eine zweite Tabelle, welche 1:1 den Vertragspreis mit dem Artikel in der Artikeltabelle verbindet. Somit hast du den damals gültigen Preis zusammen mit dem Artikel, welcher über ein Bundle zusammengefaßt ist.

Besser allerdings wäre, wenn du Vertragsabschlüsse und Bundle-Angebote tabellenmäßig komplett trennst. Ein Vertrag ist vom Prinzip her zwar auch ein Bundle, aber er enthält konstante Preise, die sich nur bei bestimmten Anlässen ändern und grundsätzlich individuell gestaltet sind/sein können.

Deshalb: Bundles, die in einen Vertrag münden, gehören zum Vertragsstichtag kopiert, damit der Preis gerettet wird, der gültig war.

2. Umfangreich wäre, wenn du in der Artikelliste statt des Feldes für den aktuellen (und einzigen) Preis eine Tabelle 1:n verknüpfst. Diese Tabelle enthält:
preistabelle:
id  art_id   preis   gueltig_ab

Auf diese Weise kannst du einem Artikel einen Preis zuordnen, der ab einem bestimmten Datum gültig ist, und durch einen neuen Eintrag mit einem späteren Gültigkeitsdatum geändert wird. Auch Preisänderungen für die Zukunft lassen sich auf diese Weise einpflegen.

Die Datenbankabfrage wird dadurch aber keinesfalls einfacher. :)

Damit kannst du aber auf jeden Fall den Preis feststellen, der für einen bestimmten Stichtag galt. Wenn du also das Vertragsschließungsdatum hast, kannst du die zu dem Zeitpunkt gültigen Preise feststellen. Um ein Preisupdate für den Kunden hinzukriegen, machst du einfach ein Datumsupdate.

Wie du es hinkriegst, bei den verschiedenen Bundles und Einzelzukäufen den Überblick zu behalten, insbesondere, wenn das Bundle einen neuen Preis kriegt, der Einzelzukauf aber nicht, sei dir überlassen. Diese Aufgabe ist weit weg von "trivial". :)

- Sven Rautenberg