Christian Bliß: UUID

Hallo,

in PERL habe ich eine UUID erzeugt:

$uuid = $ug->create_str();

heraus kam so etwas:

C948WCBE-FD77-11DA-8A42-9629134F0892

Zu meiner Frage: Bleibt das Format immer gleich? Also ändert sich am Aufbau 8-4-4-4-12 Zeichen nichts? Auch nicht in ein paar Jahren? Da in einer UUID ja auch der Timestamp eingerechnet wird, müsste ja auch der UUID-String immer länger werden, oder?

Gruß Christian Bliß

  1. Hi,

    Zu meiner Frage: Bleibt das Format immer gleich? Also ändert sich am Aufbau 8-4-4-4-12 Zeichen nichts?

    Sollte es nicht.

    Da in einer UUID ja auch der Timestamp eingerechnet wird, müsste ja auch der UUID-String immer länger werden, oder?

    Timestamps werden länger?? Ich glaube das wäre schlecht.

    MfG
    Rouven

    --
    -------------------
    ie:| fl:| br:> va:| ls:& fo:) rl:( n4:{ ss:) de:] js:| ch:? mo:} zu:|
    1. Hallo,

      Da in einer UUID ja auch der Timestamp eingerechnet wird, müsste ja auch der UUID-String immer länger werden, oder?
      Timestamps werden länger?? Ich glaube das wäre schlecht.

      Da der Timestamp jede Sekunde inkrementiert muss er früher oder später länger werden oder nicht? Hat das am 01.01.1970 nicht bei "0" begonnen und inzwischen sind wir bei "1150998491" ...

      Gruß Christian

      1. Da der Timestamp jede Sekunde inkrementiert muss er früher oder später länger werden oder nicht? Hat das am 01.01.1970 nicht bei "0" begonnen und inzwischen sind wir bei "1150998491" ...

        Sicher, aber der Timestamp wird ja intern als eine normale binäre Zahl geschpeichert, die eben eine feste anzahl an Bit hat. Sicher, irgendwann werden auch diese bits 'voll' sein. Dann kommt es halt zum Jahr-2038-Problem.

  2. Hi,

    Da in einer UUID ja auch der Timestamp eingerechnet wird, müsste ja auch der UUID-String immer länger werden, oder?

    Wie denn das? Meine Timestamp sieht so aus: Do Jun 22 19:44:28 CEST 2006
    Möglich, das es bei PERL leicht abweicht, bei MySQL besteht sie auch Datum und Uhrzeit: 2006-06-04 17:55:13

    Also ich bin mir ziemlich sicher, das sich die Länge nie ändern wird, ausser unsere Zeit-/Datumsstruktur wird geändert.

    1. Hallo,

      Wie denn das? Meine Timestamp sieht so aus: Do Jun 22 19:44:28 CEST 2006
      Möglich, das es bei PERL leicht abweicht, bei MySQL besteht sie auch Datum und Uhrzeit: 2006-06-04 17:55:13

      Also ich bin mir ziemlich sicher, das sich die Länge nie ändern wird, ausser unsere Zeit-/Datumsstruktur wird geändert.

      Nein, der Timestamp ist eine 32-Bit-Zahl die jede Sekunde inkrementiert, oder bringe ich da was durcheinander?

      1. Hello again,

        Nein, der Timestamp ist eine 32-Bit-Zahl die jede Sekunde inkrementiert, oder bringe ich da was durcheinander?

        und was sagt es dir, dass es eine 32-Bit-Zahl (was ich im Moment nicht weiß) ist - auch für 1 Sekunde? Richtig, konstante Länge.
        Das reicht nach grober Abschätzung in jedem Fall für 138 Jahre.

        MfG
        Rouven

        --
        -------------------
        ie:| fl:| br:> va:| ls:& fo:) rl:( n4:{ ss:) de:] js:| ch:? mo:} zu:|
        1. Hi Rouven!

          Das reicht nach grober Abschätzung in jedem Fall für 138 Jahre.

          Fast! =)

          MfG H☼psel

          --
          "It's amazing I won. I was running against peace, prosperity, and incumbency."
          George W. Bush speaking to Swedish Prime Minister unaware a live television camera was still rolling, June 14, 2001
          Selfcode: ie:% fl:( br:> va:) ls:& fo:) rl:? n4:& ss:| de:] js:| ch:? sh:( mo:) zu:)
    2. Hallo Manuel,

      Wie denn das? Meine Timestamp sieht so aus: Do Jun 22 19:44:28 CEST 2006
      Möglich, das es bei PERL leicht abweicht, bei MySQL besteht sie auch Datum und Uhrzeit: 2006-06-04 17:55:13

      Also ich bin mir ziemlich sicher, das sich die Länge nie ändern wird, ausser unsere Zeit-/Datumsstruktur wird geändert.

      Du solltest Dir den entsprechenden Handbuchabschnitt durchlesen. Die Darstellung von Timestampwerten in MySQL hat _überhaupt nichts_ mit der internen Speicherung von Timestampwerten zu tun. Vergleichbares gilt für andere DBMS, vergleichbares gilt für die Speicherung von Datums- und Zeitangaben. Es ist ja einer der Vorteile eines DBMS, dass es die physische Speicherung eines Datentyps von seiner Repräsentation trennt.

      Ganz bestimmt wird innerhalb der nächsten 32 Jahre der Datentyp von Timestamp geändert werden, die 64-Bit-Variante sollte ausreichend dimensioniert sein, so dass wir uns keine Gedanken um eine weitere Änderung machen müssten, selbst wenn statt Sekunden Millisekunden oder sogar Mikrosekunden gezählt werden :-)

      Freundliche Grüße

      Vinzenz

      1. Zurück zur UUID ;)

        Bleibt das Format nun eigentlich immer gleich?

        1. Bleibt das Format nun eigentlich immer gleich?

          Das UUID-Format, das du verwendest bleibt immer gleich. Vielleicht wird das Format in Zukunft abgeschafft und durch ein anderes abgeköst, oder so, aber ich kann nicht hellsehen.

          Jonathan

      2. Hi Vinzenz,

        Die Darstellung von Timestampwerten in MySQL hat _überhaupt nichts_ mit der internen Speicherung von Timestampwerten zu tun.

        Das ist mir klar, ich wollte damit nur aussagen, das sich im Moment an der länge der Timestamp nix ändert. Und bitte jetzt keine Erbsenzählerei. ;)

  3. Hallo Christian,

    Zu meiner Frage: Bleibt das Format immer gleich?

    Ja, die Länge ist fest vorgeschrieben.
    Natürlich reicht der Zeitstempel nicht ewig, aber er sollte erst mal ausreichen.
    UUID verwendet 60 bit für Sekunden * 10^-4 seit dem 1.1.1 0:0 Uhr.
    2^60 / (10^4 * 60 * 60 * 24 * 365) = 3,7 * 10^6 Jahre
    Wenn ich mich nicht verrechnet habe, sollte das also vorläufig reichen.

    Wenn man nicht so genau weiß, was eine verwendete Kodierung genau tut, ist es übrigens auch eine gute Idee, dies nachzulesen: http://www.ietf.org/rfc/rfc4122.txt ;-)

    Grüße

    Daniel