Zur ersten Frage: Ja, ich habs gesehen und ja, ich weiß, wie ich es finden würde, denn der Titel beinhaltet auch "75%". Von daher ist die Suche davon innerhalb eures Kanals einfach ;-)
@@thenativeweb Aber dafür habt ihr doch eure App! Dass die nicht erwähnt wurde, ist ja nahezu fahrlässig. Der eindeutige Bezeichner dafür ist ja auch die URL. Ich schreibe die mal nicht aus. RUclips mag das ja wohl angeblich nicht so sehr, wenn URLs in Kommentaren stehen.
Ich fände es ziemlich gut, immer zumindest einen groben Richtwert für die Anwendungsgröße anzugeben, wenn man Leuten vor dem "default Verhalten" Angst macht. Ich habe noch keine Anwendung gesehen, bei der stinknormale bigint-IDs aus Performance-Gründen nicht ausreichend waren. Über wie viele DB-Schreibzugriffe pro Sekunde reden wir? Ich glaube dir schon, dass du größere Anwendungen baust, als ich. Aber vermutlich baust du auch größere Anwendungen, als 97% deiner restlichen Zuschauer.
14:30 dazu hätte ich einmal eine Frage: Wenn IDs keine Daten enthalten sollen, müssten dann nicht einfache counter wegfallen, da ich hier informationen über die Erstellungsreihenfolge von Objekten herleiten kann? Und müsste nicht alles mit Zeitstempel ebenfalls ungeeignet sein, da ich hier direkt die Information habe, wann ein Objekt erstellt wurde? Vielen Dank schonmal.
Ja und nein bzw. "Das kommt drauf an" Die Frage dabei ist, was es für Rückschlüsse zulässt, wenn du einen Counter hast. Bsp: Habe ich eine Anwendung zur Verwaltung von Geräten mit Ausleihfunktion (Zum Beispiel Rechnerverwaltung mit Beamerverleih an einer Uni) dann erlaubt eine hochgezählte ID keinerlei Rückschlüsse auf nicht bereits offensichtliche oder irgendwie schützenswerte Daten. Die Mitarbeiter können ruhig wissen wie viele PCs, Monitore, Beamer, Laptops, Tastaturen und Mäuse es gibt. Habe ich einen Onlineshop, sieht das wieder sehr anders aus. Eine hochzählende ID verrät hier einem Wettbewerber sehr wohl etwas über das Ordervolumen. Das sind einfach Daten, die man nicht jedem geben möchte. Da wäre ein Zeitstempel schon wieder interessanter. Zeitstempel können aber auch ein Problem sein, wenn sich deshalb bestimmte Dinge leicht raten lassen. Habe ich eine Order-Ansicht ohne Login, damit niemand gezwungen ist ein Kundenkonto anzulegen, wäre es fahrlässig einen einfachen Zeitstempel zu verwenden. Das ließe sich dann wieder raten und dann kann man sicherlich ne ganze Menge Kundendaten abgreifen. Da wären zufällige Daten IDs (UUIDv4) dann doch besser.
Wahnsinn. Erst gestern habe ich mich mit dem Thema beschäftigt und jetzt das Video! :) Für meine Anwendung möchte ich keine Authentifizierung im Frontend. Daher möchte ich UUIDs für Modelle nutzen, deren Daten im Frontend landen können. Nun soll der User einen Link zugeschickt bekommt, die die UUID enthält und so auf die Daten zugreifen können. So möchte ich sicher stellen, dass der User möglichst einfach (ohne Authentifizierung) zu den Inhalten kommt und diese gleichzeitig nur für User, die über die UUID/den Link verfügen, zugänglich sind. Sind UUIDs dabei wirklich anonym, d.h. nicht erratbar? Wie verhält es sich bei ULIDs? Ließen diese sich deutlich einfacherer erraten? Was denkst Du über diese Herangehensweise?
Du solltest Butter statt Lätta kaufen. Kalorienmäßig gleich, aber die Butter sättigt zumindest. Seitdem ich pflanzliche Fette meide geht es mir deutlich besser. Sorry Off-topic, LG ;)
![[#2024MAMA] BIGBANG (빅뱅) - 뱅뱅뱅 (BANG BANG BANG) + FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/EQsYfiPR9uM/mqdefault.jpg)
Zur ersten Frage:
Ja, ich habs gesehen und ja, ich weiß, wie ich es finden würde, denn der Titel beinhaltet auch "75%". Von daher ist die Suche davon innerhalb eures Kanals einfach ;-)
Ich dachte erst das wäre eine Neuauflage des UUID Videos. :-)
Schöne Woche!
Ich muss ganz ehrlich zugeben - das andere Video hatte ich komplett vergessen 🤣
ruclips.net/video/cEWlm-iXeF8/видео.html
@@thenativeweb Aber dafür habt ihr doch eure App! Dass die nicht erwähnt wurde, ist ja nahezu fahrlässig. Der eindeutige Bezeichner dafür ist ja auch die URL. Ich schreibe die mal nicht aus. RUclips mag das ja wohl angeblich nicht so sehr, wenn URLs in Kommentaren stehen.
Ich fände es ziemlich gut, immer zumindest einen groben Richtwert für die Anwendungsgröße anzugeben, wenn man Leuten vor dem "default Verhalten" Angst macht. Ich habe noch keine Anwendung gesehen, bei der stinknormale bigint-IDs aus Performance-Gründen nicht ausreichend waren. Über wie viele DB-Schreibzugriffe pro Sekunde reden wir? Ich glaube dir schon, dass du größere Anwendungen baust, als ich. Aber vermutlich baust du auch größere Anwendungen, als 97% deiner restlichen Zuschauer.
Danke!
Gerne 😊
14:30 dazu hätte ich einmal eine Frage:
Wenn IDs keine Daten enthalten sollen, müssten dann nicht einfache counter wegfallen, da ich hier informationen über die Erstellungsreihenfolge von Objekten herleiten kann?
Und müsste nicht alles mit Zeitstempel ebenfalls ungeeignet sein, da ich hier direkt die Information habe, wann ein Objekt erstellt wurde?
Vielen Dank schonmal.
Ja und nein bzw. "Das kommt drauf an"
Die Frage dabei ist, was es für Rückschlüsse zulässt, wenn du einen Counter hast. Bsp: Habe ich eine Anwendung zur Verwaltung von Geräten mit Ausleihfunktion (Zum Beispiel Rechnerverwaltung mit Beamerverleih an einer Uni) dann erlaubt eine hochgezählte ID keinerlei Rückschlüsse auf nicht bereits offensichtliche oder irgendwie schützenswerte Daten. Die Mitarbeiter können ruhig wissen wie viele PCs, Monitore, Beamer, Laptops, Tastaturen und Mäuse es gibt. Habe ich einen Onlineshop, sieht das wieder sehr anders aus. Eine hochzählende ID verrät hier einem Wettbewerber sehr wohl etwas über das Ordervolumen. Das sind einfach Daten, die man nicht jedem geben möchte. Da wäre ein Zeitstempel schon wieder interessanter. Zeitstempel können aber auch ein Problem sein, wenn sich deshalb bestimmte Dinge leicht raten lassen. Habe ich eine Order-Ansicht ohne Login, damit niemand gezwungen ist ein Kundenkonto anzulegen, wäre es fahrlässig einen einfachen Zeitstempel zu verwenden. Das ließe sich dann wieder raten und dann kann man sicherlich ne ganze Menge Kundendaten abgreifen. Da wären zufällige Daten IDs (UUIDv4) dann doch besser.
Wahnsinn. Erst gestern habe ich mich mit dem Thema beschäftigt und jetzt das Video! :)
Für meine Anwendung möchte ich keine Authentifizierung im Frontend.
Daher möchte ich UUIDs für Modelle nutzen, deren Daten im Frontend landen können. Nun soll der User einen Link zugeschickt bekommt, die die UUID enthält und so auf die Daten zugreifen können.
So möchte ich sicher stellen, dass der User möglichst einfach (ohne Authentifizierung) zu den Inhalten kommt und diese gleichzeitig nur für User, die über die UUID/den Link verfügen, zugänglich sind.
Sind UUIDs dabei wirklich anonym, d.h. nicht erratbar? Wie verhält es sich bei ULIDs? Ließen diese sich deutlich einfacherer erraten?
Was denkst Du über diese Herangehensweise?
Kann halt jeder drauf zugreifen, der den Link aus irgendwelchen Gründen bekommen hat.
Ist es nicht so, dass viele DBMS sich dieser Problematik (nicht indexierbare unique IDs) intern “annehmen”, d.h., optimieren?
Also theoretisch kann ja etwas nicht zur selben Zeit am selben Ort passieren. Aber lat long alt macht wohl eher Probleme wegen..
Equality vs Equivalence: auch in C++ mit dem Spaceship Operator immer eine Basis für interessante Diskussionen…
Ja … ich denke, die Diskussion gibt's so oder so ähnlich in jeder Sprache.
Du solltest Butter statt Lätta kaufen. Kalorienmäßig gleich, aber die Butter sättigt zumindest. Seitdem ich pflanzliche Fette meide geht es mir deutlich besser. Sorry Off-topic, LG ;)