Workaround Lock Tables In Trigger

Hallo

Ich weiß, dass Lock Tables in Triggern nicht zulässig ist, ich
benötige des wegen einen Workaround dafür: Hier mein Trigger

CREATE TRIGGER TRG_BI_T1 BEFORE INSERT ON T1
FOR EACH ROW BEGIN
SELECT EINENUMMER INTO @vENR FROM T2 WHERE ID=3DNEW.ID_T2 AND
TYPE=3DNEW.TYPE_T2;
SET @vBORDER =3D LENGTH(@vENR);
SET @vINITIAL =3D '0';
SET @vDEFAULT =3D '0';
SET @vLENGTH =3D 7;
SET @vSTEP =3D 1;
SELECT
LPAD(CAST(IFNULL(MAX(SUBSTRING(EINDEUTIGE_ID_NICHT_PK,@vBORD ER
+1)),@vINITIAL) AS SIGNED)+@vSTEP,@vLENGTH,@vDEFAULT) INTO @vEID FROM
T2 WHERE SUBSTRING(EINDEUTIGE_ID_NICHT_PK,1,@vBORDER)=3D@vENR;
SET NEW.EINDEUTIGE_ID_NICHT_PK =3D CONCAT(@vENR,@vEID);
END;

Vielleicht habt Ih 'ne Idee wie ich das sinnvoller gestalten kann

Die EINDEUTIGE_ID_NICHT_PK soll wie der Name schon sagt eindeutig
sein, deshalb wollte ich iinnerhalb des Triggeres ein Lock Table
setzen, was ja nicht zulässig ist. Im Übrigen gibt es Gründe dafür,
dass die ID nicht im Primärschlüssel ist und auch für den Aufbau
dieser.

Ist es eventuell möglich EINDEUTIGE_ID_NICHT_PK erst mal auf 0 zu
setzen undn danach in AFTER INSERT ein

UPDATE T2 SET EINDEUTIGE_ID_NICHT_PK=3DCONCAT(SELECT EINENUMMER INTO
@vENR FROM T2 WHERE ID=3DNEW.ID_T2 AND TYPE=3DNEW.TYPE_T2, .... ) Ist das
möglich?

Gruss Ren=E9

Re: Workaround Lock Tables In Trigger

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Workaround Lock Tables In Trigger

"rene.spengler@googlemail.com" wrote:



> Vielleicht habt Ih 'ne Idee wie ich das sinnvoller gestalten kann

Ja. Mach EINDEUTIGE_ID_NICHT_PK einfach INT UNSIGNED AUTO_INCREMENT
PRIMARY KEY und fertig.

> Die EINDEUTIGE_ID_NICHT_PK soll wie der Name schon sagt eindeutig
> sein, deshalb wollte ich iinnerhalb des Triggeres ein Lock Table
> setzen, was ja nicht zulässig ist. Im Übrigen gibt es Gründe dafür,
> dass die ID nicht im Primärschlüssel ist und auch für den Aufbau
> dieser.

Ich bin mir sicher, daß du glaubst Gründe zu haben. Ich bin mir fast
genauso sicher, daß diese Gründe nicht stichhaltig sind. Der PK ist
nix weiter als eine eindeutige Referenz auf einen Datensatz. Entweder
steht der PK schon beim Einfügen fest (und Eindeutigkeit wird von der
Datenquelle garantiert) oder du nimmst ein AUTO_INCREMENT. Fertig.

Wenn du eine UNIQUE Spalte im Format 'foo,bar' brauchst, dann mach die
halt separat.


XL

Re: Workaround Lock Tables In Trigger

On 15 Jun., 10:21, Axel Schwenke wrote:

...
> Ja. Mach EINDEUTIGE_ID_NICHT_PK einfach INT UNSIGNED AUTO_INCREMENT
> PRIMARY KEY und fertig.
>
> > Die EINDEUTIGE_ID_NICHT_PK soll wie der Name schon sagt eindeutig
> > sein, deshalb wollte ich iinnerhalb des Triggeres ein Lock Table
> > setzen, was ja nicht zulässig ist. Im Übrigen gibt es Gründe daf=
ür,
> > dass die ID nicht im Primärschlüssel ist und auch für den Aufbau
> > dieser.
>
> Ich bin mir sicher, daß du glaubst Gründe zu haben. Ich bin mir fast
> genauso sicher, daß diese Gründe nicht stichhaltig sind. Der PK ist
> nix weiter als eine eindeutige Referenz auf einen Datensatz. Entweder
> steht der PK schon beim Einfügen fest (und Eindeutigkeit wird von der
> Datenquelle garantiert) oder du nimmst ein AUTO_INCREMENT. Fertig.
>
> Wenn du eine UNIQUE Spalte im Format 'foo,bar' brauchst, dann mach die
> halt separat.

Der PK ist immer der gleiche Aufbau in der Anwendung (Type
VARCHAR(15), ID VARCHAR(35), Version int) so werden die Tabellen
generiert und die entsprechenden Java Klassen halt auch deswegen werde
ich nicht die Zugriffsklassen ändern, da dann die komplette Anwendung
nicht mehr wartbar wird. Die EINDEUTIGE_ID_NICHT_PK besteht aus zwei
Werten wobei der erste einen Bezug zu einer anderen Tabelle hat und
dadurch auswertbar ist. Der zweite ist eine laufende Nummer.

Das Thema Sequenzen scheint eher geeignet zu sein da etwas zu tun,
allerdings sieht es nach meinen Google Recherchen nicht so aus als
würden Sequenzen von MySql unterstützt werden

Gruss Ren=E9

Re: Workaround Lock Tables In Trigger

"rene.spengler@googlemail.com" wrote:
> On 15 Jun., 10:21, Axel Schwenke wrote:
>
>> Ich bin mir sicher, daß du glaubst Gründe zu haben. Ich bin mir fast
>> genauso sicher, daß diese Gründe nicht stichhaltig sind. Der PK ist
>> nix weiter als eine eindeutige Referenz auf einen Datensatz. Entweder
>> steht der PK schon beim Einfügen fest (und Eindeutigkeit wird von der
>> Datenquelle garantiert) oder du nimmst ein AUTO_INCREMENT. Fertig.
>>
>> Wenn du eine UNIQUE Spalte im Format 'foo,bar' brauchst, dann mach die
>> halt separat.
>
> Der PK ist immer der gleiche Aufbau in der Anwendung (Type
> VARCHAR(15), ID VARCHAR(35), Version int) so werden die Tabellen
> generiert und die entsprechenden Java Klassen halt auch deswegen werde
> ich nicht die Zugriffsklassen ändern, da dann die komplette Anwendung
> nicht mehr wartbar wird.

m.a.W. du hast eine datenbankgestützte Java-Applikation, die von
jemandem designt wurde, der keine Ahnung von Datenbanken hat.
Die Chancen stehen gut, daß du diese Applikation früher oder
später (etliche graue Haare später) in die Tonne trittst, weil
dir das laufend auf die Füße fällt. z.B. in Form quälend langsamer
Queries.

Ein PK (VARCHAR(15), VARCHAR(35), INT) ist dermaßen lächerlich,
da brauchen wir gar nicht weiter zu diskutieren.

> Die EINDEUTIGE_ID_NICHT_PK besteht aus zwei
> Werten wobei der erste einen Bezug zu einer anderen Tabelle hat und
> dadurch auswertbar ist.

Falls das eine SQL-Beziehung werden soll, gehört dieser Wert in eine
separate Spalte. Mit einem Index und einem FOREIGN KEY Constraint.

> Der zweite ist eine laufende Nummer.

Und dafür würde dann prima ein AUTO_INCREMENT passen.

> Das Thema Sequenzen scheint eher geeignet zu sein da etwas zu tun,
> allerdings sieht es nach meinen Google Recherchen nicht so aus als
> würden Sequenzen von MySql unterstützt werden

Kann man trivial selber bauen. Falls man mag, auch als stored
routine (Procedure oder Function). Habe ich mal auf MySQL-Forge
vorexerziert: http://forge.mysql.com/snippets/view.php?id=7


XL

Re: Workaround Lock Tables In Trigger

rene.spengler@googlemail.com meinte:

> Der PK ist immer der gleiche Aufbau in der Anwendung (Type
> VARCHAR(15), ID VARCHAR(35), Version int) so werden die Tabellen

Ächz!

> generiert und die entsprechenden Java Klassen halt auch deswegen werde
> ich nicht die Zugriffsklassen ändern, da dann die komplette Anwendung
> nicht mehr wartbar wird.

Das wird bei dieser DB (wenn schon die PKs so ausschauen) sowieso früher
oder später passieren.


Gruß, Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.image2d.com ::: Bildagentur für den alpinen Raum