Wiki-Artikel Reloadsperre

[Matthias Apsel]

Hallo Christian Kruse,

Ich würde Teil 1 und Teil 2 lassen und in Teil 3 ein künstliches UNIQUE-Constraint vorstellen, denn das unterscheidet sich ja schon deutlich von einem Primärschlüssel.

Naja, so groß sind die Unterschiede ja nun wirklich nicht. Beide fordern die Eindeutigkeit der entsprechenden Spalten, bei UNIQUE ist NULL (für jede beteiligte Spalte) genau einmal erlaubt, bei PRIMARY KEY nicht. Damit ist eine UNIQUE-Spalte doch auch nur ein Zweit- oder Drittschlüssel.

Denn das Token als UNIQUE-Constraint-Spalte in die DB einzutragen entspricht ja eigentlich dem, was unter natürliche Primärschlüssel beschrieben ist.

Der Grundgedanke ist der Gleiche, ja - ist er aber ja auch bei der Variante mit den Sessions. Ich betrachte ein eindeutiges Kriterium um zu prüfen, ob ich die Daten schonmal hatte.

Hebt man denn die Tokens bis in alle Ewigkeit auf? Denn es könnte ja nun passieren, dass identische Tokens generiert werden. (Wenn die Wahrscheinlichkeit doch auch sehr klein ist) Speichert man da zusätzlich noch einen Zeitstempel mit und setzt man Token und Zeitstempel zusammen auf UNIQUE Oder macht man sich um diesen praktisch nur theoretisch (sic) auftretenden Fall keine Gedanken?

Bis demnächst
Matthias