MySQL5, Views und INSERT

MySQL5, Views und INSERT

am 13.03.2007 19:35:41 von Lars Uhlmann

Gegeben sind drei Tabellen (Struktur ist leider nicht änderbar, Tabelle
`a` hat real mehr als 50 Spalten)

mysql> explain a;
+----------+------------------+------+-----+---------+------ ----------+
| Field | Type | Null | Key | Default | Extra |
+----------+------------------+------+-----+---------+------ ----------+
| userid | int(10) unsigned | NO | PRI | NULL | auto_increment |
| username | varchar(100) | NO | | | |
| password | char(32) | NO | | | |
+----------+------------------+------+-----+---------+------ ----------+

mysql> explain a_ext1;
+--------+------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+------------------+------+-----+---------+-------+
| userid | int(10) unsigned | NO | PRI | 0 | |
| ext1 | varchar(128) | YES | | NULL | |
| ext2 | varchar(128) | YES | | NULL | |
| ext3 | varchar(128) | YES | | NULL | |
+--------+------------------+------+-----+---------+-------+

mysql> explain a_ext2;
+--------+------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+------------------+------+-----+---------+-------+
| userid | int(10) unsigned | NO | PRI | 0 | |
| stuff1 | varchar(128) | YES | | NULL | |
| stuff2 | varchar(128) | YES | | NULL | |
| stuff3 | varchar(128) | YES | | NULL | |
+--------+------------------+------+-----+---------+-------+

Um `a_ext1` und `a_ext2` befüllen zu können, muß erst ein Eintrag in `a`
erzeugt werden, um an die `userid` zu kommen. Ganz naiv hatte ich eine
View erzeugt:

CREATE VIEW v AS SELECT
a.userid,
a.username,
a.`password`,
a_ext.ef1,
a_ext.ef2,
a_ext.ef3,
a_ext_ext.stuff1,
a_ext_ext.stuff2,
a_ext_ext.stuff3
FROM
a, a_ext, a_ext_ext
WHERE
a.userid=a_ext.userid AND a.userid=a_ext_ext.userid;

und einen Datensatz eingefügt:

INSERT INTO v (username,`password`) VALUES ('user1','geheim');

Der funktionierte allerdings nur, weil er sich einzig auf Spalten von
`a` auswirkte (vgl. [0]). Die Tabellen `a_ext` und `a_ext_ext` blieben
leer. Views sind also für das Problem wohl (noch) nicht geeignet!?
Wie kann man so ein unsicheres Konstrukt wie

INSERT INTO a (username,`password`) VALUES ('user1','geheim');
INSERT INTO a_ext (userid) VALUES (LAST_INSERT_ID());
INSERT INTO a_ext_ext (userid) VALUES (LAST_INSERT_ID());

vermeiden und vllt. anders in einer einzigen query abarbeiten?
Transktionen gibt's leider nicht, die Tabellen sind vom Typ MyISAM.

Danke
Lars

[0]http://dev.mysql.com/doc/refman/5.0/en/faqs-views.html#qa ndaitem-26-7-6

Re: MySQL5, Views und INSERT

am 13.03.2007 19:41:39 von Lars Uhlmann

Sorry, das ist mir bei meinen Auführungen ein Schreibfehler unterlaufen:

`a_ext1` = `a_ext` und `a_ext2` = `a_ext_ext`

Lars

Re: MySQL5, Views und INSERT

am 13.03.2007 21:31:43 von Daniel Fischer

Lars Uhlmann!

> Views sind also für das Problem wohl (noch) nicht geeignet!?

Nein.

> Wie kann man so ein unsicheres Konstrukt wie [...]
> vermeiden und vllt. anders in einer einzigen query abarbeiten?

In einem einzigen Query ist eher nicht drin.

> Transktionen gibt's leider nicht, die Tabellen sind vom Typ MyISAM.

LOCK TABLES gibt es aber.

Ja, ich weiß, Transaktionen sind besser, aber sowas überlegt man sich
i.d.R. auch, *bevor* man seine Datenbank implementiert. Naja, es gibt ja
auch noch ALTER TABLE ENGINE=InnoDB. ;-)


Gruß
Daniel

Re: MySQL5, Views und INSERT

am 13.03.2007 22:38:43 von Lars Uhlmann

On Tue, 13 Mar 2007 21:31:43 +0100, Daniel Fischer wrote:

>> Views sind also für das Problem wohl (noch) nicht geeignet!?
>
> Nein.
>
>> Wie kann man so ein unsicheres Konstrukt wie [...]
>> vermeiden und vllt. anders in einer einzigen query abarbeiten?
>
> In einem einzigen Query ist eher nicht drin.

Ich hab's befürchtet.

>> Transktionen gibt's leider nicht, die Tabellen sind vom Typ MyISAM.
>
> LOCK TABLES gibt es aber.

Ja, löst aber auch nicht das Problem, das im ungünstigsten Fall der
DB-Server zwischen zwei INSERTs plötzlich den Dienst versagt.

> Ja, ich weiß, Transaktionen sind besser, aber sowas überlegt man sich
> i.d.R. auch, *bevor* man seine Datenbank implementiert. Naja, es gibt ja
> auch noch ALTER TABLE ENGINE=InnoDB. ;-)

FULL ACK.

Ändern daran ich kann nichts, benutzen und Daten einpflegen ich muß.
Das ganze ist ein Produkt in dessen Userverwaltung ich von extern Daten
einfügen will. Nun ja, bleibt also nur der Weg, wieder selbst eine Art
Journal zu bauen.

Danke
Lars

Re: MySQL5, Views und INSERT

am 13.03.2007 22:47:36 von Siegfried Schmidt

Hallo Lars,

> Ja, löst aber auch nicht das Problem, das im ungünstigsten Fall der
> DB-Server zwischen zwei INSERTs plötzlich den Dienst versagt.

Und warum ist das Fehlen von abhängigen Datensätzen ein Problem?

Ohne serverseitige Verriegelung ist die gleich Situation auch später
jederzeit durch Löschen provozierbar, d.h. ein Frontend darf sowieso nicht
einfach deren Extistenz voraussetzen.


Siegfried
--
http://www.schmidt.ath.cx

Re: MySQL5, Views und INSERT

am 14.03.2007 07:41:13 von Andreas Kretschmer

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: MySQL5, Views und INSERT

am 14.03.2007 15:59:31 von Lars Uhlmann

On Tue, 13 Mar 2007 22:47:36 +0100, Siegfried Schmidt wrote:

>> Ja, löst aber auch nicht das Problem, das im ungünstigsten Fall der
>> DB-Server zwischen zwei INSERTs plötzlich den Dienst versagt.
>
> Und warum ist das Fehlen von abhängigen Datensätzen ein Problem?
>
> Ohne serverseitige Verriegelung ist die gleich Situation auch später
> jederzeit durch Löschen provozierbar, d.h. ein Frontend darf sowieso nicht
> einfach deren Extistenz voraussetzen.

Du hast völlig Recht. Da ich aber die Applikation nicht kenne und daher
nicht voraussetzen kann, daß ein abhängiger Datensatz kein Problem
verursacht, muß bzw. will ich von meiner Seite aus sicherstellen, daß
ich kein unvorhersehbares Verhalten herbeiführe.

Lars

Re: MySQL5, Views und INSERT

am 14.03.2007 16:20:38 von Andreas Kretschmer

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: MySQL5, Views und INSERT

am 14.03.2007 20:08:05 von Lars Uhlmann

On Wed, 14 Mar 2007 16:20:38 +0100, Andreas Kretschmer wrote:

>> Du hast völlig Recht. Da ich aber die Applikation nicht kenne und daher
>> nicht voraussetzen kann, daß ein abhängiger Datensatz kein Problem
>> verursacht, muß bzw. will ich von meiner Seite aus sicherstellen, daß
>> ich kein unvorhersehbares Verhalten herbeiführe.
>
> Löblich, aber für sowas wurden Transaktionen und ref. Integrität
> erfunden...

Da drehen wir uns im Kreis, denn wie bereits geschrieben kann und will
ich an der Datenbank, die zur Applikation gehört, nichts ändern.

Danke für die Antworten (auch an die anderen)
Lars

Re: MySQL5, Views und INSERT

am 15.03.2007 12:45:48 von Johannes Vogel

Hallo Lars

Lars Uhlmann wrote:
> On Wed, 14 Mar 2007 16:20:38 +0100, Andreas Kretschmer wrote:
>>> Du hast völlig Recht. Da ich aber die Applikation nicht kenne und daher
>>> nicht voraussetzen kann, daß ein abhängiger Datensatz kein Problem
>>> verursacht, muß bzw. will ich von meiner Seite aus sicherstellen, daß
>>> ich kein unvorhersehbares Verhalten herbeiführe.
>> Löblich, aber für sowas wurden Transaktionen und ref. Integrität
>> erfunden...
> Da drehen wir uns im Kreis, denn wie bereits geschrieben kann und will
> ich an der Datenbank, die zur Applikation gehört, nichts ändern.

Fassen wir also nochmals zusammen: Du kennst die Anwendung nicht, willst
aber auch an der DB nichts ändern. Na, dann ist der Fall doch klar: Lass
es bleiben.

Johannes

Re: MySQL5, Views und INSERT

am 15.03.2007 14:40:30 von Lars Uhlmann

Johannes Vogel schrieb:

>>> Löblich, aber für sowas wurden Transaktionen und ref. Integrität
>>> erfunden...
>>
>> Da drehen wir uns im Kreis, denn wie bereits geschrieben kann und will
>> ich an der Datenbank, die zur Applikation gehört, nichts ändern.
>
>
> Fassen wir also nochmals zusammen: Du kennst die Anwendung nicht, willst
> aber auch an der DB nichts ändern. Na, dann ist der Fall doch klar: Lass
> es bleiben.

Auf die Idee bin ich noch garnicht gekommen! Danke.

Lars