私は間違って制約を作成した可能性があります。私は3つのテーブルを持っています:アクティビティ、認証、ログイン。私は、認証を "プライマリ"テーブルにしたいと思っていました。そこで、ユーザーを作成するためのデータとその詳細を挿入します。新しく作成されたテーブル、セッションIDを格納する認証テーブルと1対1の関係(id
のログインでid
)が1対1の関係になります。 3番目のテーブルは、AuthenticationID
の複数の行と1対多の関係を持ち、これはid
のLoginに対応します。不適切に作成された制約を編集する
これは私が作成したものです:私は(私は制約を作成したまで働いていた)認証に新しい行を挿入しようとした残念ながら
| Login | CREATE TABLE `Login` (
`id` int(6) unsigned NOT NULL AUTO_INCREMENT,
`TimeLoggedIn` text NOT NULL,
`sessionid` varchar(255) NOT NULL,
PRIMARY KEY (`id`),
KEY `id` (`id`),
KEY `id_2` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=13 DEFAULT CHARSET=latin1 |
| Authentication | CREATE TABLE `Authentication` (
`id` int(6) unsigned NOT NULL AUTO_INCREMENT,
`userid` varchar(30) NOT NULL,
`password` varchar(30) NOT NULL,
`role` varchar(20) NOT NULL,
`email` varchar(50) DEFAULT NULL,
`AuthenticationID` int(6) unsigned DEFAULT NULL,
PRIMARY KEY (`id`),
CONSTRAINT `Authentication_ibfk_1` FOREIGN KEY (`id`) REFERENCES `Login` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=latin1 |
| Activity | CREATE TABLE `Activity` (
`num` int(11) NOT NULL AUTO_INCREMENT,
`AuthenticationID` int(6) unsigned NOT NULL,
`TorrentMag` mediumtext NOT NULL,
PRIMARY KEY (`num`),
KEY `FK_myKey2` (`AuthenticationID`),
CONSTRAINT `FK_myKey` FOREIGN KEY (`AuthenticationID`) REFERENCES `Authentication` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT `FK_myKey2` FOREIGN KEY (`AuthenticationID`) REFERENCES `Authentication` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=104 DEFAULT CHARSET=latin1 |
、
INSERT INTO Authentication (userid, password, role, email) VALUES ("user", "SeG^SU;B2_&Uhw", "user", "[email protected]");
を
Cannot add or update a child row: a foreign key constraint fails (`episodescopy`.`Authentication`, CONSTRAINT `Authentication_ibfk_1` FOREIGN KEY (`id`) REFERENCES `Login` (`id`))
私は間違って必要なものと逆の関係を作成しましたか?また、私はテーブルのアクティビティに重複制約を作成したようです?これをどうすれば解決できますか?
'user'は' Login'テーブルに対応するエントリを持っていますか?これが私がチェックする最初のものであり、エラーが何を示唆しているかのようです。 –
ユーザーが作成されています。ログインテーブルのIDは、認証テーブルのユーザー作成時に更新されます。その逆もありません。 – Droidzone
これは本当ですか?ユーザーは_Login_テーブルに存在していなければなりません。認証前に参照することができます。これはここのケースですか? –