Eindeutiger Code erzeugen und speichern

[truemaster]

Guten Tag zusammen,

ich muss pro Datensatz bei INSERT eine eindeutige Zahl in ein Feld speichern. Spalte setze ich auf Unique. Macht es Sinn vielleicht einfach die Spalte wegzulassen und dafür Spalte ID zunehmen, die sich sowierso hochzählt oder ist das nicht ratsam? Ich muss damit RFID-Chips eindeutig indentifizieren.

Am liebsten wäre mir, wenn ich mit MYSQL automatisch eine eindeutige ID erzeuge lasse und ins Feld rfid speichern lasse.

[akretschmer]

In PG würde ich SERIAL oder BIGSERIAL nehmen, MySQL hat was vergleichbares (nun ja, nicht ganz, aber egal), nutze es.

[protestix]

Das sollte mit dem PK gehen oder wenn du die Spalte auf auto increment setzt.

[truemaster]

Leider kann ich nur ein Feld auf auto_increment setzen. Und das ist das Feld ID bei mir. Sowohl bei Serial als auch auch nur bei auto increment setzen kommt folgender Fehler:

Fehler:
#1075 - Falsche Tabellendefinition. Es darf nur eine AUTO_INCREMENT-Spalte geben, und diese muss als Schlüssel definiert werden

[akretschmer]

Tja, die Limitierungen von MySQL:

test=*# create table truemaster(a serial, b bigserial, c serial, d bigserial);
CREATE TABLE
test=*# \d truemaster
                            Table "public.truemaster"
 Column |  Type   | Collation | Nullable |                Default                
--------+---------+-----------+----------+---------------------------------------
 a      | integer |           | not null | nextval('truemaster_a_seq'::regclass)
 b      | bigint  |           | not null | nextval('truemaster_b_seq'::regclass)
 c      | integer |           | not null | nextval('truemaster_c_seq'::regclass)
 d      | bigint  |           | not null | nextval('truemaster_d_seq'::regclass)

test=*#

reine Faulheit, daß ich nur 4 solcher Spalten habe. Aber: was spricht gegen die Verwendung der id-Spalte?

[protestix]

Du hast es dir ja auch schon selbst beantwortet.

Macht es Sinn vielleicht einfach die Spalte wegzulassen und dafür Spalte ID zunehmen, die sich sowierso hochzählt oder ist das nicht ratsam?

Warum es nicht ratsam sein sollte, fällt mir jetzt nicht ein, ich kenne aber deine Daten und dein Hintergrund zu der Frage auch nicht..

[truemaster]

Ich lese einen RFID-Chip aus. Dann öffnet sich direkt die Seite mit der ID. Und dann kann man einen Button klicken der den Status ändert

[protestix]

Ändern -> UPDATE
ist aber nicht das selbe wie
Neu anlegen -> INSERT (Spalte X automaitsch um 1 erhöhen)

[truemaster]

Das ist mir klar. Mir geht es hier aber um die Stammdatenanlage.

Ich lege ein Objekt an. Dann brauche ich eine eindeutige ID. Diese ID bzw. der gesamte Link wird dann auf den RFID Chip gespeichert.

[tk1234]

ich muss pro Datensatz bei INSERT eine eindeutige Zahl in ein Feld speichern. Spalte setze ich auf Unique. Macht es Sinn vielleicht einfach die Spalte wegzulassen und dafür Spalte ID zunehmen, die sich sowierso hochzählt oder ist das nicht ratsam? Ich muss damit RFID-Chips eindeutig indentifizieren.

Wie schon geschrieben wurde: zum reinen identifizieren reicht die ID (dafür ist die ja da). Wenn die Zahl (o.ä.) zum identifizieren des Chips aber nicht einfach durch erraten herauszubekommen sein soll - und das wäre sie wenn man die auto-increment-Spalte verwendet - dann brauchst du eine eigen Spalte mit einer zufällig erzeugen Zahl bzw. einem String.
Eine vierstellige Zahl könntest du z.B. mit RIGHT(CONCAT('00',ROUND(RAND()*10000)),4) erzeugen - ich würde aber was längeres nehmen und ggf. auch noch Buchstaben mit verwenden.

[Perry Staltic]

Ein Primary (oder auch Foreign Key) sollte keine andere fachliche Funktion haben, als den Datensatz zu identifizieren. Solche Sachen werden z.B. kritisch, wenn migriert, exportiert, importiert wird.
Man kann sich natürlich um solche Regeln drumrum arangieren. Vielleicht ist ja auch Dein Objekt Haar genau identisch mit den Daten in der Tabelle.

Ansonsten gibt es andere Vehikel, UUID() o.ä., es gibt vielleicht auch andere Argumente, die gegen die "schnöde" Verwendung einer aufsteigenden Zahlenfolge sprechen, Verwechselungsgefahr - ist bei einer rein automatisierten Verwendung natürlich nicht so naheliegend.

[akretschmer]

und wo exakt ist das Problem? Falls das Problem ist, daß die so erzeugten Nummern bekannt sind, dann verwende halt UUID:

test=*# create extension "uuid-ossp";
CREATE EXTENSION
test=*# create table rfid(ig uuid default uuid_generate_v1mc() primary key, data text);
CREATE TABLE
test=*# insert into rfid (data) values ('bla');
INSERT 0 1
test=*# insert into rfid (data) values ('blub');
INSERT 0 1
test=*# insert into rfid (data) values ('foo');
INSERT 0 1
test=*# select * from rfid ;
                  ig                  | data
--------------------------------------+------
 721267fa-0857-11ea-850a-4b295b15202f | bla
 7462ef5c-0857-11ea-850a-a711e14dde3c | blub
 76c9045c-0857-11ea-850a-8f0aff8ad0db | foo
(3 rows)

test=*#

[Perry Staltic]

Kein Problem, ich habe einfach eine praktikable Akternative zum Autoincrement vorgeschlagen.

[protestix]

Wenn nur eine Zahl gefordert ist hat Mysql noch uuid_short anzubieten.

CREATE TABLE IF NOT EXISTS `uuid` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `uuid` char(36) NOT NULL,
  `uuid_short` varchar(20) NOT NULL,
  `comment` text NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uuid` (`uuid`),
  UNIQUE KEY `uuid_short` (`uuid_short`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

Inserts

INSERT INTO `uuid` (`uuid`, `uuid_short`, `comment`) VALUES
(UUID(), UUID_SHORT(), 'bla'),

Fiddle dazu.

[tomBuilder]

Besitzt ein RFID chip nicht eine eindeutige identifikation ?
ist dies nicht für die kommunikation eines rfid chips notwendig ?