bład errno: 150, tworzenie obcych kluczy Opcje

[squid]

majac takie tabele :

[SQL] pobierz, plaintext 
CREATE TABLE `nodes` (
  `nodeID` int(10) UNSIGNED NOT NULL,
  `nodeName` varchar(64) DEFAULT NULL,
  PRIMARY KEY  (`nodeID`)
) TYPE=InnoDB;
 
# --------------------------------------------------------
 
#
# Struktura tabeli dla  `blood`
#
 
CREATE TABLE `blood` (
  `parentID` int(10) UNSIGNED NOT NULL,
  `childID` int(10) UNSIGNED NOT NULL,
  INDEX (`parentID`,`childID`),
  FOREIGN KEY(`parentID`) REFERENCES nodes(`nodeID`),
  FOREIGN KEY(`childID`) REFERENCES nodes(`nodeID`)
) TYPE=InnoDB;
[SQL] pobierz, plaintext 

otrzymuje taki komunikat:

Błąd


zapytanie SQL : 


CREATE TABLE `blood` (
`parentID` int( 10 ) unsigned NOT NULL ,
`childID` int( 10 ) unsigned NOT NULL ,
INDEX ( `parentID` , `childID` ) ,
FOREIGN KEY ( `parentID` ) REFERENCES nodes( `nodeID` ) ,
FOREIGN KEY ( `childID` ) REFERENCES nodes( `nodeID` )
) TYPE = InnoDB


MySQL zwrócił komunikat:


#1005 - Can't create table './test2/blood.frm' (errno: 150)

nie wiem co tam poprawic, ktos ma jakis pomysl?

[spenalzo]

W mysql chyba nie ma obcych kluczy.
A co do bledu sprawdz uprawnienia mysqla do katalogu data.

[popbart]

spenalzo -> mylisz sie

squid ->dodaj index do nodes.nodeID
aaa... i pole childID nie powinno byc chyba kluczem obcym

[spenalzo]

Ano faktycznie, przyznaje sie do błedu, nie zauważyłęm że jest tam typ InnoDB

[squid]

Ano faktycznie, przyznaje sie do błedu, nie zauważyłęm że jest tam typ InnoDB

i to od bardzo dawna

co do childID to musi byc kluczem obcym tak samo jak parentID

jesli chodzi o indeks dla nodes.nodeID to wiem iz musi byc zalozny kiedy uzywam kluczy obcych ale zauwazcie ze ustawieml

[SQL] pobierz, plaintext 
PRIMARY KEY (`nodeID`)
[SQL] pobierz, plaintext 

a to automatycznie powoduje powstanie indeksu dla atrybutu/kolumny nodeID tak samo jak aotomatycznie przypisywany jest NOT NULL

spradze jeszcze te prawa do katalogu ale nie wietrze powodzenia (inne tabele dodaje ok)

Ten post edytował squid 23.10.2004, 22:38:13

[anas]

Hej.

Jaka masz wersje MySQL-a, bo w starszych wersjach tworzac tabele typu InnoDB i uzywajac kluczy obcych byly problemy ze skladnia wlasnie przy definiowaniu stuktury tabeli(chyba brak spacji przed FOREIGN. Ale zastanawia mnie fakt ze tworzysz w drugiej tabeli dwa klucze ktore sa referncja do jednego klucza z pierwszej tabeli - nie wiem czy taki zapis jest wogole dopuszczalny - ale wydaje mi sie ze to on powoduje problem.

pozdrawiam

anas

[squid]

Hej.

Jaka masz wersje MySQL-a, bo w starszych wersjach tworzac tabele typu InnoDB i uzywajac kluczy obcych byly problemy ze skladnia wlasnie przy definiowaniu stuktury tabeli(chyba brak spacji przed FOREIGN. Ale zastanawia mnie fakt ze tworzysz w drugiej tabeli dwa klucze ktore sa referncja do jednego klucza z pierwszej tabeli - nie wiem czy taki zapis jest wogole dopuszczalny - ale wydaje mi sie ze to on powoduje problem.

pozdrawiam

anas

wersja 4.0.2 chyba w wersjach 3 trzeba bylo zaminic plik serwera i mozna bylo sie bawic w InnoDB.

Czy bledem mzoe byc to ze dwa klucze obce odwoluja sie do tej samej kolumny w innej dameli? mozliwe aczkolwiek nie wiem jak inaczej powiazac ze soba dwa obiekty tego samego typu, w kazdym razie jak jeden z kluczy obcych usuwam to mam ten sam blad

[anas]

Hej.

U mnie po usunieciu jednego z kluczy obcych tabela zalozyla sie poprawnie, tez robilem ostatnio cos takiego, ale poprostu zalozylem tabele ktora przechowywala dwa klucze nie powiazane jawna relacja. Musi to byc w taki sposob zrobione - bedziesz uzywal transakcji badz polecen ON DELETE lub ON UPDATE - bo jesli nie - to mozesz zrobic jak zaproponowalem.

pozdrawiam

anas

// EDIT

Hej ponownie... walczac z wlasnymi problemami przypadkowo trafilem na takie cos na stronach domowych DBDesigner-a:

BUG ktory powodowal blad o numerze 150

Ten post edytował anas 25.10.2004, 11:36:06

[squid]

sek w tym ze wolabym to tak zrobic bo transakcje raczej beda ale moglbys mi kode przyblizyc swoje rozwiazanie

[anas]

Hej.

Ostatnio musialem sprostac podobnemu wyzwaniu jak Ty - wiec podziele sie w jaki sposob udalo mi sie to zrobic:

Tabela Produkty:

[SQL] pobierz, plaintext 
CREATE TABLE Produkty (
	ProduktID Bigint NOT NULL AUTO_INCREMENT,
	StawkaID Int NOT NULL,
	GrupaID Bigint NOT NULL,
	Nazwa Varchar(255) NOT NULL,
	CenaNetto Double(9,2) NOT NULL,
	Opis Longtext,
	UNIQUE (ProduktID),
	INDEX AI_ProduktID (ProduktID),
 PRIMARY KEY (ProduktID,StawkaID,GrupaID),
 INDEX IX_GrupyTowarowe_Produkty (GrupaID),
 FOREIGN KEY (GrupaID) REFERENCES GrupyTowarowe (GrupaID) ON DELETE cascade ON UPDATE cascade,
 INDEX IX_Relationship9 (StawkaID),
 FOREIGN KEY (StawkaID) REFERENCES StawkiVat (StawkaID) ON DELETE cascade ON UPDATE cascade
) TYPE = InnoDB
ROW_FORMAT = DEFAULT;
[SQL] pobierz, plaintext 

Teraz tak - aby bylo prosciej nie patrz na nic w tej tabeli, oprocz klucza ProduktID - jak widzisz jest zdefiniowany jako Primary Key, ale nie jako jedyny - rowniez jako Primary Key zdefiniowane sa klucze obce StawkaID oraz GrupaID - wiec aby mogl zrobic relacje ktora dziedziczy mi tylko jeden klucz i identyfikuje po nim ustawiam to pole jako UNIQUE - pod polem opis znajduje sie to ustawienie. Ustawiam indexy itd...

i teraz druga tabela w ktorej bede trzymal powiazania:

[SQL] pobierz, plaintext 
CREATE TABLE ProduktyPowiazania (
	ProduktID Bigint NOT NULL,
	PowiazanyZ Bigint NOT NULL,	
 PRIMARY KEY (ProduktID,PowiazanyZ),
 INDEX IX_Relationship11 (ProduktID),
 FOREIGN KEY (ProduktID) REFERENCES Produkty (ProduktID) ON DELETE cascade ON UPDATE cascade,
 INDEX IX_Relationship12 (PowiazanyZ),
 FOREIGN KEY (PowiazanyZ) REFERENCES Produkty (ProduktID) ON DELETE cascade ON UPDATE cascade
) TYPE = InnoDB
ROW_FORMAT = DEFAULT;
[SQL] pobierz, plaintext 

Jak widzisz sa zrobione dwie relacje - i dwa rozne indexy zalozone na klucze obce - nastepnie definicje tych relacji i co w przypadku kiedy zostanie skasowany rodzic - akurat CASCADE oznacza ze zostana rowniez skasowane wszystkie wiersze posiadajace klucz rodzica.

Nazewnistwo index'ow i niektorych pol moze wydawac sie dziwne - ale to jest wygenerowane prosto z narzedzia do projektowania baz i nie zdazylem jeszcze poprawic, bo projekt nadal jest na tapecie ... jesli masz jakies pytania jeszcze to wal... postaram sie pomoc na tyle na ile potrafie, ale u mnie cos takiego dziala - a Twoj problem pokrywa sie z tym przykladem w 100%-tach .

pozdrowka

anas

[squid]

No dzieki wielkie!!

zrobilem na podstwaie tego co mi dales tak :

[SQL] pobierz, plaintext 
#
# Struktura tabeli dla  `nodes`
#
 
CREATE TABLE `nodes` (
  `nodeID` int(10) UNSIGNED AUTO_INCREMENT,
  `nodeName` varchar(64) DEFAULT NULL,
   UNIQUE (nodeID),
   INDEX nowy1 (nodeID),
  PRIMARY KEY  (`nodeID`)
) TYPE=InnoDB;
 
# --------------------------------------------------------
 
#
# Struktura tabeli dla  `blood`
#
 
CREATE TABLE `blood` (
  `parentID` int(10) UNSIGNED NOT NULL,
  `childID` int(10) UNSIGNED NOT NULL,
   PRIMARY KEY (parentID,childID),
   INDEX in1 (parentID),
   FOREIGN KEY (parentID) REFERENCES nodes (nodeID) ON DELETE cascade ON UPDATE cascade,
   INDEX in2 (childID),
   FOREIGN KEY (childID) REFERENCES nodes (nodeID) ON DELETE cascade ON UPDATE cascade
) TYPE=InnoDB;
 
# --------------------------------------------------------
[SQL] pobierz, plaintext 

i dziala.

Pytania:
1. Jesli usune indeksy to juz nie dziala ale dlaczego przeciez wymagane indexy powinno tworzyc Primary Key ?
2. co znaczy :

[SQL] pobierz, plaintext 
ON DELETE cascade ON UPDATE cascade
[SQL] pobierz, plaintext 

znaczy wiem ze podczas kasowania i uaktulaniania sprawdzane jest czy istnieje wogole taki nodeID jego powiazania itp. ale czy bez tego dzialaloby inaczej?
3. kontrola integralnosc i kluczy na poziomie bazy danych to naprawde fajna sprawa tylko czy ktos testowal kto zrobi to szybciej baza czy skrypt? obstawiam baze ale moge sie mylic
4. Co z przenosnoscia takiego kodu? postgre tez by cos takiego dzialalo?

z gory dzieki za odpowiedz

Ten post edytował squid 31.10.2004, 17:33:42