Hallo Matthias,
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.
Was?? Nein, NULL != NULL ist wahr, du kannst soviele NULL-Werte einfügen wie du willst:
MariaDB [test]> CREATE TABLE foo(bar INT UNIQUE);
Query OK, 0 rows affected (0.05 sec)
MariaDB [test]> INSERT INTO foo (bar) VALUES (NULL);
Query OK, 1 row affected (0.01 sec)
MariaDB [test]> INSERT INTO foo (bar) VALUES (NULL);
Query OK, 1 row affected (0.01 sec)
MariaDB [test]> INSERT INTO foo (bar) VALUES (NULL);
Query OK, 1 row affected (0.01 sec)
MariaDB [test]> INSERT INTO foo (bar) VALUES (NULL);
Query OK, 1 row affected (0.00 sec)
MariaDB [test]> SELECT * FROM foo;
+------+
| bar |
+------+
| NULL |
| NULL |
| NULL |
| NULL |
+------+
4 rows in set (0.00 sec)
MariaDB [test]>
Das gilt für MySQL und PostgreSQL auch, nur MS SQL ist da kaputt und hält sich nicht an den Standard.
Mir ging es aber auch um den logischen Unterschied, nicht um den technischen.
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?
Ja.
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?
Man nutzt eine Funktion, die einem mehr oder weniger garantiert, dass die ID nur einmal auftreten kann. In anderen Sprachen wäre das eine UUID oder eine GUID, in PHP muss man dafür auf uniqueid() zurückgreifen; da die Funktion aber eine Funktion der Zeit ist, sollte das hier auch gegeben sein. Kollisionen werden damit so unwahrscheinlich, dass man sie ignoriert. Wenn man es aber richtig[tm] machen will, setzt man die Spalte regelmäßig auf NULL oder so, ja.
LG,
CK
nicht angemeldet
Matthias Apsel
Der Martin
Auge
