WEBVTT 00:00.031 --> 00:12.084 [SPEAKER_00]: Du bist hier im Engineering Kiosk gelandet und zwar im Engineering Kiosk Attenwentskalender. 00:12.144 --> 00:20.733 [SPEAKER_00]: Leider hat dieser Kalender nichts mit Schokolade zu tun, doof, finde ich auch, noch gut, mach's nix als Alternative, bieten wir ein wenig wissen. 00:20.773 --> 00:29.582 [SPEAKER_00]: Ein Thema kurz so knapp in ein paar Minuten und das Ganze bis heilig ab. 00:29.731 --> 00:31.213 [SPEAKER_00]: Präsentiert von Wolfi. 00:31.233 --> 00:31.995 [SPEAKER_00]: Los geht's! 00:32.015 --> 00:35.220 [SPEAKER_01]: Viel Spaß! 00:35.240 --> 00:52.228 [SPEAKER_01]: 389-4 F9-389-4 9F-90-Binnestrich-180-3-Binnestrich-415-strich-B25C-Binnestrich-4-1-4-1-2-7-E-8-2-0-4-7-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1 00:52.208 --> 00:54.011 [SPEAKER_01]: Kennt ihr wahrscheinlich alle, oder? 00:54.031 --> 00:57.457 [SPEAKER_01]: Sind die sogenannten UUIDs? 00:57.497 --> 00:58.960 [SPEAKER_01]: Finnenmeinlich überall. 00:59.000 --> 01:05.812 [SPEAKER_01]: Kennt man vielleicht das dem F-Stab-File im Linux-Filesystem botcast Episodeen waren so auch eindeutig definiert. 01:05.832 --> 01:13.525 [SPEAKER_01]: Also 36 Stellen sind 128bit, weil 32X-Kalks das sind und eben 4 Winnestriche dazwischen. 01:13.724 --> 01:27.248 [SPEAKER_01]: Diese EU-I-Dies sind wirklich sehr beliebt und stammen ursprünglich schon aus den 80er-Jahren von dem Apollo-Computer, der besonders für den Netzwerkbereich diese EU-I-Dies verwendet hat. 01:27.309 --> 01:38.128 [SPEAKER_01]: Später ist es auch aufgegriffen worden von der OSF oder wer vielleicht aus der Microsoft-Welt kommt. 01:38.108 --> 01:47.226 [SPEAKER_01]: Sind global unique Identifiers, Microsoft Backtagern zu geschwungenen der Klammern, um herum um so eine EU-ID oder gut zu definieren. 01:47.266 --> 01:56.404 [SPEAKER_01]: Wo viele jetzt vielleicht einfach nur einen Random-Spring sehen, das Ganze ist auch wirklich standardisiert, gibt auch mehrere Versionen von EU-IDs. 01:56.384 --> 02:00.931 [SPEAKER_01]: Aber die Frage, der sich eigentlich stellt, ist, warum verwendet man diese EU-IDs? 02:00.951 --> 02:13.991 [SPEAKER_01]: Und die Idee ist, dass EU-IDs wirklich eindeutig sind, dann sich ja auch Universi-Unique-Adentifiers, dass die Unique sind, weltweit auch, wenn sie nicht am selben System erzeugt worden sind. 02:14.031 --> 02:17.717 [SPEAKER_01]: Also im Gegensatz zu Auto-Inkrimand, den Datenbanken, wo man einfach hochzählt, 02:17.697 --> 02:27.703 [SPEAKER_01]: Wenn es zwei Datenbanken machen, auf zwei verschiedenen Rechnen, bekommt man natürlich Überlapungen und die Selben IDS mit UU IDS passiert das eigentlich nicht. 02:27.943 --> 02:29.327 [SPEAKER_01]: Wie funktioniert das nun? 02:29.347 --> 02:33.377 [SPEAKER_01]: Das ist da keine Überschneidungen gibt oder das ganze Eindeutig bleibt. 02:33.357 --> 02:36.642 [SPEAKER_01]: Das hat einfach damit zu tun, dass das ein sehr großer Zahlenraum ist. 02:36.702 --> 02:40.769 [SPEAKER_01]: Wir sprechen davon, 2,288 Möglichkeiten. 02:40.809 --> 02:52.969 [SPEAKER_01]: Also, diese ist eine Zahl mit 3800 und wenn man jedes Sandkorn auf allen Stränden auf der Welt durch numerehen würde, hätte man trotzdem noch 99,9 Prozent von den gesamten Zahlenraum. 02:52.949 --> 02:59.340 [SPEAKER_01]: Und dadurch der Zahlenraum so groß ist, bis sie in Koalitionen eigentlich in der Realität nicht. 02:59.360 --> 03:13.303 [SPEAKER_01]: Und das obwohl nicht mal die 36 Stellen alle für die Zahl an sich genutzt waren, es gibt auch einen Version, die noch kutiert ist und eine Variante im vierten Block, die zusätzlich noch in der UUID automatisch mitkutiert wird. 03:13.283 --> 03:18.308 [SPEAKER_01]: Und genau diese Koalitionsfreiheit ist eigentlich das Interessante an UUIDs. 03:18.328 --> 03:20.169 [SPEAKER_01]: Und warum sie auch so gerne verwendet werden? 03:20.189 --> 03:25.934 [SPEAKER_01]: Weil man muss nur dran denken, an Verteiltesysteme, Microsoft SSDs immer stärker aufgekommen sind. 03:25.954 --> 03:28.136 [SPEAKER_01]: Wenn man offline Systeme z.B. 03:28.176 --> 03:43.290 [SPEAKER_01]: hat, oder auch Edge Systeme, die möglichst schnell antworten müssen, möglichst schnell IDs erzeugen müssen, dann verwendet man natürlich gerne UUIDs, weil jedes System des Selbstständig erzeugen kann, 03:43.270 --> 03:53.287 [SPEAKER_01]: Und wenn man dann natürlich Daten zusammenführt, später ist es essentiell, dass man da Juniq ID ist hat und keine Koalitionen bei einem Merch dann aufdauchen. 03:53.708 --> 04:08.653 [SPEAKER_01]: Zusätzlich, was wir in Vorteil mal noch kostenlos zu sagen mitbekommen ist, dass die IDs nicht erraten werden können, das heißt, gerade bei einer öffentlichen API zum Beispiel, wenn man dann Auto increment hat und User 1 User 2 User 3, 04:08.633 --> 04:18.309 [SPEAKER_01]: Kann natürlich am Mensch sehr schnell erraten, okay, die nächste ADSUze 4, Joseph 5, Joseph 6 und kann dann vielleicht auch gewisse Dinge ausprobieren. 04:18.349 --> 04:29.106 [SPEAKER_01]: Wenn man so eine EU-ID hat, ist es eigentlich kaum möglich, die nächste ID zu erraten und dadurch sind natürlich solche Brutforsordakten und umständen auch wesentlich schwere Durchzufinden. 04:29.373 --> 04:54.132 [SPEAKER_01]: Jetzt werden natürlich vielleicht viele sagen, ja, aber verdeiltes Systeme haben wir meistens auch verantwortlichkeiten und jedes verdeiltes System ist für eine Art von Entität verantwortlich, aber in der Realität muss man schon auch sagen, dass das immer schwieriger wird vor allem immer in größeren Firmen, verdeilt die Teams, verdeiltes Systeme haben und da kann es dann auch natürlich solche Schärterysponsibilities geben, wenn man zum Beispiel sich überlegt, man hat so ein 04:54.112 --> 05:03.106 [SPEAKER_01]: Hotel Management System, wo man neue Hotels anlegen kann und man will jetzt diese Hotels nummerieren und eine Idee vergeben. 05:03.146 --> 05:09.456 [SPEAKER_01]: Jetzt können wir natürlich neue Hotels reinkommen bei irgendwelchen automatischen Imports von irgendwelchen Partnern von Schnittstellen. 05:09.956 --> 05:13.822 [SPEAKER_01]: Es kann das Abort vielleicht ein neues Hotel anlegen in einem Online-Tool. 05:13.842 --> 05:18.229 [SPEAKER_01]: Der User kann vielleicht selbstständig ein neues Hotel anlegen von einer Hotelkette. 05:18.209 --> 05:24.499 [SPEAKER_01]: Also das sieht man schon, dass die selber Entität in verschiedenen Systemen angelegt werden kann. 05:24.539 --> 05:31.631 [SPEAKER_01]: Und wenn man dazu dann keine EU-IDs verwendet, dann werde die Alternative, dass meine Single Authority hat. 05:31.651 --> 05:38.682 [SPEAKER_01]: Also eine zentrale Stelle, wo man immer anfangen muss, gibt mir die nächste verfügbare ID, damit man dann Transaktionen haben. 05:38.662 --> 06:03.673 [SPEAKER_01]: ist das sauber alles durchführen, mit der Handshakes, wo möglich haben, das ganze Aufleihen funktioniert natürlich nicht, wenn jetzt am Handy irgendwas erstellt, bei meinem Kunden zum Beispiel bin ich in dem Hotel vor Ort, habt dort kein Internet, das irgendeinem Grund wilder etwas erstellen, da muss ich später als wieder eine AD erzeugen, kann es nicht an der Fleim machen, also das in YouTube ID ist wesentlich flexibler und darum werden sie auch sehr gerne eingesetzt. 06:03.653 --> 06:31.180 [SPEAKER_01]: Ihr habt schon erwähnt, es gibt verschiedene Versionen von UU IDS, also es gibt wasion 1 bis Version 8, die Version 1 und 2 sind zeitbasierte, Formate, also da ist die Zeit, wann die ID erstellt wurde und die Mekka Dresse auch noch mit reinkuttiert, als dem Grund wird das eigentlich auch nicht mehr empfohlen zu machen, weil wenn man die Mekka Dresse irgendwo reinkuttiert ist es sicher als technisch meistens weniger schlau, Version 3, 5, 06:31.160 --> 06:48.950 [SPEAKER_01]: Sie namensbesierte Varianten, das heißt, man hat da eigentlich eine Namespace und einen eigentlichen Namen in den Einlichen Welt und der ganze wird dann gehecht ganz klassisch mit MD5 oder Scha1 und es kommt am Ende wieder eine UUID heraus. 06:48.971 --> 06:55.682 [SPEAKER_01]: Da ist da Namespace auch schon kutiert, das heißt, ich kann das sagen, okay, diese UUID soll ein Hotel sein, diese UUID soll. 06:55.662 --> 07:02.049 [SPEAKER_01]: Ein Hotel Timmer sein, die für UUID soll, ein Preis sein, für eine gewisse Zeit. 07:02.069 --> 07:05.393 [SPEAKER_01]: Also da kann ich dann über den Namespace solche Dinge schon rein. 07:05.413 --> 07:08.776 [SPEAKER_01]: Kodieren und der Namespace selbst ist dann auch wieder eine UUID. 07:08.796 --> 07:14.983 [SPEAKER_01]: Und dadurch das Geherst wird, habe da keine langen Probleme und kann das immer wieder auf eine UUID zurückführen. 07:15.003 --> 07:20.870 [SPEAKER_01]: Dadurch dessen Hash ist, kommt da immer auch die selber UUID für die selben Ausgangswerte heraus. 07:20.910 --> 07:22.952 [SPEAKER_01]: Und das bleibt da so auch so nachvollziehbar. 07:22.932 --> 07:30.827 [SPEAKER_01]: Die wohl bekannteste Version ist die Version 4, auch Random genannt, dies also wirklich komplett zufällig. 07:30.847 --> 07:43.692 [SPEAKER_01]: Das ist eigentlich die, die gerne eingesetzt wird, bei Verteilten Systemen, weil sie halt sehr einfach ist, man kutiert gar nicht zenein, es ist komplett Random und man bekommt einfach eine unique ID zurück, die im normalfall keine Koalition hat. 07:43.672 --> 08:00.197 [SPEAKER_01]: Version 6 hat dann wieder Zeitstempel hineingenommen, auch im Bezug auf Zudierbarkeit, dass man das nach Zeit zu diren kann und dem Gegensatz zu der Version 1 und 2, die auch die Meckertresse mit dabei haben, hat die Version 6 jetzt keine Meckertresse mit dabei. 08:00.717 --> 08:10.472 [SPEAKER_01]: Version 7 hat auch die timestamp die Unix timestamp in dem Fall mit dabei und ist dadurch auch Zudierbar und gerade gut für Datenbanken verwendbar. 08:10.452 --> 08:21.164 [SPEAKER_01]: Version 8 ist komplett kastem, das heißt da kann man wirklich jedes Format reinspeichern und sich selber ein Pättern überlegen, wie man das Ganze aufdeilt den Atressraum. 08:21.504 --> 08:27.111 [SPEAKER_01]: Was natürlich alle gemeinsam haben ist die Koalitionsverscheinlichkeit und die ist wirklich sehr niedrig. 08:27.131 --> 08:31.416 [SPEAKER_01]: Hab ich auch schon kurz ausgeführt, aber um das noch mal in Zahlen zu fassen. 08:31.876 --> 08:38.063 [SPEAKER_01]: Es gibt ja dieses bekanntige Budstocksparadoxon, das besagt das, wenn man zum Beispiel 08:38.043 --> 08:48.319 [SPEAKER_01]: Und man in einem Raum mit 23 Personen ist, dann ist die Wahrscheinlichkeit, dass es zwei Personen gibt, die im selben Tag Geburtstag haben, bei 50 Prozent. 08:48.339 --> 08:58.195 [SPEAKER_01]: Also man nimmt immer so eine 50 Prozent Wahrscheinlichkeit an, dass man eine Koalition hat, also zwei Geburtstag in dem Fall, und bei einer Geburtstagspartewende schon 23 Personen. 08:58.175 --> 09:09.175 [SPEAKER_01]: Bei UUIDs ist es ganze 2 hoch 4 und 60, das sind also ungefähr 18 Drillionen, dass wir eine 50% die Gehverscheinlichkeit hat, eine Koalition zu haben. 09:09.616 --> 09:20.976 [SPEAKER_01]: Auch wir das kleiner vergleich, wenn jeder Mensch auf der Erde jede Sekunde eine UUID erstellen würde, dann bräuchten wir Jahrzehnte bis man eine einzige Koalition hätte in dem ganzen System. 09:20.956 --> 09:28.665 [SPEAKER_01]: Also wenn du dir jetzt ernsthaft irgendwie Gedanken machst, ob ihr die UU-IDs verwenden kann, weil ihr da vielleicht Koalitionen auftreten können. 09:28.705 --> 09:31.548 [SPEAKER_01]: Ja, dann auch jetzt ist du wahrscheinlich beim Zellen. 09:31.568 --> 09:46.525 [SPEAKER_01]: Oder hast einfach einen extrem schlechten Random Number Generator, weil das ist auch auf dein Problem, dass dann UU-ID-Kollisionen vorkommen, aber wenn man eine Library verwendet, dann ist es normalerweise sichergestellt und die verwenden dann auch eine sauberen Bementierung. 09:46.572 --> 09:58.748 [SPEAKER_01]: Aber in der Informatik gibt es ja nichts ohne Nachteile, sonst war es ja schön, die, die es lösen, alle unsere Probleme in verteilten Systemen, aber gerade in Datenbanken, wenn man mit UUIDs arbeitet, hat man natürlich gewisse Nachteile. 09:58.768 --> 10:02.473 [SPEAKER_01]: Also grundsätzlich hat man mal den Speicherbedarf, der wesentlich höher ist. 10:02.573 --> 10:11.905 [SPEAKER_01]: So bei einem klassischen Integer sprechen wir normalerweise von vier Beit, ein Bic-Innt, acht Beit und eine UUID, aber schon 16 Beit. 10:11.885 --> 10:31.078 [SPEAKER_01]: Wenn Sie bisher gespeichert wird, wenn man es jetzt wirklich als Charakter speichert, also als Hecks Charakter, dann hat man überhaupt 36 Characters, die sollte man auf keinen Fall machen, weil auch Strang in die Zeiss in Datenbanken üblicherweise ganz anders funktionieren und im normalen Fall auch wesentlich langsam ersehen als Benäire in die Zeiss. 10:31.118 --> 10:34.163 [SPEAKER_01]: Die wirklich auf den Numen, auf den Benäirtaten arbeiten. 10:34.143 --> 10:38.229 [SPEAKER_01]: Was heißt das jetzt 16 Beit statt 4 Beit oder 8 Beit? 10:38.249 --> 10:55.273 [SPEAKER_01]: Also, wenn man jetzt eine Milliarde Einträge hätte und das ist ja ungefähr was ein Intischer Platz hat, dann hätte man 12 Beit oberhalb zu 4 Beit intischer und das wäre am Ende dann schon zehn geige Beit, wobei man natürlich da sagen muss, wer hat schon eine Milliarde Rose, die man da so einträgt in der Datenbank. 10:55.253 --> 11:00.361 [SPEAKER_01]: Wenn man es von einem realistischeren Beispiel ausgehen, wir im 1.000 Millionen Einträge, wenn sie z.B. 11:00.401 --> 11:07.492 [SPEAKER_01]: welche Artikel geht oder Kräufe, da sind wir mit 1.000 Millionen E-Schunds her hoch und sprechen, wir von dem Oberhead von 10 Meter Beit. 11:08.012 --> 11:14.983 [SPEAKER_01]: Also 10 Meter Beit sind heute da gewöcklich kein Problem, auch 10-Jiger Beit sind wahrscheinlich kein Problem, wenn man Milliarden von Einträge hat, weil dann hat man. 11:14.963 --> 11:20.092 [SPEAKER_01]: höchst wahrscheinlich sehr große Datenbank, weil die anderen Werte wesentlich mehr Speicher benötigen. 11:20.112 --> 11:28.707 [SPEAKER_01]: Also es fällt jetzt nicht so stark, hinsgewicht zu lang man auf binary 16 bleibt, also wirklich dem RAW Format von UUIDs. 11:28.727 --> 11:31.572 [SPEAKER_01]: Ein anderes Problem mit Datenbanken und UUIDs 11:31.552 --> 11:34.577 [SPEAKER_01]: ist aber der Index an sich und die Zutierung. 11:34.858 --> 11:40.808 [SPEAKER_01]: Jetzt haben wir schon darüber gesprochen, dass die Version 4 von UUIDs komplett random ist zufällige Werte. 11:41.169 --> 11:47.941 [SPEAKER_01]: Das Problem in Datenbanken und Indexstrukturen und auch die Speichrung der Daten an sich ist dass das ganze über B-Breume läuft. 11:47.981 --> 11:53.290 [SPEAKER_01]: B-Breume sind ja super optimiert und lieben es aber sehr kvinzielle Insatz zu haben. 11:53.270 --> 12:01.586 [SPEAKER_01]: Das heißt, die lieben Sequenzielle IDs zu haben, damit die im Baum immer optimiert am Ende in den Blättern hängen. 12:01.906 --> 12:07.377 [SPEAKER_01]: Hat man jetzt Jürio IDs landen diese Random-Werte natürlich irgendwo im Baum. 12:07.437 --> 12:10.182 [SPEAKER_01]: Das heißt, der Baum kann sich nicht schön langsam füllen. 12:10.162 --> 12:12.787 [SPEAKER_01]: sondern es gibt ganz vieles Blitzes werden. 12:12.827 --> 12:15.472 [SPEAKER_01]: Blätterges Blätter, das gibt Hallblare Knoten. 12:15.492 --> 12:28.778 [SPEAKER_01]: Die Speichermanenschmend wird viel schwieriger, weil die Batsch ist natürlich ständig aus dem Cash rausgekickt werden, weil man springt der im Baum wahllos herum und dafür sein Babam einfach nicht geeignet und auch nicht gemacht wurden. 12:28.758 --> 12:35.668 [SPEAKER_01]: Das ist jetzt, wenn man 1000 Entries hat oder auch vielleicht eine Million Entries wahrscheinlich noch gar nicht so relevant. 12:35.688 --> 12:49.247 [SPEAKER_01]: Aber man spielt es natürlich schon, wenn man viele Giants hat, die ID sind ja doch immer ein zentraler Punkt, wo ganz viele Giants gemacht werden, wo Daten gesucht werden und da hat man dann direkt dann schon das Problem, dass das Ganze langsam er wird. 12:49.227 --> 13:10.071 [SPEAKER_01]: Die Alternative wäre, dass man Zeit passiert, der Version ernehmt von den UUIDs, also Version 1 oder besser noch 6 oder 7, weil die Meckertresse eben nicht mitkutiert ist und Bosch-Gress und MariaDB haben auch eigene UUID-Düppen, also MariaDB erst seit Version 107 und diese UUID-Düppen. 13:10.051 --> 13:22.809 [SPEAKER_01]: Ob die mir in das ganze noch mal mehr, das gewisse Deile nach vorne verschoben werden, von den U.U.IDs, damit das ganze noch sequenzieller ist und noch optimierter eingefügt werden kann. 13:22.849 --> 13:31.021 [SPEAKER_01]: Also die machen in Internet Swapping, von Teilbereichen einer U.U.ID, um insgesamt noch mal mehr Optimierung rausholen zu können. 13:31.442 --> 13:39.433 [SPEAKER_01]: Also wenn man mit Datenbank arbeitet, sollte man wirklich auf die nativen Typen gehen und 13:39.413 --> 13:54.136 [SPEAKER_01]: Es gibt aber auch natürlich Alternativen, weil wie gesagt die UUIDs oder Gits sind schon sehr alt sind, dass den 80er-Jahren die Konstrukte davon sind noch älter und seitdem hat sich natürlich viel gedaan. 13:54.196 --> 14:00.426 [SPEAKER_01]: Das heißt, es gibt auch mittlerweile ein Alternativen, es gibt die Snowflake halties, die ursprünglich Twitter verwendet hat. 14:00.406 --> 14:09.702 [SPEAKER_01]: Also das Ganze wieder timestampusiert, hab eine timestamp, hab dann noch eine Schart ID und einen Siegwenskater und erreichen so mit dann auch die Eindeutigkeit. 14:09.743 --> 14:24.709 [SPEAKER_01]: Es gibt die U-Litz, die Universi-Unique Lexico Graphic-Hilly, Sortable Identifier-Schwieries-Wort, auch wieder Zeit, Informationen plus ein Zufallswert dahinter, was mittlerweile auch sehr beliebt ist, in dieser Nano ID ist, das sind eigentlich 14:24.689 --> 14:33.261 [SPEAKER_01]: Characters passiert der IDs, also die haben ein Alphabet von 64 Zeichen ohne Zomterzeichen und man verwendet dann z.B. 14:33.281 --> 14:48.283 [SPEAKER_01]: 21 Zeichen und es gibt dann wieder eine Entruppie von 108 und 20 Bit ungefähr, kennt man ja, wenn man mehr Zeichen verwendet, dann hat man einfach an wesentlich größeren Raum mit weniger Zeichen und bekommt dann da auch sehr viel unter. 14:48.263 --> 15:17.325 [SPEAKER_01]: Also noch mal abschließend, vielleicht so als Faustregel, wenn ihr in den Monolithen unterwegs seid, eurem heiße Kuelldatenbank habt, und eine Monolithen in BHB oder sonst eine Sprache, kann man Auto increment verwenden, außer man hat jetzt vielleicht das Problem, dass die Ideis offensichtlich sind und man diese Erraten kann und vielleicht auch im Alltag sich dann so einschleicht, dass man dann immer von der ID 8-redet, wenn zum Öntnis Kategorie geht und jeder weiß dann, 15:17.305 --> 15:25.179 [SPEAKER_01]: Also auch das ist teilweise gar nicht so gut, wenn man so gewisse Werte so im Direkt im Kopf hat und immer darüber spricht. 15:25.239 --> 15:31.951 [SPEAKER_01]: Also auch da, wenn man so was verhindern will, kann man natürlich die USA des verwenden, aber sonst ist ein Auto increment vollkommen in Ordnung. 15:31.991 --> 15:35.618 [SPEAKER_01]: Sobald man jetzt in die Verteilung geht und wirklich darauf angewiesen ist, dass man ... 15:35.598 --> 15:37.721 [SPEAKER_01]: Enttideten bzw. 15:37.761 --> 15:48.996 [SPEAKER_01]: ihre ITs, detzentral erstellen will, dann braucht man Julia IDs und da ist eigentlich die Empfehlung, weil man muss irgendwo wegspeichen und üblicherweise sind des Datenbanken. 15:49.016 --> 16:00.812 [SPEAKER_01]: Dass man da einer Differ-U-ID-Typen verwendet, wenn die Datenbank des Hergibt und auf Zeit passiert der Version entgeht, also nicht die Version 4, die komplett random ist, sondern 16:00.792 --> 16:12.377 [SPEAKER_01]: Und auch ganz wichtig, dass wir immer mit dem Benerwerten rechnet, also eine binary 16, wenn man schon keine nativen UU-IT-Typen verwendet und auf keinen Fall die Charakter dann wirklich abspeichert. 16:12.397 --> 16:20.033 [SPEAKER_01]: Obwohl man natürlich jetzt zu dem repräsentieren, da IT, dann jeweils die Charakter verwendet, weil die halt human readable sind als die Benerdaten. 16:20.013 --> 16:41.543 [SPEAKER_01]: Und wenn man Probleme mit den UUIDs hat, kann man eben die diversen Alternativen wie Snowflake ID durchausmal anschauen, aber UUIDs sind natürlich super unterstützt, gibt fast in jeder Sprache irgendwelche Funktionen um UUIDs zu erstellen und damit zu arbeiten und das macht das Ganze dann natürlich auch wesentlich einfacher im Alltag. 16:41.583 --> 16:46.830 [SPEAKER_01]: Und weder die Koalitionen noch der Speicherbedarf, sind im Alltag üblicherweise ein Problem. 16:46.810 --> 16:56.264 [SPEAKER_01]: In den Schauen uns findet ihr natürlich noch ein Ballings zu Block einträgen, auch von den üblichen Datenbank, Verdächtigen, wo es danach mehr um die ganze Implementierung und Optimierung geht. 16:56.324 --> 17:00.651 [SPEAKER_01]: Also falls ihr mal mehr Zeit haben solltet in der ruhigen Adventszeit. 17:00.671 --> 17:05.899 [SPEAKER_01]: Siem Bagut der Blockartikel dabei und damit wünsche ihr euch nur schöne Adventszeit bis zur nächsten Episode. 17:07.077 --> 17:09.460 [SPEAKER_00]: Danke, Wolfi, für diese Episode. 17:09.480 --> 17:15.789 [SPEAKER_00]: Das war's für heute von uns, wenn dir das, was du gehört hast, gefallen hat, würden wir uns natürlich immer über Feedback freuen. 17:15.829 --> 17:23.780 [SPEAKER_00]: Entweder über ein positives Review auf der Podcastplatz von der Naval, ein Daumen hoch auf Social Media oder einer anecdote in unserer Discord Community. 17:23.800 --> 17:25.422 [SPEAKER_00]: Ich bin mir sicher, du findest schon ein Weg. 17:25.842 --> 17:30.829 [SPEAKER_00]: Wir freuen uns auch, wenn du diesen Podcast abonnierst und einfach bei der nächsten Episode wieder einschalten. 17:30.849 --> 17:31.690 [SPEAKER_00]: Wir hören uns bald. 17:31.710 --> 17:33.793 [SPEAKER_00]: Schöne Weihnachtszeit.