Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: bład errno: 150
Forum PHP.pl > Forum > Bazy danych > MySQL
squid
majac takie tabele :
  1. CREATE TABLE `nodes` (
  2. `nodeID` int(10) UNSIGNED NOT NULL,
  3. `nodeName` varchar(64) DEFAULT NULL,
  4. PRIMARY KEY (`nodeID`)
  5. ) TYPE=InnoDB;
  6.  
  7. # --------------------------------------------------------
  8.  
  9. #
  10. # Struktura tabeli dla `blood`
  11. #
  12.  
  13. CREATE TABLE `blood` (
  14. `parentID` int(10) UNSIGNED NOT NULL,
  15. `childID` int(10) UNSIGNED NOT NULL,
  16. INDEX (`parentID`,`childID`),
  17. FOREIGN KEY(`parentID`) REFERENCES nodes(`nodeID`),
  18. FOREIGN KEY(`childID`) REFERENCES nodes(`nodeID`)
  19. ) TYPE=InnoDB;


otrzymuje taki komunikat:
Cytat
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 tongue.gif
squid
Cytat(spenalzo @ 2004-10-20 23:34:12)
Ano faktycznie, przyznaje sie do błedu, nie zauważyłęm że jest tam typ InnoDB tongue.gif

i to od bardzo dawna winksmiley.jpg

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
  1. PRIMARY KEY (`nodeID`)

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)
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
Cytat(anas @ 2004-10-24 15:23:04)
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 sad.gif
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
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:

  1. CREATE TABLE Produkty (
  2. ProduktID Bigint NOT NULL AUTO_INCREMENT,
  3. StawkaID Int NOT NULL,
  4. GrupaID Bigint NOT NULL,
  5. Nazwa Varchar(255) NOT NULL,
  6. CenaNetto Double(9,2) NOT NULL,
  7. Opis Longtext,
  8. UNIQUE (ProduktID),
  9. INDEX AI_ProduktID (ProduktID),
  10. PRIMARY KEY (ProduktID,StawkaID,GrupaID),
  11. INDEX IX_GrupyTowarowe_Produkty (GrupaID),
  12. FOREIGN KEY (GrupaID) REFERENCES GrupyTowarowe (GrupaID) ON DELETE cascade ON UPDATE cascade,
  13. INDEX IX_Relationship9 (StawkaID),
  14. FOREIGN KEY (StawkaID) REFERENCES StawkiVat (StawkaID) ON DELETE cascade ON UPDATE cascade
  15. ) TYPE = InnoDB
  16. ROW_FORMAT = DEFAULT;


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:

  1. CREATE TABLE ProduktyPowiazania (
  2. ProduktID Bigint NOT NULL,
  3. PowiazanyZ Bigint NOT NULL,
  4. PRIMARY KEY (ProduktID,PowiazanyZ),
  5. INDEX IX_Relationship11 (ProduktID),
  6. FOREIGN KEY (ProduktID) REFERENCES Produkty (ProduktID) ON DELETE cascade ON UPDATE cascade,
  7. INDEX IX_Relationship12 (PowiazanyZ),
  8. FOREIGN KEY (PowiazanyZ) REFERENCES Produkty (ProduktID) ON DELETE cascade ON UPDATE cascade
  9. ) TYPE = InnoDB
  10. ROW_FORMAT = DEFAULT;


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 smile.gif... 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 smile.gif.

pozdrowka

anas
squid
No dzieki wielkie!!

zrobilem na podstwaie tego co mi dales tak :
  1. #
  2. # Struktura tabeli dla `nodes`
  3. #
  4.  
  5. CREATE TABLE `nodes` (
  6. `nodeID` int(10) UNSIGNED AUTO_INCREMENT,
  7. `nodeName` varchar(64) DEFAULT NULL,
  8. UNIQUE (nodeID),
  9. INDEX nowy1 (nodeID),
  10. PRIMARY KEY (`nodeID`)
  11. ) TYPE=InnoDB;
  12.  
  13. # --------------------------------------------------------
  14.  
  15. #
  16. # Struktura tabeli dla `blood`
  17. #
  18.  
  19. CREATE TABLE `blood` (
  20. `parentID` int(10) UNSIGNED NOT NULL,
  21. `childID` int(10) UNSIGNED NOT NULL,
  22. PRIMARY KEY (parentID,childID),
  23. INDEX in1 (parentID),
  24. FOREIGN KEY (parentID) REFERENCES nodes (nodeID) ON DELETE cascade ON UPDATE cascade,
  25. INDEX in2 (childID),
  26. FOREIGN KEY (childID) REFERENCES nodes (nodeID) ON DELETE cascade ON UPDATE cascade
  27. ) TYPE=InnoDB;
  28.  
  29. # --------------------------------------------------------


i dziala.

Pytania:
1. Jesli usune indeksy to juz nie dziala winksmiley.jpg ale dlaczego przeciez wymagane indexy powinno tworzyc Primary Key questionmark.gif?
2. co znaczy :
  1. ON DELETE cascade ON UPDATE cascade

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
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.