JavaScript Random id zuordnen?

@Piktogramm Du meinst mit hexadezimalen zu einer Base64 Zahl oder was was ist genau eine hexadezimalzahl ^^? bzw. wie codiert man soetwas?
 
Such bitte selbst und zeige ein Minimum an Eigeninitiative, ich weigere mich Fragen zu beantworten wo diese komplett zu fehlen scheint.
Ergänzung ()

Amaoto schrieb:
Hexadezimal (0-9a-f) läge die Wahrscheinlichkeit bei ca. 1:17 Mio., alphanumerisch (a-zA-Z0-9) entsprechend bei ca. 1:57 Mrd. :)

Die Wahrscheinlichkeit von 1:2^24 bei Hexadezimalen, 6 stelligen Kennungen gilt nur für den Vergleich zweier Dateien. Mit steigender Anzahl an bereits hinterlegten Dateien kommt man schnell in den Bereich, dass eine Kollision stattfinden kann.
Komplett alphanumerische Kennungen sollte man vermeiden. Denn Alphanumerik macht man für Menschen und die stellen sich mitunter etwas an div. Kombination sicher auseiandnerzuhalten (i, l, I, | ; i, j; n, M; o, O, 0; ...). Da kommt es auf die Schriftart an, aber schön ist das nicht. Auch ist ein Mapping von Zahlen auf alphanumerische Nummernkreise oft etwas komplizierter als das gute alte Hex ;)
 
Zuletzt bearbeitet:
Amaoto schrieb:
Hexadezimal (0-9a-f) läge die Wahrscheinlichkeit bei ca. 1:17 Mio., alphanumerisch (a-zA-Z0-9) entsprechend bei ca. 1:57 Mrd. :)
Die Wahrscheinlichkeit, dass Duplikate vorhanden sind, ist bei 1000 Anhängen aber dann schon ca. 35%.
 
Zuletzt bearbeitet:
new Account() schrieb:
Wieso durch 1000?

https://gist.github.com/alkaruno/b84162bae5115f4ca99b

Hier ist ein Beispiel für Eine Kodierung zu b64.

Wenn du Eine fortlaufende Nummer hast und diese zu basd64 umwandelst für strings, hast du garantiert nichts doppelt.

Öhhm ich wollte gerade nachschauen, was Hexadezimal sein soll habe nichts gefunden wollte deshalb schauen ob Base64 nicht ginge und habe das Skript oben getestet ^^ Ich merke gerade das dies genau so ist wie ich es haben wollte also halt AAAA, AAAB, AAAC usw. halt ^^ Aber ich denke mal davon und danach kann man nichts packen, dass es mindestens 6 Zeichen lang ist sonst könnte ja wieder etwas doppelt sein oder? ^^ Ansonsten mache ich es einfach mit Base64, dann sieht es halt nicht so schön aus aber es funktioniert ja dann, oder nicht?
 
Öhhm ich wollte gerade nachschauen, was Hexadezimal sein soll habe nichts gefunden [...]

Willst du micht trollen?
1527790477677.png
 
So war das nicht gemeint ^^ Ich habe nach "javascript hexadezimalen encode" gesucht und dazu nichts gefunden das meinte ich
 
@DreamGamer

Du kannst mit Zeichen auffüllen, die nicht in der Tabelle sind:
https://de.wikipedia.org/wiki/Base64
Diese musst du jedoch beim zurückwandeln wieder entfernen, falls du das machen willst.

Und mir ist gerade aufgefallen, dass base64 sich tatsächlich von base64url unterscheidet.
Daher am besten "+" durch "-" und "/" durch "_" ersetzen
 
Zuletzt bearbeitet:
Oh ich habe doch etwas zu Hexa gefunden nachdem ich "hexadezimalen converter javascript" gesucht habe ^^ Ich glaube Base64 wäre besser für das was ich vor habe ^^ @new Account() Ich habe einfach aus dem Alpha String das + und / entfernt geht dies nicht einfach oder? Und welche zeichen sind denn bitte nicht in base64 zu finden außer "^, §, %, $, ?"?
 
Nicht einfach entfernen, du must es schon ersetzen durch neue Zeichen, oder du änderst den Code so ab, dass 62 Zeichen statt 64 benutzt warden (wobei ich mir hier nicht sicher bin, ob es funktioniert).

~*"!`@{}[]()
 
Zuletzt bearbeitet:
Ich habe es jetzt zu 62 Zeichen geändert das ändert jetzt, aber nichts, außer das es halt weniger kombinationen gibt oder? Und ich habe oben nur diese paar Zeichen genommen, weil der Rest ja sonst fehler in der URL hervorruft soweit ich weiß ^^ Ich glaube ich lasse es einfach so es wird ja denke ich mal relativ schnell 2 - 3 stellig werden ^^ Dann danke :D Ich teste dann mal etwas rum, ob alles funktioniert :D Aber echt danke für die Hilfe hätte dies selber wahrscheinlich nie herausgefunden oder wäre nie dadrauf gekommen ^^
 
new Account() schrieb:
Die Wahrscheinlichkeit, dass Duplikate vorhanden sind, ist bei 1000 Anhängen aber dann schon ca. 35%.
Bezogen auf die hexadezimale Variante (also 24 Bit) wären es nur ca. 3% (hier ist die Formel), aber ja, 6 Stellen sind in dem Fall natürlich zu wenig.
Es müssen 11 sein, wie bei YouTube. ;)
 
Zuletzt bearbeitet:
new Account() schrieb:
Da muss er jedes mal durch die ganze Tabelle durch.
Ich halte zwar auch nichts von dem Vorschlag, aber das ist Unsinn. Was meinst Du wofür es Indizes gibt.

Wenn die ID erst beim Hochladen erforderlich ist, sehe ich allerdings keinen Grund, diese nicht vom Server erzeugen zu lassen.

Ansonsten gibt es die schon genannten UUID (bzw. GUID), mit diesen ist sichergestellt, dass kein Client zufällig dieselbe ID erzeugt wie ein anderer. Es ist in meinen Augen Unsinn, sich da etwas eigenes einfallen zu lassen, wenn es dafür Standards gibt.

new Account() schrieb:
Eine UUID kann auch doppelt vorkommen (obwohl anfangs unwahrscheinlich), muss also auch geprüft warden.
Du hast das Konzept der UUID nicht verstanden. In der UUID ist ein Zeitstempel enthalten. Eine doppelte UUID wäre nur möglich, wenn ein Client mit der selben Node-ID in derselben Millisekunde (eigentlich sogar 1/10 Millisekunde) eine UUID erzeugen wurde. Ich vermute Du wirst nicht einmal zwei Clients mit derselben Node-ID finden ... zum Beispiel fließt bei einem PC die Mac-Adresse in die UUID mit ein.
 
Zuletzt bearbeitet:
Ich halte zwar auch nichts von dem Vorschlag, aber das ist Unsinn. Was meinst Du wofür es Indizes gibt.
Wie hilft mir den ein Index das erste freie Element zu finden?

Andreas_ schrieb:
Du hast das Konzept der UUID nicht verstanden. In der UUID ist ein Zeitstempel enthalten.
Es gibt zig verschiedene Varianten UUIDs zu erstellen und nicht alle enthalten einen Zeitstempel oder Eine MAC.
 
Indem man über die Spalte, welche die Verwendung der ID anzeigt einen Index legt? Noch nie etwas von einem Bitmap-Index gehört? Der ist speziell für derartige Dinge designed.

Es gibt nur ein standardisiertes Verfahren zur Generierung von UUID - nachzulesen unter RFC 4122. Das wüsstest Du, wenn Du Dich mit dem Thema beschäftigt hättest und nicht nur heiße Luft absondern würdest.
 
@Andreas_
Auch wenn die Clients eine UUID erzeugen, muss der Server prüfen, es gilt die goldene Regel: Traue niemals dem Client. :)
Also simpel eine Spalte in der Datenbank mit Unique Restraint.

@new Account()
Tu dir ein gefallen und beschäftige dich mit den Grundlagen der Informatik, Programmierung und Datenbanken. Der Zeitaufwand dir das Wissen aufzuhelfen ist geringer als bei jedem Grundlagenfurz jemand Anderen Fragen zu müssen.
Ein mitzählender Index in ner Datenbank ist kein Hexenwerk. Höchster Wert + 1 ist der erste freie Wert für einen neuen Eintrag. Was alle mir bekannten relationale Datenbanksysteme von sich aus machen*, wenn man Werte einfügt.

*Zumindest in der simpelsten Konfiguration. Die Freiheiten die man hat, wenn man Datenbanken beherrscht betrachten ich jetzt nicht alle.
 
Piktogramm schrieb:
Höchster Wert + 1 ist der erste freie Wert für einen neuen Eintrag. Was alle mir bekannten relationale Datenbanksysteme von sich aus machen*, wenn man Werte einfügt.
Und wie wird da berücksichtigt, dass in einer Folge von IDs, z.B. 1,2,3,4,5,6,7,8,9,10,11,... IDs fehlen: 1,2,3,4,5,6,9,10,11,...?

Andreas_ schrieb:
Indem man über die Spalte, welche die Verwendung der ID anzeigt einen Index legt?
Eine Spalte, die die Verwendung der ID anzeigt?
Ich habe Eine Tabelle, z.B. [BIGINT ID, VARCHAR filename].

Ich komme soweit mit, dass ich mit einem Index die IDs deutlich schneller durchsuchen kann, d.h. ich finde meine freie Stelle schneller, trotzdem habe ich im Schnitt Eine Laufzeit von O(n), da ich i.d.R. durch alle Einträge des Indexs laufen muss.
Der Bitmap-Index ist mir tatsächlich neu, würde aber meiner Erkenntnis nach nur etwas bringen, falls ich Eine Tabelle hätte in der Form [BIGINT ID, VARCHAR filename, BOOL used] und auf used den Index lege, oder verstehen ich etwas falsch?

Andreas_ schrieb:
Es gibt nur ein standardisiertes Verfahren zur Generierung von UUID - nachzulesen unter RFC 4122.
Und trotzdem gibt es zig verschiedene Verfahren. Wüsstest du, wenn du mal mehr als die ersten 3 Zeilen des Wiki-Artikels gelesen hättest, siehe z.B. Wikipedia, https://docs.python.org/2/library/uuid.html oder auch andere Libraries für beliebige Sprachen.
 
new Account() schrieb:
Und wie wird da berücksichtigt, dass in einer Folge von IDs, z.B. 1,2,3,4,5,6,7,8,9,10,11,... IDs fehlen: 1,2,3,4,5,6,9,10,11,...?

Wenn jeder neue Wert die ID mit Wert MAX(ID) +1 bekommt gibt es keine fehlende IDs. Selbst wenn du Daten löschen musst ist es egal. Denn erstens ist es vollkommen egal, wenn zwischendrin IDs fehlen und zweitens ist es sowieso üblich Daten nicht zu löschen sondern nur als gelöscht zu markieren*.
Auf jeden Fall ist es untypisch IDs die bereits vergeben waren und gelöscht wurden erneut zu vergeben. Das führt zu Problemen. Einmal weil die alten IDs von Dritten genutzt werden können und zum anderen weil die Suche nach freigewordenen IDs unnötig komplizierten Code erzwingt der Fehleranfällig ist und Rechenzeit braucht.

*Hier ist Vorsicht geboten, ob man Datenschutzrechtlich nicht doch Daten löschen muss.
Ergänzung ()

new Account() schrieb:
Eine Spalte, die die Verwendung der ID anzeigt?
Ich habe Eine Tabelle, z.B. [BIGINT ID, VARCHAR filename].
In vielen Datenbanken ist es unsinnig eine eigene ID-Spalte anzulegen, da die Datenbanken sowieso eine rowid anlegen um die Einträge in einer Tabelle zu verwalten*. Wenn es nur darum geht einen Indexwert zu haben, mit dem man sehr schnell einzelne Werte identifizieren und ansprechen kann, reicht die rowid in der Regel aus. Mit dem Vorteil, dass man sich den Speicherplatz für die manuall angelegte ID-Spalte spart und die Rechenzeit für das Indizieren dieser Spalte.


*Dokumentationen von Datenbanken lesen bringt es! Im Studium wurde es mir auch anders beigebracht und die meisten Lehrbücher / Tutorials ignorieren diesen Umstand komplett. Ich musste gar länger mit meinem Prof diskutieren bis er mein notorisches Weglassen manueller ID-Spalten akzeptierte -.-
 
Zuletzt bearbeitet:
Piktogramm schrieb:
Auf jeden Fall ist es untypisch IDs die bereits vergeben waren und gelöscht wurden erneut zu vergeben. Das führt zu Problemen. Einmal weil die alten IDs von Dritten genutzt werden können und zum anderen weil die Suche nach freigewordenen IDs unnötig komplizierten Code erzwingt der Fehleranfällig ist und Rechenzeit braucht.

Auch, wenn es untypisch ist und nicht empfehlenswert ist (was ich auch geschrieben habe), geht es gerade genau darum, da wir uns auf diesen Post beziehen:
soares schrieb:
Erstell Dir eine Tabelle, die alle möglichen Ids enthält. Beim Hochladen nimmst Du die erste verfügbare Id und markierst sie als vergeben oder löschst sie.

Als kompliziert würde ich jetzt die Suche nach einer freien ID nicht bezeichnen, obgleich sie komplexer ist als nicht zu suchen ;)

Wenn es nur darum geht einen Indexwert zu haben, mit dem man sehr schnell einzelne Werte identifizieren und ansprechen kann, reicht die rowid in der Regel aus.
Hat z.B. SQL-Server nicht… und abgesehen davon ist es etwas fragil die rowID als PK zu verwenden, weshalb z.B. Oracle ausdrücklich davon abrät.
Tutorials ignorieren diesen Umstand komplett
Weil es vielleicht Eine riskante Performanzoptimierung ist, die man nicht braucht um SQL zu lernen und man diese sowieso entdeckt, wenn man Eine DB auf Performanz optimieren möchte?
Aber darum geht es hier garnicht.
 
new Account() schrieb:
Als kompliziert würde ich jetzt die Suche nach einer freien ID nicht bezeichnen, obgleich sie komplexer ist als nicht zu suchen ;)
Das es kompliziert ist, habe ich ja auch nicht geschrieben :p.
Wobei eine einfache Suche nach Fehlstellen in einer Folge von der Laufzeit her unschön ist und typischerweise wird zum Thema Komplexität von Algorithmen ja Laufzeit und Speicherverhalten gelehrt. Eine gescheit quantisierte Metrik für die menschlich wahrgenommene Komplexität von Algorithmen hat sich irgendwie noch nicht durchgesetzt. Diese wäre aber auch nicht mehr von anerkannten Metriken zur Codequalität unterscheidbar:

wtf.png

Hat z.B. SQL-Server nicht… und abgesehen davon ist es etwas fragil die rowID als PK zu verwenden, weshalb z.B. Oracle ausdrücklich davon abrät.
Man kann sich immer wunderbar in den Fuß schießen. Datenbank doku lesen und verstehen was man wieso tut und wann es wie schief gehen kann sollte man auch bedenken. Bei den typischen Anwendungsgrößen bei denen man ne Oracle DB ausrollt würde ich auch anders an solche Sachen herangehen.

Weil es vielleicht Eine riskante Performanzoptimierung ist, die man nicht braucht um SQL zu lernen und man diese sowieso entdeckt, wenn man Eine DB auf Performanz optimieren möchte?
Aber darum geht es hier garnicht.
Ich habe zunehmend den Eindruck, dass es eher aus einem "haben wir schon immer so gemacht" heraus entsteht. Es wird selbst in Vertiefungskursen fast nur SQL92 gelehrt und die ganzen schönen Tricks und Kniffe die möglich sind werden ignoriert. Da werden dann lieber absurd komplexe Abfragen verbaut und als Königsweg verkauft anstatt sich mal mit den SQL Erweiterungen von 99, 03, 11 und 16 auseinanderzusetzen die das Leben teils enorm erleichtern und komplexe Abfragen deutlich einschrumpfen können (bei gleichzeitiger Laufzeitverbesserung).
Videotip: https://media.ccc.de/v/GLT18_-_359_...ql_in_open-source_datenbanken_-_markus_winand
 
Zuletzt bearbeitet: (Wörter vergessen -.-)
  • Gefällt mir
Reaktionen: new Account()
Zurück
Oben