mysql: Zahl-ID vs. Mix-ID
0 0 
Matthias Apsel
0 
dedlfix
0 
MudGuard
0
mysql: Zahl-ID vs. Mix-ID
Folgendes Vorhaben:
Ich betreibe eine Community in der jeder User eine ID erhält:
userId BIGINT AUTO_INCREMENT PRIMARY KEY
Ich möchte aber vermeiden, dass man anhand der URL auf die Position innerhalb der Datenbank schließen kann.
Um dies zu vermeiden, gibt es noch eine "publicId" die quasi nach "außen" sichtbar wird.
Wenn ich also mit der Datenbank kommuniziere, muss ich zuerst anhand der publicId die userId ermitteln, weil userId ja nicht in der Adresszeile des Browser auftauchen soll.
Nun meine Frage:
Was genau spricht eigentlich dagegen, von begin an eine userId der Art "72H2H.J8_F6" zu verwenden und diese auch als PRIMARY KEY festzulegen. Dann könnte ich mir jeweils ein Statement sparen.
Ist das aber auch performant?
Wie macht es denn YouTube? Meint ihr, die Video-ID im Browser ist dieselbe, wie in der Datenbank?
-
Ich möchte aber vermeiden, dass man anhand der URL auf die Position innerhalb der Datenbank schließen kann.
Schätzungsweise um nicht rauszugeben in welcher Reihenfolge sich die User angemeldet haben?
So schlimm wäre das aber vielleicht auch nicht. Und du könntest ja auch eine zufällige ID vergeben, sofern du eine neue zufällige ID ohne zu großen Aufwand (sprich: etliche Versuche und Prüfungen) bilden kannst. Vielleicht wäre das ja eine Idee.Oder du berechnest die zufällige ID aus dem Identity, so dass du das auch wieder zurück rechnen kannst. public-key Verfahren gehen in diese Richtung. Aber man kann auch selber damit experimentieren, es geht ja hier nicht um zu schützende Passwörter, die unbedingt unknackbar sein müssen.
Was genau spricht eigentlich dagegen, von begin an eine userId der Art "72H2H.J8_F6" zu verwenden und diese auch als PRIMARY KEY festzulegen.
Aus meiner Sicht nichts. Das einzige wahrscheinlich, du hast hier einen String der im Vergleich zu einem int etwas komplizierter zu vergleichen ist. Aber obs das wirklich rausreißt?
Ist das aber auch performant?
Evtl. performanter als jedes mal die Umsetzung zu machen.
Oder hast du die "richtige" ID in einer Session gespeichert? Dann machst du die Umsetzung nur ein einziges mal bei der Anmeldung, alle weiteren Aufrufe erfolgen dann sowieso über die aus der Session stammende tatsächliche ID. -
Om nah hoo pez nyeetz, split.s!
Was genau spricht eigentlich dagegen, von begin an eine userId der Art "72H2H.J8_F6" zu verwenden und diese auch als PRIMARY KEY festzulegen. Dann könnte ich mir jeweils ein Statement sparen.
Ist das aber auch performant?
Es ist natürlich so, dass dadurch ggf. ein größerer Speicherplatz benötigt wird und ein String-Vergleich aufwendiger als ein Integervergleich ist.
Matthias
--
1/z ist kein Blatt Papier.
-
Tach!
Ich möchte aber vermeiden, dass man anhand der URL auf die Position innerhalb der Datenbank schließen kann.
Die Position in der Tabelle ist vermutlich dein geringstes Problem. Die Datensätze sind per Definition unsortiert. Du kannst sie also auch bei lückenlos durchnummerierten IDs unsortiert beziehungsweise zufällig sortiert in eine Tabelle schreiben. Was also ist dein eigentliches Problem?
Was genau spricht eigentlich dagegen, von begin an eine userId der Art "72H2H.J8_F6" zu verwenden und diese auch als PRIMARY KEY festzulegen.
Aus Datensicht gar nichts. Eine ID muss lediglich eindeutig sein, alles andere ist belanglos. Der rechentechnische Aufwand wurde ja bereits thematisiert.
Ist das aber auch performant?
Das kommt ganz auf deine Daten drauf an. Die Bandbreite geht hier von "belanglos, weil nicht spürbar", meistens bei wenigen Datensätzen, bis zu "ein Index nützt auch nichts mehr", wenn Indexwerte zu viele Fundstellen ergeben.
Wie macht es denn YouTube? Meint ihr, die Video-ID im Browser ist dieselbe, wie in der Datenbank?
Was wir meinen hat keinerlei Bezug zu den Dingen hinter den Kulissen von Youtube, und ob dann diese eine Relevanz für deinen Fall haben, ist ebenfalls nicht beantwortbar. Vielleicht verwendet YouTube auch etwas ganz anderes als Datenhaltung als eine Datenbank. Der Vorteil dieser ID ist vermutlich die höhere Anzahl der Kombinationen bei gleichbleibender Länge. 11 Zeichen aus 64 (a-zA-Z0-9_-) ergibt 64^11 Möglichkeiten im Gegensatz zu 10^11 bei Verwendung von 0-9. Davon abziehen muss man vermutlich die Werte, bei denen allzu viele Wiederholungen von Zeichen vorkommen.
dedlfix.
-
Hi,
Was genau spricht eigentlich dagegen, von begin an eine userId der Art "72H2H.J8_F6" zu verwenden und diese auch als PRIMARY KEY festzulegen. Dann könnte ich mir jeweils ein Statement sparen.
Ist das aber auch performant?Das kommt auch auf die Art an, wie die IDs erzeugt werden. Ein Stringvergleich ist aber aufwendiger als ein Zahlenvergleich.
Bei einer von der Datenbank (bei MySQL per auto-increment, bei Oracle per Sequence, bei ...) zur Verfügung gestellten Nummer hast Du den großen Vorteil, daß Du Dich darauf verlassen kannst, daß die ID-Werte eindeutig sind. Auch wenn gleichzeitig mehrere IDs angefordert werden.
Wenn Du IDs selber erzeugst, mußt Du auch selber sicherstellen, daß nicht mehrfach dieselbe ID erzeugt wird.
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
hi,
userId BIGINT AUTO_INCREMENT PRIMARY KEY
BIGINT: Kommt Deine Anwendung damit zurecht?
Was genau spricht eigentlich dagegen, von begin an eine userId der Art "72H2H.J8_F6" zu verwenden und diese auch als PRIMARY KEY festzulegen. Dann könnte ich mir jeweils ein Statement sparen.
Ist das aber auch performant?
Eine Abfrage, die in der where Klause den Index (prim. Key) mit der exakten Länge anspricht, ist performant.
Ich sehe die Frage der Performance eher an der Stelle, wo eine eindeutige ID erzeugt wird, also, den Code dazu würde ich nicht jedesmal laden, sondern nur auf Anforderung, die nur dann besteht, wenn ein neuer User hinzukommt.
Wenn ich also mit der Datenbank kommuniziere, muss ich zuerst anhand der publicId die userId ermitteln, weil userId ja nicht in der Adresszeile des Browser auftauchen soll.
Da kannst Du auch gleich die userId nehmen ;)
Hotti
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
Jetzt verunsicherst du mich? Wieso solle meine Anwendung damit nicht zurecht kommen?
Danke übrigens schonmal für deine Teilnahme :)
-
Tach,
Jetzt verunsicherst du mich? Wieso solle meine Anwendung damit nicht zurecht kommen?
hotti benutzt bevorzugt Perl und Skalare in 32-Bit-Perl reichen erstmal nicht für mysql BigInts.
mfg
Woodfighter -
Jetzt verunsicherst du mich? Wieso solle meine Anwendung damit nicht zurecht kommen?
Naja, mal angenommen, es würde sich pro Sekunde ein neuer User registrieren, müsste Deine Anwendung immerhin 213503982334601 Tage rund um die Uhr laufen.
Danke übrigens schonmal für deine Teilnahme :)
Meine Anteilnahme kennt keine Grenzen ;)
Hotti
-
Moin!
Jetzt verunsicherst du mich? Wieso solle meine Anwendung damit nicht zurecht kommen?
Sofern du nicht beabsichtigst, die gesamte Weltbevölkerung (7 oder 8 Milliarden Menschen) mit einer UserID versorgen zu wollen, sollte ein Wertebereich wie UNSIGNED INT mit einem Zahlenbereich bis 4,2 Milliarden doch vollkommen ausreichen, oder? Ansonsten verschwendest du schlicht und einfach Platz, den die Datenbank im Zweifel gut brauchen kann.
- Sven Rautenberg
-
-