InnoDB Referenzielle Integrität (MySQL 5.0)

Hallo Zusammen,

Ich versuche gerade in meine MySQL Datenbank etwas Referenzielle Integrität
einzubauen. So kann ich mir Programmieraufwand spaaren.

Nun habe ich mittels phpMyAdmin da ein paar Beziehungen zwischen den
Tabellen festgelegt. Nur klapt dies leider nicht für Alle Indizes :(

Ein Beispiel:

artikel
=========
PK id
beschreibung
preis

artikel_hauptgruppen
==============
PK id
name

artikel_untergruppen
==============
PK id
INDEX id_artikel_hauptgruppen
name

artikel_gruppen_positionen
===========
PK id_artikel
PK id_artikel_untergruppen
name
default_anzahl

Funktionierende Aktuallisierungs Beziehungen:
artikel.id -> artikel_gruppen_positionen.id_artikel
aktikel_hauptgruppen.id -> artikel_untergruppen.id_artikel_hauptgruppen

NICHT FUNKTIONIERENDE UPDATE-BEZIEHUNG:
artikel_untergruppen.id ->
artikel_gruppen_positionen.id_artikel_untergruppen

Woran kann das liegen? Kann eine Aktuallisierungsweitergabe nicht an einen
2. PK weitergegeben werden?

Danke für eure Antworten.

Re: InnoDB Referenzielle Integrität(MySQL 5.0)

Andreas
--
Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau-
fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert frei
von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584DA
Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-)

Re: InnoDB Referenzielle Integrität (MySQL 5.0)

>artikel
>=========
>PK id
>beschreibung
>preis
>
>artikel_hauptgruppen
>==============
>PK id
>name
>
>artikel_untergruppen
>==============
>PK id
>INDEX id_artikel_hauptgruppen
>name
>
>artikel_gruppen_positionen
>===========
>PK id_artikel
>PK id_artikel_untergruppen
>name
>default_anzahl
>
>Funktionierende Aktuallisierungs Beziehungen:
>artikel.id -> artikel_gruppen_positionen.id_artikel
>aktikel_hauptgruppen.id -> artikel_untergruppen.id_artikel_hauptgruppen
>
>NICHT FUNKTIONIERENDE UPDATE-BEZIEHUNG:
>artikel_untergruppen.id ->
>artikel_gruppen_positionen.id_artikel_untergruppen
kann nicht gehen da du dies nicht in "artikel_untergruppe" sondern in
"artikel_gruppen_positionen" definieren musst, da mehrere Artikel in ein
und derselben Untergruppe stehen können!
id_artikel_untergruppen -> artikel_untergruppen.id
>
>Woran kann das liegen? Kann eine Aktuallisierungsweitergabe nicht an einen
>2. PK weitergegeben werden?
weil dieser nicht Eindeutig ist, in deinem Fall!
Meines wissens gibt es keinen 2. PK das müsste dann ein UNIQUE INDEX sein ist es
aber bei dieser Tabelle nicht, s.o.!
>

Ich denke mal in artikel_gruppen_positon assoziierst du den Artikel mit einer Gruppe!?
Der split ist eigentlich auch nicht nötig
>artikel
>=========
>PK id
>beschreibung
>preis
>id_artikel_untergruppen
>name
>default_anzahl
id_artikel_untergruppen -> artikel_untergruppen.id


ich hoffe ich hab dein Bau richtig verstanden!

cu Stephan

Re: InnoDB Referenzielle Integrität (MySQL 5.0)

"Andreas Kretschmer" schrieb im Newsbeitrag
news:clmb73-3e4.ln1@news.a-kretschmer.de...
> Explaining the concept of referential integrity to a mysql user is
>like explaining condoms to a catholic
>
>Lief gestern oder vorgestern so in #postgresql ;-)

Tja so geht ist das halt, wenn man Jahrelang ohne dieses referenzielle dings
bumms ausgekommen ist! ;)

Wie sieht es mit meinem Problem aus? Hast du da eine Lösung parat, oder habe
ich da ein grundsätzliches Verständnisproblem was Referenzielle Integrität
anbelangt?

PS: Kannst du mir noch die Geschichte mit den Condomen erläutern? Habe ich
bis jetzt auch noch nicht begriffen *lol

Grüsse
Martin

Re: InnoDB Referenzielle Integrität (MySQL 5.0)

"Stephan Menzel" schrieb im Newsbeitrag
news:u4a6q1tmbujptum5onkp2qnmn1lvemdvap@4ax.com...
NDE UPDATE-BEZIEHUNG:
>>artikel_untergruppen.id ->
>>artikel_gruppen_positionen.id_artikel_untergruppen
> kann nicht gehen da du dies nicht in "artikel_untergruppe" sondern in
> "artikel_gruppen_positionen" definieren musst, da mehrere Artikel in ein
> und derselben Untergruppe stehen können!
> id_artikel_untergruppen -> artikel_untergruppen.id

Habe ich auch so gemacht (oder Versucht)... Wie bei den anderen Beziehungen
auch. Die Pfeile entsprechen dem "Aktuallisierungsweg".
dieses_feld_wird_geändert -> dieses_feld_wird_aktuallisiert

>>Woran kann das liegen? Kann eine Aktuallisierungsweitergabe nicht an einen
>>2. PK weitergegeben werden?
> weil dieser nicht Eindeutig ist, in deinem Fall!
> Meines wissens gibt es keinen 2. PK das müsste dann ein UNIQUE INDEX sein
> ist es
> aber bei dieser Tabelle nicht, s.o.!

Das Feld id_artikel und id_artikel_untergruppen der Tabelle
artikel_gruppen_positionen ergeben zusammen einen PK. Pro Gruppe kann ein
bestimmter Artikel nur einmal aufgeführt werden. Den "2. PK" habe ich also
falsch beschrieben. Ist nur ein "Hilfs PK" weiss auch nicht wie man den
nennt... ;)

> Ich denke mal in artikel_gruppen_positon assoziierst du den Artikel mit
> einer Gruppe!?
> Der split ist eigentlich auch nicht nötig
>>artikel
>>=========
>>PK id
>>beschreibung
>>preis
>>id_artikel_untergruppen
>>name
>>default_anzahl
> id_artikel_untergruppen -> artikel_untergruppen.id

Habe den Split gemacht, da ein Artikel in mehreren Gruppen vorkommen kann.

Re: InnoDB Referenzielle Integrität (MySQL 5.0)

>>artikel_untergruppen.id ->
>>>artikel_gruppen_positionen.id_artikel_untergruppen
>> kann nicht gehen da du dies nicht in "artikel_untergruppe" sondern in
>> "artikel_gruppen_positionen" definieren musst, da mehrere Artikel in ein
>> und derselben Untergruppe stehen können!
>> id_artikel_untergruppen -> artikel_untergruppen.id
>
>Habe ich auch so gemacht (oder Versucht)... Wie bei den anderen Beziehungen
>auch. Die Pfeile entsprechen dem "Aktuallisierungsweg".
>dieses_feld_wird_geändert -> dieses_feld_wird_aktuallisiert
>
>>>Woran kann das liegen? Kann eine Aktuallisierungsweitergabe nicht an einen
>>>2. PK weitergegeben werden?
>> weil dieser nicht Eindeutig ist, in deinem Fall!
>> Meines wissens gibt es keinen 2. PK das müsste dann ein UNIQUE INDEX sein
>> ist es
>> aber bei dieser Tabelle nicht, s.o.!
>
>Das Feld id_artikel und id_artikel_untergruppen der Tabelle
>artikel_gruppen_positionen ergeben zusammen einen PK. Pro Gruppe kann ein
>bestimmter Artikel nur einmal aufgeführt werden. Den "2. PK" habe ich also
>falsch beschrieben. Ist nur ein "Hilfs PK" weiss auch nicht wie man den
>nennt... ;)
Ja ok zusammen shon aber hier geht es um den Bezug auf das Feld "id_artikel_untergruppen"
und da ist es nicht Eindeutig deshalb muss du den bezug in "artikel_gruppen_positionen" auf das
Feld in "artikel_untergruppen.id" definieren.
Da "artikel_untergruppen" die Parenttable ist! und der Bezug vom Child aus zu setzen ist!

>
>> Ich denke mal in artikel_gruppen_positon assoziierst du den Artikel mit
>> einer Gruppe!?
>> Der split ist eigentlich auch nicht nötig
>>>artikel
>>>=========
>>>PK id
>>>beschreibung
>>>preis
>>>id_artikel_untergruppen
>>>name
>>>default_anzahl
>> id_artikel_untergruppen -> artikel_untergruppen.id
>
>Habe den Split gemacht, da ein Artikel in mehreren Gruppen vorkommen kann.
Ah verstehe!
aber was hat dann der name und default_anzahl hier zu Suchen, haben die Artikel
verschiedene Namen und Mengen in unterschiedlichen Gruppen?

cu Stephan

Re: InnoDB Referenzielle Integrität (MySQL 5.0)

Martin Borer wrote:
> Hallo Zusammen,
>=20
> Ich versuche gerade in meine MySQL Datenbank etwas Referenzielle Integr=
ität=20
> einzubauen. So kann ich mir Programmieraufwand spaaren.
>=20
> Nun habe ich mittels phpMyAdmin da ein paar Beziehungen zwischen den=20
> Tabellen festgelegt. Nur klapt dies leider nicht für Alle Indizes :(

kannst du das ganze noch einmal als SQL Statements posten
(CREATE TABLE ..., UPDATE ...)?

Aus deiner Freitext-Beschreibung wird meine Kristallkugel nicht
wirklich schlau, zu viele Freiheitsgrade ...

--=20
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com

http://www.mysql.com/support/

Re: InnoDB Referenzielle Integrit?t (MySQL 5.0)

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

Re: InnoDB Referenzielle Integrität (MySQL 5.0)

Hartmut Holzgraefe wrote:
> kannst du das ganze noch einmal als SQL Statements posten
> (CREATE TABLE ..., UPDATE ...)?

Das mach ich doch glatt:

-- Artikelstamm
CREATE TABLE `artikel` (
`viele_andere_spalten` decimal(15,10) default NULL,
`ClientHdl` varchar(20) collate latin1_general_ci default NULL,
`ARTIKEL-NR` varchar(20) collate latin1_general_ci NOT NULL default
'',
`MANDANT` int(11) NOT NULL default '0',
PRIMARY KEY (`ARTIKEL-NR`,`MANDANT`)
) ENGINE=3DInnoDB DEFAULT CHARSET=3Dlatin1 COLLATE=3Dlatin1_general_ci;

-- --------------------------------------------------------


-- Artikel Hauptgruppe
CREATE TABLE `artikel_gruppen_bez_1` (
`id` varchar(20) collate latin1_general_ci NOT NULL,
`Name` text collate latin1_general_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=3DInnoDB DEFAULT CHARSET=3Dlatin1 COLLATE=3Dlatin1_general_ci;


-- Artikel Untergruppe
CREATE TABLE `artikel_gruppen_bez` (
`id` varchar(20) collate latin1_general_ci NOT NULL,
`name` text collate latin1_general_ci NOT NULL,
`id_gruppen_bez_1` varchar(20) collate latin1_general_ci NOT NULL,
PRIMARY KEY (`id`),
KEY `id_gruppen_bez_1` (`id_gruppen_bez_1`)
) ENGINE=3DInnoDB DEFAULT CHARSET=3Dlatin1 COLLATE=3Dlatin1_general_ci;

-- Artikel Gruppen Positionen
CREATE TABLE `artikel_gruppen` (
`artikelnr` varchar(20) collate latin1_general_ci NOT NULL,
`id_gruppen_bez` varchar(20) collate latin1_general_ci NOT NULL,
`anzahl` double NOT NULL,
`option` int(1) NOT NULL default '0',
PRIMARY KEY (`artikelnr`,`id_gruppen_bez`)
) ENGINE=3DInnoDB DEFAULT CHARSET=3Dlatin1 COLLATE=3Dlatin1_general_ci;

--
-- Constraints der Tabelle `artikel_gruppen`
--
ALTER TABLE `artikel_gruppen`
ADD CONSTRAINT `artikel_gruppen_ibfk_1` FOREIGN KEY (`artikelnr`)
REFERENCES `artikel` (`ARTIKEL-NR`) ON UPDATE CASCADE;
-- Die 2. Beziehung artikel_gruppen.id_gruppen_bez ->
artikel_gruppen_bez.id konnte nicht hinzugefügt werden!

--
-- Constraints der Tabelle `artikel_gruppen_bez`
--
ALTER TABLE `artikel_gruppen_bez`
ADD CONSTRAINT `artikel_gruppen_bez_ibfk_1` FOREIGN KEY
(`id_gruppen_bez_1`) REFERENCES `artikel_gruppen_bez_1` (`id`) ON
UPDATE CASCADE;

Re: InnoDB Referenzielle Integrität (MySQL 5.0)

UPS!!!

Es funktioniert nun alles! Ich hatte "dreckige" Daten in einer Tabelle.
Nach bereinigen konnte ich den Key Setzen!

Sorry mein Fehler!!

Re: InnoDB Referenzielle Integrit?t (MySQL 5.0)

Andreas Kretschmer wrote:
>> Tja so geht ist das halt, wenn man Jahrelang ohne dieses referenzielle=
dings=20
>> bumms ausgekommen ist! ;)
>=20
> http://software.newsforge.com/software/05/12/15/1611251.shtm l?tid=3D72

was jetzt die Re-Implementation von MySQL-sepzifischen Funktionen
als PgSQL Stored Procedures mit referenzieller Integrität zu tun
hat erschließt sich mir irgendwie grad so überhaupt nicht :/


--=20
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com

http://www.mysql.com/support/

Re: InnoDB Referenzielle Integrit?t (MySQL 5.0)

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

Re: InnoDB Referenzielle Integrit?t (MySQL 5.0)

Hartmut Holzgraefe wrote:

>
> was jetzt die Re-Implementation von MySQL-sepzifischen Funktionen
> als PgSQL Stored Procedures mit referenzieller Integrität zu tun
> hat erschließt sich mir irgendwie grad so überhaupt nicht :/
>
>

Nichts - Hauptsache rumgetrollt.

Wie meinte Josh Berkus (PostgreSQL) neulich beim OSDB Consortium meeting
zu den unverbesserlichen "meine DB ist besser als Deine Trolls": Keine
Ahnung von Datenbanken im Allgemeinen, und von Open Source im Speziellen.

/Georg

Re: InnoDB Referenzielle Integrit?t (MySQL 5.0)

Andreas Kretschmer wrote:
> Nichts, das stimmt. Aber es ist ja vielleicht eine ganz nette Idee, die=

> allgemein hinter dem Projekt steht, auch wenn Du als MySQL-Angestellter=

> das aus begreiflichen Gründen wohl anders siehst...

Portabilität ist immer eine gute Idee (wenn auch für keinen der
Datenbankserver wirklich ein Primärziel), aber dieses Projekt als
allumfassende MySQL->PostgreSQL Portierungslösung anzupreisen ist
doch wohl ein schlechter Scherz.

Meine Wunschliste an solch ein Tool wäre:

- Abbildung des MySQL C API auf das entsprechende PG API
- weitgehende SQL-Syntax-Kompatibilität
- performante Implementation der MySQL-spezifischen SQL-Funktionen
- Abbildung der MySQL-spezifischen Features wie Fulltext-Indices,
Autoincrement, TIMESTAMP-Typen ... auf entsprechende PG-Features
(falls vorhanden)

Wenn man sich das Packet dann aber anschaut findet man 'nur'
Dateien mit der Endung .sql, bei näherer Betrachtung findet man
darin eine Menge PostgreSQL-Funktionen die die entsprechenden
nativen MySQL-Funktionen nachbilden.

Aus meiner Wunschliste an ein "Migrationstool" erfüllt dies nur
den dritten Punkt, und auch den nur zum Teil da zumindest für
einige Funktionen ( CRC32() fällt dort ganz besinders ins Auge)
mit deutlichen Performanceeinbußen verbunden sein wird.

Bevor mich jetzt jemand völlig falsch versteht: das Projekt ist
durchaus interessant und hat seine Existenzberechtigung. Es
erleichtert Portierungen von MySQL nach PostgreSQL mit Sicherheit,
aber die Art und Weise wie es in dem Artikel als eierlegende
Wollmilchsau dargestellt wird weckt vollkommen falsche Erwartungen.

Zusammenfassung: das Tool erleichtert Portierungen in einem
bestimmten Teilbereich, aber es ist *nicht* die Rundumlösung als
die es dargestellt wird.

PS: der Ansatz ist in keiner Weise PostgreSQL spezifisch, genausogut
könnte jemand daherkommen und in MySQL fehlende PostgreSQL Funktionen
als Stored Procedures oder (besser) nativ als User Defined Functions
implementieren. Aber so ein Tool würde genausowenig Hype verdienen ...

--=20
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com

http://www.mysql.com/support/