制約っていらなくね? (114レス)
上
下
前
次
1-
新
41
:
29
04/07/12 02:30 ID:???
AA×
>>39
,
40
[240|
320
|
480
|
600
|
100%
|
JPG
|
べ
|
レス栞
|
レス消
]
41: 29 [sage] 04/07/12 02:30 ID:??? >>39,40 文章得意じゃなくて、端的に書けなくてスマソ。 INDEX を張るのを躊躇した理由は、容量の問題だけではなくて更新時のパフォーマンスも気にしてのことです。 さらに言うと、実はTABLE_A.ID への外部キーは、一つのテーブルあたり挿入時用、更新時用、削除マーク用の 3つあるので、 容量もINDEX更新のコストも3倍かかりそうで、なおさら気になったのです。 自分はINDEXに必要なディスクスペースや、INDEX更新に必要なコストを見積もるスキルは無いのですが、せっかく制約の スレを見つけたので、制約に関する便利機能なんかの意見をもらえるかな、と思っての質問でした。 自分でも結局は INDEX 張って正攻法でやることになるんだろうな、と思っています。 > たしかに、継承するなら制約やトリガなども継承された方が便利だと > 思うんだけどね。 ですよね。 そのほうがエレガントだと思うんですけど、PostgreSQL 7.0 から 7.1 への変更に「継承先のテーブルの継承列で主キー, 外部キーが定義できるようになりました.」とあるので、やっぱり仕様として意図的にこうなってるんですよね。 ところで > FKとB、Cは別のテーブルであって、FKをselectした際にデフォルトで > BとCも一緒に検索してるだけ。Aにない値がFKに入ったわけではない。 EXPLAIN で TABLE_FK をSELECT するクエリプランを見てみたら、本当に TABLE_B、TABLE_C の SELECT も やってるんですね。 実はテーブルの継承って言葉はここ2〜3日で覚えたので、新しい発見だらけです。 このスレで話してよかったです。 でも、ということは、INDEX を継承元テーブルに張るだけではなく、それを継承するテーブルにも INDEX を張らないと ダメなんですね? うーん、めんどくさいなぁ・・・ そう思うと、テーブルを継承するメリットってなんなんでしょうかね? http://mevius.5ch.net/test/read.cgi/db/1087483786/41
文章得意じゃなくて端的に書けなくて を張るのをした理由は容量の問題だけではなくて更新時のパフォーマンスも気にしてのことです さらに言うと実は への外部キーは一つのテーブルあたり挿入時用更新時用削除マーク用の つあるので 容量も更新のコストも倍かかりそうでなおさら気になったのです 自分はに必要なディスクスペースや更新に必要なコストを見積もるスキルは無いのですがせっかく制約の スレを見つけたので制約に関する便利機能なんかの意見をもらえるかなと思っての質問でした 自分でも結局は 張って正攻法でやることになるんだろうなと思っています たしかに継承するなら制約やトリガなども継承された方が便利だと 思うんだけどね ですよね そのほうがエレガントだと思うんですけど から への変更に継承先のテーブルの継承列で主キー 外部キーが定義できるようになりましたとあるのでやっぱり仕様として意図的にこうなってるんですよね ところで とは別のテーブルであってをした際にデフォルトで とも一緒に検索してるだけにない値がに入ったわけではない で を するクエリプランを見てみたら本当に の も やってるんですね 実はテーブルの継承って言葉はここ日で覚えたので新しい発見だらけです このスレで話してよかったです でもということは を継承元テーブルに張るだけではなくそれを継承するテーブルにも を張らないと ダメなんですね? うーんめんどくさいなぁ そう思うとテーブルを継承するメリットってなんなんでしょうかね?
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 73 レスあります
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
ぬこの手
ぬこTOP
0.070s