- Registriert
- Feb. 2017
- Beiträge
- 543
@Piktogramm Du meinst mit hexadezimalen zu einer Base64 Zahl oder was was ist genau eine hexadezimalzahl ^^? bzw. wie codiert man soetwas?
Folge dem Video um zu sehen, wie unsere Website als Web-App auf dem Startbildschirm installiert werden kann.
Anmerkung: Diese Funktion ist in einigen Browsern möglicherweise nicht verfügbar.
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%.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.
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 [...]
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.new Account() schrieb:Die Wahrscheinlichkeit, dass Duplikate vorhanden sind, ist bei 1000 Anhängen aber dann schon ca. 35%.
Ich halte zwar auch nichts von dem Vorschlag, aber das ist Unsinn. Was meinst Du wofür es Indizes gibt.new Account() schrieb:Da muss er jedes mal durch die ganze Tabelle durch.
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.new Account() schrieb:Eine UUID kann auch doppelt vorkommen (obwohl anfangs unwahrscheinlich), muss also auch geprüft warden.
Wie hilft mir den ein Index das erste freie Element zu finden?Ich halte zwar auch nichts von dem Vorschlag, aber das ist Unsinn. Was meinst Du wofür es Indizes gibt.
Es gibt zig verschiedene Varianten UUIDs zu erstellen und nicht alle enthalten einen Zeitstempel oder Eine MAC.Andreas_ schrieb:Du hast das Konzept der UUID nicht verstanden. In der UUID ist ein Zeitstempel enthalten.
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,...?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.
Eine Spalte, die die Verwendung der ID anzeigt?Andreas_ schrieb:Indem man über die Spalte, welche die Verwendung der ID anzeigt einen Index legt?
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.Andreas_ schrieb:Es gibt nur ein standardisiertes Verfahren zur Generierung von UUID - nachzulesen unter RFC 4122.
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,...?
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.new Account() schrieb:Eine Spalte, die die Verwendung der ID anzeigt?
Ich habe Eine Tabelle, z.B. [BIGINT ID, VARCHAR filename].
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.
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.
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.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.
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?Tutorials ignorieren diesen Umstand komplett
Das es kompliziert ist, habe ich ja auch nicht geschrieben .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
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.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.
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).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.