Es gibt einen uralten Satz (aus der Antike): "Mir war so, als wüsste ich's. Doch soll ich's erklären, dann weiß ich's nicht". Das hier muss man erstmal machen. Weiter so!
In monolithischen Anwendungen habe ich bisher immer mit klassischen IDs gearbeitet. Inzwischen aber angekommen in der Welt von verteilten Anwendungen dann umgestiegen auf UUIDs. Liebe Grüße und besten Dank für das sehr gut aufbereitete Video.
Danke für das Video! Wahnsinn, was man bei dir alles lernen kann. Schade, dass ich diesen Kanal nicht noch viel eher gefunden habe. Da ich nicht mit verteilten Systemen arbeite, habe ich größtenteils mit klassischen IDs zu tun. Aber natürlich kenne ich auch die UUID. Schönes WE!
Moin und danke für die ausführlichen Erläuterungen, wieder einiges gelernt :) Wir ziehen gerade ein Projekt von UUIDs auf nanoids um, weil wir sehr viele Objekte identifizieren müssen und damit spührbar den traffic reduzieren können.
Wenn Du Fragmentierung meinst, schau dir das Video an: ua-cam.com/video/rvZwMNJxqVo/v-deo.html Sehr interessant. Der Herr Moden aus dem Video ist 9-facher MVP für SQL Server.
@@mathiasschubert9963 Memory, physical reads, Hashjoins etc pp. Wenn mann GUIDs als PK nutzt, sollte man wirklich gute Gründe haben und es vorher mit den zu erwartenden Datenmengen testen. Ich musste mal ein Projekt mit fast 1 Mrd Zeilen von random Strings auf seq. Number migrieren, weil es zu langsam war. Das war kein Spaß.
@@zickzack987 Ich nutzte das für Quartalsdaten. Wir können daher Partitionen für die jeweiligen Quartale nutzen. Das funktioniert gut. Pro Quartal haben wir ca 11.5 Mio Datensätze. Wir machen das jetzt 2.5 Jahre so. Das funktioniert sehr gut. Es ist aber im Prinzip auch eine reine Select Geschichte nach dem Einfügen. Die Daten werden hineingeschrieben und nie mehr gelöscht oder geupdatet. Sicher ein etwas anderes Beispiel. Zudem Firmen intern im selbigen Netzwerk. Was ich habe aus Erfahrung kenne und auch mehrmals gelesen habe sind 5-10% Performance einbüßen bei Joins gegeben. Daher muss man es sicher abwiegen, ob das der Killer ist. Ohne Joins ist die Performance gar nicht schlechter, so wie ich das kenne. Kann aber auch Zufall sein. Bei uns kommt schon das ein oder andere an Daten zusammen.
ich bin schon vor einiger Zeit (Jahren) auf UUID'S umgestiegen. Ich finde es eigentlich ganz Charmant, dass die UUID's keine zusätzlichen Infos enthalten. Jedes Feld sollte ja eindeutig und nur eine Aufgaben haben. Zumindest in einer relationalen Datenbank. Deswegen hab ich klassisch ein createdAt Feld auf meinem Datensatz. Und danach kann ich ja dann wieder sortieren, wenn ich das brauche.
Hab bisher fast immer mit GUIDs gearbeitet. (Das ist Microsofts Name für UUIDs.) Ist praktisch, wobei ich Int als Id-Typ immernoch wichtig finde, weil es in bestimmten Fällen die Datenbank-Performance erhöhen kann. Sortieren müssen wir die Datensätze nicht oder wenn dann nur nach anderen Attributen, von daher ist die Nicht-Sortierbarkeit der Ids bei uns egal. Das mit diesen Ids, die einen Timestamp beinhalten find ich interessant. Bin gespannt ob sich das vielleicht sogar mal als Standard durchsetzt.
[gr] Das hängt davon ab, was man damit erreichen will - wenn's um die Sortierbarkeit geht: Unter Umständen erzeugst Du mehrere Objekte schneller als die Granularität Deines Zeitstempels zulässt, und Zeitstempel funktionieren nicht verlässlich über mehrere Server hinweg (also im Cluster), weil Du dort mit Clock-Skew und ähnlichem rechnen musst.
Sehr interessantes Video! Weiter so! Eine Consensus Funktion erscheint mir sehr aufwendig, wäre es nicht einfacher je Server einen kleinen Prefix vor die UUID zu setzen? Dann könnte es niemals identische UUID´s geben.
Es gibt theoretisch auch noch die Möglichkeit sowohl eine uuid als auch eine auto incrementierte zahlen ID zu verwenden. Hat den netten Vorteil, dass damit relationale Datenbanken besser arbeiten können als mit guids (Stichwort Index) und man extern halt keine incrementelle Id verwendet Auch gibt es den "Verschleierungs" Ansatz, bei dem entsprechende numerische ids Mithilfe eines Passwortes Bswp. Entropie zugefügt bekommen und so dann halt auch nicht mehr hichzählbar nach außen sind
Ich persönlich benutze eigentlich hauptsächlich UUIDs und wenn eine zeitliche Sortierung notwendig ist ein extra Feld dafür. So kann ich sicher gehen, dass mir der Client nicht irgendeine Zeit unter jubeln will, kann aber direkt im Client mit der ihm bekannten UUID weiterarbeiten.
Top! Ich persönlich arbeite serverseitig mit klassischen, vorhersagbaren IDs. Diese werden anschließend gehasht und gesaltet, sodass sie für den Client zufällig erscheinen. Ähnlich macht es UA-cam (man achte auf den Query Parameter ?v={zufällig erscheinende ID}).
UUIDv1 hat tatsächlich auch heute noch eine sinnvollen Einsatzzweck. Das Problem bei UUIDv4 ist, dass es nicht zu 100% sicher ist, dass eine ID global-galaktisch eindeutig ist und bleibt. Grundsätzlich kann eine UUIDv4 auch mehr als einmal generiert werden. Sie sind halt zufallsgeneriert und haben eine begrenzte Länge. UUIDv1 hat zwar den Nachteil, dass man sie erraten kann, aber dafür ist sichergestellt, dass sie auch global-galaktisch eindeutig sind, da sie eben auf der global-galaktisch eindeutigen MAC-Adresse und auf der Zeit basieren. ist die Erratbarkeit egal, da es sich z.B. nur um internes Irgendwas oder so geht, aber die Eindeutigkeit muss absolut sichergestellt werden (und eine Eindeutigkeitsprüfung ist wegen der Menge der Datensätze zu teuer), ist UUIDv1 in verteilten System durchaus eine sinnvolle Möglichkeit.
Uuidv1 kann nur so eindeutig sein wie die Mac es ist. Vielleicht vergeben Aliens in einer Galaxie auch zufällig die gleichen Mac Adresse wie hier? Ich habe im Video die (Un-) wahrscheinlichkeitsangabe vermißt, mit der IDs nach Uuidv4 doch mal kollidieren könnten.
Ich nutze GUID, welche binärcodiert in der Datenbank gespeichert wird. Z. B. mit MySql bzw. MariaDb, wo mir ein konkreter GUID-Datentyp nicht bekannt wäre. Wo ist eigentlich der Unterschied zwischen GUID und UUID. Ich vermute keiner 🤔
Ich nutze hashids. Die sind kurz und wenn man diese anhand des PrimaryKey erstellt auch immer eindeutig. Außerdem kann man die zurückrechnen wenn man den Schlüssel hat. UA-cam macht das bei den Videos genauso.
In meinem aktuellem Projekt nutze ich als ID ein Object bestehend aus der eigentlichen ID in Form einer uuid4 und einer Versionsnummer in Form des Erstellungszeitpunkt bzw. Änderungszeitpunkt des Objektes. Dadurch kann ich immer den Zustand jedes Objekts zu jedem Zeitpunkt ermitteln oder in einem anderen Objekt darauf referenzieren & habe auch eine Zeitliche Sortierung.
@@luxaaa2602 Weil es sehr nach Framework von der Stange klingt. Historisierung und Id-Management haben an sich nichts miteinander zu tun. Eine REST-Resource zB. hat einen Identifier. Und die muss da sein, wenn die Post abgeht. Hängst du eine Versionsnummer dran, ist es eine Query und die muss warten, da sie (hoffentlich) auch aus einem anderen System kommt. Trotzdem soll das jetzt nicht negativ klingen. Alles hat seine Berechtigung. Wenn es für dich funktioniert und wartbar ist, dann mach es so! :-)
Ich habe nach deiner Anmerkung mit dem Sicherheitsaspekt bezüglich der numerischen IDs, die Anwendung meines Unternehmens aufgerufen und habe einfach mal die Detail-Seite eines Eintrages geöffnet von mir und dann die ID in der Suchleiste geändert. Und tatsächlich, ich konnte auf die Detail-Seite eines Eintrages zugreifen die überhaupt nicht zu meinem Nutzer gehört. Ich habe es direkt geändert, nun ist kein Zugriff mehr möglich! 😅
Vielleicht sollte ich noch erwähnen, dass die Anwendung nur für den internen Gebrauch programmiert wurde und deshalb auf einige Aspekte der Sicherheit verzichtet wurden ist.
Fast überall gibt es zusätzliche Business Keys, die auch eindeutig über alle Instanzen sein müssen. So ganz kommt man auch damit aus dem Dilemma nicht raus. Auch wenn man diese Keys erst später generieren kann.
Es kommt immer auf den Verwendungszweck an. Keine UID ist per se die Beste. Ich achte bei der Verwendung auf den Anwendungsfall und die Performance bei der Generierung. Persönlich empfehle ich sich mal XIDs anzuschauen.
Sehr gutest Video! Man hätte auch noch auf andere Algorithmen wie Snowflakes (z.B. verwendet von Twitter und Discord) eingehen können. Diese benutze ich in den meisten Fällen, da sie relativ numerisch nach Zeit sortierbar sind und sich ohne kompliziertes decoden wieder zu einem UNIX timestamp umwandeln lassen.
Bevorzuge natürliche Schlüssel. Beispiel Manufacturer + Serial-No. Bei künstlichen Schlüsseln kann man niemals das Objekt finden, ohne den Schlüssel zu kennen. Der Vorteil dass dieser eindeutig ist, entpuppt sich dann eher als Nachteil.
Hab auch meistens im Web mit UUIDs zu tun (oder MongoDBs ObjectID). Dass numerische IDs für offline fähige Anwendungen nicht geeignet ist ist meiner Meinung nach eher falsch. Wenn alles lokal sein soll ist SQLite sehr gut und benützt auch numerische IDs. Wenn du schon mal Android entwickelt hast deren mehr oder weniger empfohlener ansatz für offline caching von online daten ist auch dass du diese ine in eine lokale SQLite datenbank packst und dann halt je nachdem ob du internet hast oder nicht in deinen Repositories das richtige zurückgibtst. Son ähnlichen ansatz kann man mit edge Anwendungen auch betreiben schreibt man halt die Daten in eine lokale SQLite DB wenn kein internet da ist und schiebt die irgendwann später in die online DB wenn das internet wieder verfügbar ist. Bekommen sie dann halt ne neue ID, kein Problem. Ne Datenbank zu haben die dir hier die Arbeit abnimmt ist sicherlich nett, aber es ist auch keineswegs ein schwer lösbares Problem wenn das nicht der Fall ist (in vielen Fällen).
[gr] Naja, den kritischen Punkt hast Du schon erwähnt: > "Bekommen sie dann halt ne neue ID, kein Problem." Das sehe ich ein bisschen anders, weil Du ja basierend auf dieser ID eventuell schon andere Sachen gemacht hast. Das ist ja nicht nur eine ID an einer einzigen Stelle, die es zu ändern gilt, sondern das zieht unter Umständen einen ganz schönen Rattenschwanz nach sich. Und wenn Du an ein System wie Git denkst, dann geht das schon mal gar nicht mehr (was ja auch der Grund ist, warum Git nicht mit numerischen IDs, sondern mit Hashes als IDs arbeitet).
@@thenativeweb Kommt halt drauf an mit was du arbeitest. Bei den Daten mit denen ich in der Arbeit zu tun habe ist für gewöhnlich die ID relativ egal und ledeglich die Zeit zu der die daten (ursprünglich) aufgenommen worden sind wichtig. Also on edge wird nur typisches IOT data hoarding betrieben und nicht wirklich großartig was damit gemacht. Es wird halt lokal zwischengespeichert wenn kein internet verfügbar ist in unter umständen riesengroße recht unleserliche minimal strukturierte jsons. Solang das technisch keine Probleme darstellt hat das auch seine Vorteile. Selbst wenn man bei nem Kunden nen Fehler baut für irgend einen Wert. Wenn du bei der abspeicherung der Rohdaten keine großartige Logik eingebaust, kannst du wenn Fehler auftreten alles im nachhinein wieder nachrechnen. Muss sich dabei nichtmal um einen Fehler im Code handeln. Das hat alles bezug zur realität. Vielleicht hast du dich irgendwo vermessen, oder vertippt bei Kunde xyz und temperatursensor z ist jetzt ganz wo anders als er eigentlich sein sollte.
Hi, ich gebe Dir nur zum Teil recht. Doch leider funktioniert das nicht so einfach auf die ID zu verzichten. Ich habe schon einige Security Dialoge geschrieben auf Mainframes (IBM Grossrecner z/OS). Hier muss man eine ID haben um sich anzumelden. Das heisst aber nicht das ich mich nur auf die Mainframes beziehe, ich benutze weiter noch andere Systeme wie Windows, AIX, Solaris und Linux. Wenn auf einem der erwähnten Systeme ein Problem auftritt werden die Änderungen nachgefahren. Die Daten sind auf x-Systemen verteilt. Natürlich muss man sich gedanken machen wie hallte ich das ganze sauber so das alle Systeme auf dem gleichen Stand sind. Denn jeder User hat eine ID welche ganz bestimmte Berechtigungen hat und das auf verschiedenen systemen. Natürlich muss man auch ein System Führendes System definieren. Klar die anderen ID Typen sind Sicherer aber die kann man nicht überall verwenden. Gruss
Woahh. In welcher App aus der Hölle lässt du vorgeben, welche ID erstellt werden soll? Das ist null-komma-nix ihre Aufgabe, sondern die des Storages (Mysql, Postresql, Mssql, Oracle - und wenn man noSQL dazu zählen will, auch Couch, Mongo und co - oder auch Redis, Shinxsearch, Elasticsearch, ...). Dass man sie von aussen abschirmt, ist nen "feature" - man erstellt ein uniques "slug" Feld zum Direktaufruf. Dass man sie sortable macht - nen created_at Feld im Table / Document / Name it. Aber das Video war jetzt mal krass an der Realität vorbei - zumindest da, wo es sich um sehr komplexe Applikationen handelt. Und zum Thema Cloud: Irgendwo muss es immer nen sync geben zwischen den Master / Slaves (oder Clusters - und darf man master / slave eigentlich noch sagen?) - sehe da nichts aus deiner Argumentation. Aber mag DURCHAUS MÖGLICH sein, dass ich da was falsch verstanden habe. P.S. Bei Elastisearch gibt man die ID (normal numerisch) an, aber bei Spinx weiss ich nicht mehr - schon zu lange her Ansonsten: Mag euren Content. Eine meiner "Up-To-Date Bleiben" Kanäle. Aber das war irgendwie nichts ;)
[gr] Also, zuerst einmal: Nicht jede Anwendung nutzt eine Datenbank, insofern kann man die Entscheidung manchmal eben nicht "auf die Storage" auslagern. Zum zweiten, selbst wenn man das macht, muss auch dort irgendwer initial einmal die Entscheidung treffen, wie IDs aussehen sollen (Autoincrement-Feld, UUID-Feld, …), die Frage ist also auch mit Datenbank nicht hinfällig. Zum dritten: Deine Idee mit dem CreatedAt-Feld greift unter Umständen zu kurz, weil Du damit erstens auf die Granularität von Timestamps angewiesen bist, und weil Du zweitens wieder das Problem mit Clock-Skew in verteilten Anwendungen hast. Ja, das lösen UUIDs auch nicht, aber Vektor-Uhren zB schon. Viertens: Du lehnst Dich ja sehr weit aus dem Fenster mit der Aussage, dass das Video "mal krass an der Realität vorbei" war. Vielleicht lässt Du uns ja an Deinen Erfahrungen zu "sehr komplexe[n] Applikationen" teilhaben, und erklärst, wie man dort mit IDs Deiner Meinung nach richtig umgeht? Wäre schön, wenn Du dazu ein bisschen mehr sagen und vor allem konkreter werden könntest als einfach zu behaupten, das sei Aufgabe der Storage und damit wäre das Problem ja gelöst …
@@thenativeweb Also bei "komplexen Anwendungen" rede ich von selbstgebauten CMS, Shoppingsystemen und dergleichen. Also Zeug, wo man ohne einer Storage nicht so weit kommt, sondern schon relationale Datenbanken (noSQL ist für sowas einfach nur: nein ;)) + etwas "Side-Schnickschnack" (Elasticsearch z.B.) braucht. Was ich auch seit 20 Jahren+ mache. Und an die Datenbanken tritt man ja häufig mit ORMs / ODMs ran - raw query schreiben tut man eigentlich nur noch selten - eigentlich nur noch bei harter Performanceoptimierung und stored procedures und/oder big data. Und solche ORMs bzw. ODMs haben normalerweise keine Setter für IDs. Man kann zwar irgendwie die default ID von (autoincrement) Int auf was anderes umbiegen, MariaDb selber sagt da aber z.B. "tuts aus performance gründen lieber nicht" - ich weiss jetzt nicht, ob ich hier links posten darf - aber google uuid mariadb. Deswegen meinte ich, das ist hart an der Realität vorbei: weil normal hast keine Wahl.
Beeindruckende Klarheit des Vortrags. Der Vortragende ist augenscheinlich nicht nur kompetent, sondern auch recht erfahren. Danke!
Es gibt einen uralten Satz (aus der Antike): "Mir war so, als wüsste ich's. Doch soll ich's erklären, dann weiß ich's nicht". Das hier muss man erstmal machen. Weiter so!
Zuerst bedanke ich mich. Sehr kurze, aber wirklich breite Darstellung des Themas. Über meine Erfahrungen z.B.schreibe ich später was. Danke.
[gr] Danke für Dein Feedback 😊
In monolithischen Anwendungen habe ich bisher immer mit klassischen IDs gearbeitet. Inzwischen aber angekommen in der Welt von verteilten Anwendungen dann umgestiegen auf UUIDs. Liebe Grüße und besten Dank für das sehr gut aufbereitete Video.
[gr] Danke schön 😊
Danke für das Video! Wahnsinn, was man bei dir alles lernen kann. Schade, dass ich diesen Kanal nicht noch viel eher gefunden habe.
Da ich nicht mit verteilten Systemen arbeite, habe ich größtenteils mit klassischen IDs zu tun. Aber natürlich kenne ich auch die UUID.
Schönes WE!
[gr] Vielen Dank für das tolle Feedback, das freut mich riesig 😊
Sehr interessantes und relevantes Thema. Muss dann unbedingt auch die user comments studieren...Und von ULIDs und KSUIDs noch nie was gehoert.
[gr] Danke schön für das Feedback 😊
Moin und danke für die ausführlichen Erläuterungen, wieder einiges gelernt :) Wir ziehen gerade ein Projekt von UUIDs auf nanoids um, weil wir sehr viele Objekte identifizieren müssen und damit spührbar den traffic reduzieren können.
[gr] NanoIDs und UUIDs sind AFAIK gleich groß (beide 128 Bit), oder irre ich mich da?
@@thenativeweb die String Repräsentation (in versendeten JSON beim versenden von Server zum Client) ist kürzer, nicht?
[gr] Ach so, ja, das stimmt - ich war gedanklich bei der Bit-Repräsentation, und das sind so oder so 128 Bit.
Uuid als Primary Key in einer DB mit vielen Datensätzen sind ein netter Performance Killer, der oft erst zuschlägt, wenn es zu spät ist 😎
Wenn Du Fragmentierung meinst, schau dir das Video an: ua-cam.com/video/rvZwMNJxqVo/v-deo.html
Sehr interessant.
Der Herr Moden aus dem Video ist 9-facher MVP für SQL Server.
@@mathiasschubert9963 Memory, physical reads, Hashjoins etc pp. Wenn mann GUIDs als PK nutzt, sollte man wirklich gute Gründe haben und es vorher mit den zu erwartenden Datenmengen testen. Ich musste mal ein Projekt mit fast 1 Mrd Zeilen von random Strings auf seq. Number migrieren, weil es zu langsam war. Das war kein Spaß.
@@zickzack987 Ich nutzte das für Quartalsdaten. Wir können daher Partitionen für die jeweiligen Quartale nutzen. Das funktioniert gut. Pro Quartal haben wir ca 11.5 Mio Datensätze. Wir machen das jetzt 2.5 Jahre so. Das funktioniert sehr gut.
Es ist aber im Prinzip auch eine reine Select Geschichte nach dem Einfügen. Die Daten werden hineingeschrieben und nie mehr gelöscht oder geupdatet. Sicher ein etwas anderes Beispiel. Zudem Firmen intern im selbigen Netzwerk.
Was ich habe aus Erfahrung kenne und auch mehrmals gelesen habe sind 5-10% Performance einbüßen bei Joins gegeben. Daher muss man es sicher abwiegen, ob das der Killer ist. Ohne Joins ist die Performance gar nicht schlechter, so wie ich das kenne. Kann aber auch Zufall sein. Bei uns kommt schon das ein oder andere an Daten zusammen.
ich bin schon vor einiger Zeit (Jahren) auf UUID'S umgestiegen. Ich finde es eigentlich ganz Charmant, dass die UUID's keine zusätzlichen Infos enthalten. Jedes Feld sollte ja eindeutig und nur eine Aufgaben haben. Zumindest in einer relationalen Datenbank. Deswegen hab ich klassisch ein createdAt Feld auf meinem Datensatz. Und danach kann ich ja dann wieder sortieren, wenn ich das brauche.
[gr] Aus Neugier - welche Auflösung hat der Zeitstempel?
Hab bisher fast immer mit GUIDs gearbeitet. (Das ist Microsofts Name für UUIDs.)
Ist praktisch, wobei ich Int als Id-Typ immernoch wichtig finde, weil es in bestimmten Fällen die Datenbank-Performance erhöhen kann. Sortieren müssen wir die Datensätze nicht oder wenn dann nur nach anderen Attributen, von daher ist die Nicht-Sortierbarkeit der Ids bei uns egal.
Das mit diesen Ids, die einen Timestamp beinhalten find ich interessant. Bin gespannt ob sich das vielleicht sogar mal als Standard durchsetzt.
[gr] Ach, Mist, die GUIDs wollte ich noch erwähnen, das habe ich dann völlig vergessen. Danke, dass Du es nachgetragen hast 😊
was spricht dagegen neben der UUID ein eigenes Attribut für einen Zeitsempel einzufügen?
[gr] Das hängt davon ab, was man damit erreichen will - wenn's um die Sortierbarkeit geht: Unter Umständen erzeugst Du mehrere Objekte schneller als die Granularität Deines Zeitstempels zulässt, und Zeitstempel funktionieren nicht verlässlich über mehrere Server hinweg (also im Cluster), weil Du dort mit Clock-Skew und ähnlichem rechnen musst.
Sehr interessantes Video! Weiter so! Eine Consensus Funktion erscheint mir sehr aufwendig, wäre es nicht einfacher je Server einen kleinen Prefix vor die UUID zu setzen? Dann könnte es niemals identische UUID´s geben.
[gr] Das ist richtig - nur verliert man dann wieder die zeitliche Sortierbarkeit.
Es gibt theoretisch auch noch die Möglichkeit sowohl eine uuid als auch eine auto incrementierte zahlen ID zu verwenden.
Hat den netten Vorteil, dass damit relationale Datenbanken besser arbeiten können als mit guids (Stichwort Index) und man extern halt keine incrementelle Id verwendet
Auch gibt es den "Verschleierungs" Ansatz, bei dem entsprechende numerische ids Mithilfe eines Passwortes Bswp. Entropie zugefügt bekommen und so dann halt auch nicht mehr hichzählbar nach außen sind
[gr] Danke für Deinen Kommentar 😊
UUID7 ? Wie waers mal mit einem update ueber UUIDs bzgl. version 7
Können wir bei Gelegenheit sicher mal machen …
Ich persönlich benutze eigentlich hauptsächlich UUIDs und wenn eine zeitliche Sortierung notwendig ist ein extra Feld dafür. So kann ich sicher gehen, dass mir der Client nicht irgendeine Zeit unter jubeln will, kann aber direkt im Client mit der ihm bekannten UUID weiterarbeiten.
[gr] Wie erzeugst Du dieses Extra-Feld?
Vielen Dank!
[gr] Gerne 😊
Top! Ich persönlich arbeite serverseitig mit klassischen, vorhersagbaren IDs. Diese werden anschließend gehasht und gesaltet, sodass sie für den Client zufällig erscheinen. Ähnlich macht es UA-cam (man achte auf den Query Parameter ?v={zufällig erscheinende ID}).
@@manmanmanichfindekeinennam7613 darum kümmert sich das framework (ef core). Im dümmsten Fall nimmst du höchste/letzte ID und erhöht sie um 1^^.
UUIDv1 hat tatsächlich auch heute noch eine sinnvollen Einsatzzweck. Das Problem bei UUIDv4 ist, dass es nicht zu 100% sicher ist, dass eine ID global-galaktisch eindeutig ist und bleibt. Grundsätzlich kann eine UUIDv4 auch mehr als einmal generiert werden. Sie sind halt zufallsgeneriert und haben eine begrenzte Länge. UUIDv1 hat zwar den Nachteil, dass man sie erraten kann, aber dafür ist sichergestellt, dass sie auch global-galaktisch eindeutig sind, da sie eben auf der global-galaktisch eindeutigen MAC-Adresse und auf der Zeit basieren. ist die Erratbarkeit egal, da es sich z.B. nur um internes Irgendwas oder so geht, aber die Eindeutigkeit muss absolut sichergestellt werden (und eine Eindeutigkeitsprüfung ist wegen der Menge der Datensätze zu teuer), ist UUIDv1 in verteilten System durchaus eine sinnvolle Möglichkeit.
Uuidv1 kann nur so eindeutig sein wie die Mac es ist. Vielleicht vergeben Aliens in einer Galaxie auch zufällig die gleichen Mac Adresse wie hier?
Ich habe im Video die (Un-) wahrscheinlichkeitsangabe vermißt, mit der IDs nach Uuidv4 doch mal kollidieren könnten.
Ich nutze GUID, welche binärcodiert in der Datenbank gespeichert wird. Z. B. mit MySql bzw. MariaDb, wo mir ein konkreter GUID-Datentyp nicht bekannt wäre. Wo ist eigentlich der Unterschied zwischen GUID und UUID. Ich vermute keiner 🤔
Einfach nur ein anderer Name des gleichen Konzepts (universally vs. globally).
Ich nutze hashids. Die sind kurz und wenn man diese anhand des PrimaryKey erstellt auch immer eindeutig. Außerdem kann man die zurückrechnen wenn man den Schlüssel hat. UA-cam macht das bei den Videos genauso.
[gr] Danke für Deinen Kommentar 😊
In meinem aktuellem Projekt nutze ich als ID ein Object bestehend aus der eigentlichen ID in Form einer uuid4 und einer Versionsnummer in Form des Erstellungszeitpunkt bzw. Änderungszeitpunkt des Objektes. Dadurch kann ich immer den Zustand jedes Objekts zu jedem Zeitpunkt ermitteln oder in einem anderen Objekt darauf referenzieren & habe auch eine Zeitliche Sortierung.
Scheint kein größeres Projekt zu sein.
@@skrymir1 ist es nicht. Aber wieso scheint es so?
@@luxaaa2602 Weil es sehr nach Framework von der Stange klingt. Historisierung und Id-Management haben an sich nichts miteinander zu tun. Eine REST-Resource zB. hat einen Identifier. Und die muss da sein, wenn die Post abgeht. Hängst du eine Versionsnummer dran, ist es eine Query und die muss warten, da sie (hoffentlich) auch aus einem anderen System kommt. Trotzdem soll das jetzt nicht negativ klingen. Alles hat seine Berechtigung. Wenn es für dich funktioniert und wartbar ist, dann mach es so! :-)
@@skrymir1 tatsächlich ist die Implementierung eine Eigenentwicklung. Ich habe viel ausprobiert & das ist bisher die beste & einfachste Lösung.
@@luxaaa2602 Viel ausprobiert und beste/einfachste Lösung gefunden klingt sehr gut.
Ich habe nach deiner Anmerkung mit dem Sicherheitsaspekt bezüglich der numerischen IDs, die Anwendung meines Unternehmens aufgerufen und habe einfach mal die Detail-Seite eines Eintrages geöffnet von mir und dann die ID in der Suchleiste geändert. Und tatsächlich, ich konnte auf die Detail-Seite eines Eintrages zugreifen die überhaupt nicht zu meinem Nutzer gehört.
Ich habe es direkt geändert, nun ist kein Zugriff mehr möglich! 😅
Vielleicht sollte ich noch erwähnen, dass die Anwendung nur für den internen Gebrauch programmiert wurde und deshalb auf einige Aspekte der Sicherheit verzichtet wurden ist.
Fast überall gibt es zusätzliche Business Keys, die auch eindeutig über alle Instanzen sein müssen. So ganz kommt man auch damit aus dem Dilemma nicht raus. Auch wenn man diese Keys erst später generieren kann.
[gr] Danke für Dein Feedback 😊
Es kommt immer auf den Verwendungszweck an. Keine UID ist per se die Beste. Ich achte bei der Verwendung auf den Anwendungsfall und die Performance bei der Generierung. Persönlich empfehle ich sich mal XIDs anzuschauen.
[gr] Danke für Dein Feedback 😊
Sehr gutest Video! Man hätte auch noch auf andere Algorithmen wie Snowflakes (z.B. verwendet von Twitter und Discord) eingehen können. Diese benutze ich in den meisten Fällen, da sie relativ numerisch nach Zeit sortierbar sind und sich ohne kompliziertes decoden wieder zu einem UNIX timestamp umwandeln lassen.
[gr] Danke für Deinen Kommentar 😊
Bevorzuge natürliche Schlüssel. Beispiel Manufacturer + Serial-No. Bei künstlichen Schlüsseln kann man niemals das Objekt finden, ohne den Schlüssel zu kennen. Der Vorteil dass dieser eindeutig ist, entpuppt sich dann eher als Nachteil.
Ich nutze auch UUIDs mit Zeitstempel in den ersten Bits ;-)
[gr] Danke für Dein Feedback 😊
Hab auch meistens im Web mit UUIDs zu tun (oder MongoDBs ObjectID). Dass numerische IDs für offline fähige Anwendungen nicht geeignet ist ist meiner Meinung nach eher falsch. Wenn alles lokal sein soll ist SQLite sehr gut und benützt auch numerische IDs. Wenn du schon mal Android entwickelt hast deren mehr oder weniger empfohlener ansatz für offline caching von online daten ist auch dass du diese ine in eine lokale SQLite datenbank packst und dann halt je nachdem ob du internet hast oder nicht in deinen Repositories das richtige zurückgibtst. Son ähnlichen ansatz kann man mit edge Anwendungen auch betreiben schreibt man halt die Daten in eine lokale SQLite DB wenn kein internet da ist und schiebt die irgendwann später in die online DB wenn das internet wieder verfügbar ist. Bekommen sie dann halt ne neue ID, kein Problem. Ne Datenbank zu haben die dir hier die Arbeit abnimmt ist sicherlich nett, aber es ist auch keineswegs ein schwer lösbares Problem wenn das nicht der Fall ist (in vielen Fällen).
[gr] Naja, den kritischen Punkt hast Du schon erwähnt:
> "Bekommen sie dann halt ne neue ID, kein Problem."
Das sehe ich ein bisschen anders, weil Du ja basierend auf dieser ID eventuell schon andere Sachen gemacht hast. Das ist ja nicht nur eine ID an einer einzigen Stelle, die es zu ändern gilt, sondern das zieht unter Umständen einen ganz schönen Rattenschwanz nach sich.
Und wenn Du an ein System wie Git denkst, dann geht das schon mal gar nicht mehr (was ja auch der Grund ist, warum Git nicht mit numerischen IDs, sondern mit Hashes als IDs arbeitet).
@@thenativeweb Kommt halt drauf an mit was du arbeitest. Bei den Daten mit denen ich in der Arbeit zu tun habe ist für gewöhnlich die ID relativ egal und ledeglich die Zeit zu der die daten (ursprünglich) aufgenommen worden sind wichtig. Also on edge wird nur typisches IOT data hoarding betrieben und nicht wirklich großartig was damit gemacht. Es wird halt lokal zwischengespeichert wenn kein internet verfügbar ist in unter umständen riesengroße recht unleserliche minimal strukturierte jsons. Solang das technisch keine Probleme darstellt hat das auch seine Vorteile. Selbst wenn man bei nem Kunden nen Fehler baut für irgend einen Wert. Wenn du bei der abspeicherung der Rohdaten keine großartige Logik eingebaust, kannst du wenn Fehler auftreten alles im nachhinein wieder nachrechnen. Muss sich dabei nichtmal um einen Fehler im Code handeln. Das hat alles bezug zur realität. Vielleicht hast du dich irgendwo vermessen, oder vertippt bei Kunde xyz und temperatursensor z ist jetzt ganz wo anders als er eigentlich sein sollte.
ich nutz meistens nen idgenerator der auf twitter snowflake basiert. nach aussen werden die generierten ids dann noch zusätzlich verschlüsselt
[gr] Danke für Dein Feedback 😊
Es gibt seit neuem auch UUIDv6, UUIDv7 und UUIDv8
Uuid beste!
Irgendwie flackert der Hintergrund, denke es liegt an den Nanoleafs.
Hi, ich gebe Dir nur zum Teil recht. Doch leider funktioniert das nicht so einfach auf die ID zu verzichten. Ich habe schon einige Security Dialoge geschrieben auf Mainframes (IBM Grossrecner z/OS). Hier muss man eine ID haben um sich anzumelden. Das heisst aber nicht das ich mich nur auf die Mainframes beziehe, ich benutze weiter noch andere Systeme wie Windows, AIX, Solaris und Linux. Wenn auf einem der erwähnten Systeme ein Problem auftritt werden die Änderungen nachgefahren. Die Daten sind auf x-Systemen verteilt. Natürlich muss man sich gedanken machen wie hallte ich das ganze sauber so das alle Systeme auf dem gleichen Stand sind. Denn jeder User hat eine ID welche ganz bestimmte Berechtigungen hat und das auf verschiedenen systemen. Natürlich muss man auch ein System Führendes System definieren. Klar die anderen ID Typen sind Sicherer aber die kann man nicht überall verwenden.
Gruss
Woahh. In welcher App aus der Hölle lässt du vorgeben, welche ID erstellt werden soll? Das ist null-komma-nix ihre Aufgabe, sondern die des Storages (Mysql, Postresql, Mssql, Oracle - und wenn man noSQL dazu zählen will, auch Couch, Mongo und co - oder auch Redis, Shinxsearch, Elasticsearch, ...). Dass man sie von aussen abschirmt, ist nen "feature" - man erstellt ein uniques "slug" Feld zum Direktaufruf. Dass man sie sortable macht - nen created_at Feld im Table / Document / Name it. Aber das Video war jetzt mal krass an der Realität vorbei - zumindest da, wo es sich um sehr komplexe Applikationen handelt.
Und zum Thema Cloud: Irgendwo muss es immer nen sync geben zwischen den Master / Slaves (oder Clusters - und darf man master / slave eigentlich noch sagen?) - sehe da nichts aus deiner Argumentation. Aber mag DURCHAUS MÖGLICH sein, dass ich da was falsch verstanden habe.
P.S. Bei Elastisearch gibt man die ID (normal numerisch) an, aber bei Spinx weiss ich nicht mehr - schon zu lange her
Ansonsten: Mag euren Content. Eine meiner "Up-To-Date Bleiben" Kanäle. Aber das war irgendwie nichts ;)
[gr] Also, zuerst einmal: Nicht jede Anwendung nutzt eine Datenbank, insofern kann man die Entscheidung manchmal eben nicht "auf die Storage" auslagern.
Zum zweiten, selbst wenn man das macht, muss auch dort irgendwer initial einmal die Entscheidung treffen, wie IDs aussehen sollen (Autoincrement-Feld, UUID-Feld, …), die Frage ist also auch mit Datenbank nicht hinfällig.
Zum dritten: Deine Idee mit dem CreatedAt-Feld greift unter Umständen zu kurz, weil Du damit erstens auf die Granularität von Timestamps angewiesen bist, und weil Du zweitens wieder das Problem mit Clock-Skew in verteilten Anwendungen hast. Ja, das lösen UUIDs auch nicht, aber Vektor-Uhren zB schon.
Viertens: Du lehnst Dich ja sehr weit aus dem Fenster mit der Aussage, dass das Video "mal krass an der Realität vorbei" war. Vielleicht lässt Du uns ja an Deinen Erfahrungen zu "sehr komplexe[n] Applikationen" teilhaben, und erklärst, wie man dort mit IDs Deiner Meinung nach richtig umgeht?
Wäre schön, wenn Du dazu ein bisschen mehr sagen und vor allem konkreter werden könntest als einfach zu behaupten, das sei Aufgabe der Storage und damit wäre das Problem ja gelöst …
@@thenativeweb Also bei "komplexen Anwendungen" rede ich von selbstgebauten CMS, Shoppingsystemen und dergleichen. Also Zeug, wo man ohne einer Storage nicht so weit kommt, sondern schon relationale Datenbanken (noSQL ist für sowas einfach nur: nein ;)) + etwas "Side-Schnickschnack" (Elasticsearch z.B.) braucht. Was ich auch seit 20 Jahren+ mache. Und an die Datenbanken tritt man ja häufig mit ORMs / ODMs ran - raw query schreiben tut man eigentlich nur noch selten - eigentlich nur noch bei harter Performanceoptimierung und stored procedures und/oder big data. Und solche ORMs bzw. ODMs haben normalerweise keine Setter für IDs.
Man kann zwar irgendwie die default ID von (autoincrement) Int auf was anderes umbiegen, MariaDb selber sagt da aber z.B. "tuts aus performance gründen lieber nicht" - ich weiss jetzt nicht, ob ich hier links posten darf - aber google uuid mariadb.
Deswegen meinte ich, das ist hart an der Realität vorbei: weil normal hast keine Wahl.
TLDR: benutze ULID
[gr] Danke für Dein Feedback 😊
Bin ein Freund von timeuuid
[gr] Du meinst die aus Cassandra?