回答編集履歴

5 追記修正

Panzer_vor

Panzer_vor score 1612

2016/07/22 21:11  投稿

主キーをCakePHP側か実テーブル側に合わせるべきでしょうね。
ただcommentの方はpost_idを主キーにすると関連が1:1になってしまうので、
postとcommentが1:N(1:多)であるならidをそのまま主キーとするか、
post_idともう一つ連番などの識別用の列を用意して複合主キーにするとかですかね。
ただ恐らくデータが入っていると思うので、
今のテーブルをリネーム(post_bkなど)して
正しくテーブル定義し直したものに、
```SQL
INSERT INTO post SELECT * FROM post_bk
```
とかで一括移行すると良いと思います。
主キー重複には要注意ですが。
**追記①**
CakePHPほとんどかじってないから見当違いなこと言ってるかも…。
①と②にも返答しておくと、
①はUNIQUE制約を張れば主キーと似たようなことはできますが、
違いとしとしてNULLが許容される点とNULLに限っては重複が認められる点があります。
まぁNOT NULL制約を合わせてつけるとNULL自体登録不可に出来るのでより主キーっぽくは出来ますが。
(UNIQUE INDEXも勝手に貼られたと思います。)
②は範疇外であまり分からないのですが、
save時にpost_idが重複してこけるのであれば、
save呼び出し前にユニークなpost_idを採番できてないだけとかありませんか?
**追記②**
質問にあまり関係のない蛇足ですが…
1.post_idは必ず採番される
2.post_idは必ず一意に定まる
上記の要件があるのでしたら主キー制約が張れないにしろ、
UNIQUE制約とNOT NULL制約は、
よっぽどの理由がない限りは付与した方が良いです。
よっぽどの理由がない限りはpost_idには付与した方が良いです。
(既にしてるということであれば以下もスルーで…)
制約は**ビジネスルールの再現、データ整合性の保証**を可能にするので。
付加的な要素として他の開発者にも意図を伝える手段にもなり得ます。
洗練されたテーブル設計は、
それだけである程度のビジネスルールを浮き彫りに出来ることを知っておいて損はないです。
4 誤字修正

Panzer_vor

Panzer_vor score 1612

2016/07/22 21:08  投稿

主キーをCakePHP側か実テーブル側に合わせるべきでしょうね。
ただcommentの方はpost_idを主キーにすると関連が1:1になってしまうので、
postとcommentが1:N(1:多)であるならidをそのまま主キーとするか、
post_idともう一つ連番などの識別用の列を用意して複合主キーにするとかですかね。
ただ恐らくデータが入っていると思うので、
今のテーブルをリネーム(post_bkなど)して
正しくテーブル定義し直したものに、
```SQL
INSERT INTO post SELECT * FROM post_bk
```
とかで一括移行すると良いと思います。
主キー重複には要注意ですが。
**追記①**
CakePHPほとんどかじってないから見当違いなこと言ってるかも…。
①と②にも返答しておくと、
①はUNIQUE制約を張れば主キーと似たようなことはできますが、
違いとしとしてNULLが許容される点とNULLに限っては重複が認められる点があります。
まぁNOT NULL制約を合わせてつけるとNULL自体登録不可に出来るのでより主キーっぽくは出来ますが。
(UNIQUE INDEXも勝手に貼られたと思います。)
②は範疇外であまり分からないのですが、
save時にpost_idが重複してこけるのであれば、
save呼び出し前にユニークなpost_idを採番できてないだけとかありませんか?
**追記②**
質問にあまり関係のない蛇足ですが…
1.post_idは必ず採番される
2.post_idは必ず一意に定まる
上記の要件があるのでしたらが張れないにしろ、
上記の要件があるのでしたら主キー制約が張れないにしろ、
UNIQUE制約とNOT NULL制約は、
よっぽどの理由がない限りは付与した方が良いです。
(既にしてるということであれば以下もスルーで…)
制約は**ビジネスルールの再現、データ整合性の保証**を可能にするので。
付加的な要素として他の開発者にも意図を伝える手段にもなり得ます。
洗練されたテーブル設計は、
それだけである程度のビジネスルールを浮き彫りに出来ることを知っておいて損はないです。
3 蛇足の追加

Panzer_vor

Panzer_vor score 1612

2016/07/22 21:07  投稿

主キーをCakePHP側か実テーブル側に合わせるべきでしょうね。
ただcommentの方はpost_idを主キーにすると関連が1:1になってしまうので、
postとcommentが1:N(1:多)であるならidをそのまま主キーとするか、
post_idともう一つ連番などの識別用の列を用意して複合主キーにするとかですかね。
ただ恐らくデータが入っていると思うので、
今のテーブルをリネーム(post_bkなど)して
正しくテーブル定義し直したものに、
```SQL
INSERT INTO post SELECT * FROM post_bk
```
とかで一括移行すると良いと思います。
主キー重複には要注意ですが。
**追記**
**追記①**
CakePHPほとんどかじってないから見当違いなこと言ってるかも…。
①と②にも返答しておくと、
①はUNIQUE制約を張れば主キーと似たようなことはできますが、
違いとしとしてNULLが許容される点とNULLに限っては重複が認められる点があります。
まぁNOT NULL制約を合わせてつけるとNULL自体登録不可に出来るのでより主キーっぽくは出来ますが。
(UNIQUE INDEXも勝手に貼られたと思います。)
②は範疇外であまり分からないのですが、
save時にpost_idが重複してこけるのであれば、
save呼び出し前にユニークなpost_idを採番できてないだけとかありませんか?
**追記②**  
質問にあまり関係のない蛇足ですが…  
1.post_idは必ず採番される  
2.post_idは必ず一意に定まる  
 
上記の要件があるのでしたらが張れないにしろ、  
UNIQUE制約とNOT NULL制約は、  
よっぽどの理由がない限りは付与した方が良いです。  
(既にしてるということであれば以下もスルーで…)  
 
制約は**ビジネスルールの再現、データ整合性の保証**を可能にするので。  
付加的な要素として他の開発者にも意図を伝える手段にもなり得ます。  
 
洗練されたテーブル設計は、  
それだけである程度のビジネスルールを浮き彫りに出来ることを知っておいて損はないです。  
 
 
 
2 追記

Panzer_vor

Panzer_vor score 1612

2016/07/22 19:18  投稿

主キーをCakePHP側か実テーブル側に合わせるべきでしょうね。
ただcommentの方はpost_idを主キーにすると関連が1:1になってしまうので、
postとcommentが1:N(1:多)であるならidをそのまま主キーとするか、
post_idともう一つ連番などの識別用の列を用意して複合主キーにするとかですかね。
ただ恐らくデータが入っていると思うので、
今のテーブルをリネーム(post_bkなど)して
正しくテーブル定義し直したものに、
```SQL
INSERT INTO post SELECT * FROM post_bk
```
とかで一括移行すると良いと思います。
主キー重複には要注意ですが。
主キー重複には要注意ですが。
**追記**
CakePHPほとんどかじってないから見当違いなこと言ってるかも…。
①と②にも返答しておくと、
①はUNIQUE制約を張れば主キーと似たようなことはできますが、
違いとしとしてNULLが許容される点とNULLに限っては重複が認められる点があります。
まぁNOT NULL制約を合わせてつけるとNULL自体登録不可に出来るのでより主キーっぽくは出来ますが。
(UNIQUE INDEXも勝手に貼られたと思います。)
②は範疇外であまり分からないのですが、
save時にpost_idが重複してこけるのであれば、
save呼び出し前にユニークなpost_idを採番できてないだけとかありませんか?
1 追記など

Panzer_vor

Panzer_vor score 1612

2016/07/22 18:51  投稿

主キーをCakePHP側か実テーブル側に合わせるべきでしょうね。
ただcommentの方はpost_idを主キーにすると関連が1:1になってしまうので、
postとcommentが1:N(1:多)であるならidをそのまま主キーとするか、
post_idともう一つ連番などの識別用の列を用意して複合主キーにするとかですかね。
ただ恐らくデータが入っていると思うので、
今のテーブルをリネーム(post_bkなど)して
正しくテーブル定義し直したものに、
```SQL  
INSERT INTO post SELECT * FROM post_bk
とかで一括登録すると良いと思います。
```
とかで一括移行すると良いと思います。
主キー重複には要注意ですが。

思考するエンジニアのためのQ&Aサイト「teratail」について詳しく知る