【恐怖】主キーがないテーブルみたことありますか？

1 ：NAME IS NULL：03/11/20 19:42 ID:tPSXAOuF

出向先のプロジェクトの話。

テーブルに主キーが1つも設定されていませんでした。
しかも全テーブルに。

担当者に問い合わせたところ、
「主キー付けるとデータを入れにくくない？」
っていわれました。
しかも「そんなこともしらないの」っていわれました。

システムは無事に完成。
納品されて、今も動いてます。

でも、主キー無しです。
良いのでしょうか？

2 ：NAME IS NULL：03/11/20 20:06 ID:???

(・∀・)ﾁﾝﾎﾟｰ!

3 ：NAME IS NULL：03/11/20 20:51 ID:B2SQACwz

ユニークIDを別に管理して外部キーかもしれん

4 ：NAME IS NULL：03/11/20 21:29 ID:???

See below:

CREATE TABLE PRIMARY_KEY_LESS_TABLE (id integer, data varchar(100));

見たーなーーー.

5 ：NAME IS NULL：03/11/20 21:33 ID:uR4aexea

それを発展させる気が無ければアリだと思う。

6 ：NAME IS NULL：03/11/20 21:58 ID:Nph1AJCd

きっとExcel大好きな会社なんだろ

7 ：NAME IS NULL：03/11/20 22:25 ID:???

検索が糞遅そうだなあ・・・

8 ：NAME IS NULL：03/11/20 23:42 ID:???

>>7
Joinとかしてたら最悪だね

9 ：NAME IS NULL：03/11/21 01:16 ID:???

別にprimary key　がなくても、それほどすごいことはないと思うが。
確かに、１行単位での削除とかできないが、それは用途の問題だし。
uniqueでないindexでもべつにいいわけだし、
意味のない行番号ならつける必要ないんじゃない？

10 ：NAME IS NULL：03/11/21 09:36 ID:0VNv31XX

たとえば、商品コードが商品テーブルの主キーに
なってないとしても、レコードの挿入時に商品コードの値が
テーブル中で重複しないようにプログラムがチェックする
ようになっていればいい。なぜなら、ユニーク指定なしの
インデックスでも検索できるから。

そんな調子で全テーブルをユニークキーなしで開発する
ことは可能ではある。

でもそれって、本来はＤＢＭＳがやるはずの重複検査の
仕事をプログラムがやっているってことで、開発や保守で
必要以上の苦労をしょいこむことになるな。そうでなくても、
プログラムのコードをよく読まなければテーブルの関係を
理解できないってことになってこれはつらい。
データベースの構造を見ただけでどんなシステムかがわかる
くらいでないと、開発でも保守でもラクできないよね。

11 ：NAME IS NULL：03/11/21 11:16 ID:???

＞「主キー付けるとデータを入れにくくない？」
これが全てをものがたってるな

12 ：NAME IS NULL：03/11/21 12:33 ID:8f3l89hg

そんなに深刻なるな1よ
1の担当者はエクセルシートの代わりにDBを使いたかっただけなんだよ
なぜDBにしたかというと、そのほうが儲かるからだろう
実際、どうでもいいようなシステムなんだろ？

13 ：NAME IS NULL：03/11/21 13:02 ID:???

カード型DBの発想から来てるんだろうね＞主キーなし
「カード1枚でユニークになってるだろ！」とゆー半端ユーザーの声が聞こえてきそうだ（涙

14 ：NAME IS NULL：03/11/21 15:30 ID:???

>>1

かならず主キーが必要と考えている>>1は問題あるぜ
主キーが何なのかを理解できているのか?

>>13

カード型DBって懐かしいな(w
Ninjaを思い出してしまった。

15 ：NAME IS NULL：03/11/21 18:07 ID:???

必要と言うか、パフォーマンスや整合性考えたら普通はつけるわな。

多分、必要と言っている分野の人はOracle派で、
どうでもいいと言っている人はMySQLとかMSSQLとか使いだと思う。

16 ：NAME IS NULL：03/11/21 18:13 ID:???

PostgreSQLですが、いざとなったらoid使うんでどっちでもいいけど
入れにくい、という理由でキーを廃止するのは違うと思う・・・

17 ：NAME IS NULL：03/11/21 20:56 ID:???

藻前ら Codd 博士の RDB 理論について勉強しなおせ。
理論上 RDB には主キーなど必要無い。

但し、行全体でユニークにはなっていないといけない。
同じ内容の行が二つあったら駄目なところが Excal と違うとこ。

18 ：17：03/11/21 20:57 ID:???

Excal って何だ。ｗ

19 ：NAME IS NULL：03/11/21 21:28 ID:???

主キーがあるのと無いので全然検索速度変わるDBMSもめずらしかないだろ。

20 ：NAME IS NULL：03/11/21 22:17 ID:???

メインキーなくてもmultiなindexでも検索速度かわらないDBもめずらしくないしなあ。
１はちょっといいすぎかと。やっぱ用途次第だと思うな。
「indexのないDB」だったらすごいけどな。

21 ：NAME IS NULL：03/11/21 22:21 ID:???

常にテーブルスキャンするDBもあるんでないかい？

22 ：NAME IS NULL：03/11/21 22:22 ID:???

どっちかというと、すべてのテーブルでメインキーが必要ない
データ設計ってどういうんだよ・・のほうが突っ込むとこだな。
正規化スレ的だけど。JOINとかしないんだろうなー。

23 ：NAME IS NULL：03/11/22 02:49 ID:???

>>17
主キーが行全体になっていればいいんだな(w

24 ：NAME IS NULL：03/11/22 19:52 ID:wXJ2Fokq

理論的にどうなのかはよく知らないけど、
要するに主キーを用いないで「他人にわかりやすい、
保守しやすいシステム」になるかどうかだ。
そういう意味ではどうなんだろう。

25 ：NAME IS NULL：03/11/22 20:26 ID:???

更新や削除等で、ある1行を特定するときどうやってんだろう

26 ：NAME IS NULL：03/11/22 21:10 ID:???

順次処理しか行わないテーブルなら別に主キーが無くてもいいように
思うが。
アプリケーションログとかね。

27 ：NAME IS NULL：03/11/22 21:16 ID:???

>>25
全部のカラムをwhere条件に指定する。ｗ

28 ：NAME IS NULL：03/11/22 21:17 ID:???

>>24
＞テーブルに主キーが1つも設定されていませんでした。
＞しかも全テーブルに。

こんなシステム引継ぎさせられたら、暴れちゃう（ｗ
多分、1年ぐらいしたらレスポンス悪い部分がぼろぼろ出てきて
悲しくなるんだろうなぁ。。。

29 ：NAME IS NULL：03/11/22 21:17 ID:???

>>26
それをDBで管理するのは・・・どうよ？

30 ：NAME IS NULL：03/11/22 21:20 ID:???

>>29
うん。テキストファイルやCSVに書き出せとか言われそうだけど、
ファイルオブジェクト使うのが面倒とか、バックアップ・リカバリ
などはDBMSで一元管理したいとかね。

31 ：NAME IS NULL：03/11/22 21:28 ID:???

>>28
まぁでも主キーを設定したからって、それを使ってない不毛な
アプリをこれまで結構見てきたよ。
あくまで一意制約としてのみしか扱ってない。
実行計画みたら、全部テーブルスキャンとか。

32 ：28：03/11/22 21:40 ID:???

>>31
あるある（ｗ
そういえば、もっと凄いのも見たことあった。。。
1レコードinsertするのに6時間くらいかかってたシステム。。。

ヽ（｀Д´）ﾉ思い出したくないよー。

33 ：NAME IS NULL：03/11/22 21:40 ID:???

主キーがＧＵＩＤだったっていう何の為のキーなんだか分からんのも見たことはあるな(w

34 ：NAME IS NULL：03/11/22 21:46 ID:???

>>32
どうやったら、そんなに時間が掛かるんだ？
インデックスが全カラムにあるとかか？

35 ：NAME IS NULL：03/11/22 21:52 ID:???

>>32
OLTPなら間違いなくSessionTimeoutだな(藁

36 ：NAME IS NULL：03/11/23 09:52 ID:???

>>35
ユーザが痺れを切らしてタイムアウト、つか、ｺﾞﾙｧｰされるのが早い。

37 ：28：03/11/23 10:19 ID:???

ｺﾞﾗｧされて呼ばれたのが、(作った訳でもないのに)僕な訳で・・・。

で見てみると、Oracleなのに表領域もテーブルもサイズ指定しないで
作成されてて、自動拡張し放題。
その上、データベースのディスクに通常のデータ(excel,waord,access等)
も一緒に放り込んでるので、フラグメンテーションし放題。
(´-`)．。oO（あぁ、oracleもmsaccess見たいに使うとこうなるのか・・・）
とか思いつつ。
動作しているサーバマシンを見るとメモリが128M。( Д )　　ﾟ　　ﾟ
「もう、お願いしますからマシン買ってください」と言ってサーバを新しいのにして貰った。
＃余談：1データ登録するのに帰宅ときに登録、翌朝出社したら登録終了という
＃使い方をしてたらしい。。。

DBがどうとか、言う話じゃないっすね。スレ汚しすまんです。

38 ：NAME IS NULL：03/11/23 12:08 ID:???

データ「1件」じゃなくてほんとに1レコード登録するのにそんなに
時間がかかってるとしたら、主キーがないとかディスクがどうだとか
じゃあ説明つかないような気もするが。
実はビューだったとか、挿入トリガーが仕掛けてあったとかじゃない？

39 ：28：03/11/23 12:26 ID:???

＞実はビューだったとか、挿入トリガーが仕掛けてあったとかじゃない？

ぃゃ、そんな上等な話じゃなかったと思います。。。たぶん。。。
常時スワップしててディスクアクセスしっぱなしで、
メモ帳すらろくに動かん状態だったので。
oracleのエクステントも１Mくらいのが100超えてたし。

40 ：NAME IS NULL：03/11/23 12:38 ID:???

>>39
Oracle 9i でメモリ128だとありえない話では無いな。。
それに何も考えずにOracleフルインスコしてるんだろ？必要無いものまで。

41 ：NAME IS NULL：03/11/23 12:41 ID:???

>>37
＞＃余談：1データ登録するのに帰宅ときに登録、翌朝出社したら登録終了という
＞＃使い方をしてたらしい。。。

そんなんで運用できるとはどんなアプリなんだ？？

42 ：NAME IS NULL：03/11/23 12:48 ID:???

だんだん登録が遅くなって、昼間は登録禁止、から
運用ルールが出来上がっていったんだろうなｗ

43 ：NAME IS NULL：03/11/23 13:13 ID:???

>>1のDBがAccessなら許すｗ

お客「検索が遅いんだけど速くしてくれない？？」
担当「え？主キーってなんですか？？」
のちの保守で地獄を見そうですな・・・。

１．素人は主キーを設定してはならない

44 ：NAME IS NULL：03/11/23 17:39 ID:???

>>43
Access使ってるシステムなんて企業の中枢システムなわけが無いから
テキトーでいいんです。テキトーで。

45 ：NAME IS NULL：03/11/23 17:48 ID:???

>>44
いや、中小の工場系では意外とマジに基幹だったりする・・・
納めたことありますもの。

46 ：NAME IS NULL：03/11/23 18:00 ID:???

>>45
あっ。。うちも400万ぐらいの仕事であったかも。。
新人が中心に作ってたな。
ﾊﾞｯｸｱｯﾌﾟ･ﾘｶﾊﾞﾘの立案も出来ないしﾃﾞｨｽｸ飛んだら
終了ですみたいなことを平然と言ってのけたらしい。

47 ：NAME IS NULL：03/11/23 18:05 ID:???

>>46
日次しかできないけど、バックアップ(コピー)ぐらいはしてるよね？
ウチは他に圧縮？(名前忘れた)も日次でしてるよ。

48 ：NAME IS NULL：03/11/23 18:16 ID:???

>>47
ごめん。直接携わってないからそこらへんはよくわかりません。
日次バックアップくらいはやってのかなぁ？
でも完全なスタンドアローンシステムでサーバなんてのは
無かったと思うし、業務終了したら多分パソコンの電源落としちゃう
運用だからバックアップなんてしてないかもね。

49 ：NAME IS NULL：03/11/23 18:30 ID:???

>>48
ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
ACCESSは業務に使うと定期的に壊れますた。

50 ：NAME IS NULL：03/11/24 04:38 ID:???

>>15
主キーがなくても通るのはODBC経由の話で、MSSQL自体は主キーがないと許さんよ。

51 ：NAME IS NULL：03/11/24 12:20 ID:???

>>50
いや、主キーがなくてもテーブル自体は定義出来るし、
ODBCでもアクセス出来るでしょ。

52 ：NAME IS NULL：03/11/24 15:27 ID:???

>>51
オラクルも主キーなしでテーブル作れるんだが…

53 ：NAME IS NULL：03/11/24 15:57 ID:???

主キー無しでテーブル作れないRDBってあるのか？
警告が出るのは見たことあるけど

54 ：NAME IS NULL：03/11/24 22:51 ID:???

>>53
無いね。俺の汁限り。

55 ：NAME IS NULL：03/12/02 03:45 ID:BGR/fIxz

タコな質問ですいませんが、
主キーと、ユニークインデックスってどう違うのでしょうか?

56 ：NAME IS NULL：03/12/02 03:48 ID:RebitiAp

　（健康体）　　（喘息）

1.（神が喘息であるかないかを決める）
　　Y　　　　　　　　I
2.喘息でない人　　喘息の人は
は体力がある　　　体力がない
Y I
3.　　　　　　　　行動力、
　　　　　　　　　五感（嗅覚）が鈍り感性が変化
　　　　　　　　　する
　　Y　　　　　　　　I
4.神は異常な感性の人間は本来人に迷惑をかけるから外に出てはいけないと思っている。
Y I
5.変化なし　　　　アトピーになる
Y I
6.正常な感性　　　外に出なくなりさらに異常な感　　　　　　　　　性になる
Y I
7.正常な人間　　異常な人間（レッテル）

57 ：NAME IS NULL：03/12/02 03:49 ID:RebitiAp

Y I
8. 死
　　Y　　　　　　　　I
9.　　　　　　来世
Y I
10.神は異常な人間は人に迷惑をかけるので行動を抑制する必要がある
Y I
11.神は異常な人間は人に迷惑をかけるので行動を抑制する必要があると思っている。
Y I
12.神が喘息であるかないかを決める
　　Y　　　　　　　　I
13.喘息でない　　　喘息である
　　Y　　　　　　　　I
　　　　　1.に戻る

神は事態の収拾に必死、頑張れよー。

58 ：NAME IS NULL：03/12/02 03:50 ID:RebitiAp

アトピー性皮膚炎の治し方

行動力=ガッツ=体力

アトピー性皮膚炎の患者は、
感覚の鈍い人間が多い。
それはなぜか。
幼少期喘息になるから、
体力がつかないため、
五感が弱るからである。
解決方法は、
五感を強くしてやればいい。
体力をつけることですぐに五感が正常になり、
行動力も湧くのである。
五感が正常になり、体力もつけば、
アトピー性皮膚炎も不思議と消えることが多い。

59 ：NAME IS NULL：03/12/02 06:07 ID:???

>>55
プライマリキーの設定ができないDB（古いバージョンのSQL Serverなど）
を利用している場合、ユニークなインデックスを作成して、
プライマリキーと同等の効果を得ていた。

ちなみに
主キーとは
「表の行を唯一に識別できる列または列の組」のことで、
主キーの列にNULLを入れることは可。

プライマリキーの列にNULLを入れることは不可。

1が言っている主キーとは、おそらくプライマリキーのこと。
ユニークインデックスも主キーとして扱うことは可能。

60 ：NAME IS NULL：03/12/02 22:02 ID:8caVKpbN

>>59
昔は知らんが今は主キーとプライマリキーは同義だろ。

61 ：NAME IS NULL：03/12/02 23:19 ID:???

55が使っているDBをおしえなさい。

62 ：NAME IS NULL：03/12/03 00:23 ID:???

>>60
同義とはいえないな。

プライマリキーとは主キーに設定するものだ。
プライマリキーがない場合は、ユニークインデックスで代用しても可
ということだ。

63 ：NAME IS NULL：03/12/03 01:30 ID:gFmAVNYs

Primary KeyはUNIQUE + NOT NULL

64 ：NAME IS NULL：03/12/03 01:57 ID:???

日本語と英語で同じ意味なのに違うのかよ・・・
言語そろえてくれー

65 ：NAME IS NULL：03/12/03 15:17 ID:???

>>60 >>64
昔のことを知らない若造なのだが、
昔は「主キー」と「Primary key」が別物だったのか?
単なる訳語じゃないの?

教えろ。

66 ：NAME IS NULL：03/12/03 20:41 ID:???

主キー＝ Primary key (主なるキー) だが。

67 ：NAME IS NULL：03/12/03 22:00 ID:???

>>62
今時、そんな設計する奴がどうかしてる。
ユニークインデックス設定する前にプライマリキーを設定しろ。

68 ：NAME IS NULL：03/12/04 00:40 ID:dWNHaRO0

主キーはＤＢ設計上の概念
INDEXはDB操作上の概念。

ドメインが違う。んでぇ、主キーが無いって事はRDBではない事だ。

69 ：NAME IS NULL：03/12/04 01:45 ID:???

>>68
>主キーはＤＢ設計上の概念

つまりはそういうことなんだろうな

70 ：NAME IS NULL：03/12/04 20:44 ID:???

>>68
＞んでぇ、主キーが無いって事はRDBではない事だ。

それは違ぁ～～～～う。

71 ：NAME IS NULL：03/12/05 07:02 ID:???

>>70
なぜだ？

72 ：NAME IS NULL：03/12/05 10:23 ID:???

RDBのシステムにのっけりゃなんでもRDBというわけでもないな

73 ：NAME IS NULL：03/12/05 23:21 ID:???

>>71
嫁！主キーはRDBの必須条件ではない。

http://www.amazon.co.jp/exec/obidos/ASIN/4621042769/qid=1070631476/sr=1-1/ref=sr_1_2_1/250-0170725-0347471

74 ：NAME IS NULL：03/12/06 14:15 ID:3t6cgsvv

1.単純な表には、行の重複(同一な値)は許されない。
2.行が同一であることを見分ける属性の組み合わせを候補キーという
これは複数あってもよい。
3.候補キーのうち、一つを主たるものとするとき、これを主キーという。

RDBMSとしては、主キーがなくてもよいが、候補キーは必ず必要。
(内容が全く同一な行は複数存在してはいけない)

・・・ただ、それは理論的な話で、各社のRDBMSの実装としては、
内容が同一な行を追加できたりする。

現在、RDBMSとして売られているもので、完全なRDBMSという
(理論を完全に実装している)ものはない。

75 ：NAME IS NULL：03/12/06 21:30 ID:???

＞(内容が全く同一な行は複数存在してはいけない)

そ、これがＲＤＢの必須条件。
でも、主キーが無いテーブルは激しく使いにくいわーなぁ～。

76 ：NAME IS NULL：03/12/06 21:49 ID:2T8SCnGq

>>74
違うね。RDB理論では。
内容が全く同一な行は複数存在していけない。
かつその行の一意性を定めるのが主キーだ。
つまり、RDB理論では一意性が担保されるなら

日付時間（OSと同等の分解能）商品名　こんなテーブルも許可される。
テーブルの行全体が主キーなのだ。

これを誤解してそんな風に書いたのだろう。

77 ：NAME IS NULL：03/12/06 21:51 ID:2T8SCnGq

であるから、主キーの一意性が担保されるのなら、
主キーにインデックスを張る必要は無いし、事実
そーゆう事はパフォーマンスの為にやることも有る。

RDBMSが主キーをどのように扱うかによるが。

78 ：NAME IS NULL：03/12/06 21:54 ID:2T8SCnGq

>>76
修正、
×かつその行の一意性を定めるのが主キーだ。
○かつその行の一意性を定める最小のカラム構成が主キーだ。

この方が分かり易い

79 ：NAME IS NULL：03/12/06 22:45 ID:pWhb2iV/

>>主キーにインデックスを張る必要は無いし、事実
>>そーゆう事はパフォーマンスの為にやることも有る。

さっぱり理解できん。

80 ：NAME IS NULL：03/12/06 23:48 ID:KSojWVKe

研修行かせてもらえなかったので理論はよくわかりませんが。
テーブルにもいろいろあり、
マスター系のテーブルには主キーは必要かと。
データ系のテーブルには、インデックスを張っています。
（インデックスが壊れたときのため、ジャーナルナンバーと言う枠で最低限のデータのINDEXは保っています。）
それでもINDEXがないと（DATA量5Gぐらい：TXTベース）50％ぐらい処理能力は落ちます。

今後の為、意見等ございましたらお聞かせください。（当方SYBASE）

81 ：NAME IS NULL：03/12/07 00:28 ID:rke3J8dh

別にＰＫがない表があってもおかしくないでしょう？
単に全カラムを同じように更新したいだけなのでは？
そもそも、ＰＫとは制約のひとつでしょ？　決して必須ではないはず。
もっと柔軟に考えたら？ >>1

82 ：NAME IS NULL：03/12/07 00:35 ID:???

RDBとRDBMSを分けて考える様に。

主キーはRDBなら必須。主キー制約を設定するかは任意。

83 ：NAME IS NULL：03/12/07 02:47 ID:???

>>81
データを入れにくい、という理由であえてPKを設定しないんだぜ？

84 ：NAME IS NULL：03/12/07 17:44 ID:???

履歴のデータを格納するテーブル

85 ：NAME IS NULL：03/12/07 20:03 ID:9CZAJDDr

現場、現場、実務、実務ってゆうひと多いですが、
理論をわかった上でゆってほしいものです。

86 ：NAME IS NULL：03/12/08 00:02 ID:WQRwbA5P

>>85
その心は？ただの釣り？

87 ：NAME IS NULL：03/12/08 03:13 ID:9+dnfNso

>>86
データを入れにくいからPKの設定しないような人たちの事だと思う。
てか、PKの設定をするとデータ入れにくいようなDBの設計をする人
の事だと思う。

88 ：NAME IS NULL：03/12/08 06:07 ID:???

入れにくいってどういうことだろう
データがかぶって重複エラーがうっとーしーのか
重複しない値を出すのがめんどーなのか・・

89 ：NAME IS NULL：03/12/08 15:07 ID:???

>>88
おそらく前者

おれも前に「は？」っていうテーブルにでくわしたことがある

下のようなデータをいれるテーブルで、

--------------
顧客　訪問日
--------------
A社　20030101
A社　20030110
B社　20030101
B社　20031010
C社　20030201
--------------

で、テーブル設計書には「顧客」がPKとなっていた。

担当者（上司）に「これは無理です！」って訴えたら、
「無理とかいうんじゃない！やってみなければわからんだろ！！」
って。。

わかるだろ。

90 ：８９：03/12/08 15:12 ID:???

続き

このときは、PKの設定やめました。
上司の言う通り、やってみなくちゃわからないってことですね。

91 ：NAME IS NULL：03/12/08 16:00 ID:???

( ；ﾟДﾟ)ﾎﾟｶｰﾝ

92 ：NAME IS NULL：03/12/08 16:48 ID:???

ﾜﾗﾀ

93 ：NAME IS NULL：03/12/08 21:14 ID:???

>>90
念のため聞くが、この場合はどのような切り方が正しいと思う?

94 ：NAME IS NULL：03/12/08 21:14 ID:WQRwbA5P

>>89
ネタとしか思えん。

95 ：NAME IS NULL：03/12/08 21:29 ID:WQRwbA5P

>>93
訪問履歴みたいなトランザクション系のテーブルと仮定したら
シーケンス番号(PrimaryKey)+顧客コード+訪問日
ってとこかな？

96 ：NAME IS NULL：03/12/08 22:48 ID:???

>>95
漏れなら
顧客コード＋訪問日＋枝番でPrimaryKeyかな。

97 ：NAME IS NULL：03/12/08 22:53 ID:JXurB7u3

このテーブルはいい例だ。シーケンス番号をPrimaryKeyなんだが、
全てのDBとのリンクは顧客コード中心場合によっては訪問日
なんて場合、PrimaryKeyに一意制約を付けて、顧客コードに
そのRDBMSで一番早いKeyを設定する（物凄く古いRDBMSだと重複可の主キーだったりする）

98 ：NAME IS NULL：03/12/08 23:27 ID:???

>>97
もちつけ

面白そうなんでもう少し分かりやすく説明してYO

99 ：97では無いが：03/12/08 23:46 ID:???

>>97の意訳を試みると
PrimaryKeyには一意制約（重複しない条件）ために使用し、検索のスピード
を上げるためのキーとしては顧客コードの欄を用いる。その際に用いる値は
全てのテーブルで利用しかつ検索スピードが早くなるコードを考える。

こんなとこでOK？

100 ：95：03/12/08 23:53 ID:???

>>99
単なるDWH用のテーブルなら顧客コードにインデックス張ってけば、
一意制約はいらないね。

101 ：97：03/12/08 23:59 ID:JXurB7u3

>>99
ありがとう、ウンコこらえて一気に書いたら無茶な文章だった。

>>100
DWHなら俺はPrimaryKeyを外す（定義しない）。
やっぱデータ配置が密なほうが絶対早い。
と思う。ソフトによって違うのかもしれないが。

102 ：97：03/12/09 00:02 ID:i0WwMHTk

とうぜんプライマリーキーが必要ない場合だけど。

103 ：95：03/12/09 00:04 ID:???

>>101
それをいってます。言葉足らずですまん。

104 ：NAME IS NULL：03/12/09 01:55 ID:???

顧客訪問履歴テーブル（顧客コード（PK）,訪問日（PK））

顧客テーブル（顧客コード（PK）,顧客名）

ではだめなの？

105 ：NAME IS NULL：03/12/09 23:23 ID:???

更新しなきゃユニークキーは無くても困らん。

106 ：NAME IS NULL：03/12/09 23:51 ID:???

そういう問題ではないとおもうが

107 ：NAME IS NULL：03/12/10 22:33 ID:???

複合キーいらん

108 ：NAME IS NULL：03/12/10 23:16 ID:???

>>107
回避策はたいていあるな。

109 ：NAME IS NULL：03/12/11 00:27 ID:???

>>108
というのは？

110 ：NAME IS NULL：03/12/12 03:52 ID:???

RDBを使用していない自社の会計ソフトを、
RDB対応に改造したとき、
主キーを設定していないテーブルがいくつもあったよ。

111 ：マハgogogo：03/12/13 01:22 ID:???

正直、主キー設定しないテーブルは見たことないですね。

外部キーとかで操作って言うけど、それってあえてテーブル
に主キー付けないで、外部キー使うってことでしょ。

データ入れにくいから主キー付けないって考えとは雲泥の差があると思う。

112 ：NAME IS NULL：03/12/14 16:16 ID:???

漏れは primary key のないテーブルは設計しない。たぶん。

sequence 使って捏造してでも primary key は付ける。
現場で手で UPDATE 文叩くことだって皆無じゃないから。

113 ：NAME IS NULL：03/12/14 19:14 ID:???

>>112
＞現場で手で UPDATE 文叩くことだって皆無じゃないから。

update の where 文に全カラムを入れれば無問題。
つか、最近のＤＢはExcel風のGUIツールがあるが。

114 ：NAME IS NULL：03/12/14 21:04 ID:???

>>113
primary key や unique key が存在しない場合、
内容の同じレコードが複数存在することがあります。
そのため where に全部書けばいいとは限りません。

普通は primary key がなくても相当の unique key を
付けますので、普通は unique index の付いた項目をすべて
where 句に書けば大丈夫ですね。

115 ：NAME IS NULL：03/12/15 00:13 ID:3F1uDrzr

>>114
>内容の同じレコードが複数存在することがあります。
>そのため where に全部書けばいいとは限りません。

そもそも、全く同一の内容のレコードの片方をUpdateするとき、
その片方を選ぶ根拠は何？

116 ：NAME IS NULL：03/12/15 00:36 ID:???

>>115 114じゃないけど、まったくおなじ内容のレコードの
一方を変更したい場合って、まったく同じ内容のレコードが
あると困るときだとおもうな。うっかり出来ちゃったみたいな。

117 ：NAME IS NULL：03/12/15 00:58 ID:???

>>115
普通はキー無しの表を設計しませんからね…。

内容が同じでも別レコードとして単独にupdateしたいことは
皆無とは言えないと思います。>>113で言及されているデータ
保守用アプリの利用時がまさしくその例だと思いますし。
on delete cascade のために delete before insert が使えな
い可能性もあります。

どうしてもupdateするしかない場合はOracleのROWID等、RDBMSの
拡張機能として提供されている擬似列を使うことになると思い
ます。

118 ：NAME IS NULL：03/12/15 18:07 ID:???

>>113
主要なカラムがBLOBで構成されてたら…

119 ：NAME IS NULL：03/12/16 22:50 ID:yTgNTNXB

カバかおめえら。
主キーなくても、索引つけりゃなんも問題ないだろ。
それにinsert処理なら、主キーなんてじゃま。
余計に遅くなる。
こんなんもしらんのけ

120 ：00：03/12/16 23:00 ID:iLPHMQmI

>>1
えーと
SQL鯖で、前あったな～。
いきなり投入されたシステムの運用支援で、
プログラムからのdelete 文が実行されてなくて、
「？」と思ったのがきっかけ。
(当時SQL鯖初心者)
追加削除ができないので困った。
accessからも削除ができない。

で、項目「製造番号」のところ(12桁の数字)に、
「2E+18」とか入っているレコードがあった。。
おっさん、レコードをエクセル使っていじるんじゃねぇ…！

121 ：00：03/12/16 23:02 ID:iLPHMQmI

そのシステム自体、構造が素人作成のものだったので、
(テーブルが不必要にforeign key 参照しまくりでがんじがらめ)
一年経たずに廃止になりましたけどね…。

122 ：NAME IS NULL：03/12/17 00:36 ID:???

>>119
索引はユニークな項目に対してより有効にききます。

123 ：NAME IS NULL：03/12/17 01:59 ID:???

素人プログラマが参加してるプロジェクトだと妙な
データ突っこまれそうで恐いからforeign key使いまくる。
Oracle には deferrable initially deferred という宝刀もある
から、がんじがらめにしても無問題かもなー。

124 ：NAME IS NULL：03/12/17 02:48 ID:0STEiHn4

　商品テーブル
　-------+--------
　商品ID | 商品名

　商品カテゴリテーブル
　-------+------------
　商品ID | カテゴリID

　カテゴリテーブル
　----------+------------
　カテゴリID | カテゴリ名

この場合の「商品カテゴリテーブル」はどうなん？

125 ：NAME IS NULL：03/12/17 06:40 ID:???

商品とカテゴリが、M：Mなので、
商品カテゴリテーブルはそれでいいんじゃない？

・・そういうことではない？

126 ：NAME IS NULL：03/12/17 12:44 ID:???

主キーにはシーケンス更新不可

127 ：00：03/12/17 12:53 ID:???

>>123
それはどういう決断？
開発が終わってから(開発メンバーが去ってから)のほうが長いんだから、
そんなことを考慮してテーブル構造を変えたりしないと思うのだが…。
プロジェクトにもよるのかかな。
妙なデータの発生はコーディングのほうで回避する、ってのが筋ではないかとおもう。

そもそもforeign keyの機能って、必要に迫られたためしがない…。
考え方にもよるのかな～

128 ：00：03/12/17 13:09 ID:???

「商品テーブル」
「商品カテゴリテーブル」
↑このふたつのテーブルは、実質、同じ件数が格納されることになるのではないか？
現状だと、別テーブルにする意味がないような。
(「商品テーブル」の項目数の軽減のためかな?)

おおごとだけれど、
商品IDの頭2-3桁(例)がカテゴリCDで、それ以降の桁が商品ID、っていう構造にすれば
「商品カテゴリテーブル」の妙な肥大は回避できると思うんだけどねぇ。

もう動いているのなら変えられないけどねぇ。

129 ：124：03/12/17 15:31 ID:0STEiHn4

説明不足ですた。

商品テーブル
---+---------
10 | ごぼう
11 | にんじん

商品カテゴリテーブル
---+---------
10 | 10
11 | 10
11 | 12

カテゴリテーブル
---+-------------
10 | 根菜
11 | 葉物
12 | 緑黄色野菜
13 | 季節限定

例えばこんな感じで「にんじん」が「根菜」で「緑黄色野菜」だったりして
商品とカテゴリが１：多の関係になってるときって、どういう風に管理するのが
納得な感じなのでしょうか。

何も考えないと「商品カテゴリテーブル」に主キーはないですよね、
[商品ID,カテゴリID]の組み合わせで一意になる制約はありますけど。
いや、それすら必要ないかな？

130 ：00：03/12/17 15:47 ID:???

ああ、なるほど。
だとしたらテーブル構成はこのままで良いのではないかな？

すっきりしたPKつけたいのなら、
「商品カテゴリテーブル」に、「枝番」をつけて、
「商品ID」「枝番」でPK、だよね。。

商品カテゴリテーブル
　-------+------------
　商品ID |枝番| カテゴリID
　11 　　　|01　| 10
　11 　　 |02　| 12

運用上問題なければ、PKなくても問題ない一例かもしれない。

131 ：NAME IS NULL：03/12/17 21:44 ID:???

>>130
「商品ID」「カテゴリID」でＰＫだろ？

132 ：NAME IS NULL：03/12/17 23:25 ID:???

>>128
>>130
なんか、とてつもなくダサダサな設計論を紹介しているように見えるんだが...。

133 ：NAME IS NULL：03/12/17 23:58 ID:???

>>132
眩暈を覚えるテーブル設計ですな。

134 ：NAME IS NULL：03/12/18 00:17 ID:???

>>129
商品とカテゴリは多：多でないの？

-----------------
「ごぼう」は、「根菜」である
「にんじん」は、「根菜」であり、「緑黄色野菜」である

-----------------
「根菜」は「ごぼう」と「にんじん」である
「緑黄色野菜」は「にんじん」である。

135 ：124：03/12/18 01:28 ID:oeMQRp8l

>>134
なるほどカテゴリ側から見れば多：多ですね。

設計の視点が間違っている予感はするのですが、
だからといってこの方向が良いって言える解が見つからなくて...
皆さんだったらどのように設計します？

136 ：00：03/12/18 08:34 ID:???

>>131-133
あ、ほんとだ
逝ってきま

137 ：NAME IS NULL：03/12/18 22:18 ID:???

>>135
ＲＤＢで多：多のリレーションを実現するために中間テーブルの
商品カテゴリテーブルを実装するのは全く無問題。

が、商品をカテゴリ分類する場合は商品の属するカテゴリは
１つだけにするのが普通でないの？

商品＞商品分類＞商品中分類＞商品大分類みたいに

138 ：NAME IS NULL：03/12/19 01:22 ID:ULu1+Dg6

>>135
連関エンティティ
http://www.google.com/search?sourceid=navclient&hl=ja&ie=UTF-8&oe=UTF-8&q=%E9%80%A3%E9%96%A2%E3%82%A8%E3%83%B3%E3%83%86%E3%82%A3%E3%83%86%E3%82%A3

139 ：124：03/12/19 22:31 ID:???

>>137,138
んー、普通の設計なんですね。
EJBコンテナとか使わないとエンティティ管理の実装がシンプルじゃないかもと
思ったので、違った視点が必要かなと思ったのでした。

# 商品＞商品分類＞商品中分類＞商品大分類ってなんか教科書的と言うかみかか的(w
# 商品のナビゲーションはカテゴリからが自然なので、様々なカテゴリから
# 商品にアクセスできた方が良いかも。

140 ：NAME IS NULL：03/12/19 22:40 ID:???

>>139
なんでＥＪＢの話が出てくるんだ？

141 ：NAME IS NULL：03/12/20 00:31 ID:tLfIozE0

>>140
DB設計の不味い部分を辞書クラス使って、SELECT文何十回も発行てな、
クールな設計する奴はいるぞ。

>>139
商品分類が旧世代の教科書的てなイメージを持つのは、馬鹿の証拠。
教科書は大切。
＞# 商品のナビゲーションはカテゴリからが自然なので、様々なカテゴリから
＞# 商品にアクセスできた方が良いかも。
問題は、する必要が有るのか？無いのか？それがシステム設計だ馬鹿。

142 ：NAME IS NULL：03/12/20 01:19 ID:tvcIIntn

うちの食卓テーブルはうまく設計されてますが
テーブル上には
腐ったみかんと食べ残しのカップ麺が散乱してます
ちなみ主キーは置いてありません
車のキーならたまに置きます

143 ：NAME IS NULL：03/12/20 04:53 ID:???

-------------+---------------
食卓テーブル | 腐ったみかん
+---------------
| 食べ残しのカップ麺1
+---------------
| 食べ残しのカップ麺2
+---------------
| 車のキー（たまに置く）
-------------+---------------

↑非正規形

あれ？「車のキーを時々置く」っていう場合は、
どういうテーブル設計にすればいいんだ？

144 ：143：03/12/20 04:55 ID:???

せっかく書いた図がぐちゃぐちゃに

145 ：NAME IS NULL：03/12/20 20:26 ID:???

>>141
クールな(=寒い）設計？

>>143

--------+---------+--------
食卓CD ｜　物品CD ｜　数量
--------+---------+--------
001　　　｜001　　　　｜ 3
001　　　｜002　　　　｜ 5
001　　　｜003　　　　｜ 1
001　　　｜004　　　　｜ 0

--------+--------
食卓CD ｜食卓名
--------+--------
001　　　｜うちの食卓

--------+--------
物品CD ｜物品名
--------+--------
001　　　｜食べ残しのｶｯﾌﾟ麺
002　　　｜腐ったみかん
003　　　｜車のキー
004　　　｜主キー

146 ：NAME IS NULL：03/12/21 00:54 ID:???

こういう場合、数量0っていうレコードを置くかどうか迷うよな。

147 ：NAME IS NULL：03/12/21 10:20 ID:???

食卓在庫品目
--------+--------
食卓CD ｜　物品CD
--------+---------
001　　　｜001
001　　　｜002
001　　　｜003
001　　　｜004

食卓在庫数
--------+---------+--------
食卓CD ｜　物品CD ｜　数量
--------+---------+--------
001　　　｜001　　　　｜ 3
001　　　｜002　　　　｜ 5
001　　　｜003　　　　｜ 1

JOINさせると「主キー」の数量がＮＵＬＬになっちまう。
ま、こんなＴＢＬ設計をする香具師は居ないが。

148 ：NAME IS NULL：03/12/21 11:11 ID:???

outer joinすりゃ、数量がNULLのレコードと0のレコードが混在し、
inner joinすりゃ、結果表に物品が現れない場合と数量0で現れる
場合とが混在する可能性があるから、「テーブルの上に存在しない」
ことをどっちの方法で表現するのか、きちっと決めとくべきだね。

149 ：NAME IS NULL：03/12/21 11:33 ID:jMVBpQ+5

NULLってSQLの中では無問題なんだが、プログラム中で扱うのは面倒だねえ。
日付型のフィールドなんかどうしてる？
漏れはNULLを使わずに日付最小値を入れて未入力としている厨な分けだが。ｗ

150 ：NAME IS NULL：03/12/23 23:35 ID:teG3e5jo

OracleはNULLの列を評価すると全てFalseになるんだけど、他の
DBMSはどうなの？

151 ：NAME IS NULL：03/12/23 23:50 ID:???

へ？
NULLを評価するとNULLじゃないの？ふつう。
3値論理だから、trueじゃないからといってfalseとは限らないんだが。

152 ：NAME IS NULL：03/12/24 17:21 ID:???

主キーが無いと正規化できないじゃん。

主キーがなくても問題ないといった香具師は今すぐ転職しろ。

153 ：NAME IS NULL：03/12/24 20:14 ID:???

>152
ネタだよ。きっとネタなんだよ。ありえねーもん。

154 ：NAME IS NULL：03/12/25 06:52 ID:???

>>152

「主キーがなくても問題ない」≠「明示的にプライマリーキーを設定しなくても問題ない」

155 ：NAME IS NULL：03/12/25 23:41 ID:qujOKXeg

>>152,154
「主キーが無いと正規化できない」＝「候補キーがないと正規化できない」

156 ：NAME IS NULL：04/01/06 01:14 ID:Y7tiwV5D

すいません、すごい初心者的な質問なんですが。

表Ａ

コード　　内容
-------------------
01 ＡＡＡ
02 ＢＢＢ
03 ＣＣＣ

表Ｂ

コード　　内容
-------------------
01 ＡＡＡ
03 ＣＣＣ

上記のような表があったとき、

コード　　内容
-------------------
02 ＢＢＢ

上記１行を出力したい場合、ＩＮとＥＸＩＳＴＳとＡＮＹ以外の問い合わせ
の仕方がありませんでしょうか？本当に初心者的な質問で申し訳ありません
が、お願いします。

157 ：156：04/01/06 01:15 ID:Y7tiwV5D

すいません、書き込み場所間違えました。
本当にすいません。

158 ：NAME IS NULL：04/01/06 18:43 ID:tMR0UX3m

郵便番号データって主キーを設定しないことが多くない？
郵政省が配布しているデータが
郵便番号と住所が1:1対応してないじゃん。

★意味の無い住所CDを全レコードに振る
か、
★郵便番号に枝番号を振れば
主キーの設定もできるけど。

郵政省以外に更新しない郵便番号データなんて、インデックスを振れば十分だと思うだけど。
参照しかしないし

159 ：NAME IS NULL：04/01/06 21:17 ID:???

あまいぞ158．やろうと思えば綺麗に階層構造とらせる事ができる＞郵便番号

160 ：159：04/01/06 21:21 ID:???

正確に言うと、「住所のほうを綺麗に階層構造とらせる事ができる」だった･･･
首吊ってくる

161 ：NAME IS NULL：04/01/07 01:03 ID:???

>>1
1年程前Oracleで全テーブルPrimary Keyなし＆indexもなしの
DB＋C/Sアプリ引継ぎさせられますた。。

最初アプリのレビューしてて
「やけにレスポンス悪いねー。VBだから？」
とか言っててOracleの中身見て吐血

162 ：161：04/01/07 01:07 ID:???

続き

当然Viewもストアドも一切使用してなかった。
もともと作ったのはロートルPGだったが、そいつに突っ込み入れたところ
「漏れは長年データベース組んでんだ。RDBMSつーのは云々...」
といいつつISAMのことを語ってくれました。

今思うとコボちゃんだったのかな...

163 ：NAME IS NULL：04/01/15 00:06 ID:h83lfTYG

indexなしはキツイな。。　PKなしはまー良いが。
サイズ小とかの理由でindex使われないこともあるが。
ストアドはパフォーマンス向上には寄与しないとおもふ。。

164 ：NAME IS NULL：04/01/15 00:19 ID:NrCWc0uY

インデックスやストアドが云々以前にちゃんと正規化してるんだろうな？
概念スキーマと外部スキーマの役割を区別して設計してるんだろうな？

165 ：NAME IS NULL：04/01/15 01:38 ID:h83lfTYG

正規化=机上の空論。

166 ：NAME IS NULL：04/01/15 01:43 ID:mutL718k

>>165
非正規形データはRDBMSに保存できませんが何か？

167 ：掃除屋：04/01/15 09:18 ID:NrCWc0uY

>>165
RDB設計の基礎知識であり必須作業である正規化すらできずに
人並みの仕事をしているつもりか？マヌケな野郎だ。
そうやって無駄に複雑なSQLでしかデータを取り出せない冗長性だらけで
現実のモデルとかけ離れたテーブル作って
周りに迷惑かけてろや。
どうせお前は現場でオラクルの使い方をかじっただけでデータベースの設計ができると
勘違いしちゃったクチだろ？
金槌の使い方を覚えただけで自分が建築技術者だと
言ってるようなものだ、恥ずかしい奴だな。
お前のような見込みのないシロートに業界に居座られると迷惑だ。

どうせソフ開すらもてないような奴なんだろ？資格は必要ないとかいってな。
そんな調子だからいつまでたっても自分の無知に気づかないんだよ。

168 ：NAME IS NULL：04/01/15 09:48 ID:jgmx8aMI

>>161-162
COBOLERはどこまでもCOBOLERだからな～。
COBOLER＝おじさん＝新しいものを取り込まない。

169 ：NAME IS NULL：04/01/21 19:17 ID:nARDT7b3

表本体には主キー無しというのは良くやるな､
でもアクセスパスを定義しまくって、
検索はスムーズにおこなえるようにしている。

170 ：仕様書：04/01/23 01:23 ID:CYawNWdo

あるよぉーーー　ＡＳ４００のＰＦでぇー

171 ：NAME IS NULL：04/01/23 20:40 ID:???

一部、参照するためだけに使われるテーブルには主キーをつけない
っていうテクニックはあるけれどそれ以外にはありえない。

っていうか、俺は過去に５つのテーブルが存在しリレーションすらはら
れておらずそれぞれが完結しているというとんでもないものを見かけた
ことがある。

それひとつひとつにフォームをあてているだけなので、結果としては、
単体のDBが５つあるのと同じ事になっている。アホだ

172 ：NAME IS NULL：04/01/23 22:46 ID:???

「リレーションはる」ってなんだよ...

173 ：NAME IS NULL：04/01/24 10:35 ID:???

まぁ、なんとなく言いたい事は分かる（ｗ
でも、DB５つもあってそれぞれにテーブル１個ずつでも
びっくりすると思う。

ってMS-Accessの話かな？

174 ：NAME IS NULL ：04/01/26 19:03 ID:???

┌┬┬┬┐
　　　　―――┴┴┴┴┴―――――、
　　/. ￣￣￣//.￣￣| ||￣￣￣|||￣ |｜　　　　＿＿＿＿＿＿＿＿＿＿
　　/.　　　∧// ∧ ∧| || 　　　||| 　 |｜　　／
　[/＿＿__(ﾟ_//[ ].ﾟДﾟ,,) ||＿＿＿||| 　 |｜＜　>>59を迎えに来ました
　||_.　*　＿|_|￣￣ ∪|.|. 　　　 |ヽ. _|｜　　＼＿＿＿＿＿＿＿＿＿＿
　lO|o―o|O゜.|二二東|.|京精神病院 ||
　| ∈口∋￣_l＿＿ｌ⌒ｌ_|＿＿＿__|_ｌ⌒ｌ_||
　　￣￣`ー'￣　　`ー'　 `ー'　　`ー'

175 ：NAME IS NULL ：04/01/26 19:03 ID:???

ずれた・・・＿|￣|○・・・

176 ：NAME IS NULL：04/01/26 21:51 ID:???

もう少し頑張りましょう。

177 ：NAME IS NULL：04/02/02 01:34 ID:sQ5PbkJp

>>170
AS/400だとよく見かけるね。

RPGでだけアクセスしてると別に何も感じないんだが、SQLでアクセスすると「なんで主キーがないんじゃー！！」って怒りたくなるのが不思議だｗ

178 ：NAME IS NULL ：04/02/03 14:40 ID:bgMlnR6c

マイクロソフトいわく・・・
「プライマリキーは、オートナンバーでも構わないので、作成しましょう」
とのこと。

179 ：NAME IS NULL：04/02/04 11:11 ID:6xEmbT4J

>>178
あたりまえ

180 ：いなむらきよし：04/02/07 11:49 ID:3tu0zbdS

キケー！

181 ：NAME IS NULL：04/02/08 01:00 ID:???

>178
MSSQLServerの話だろ。

182 ：NAME IS NULL：04/02/08 13:08 ID:???

>>174
遅いYO! ﾌﾟﾝﾌﾟﾝ

183 ：NAME IS NULL：04/02/13 14:08 ID:???

>>182
だからあれほど主キーを入れろといったのに

184 ：NAME IS NULL：04/02/15 19:09 ID:???

繰り返し項目を外に出したテーブルにも主キーが必要ですか？

185 ：NAME IS NULL：04/02/16 16:04 ID:???

>>184
繰り返し項目ってなに？
※おおりぢゃないよ

186 ：NAME IS NULL：04/02/16 22:59 ID:???

おおり（←何故か（ry

187 ：NAME IS NULL：04/02/17 02:21 ID:???

>>186のおかげで何のことかわかった

188 ：184：04/02/17 22:35 ID:???

>>185
「正規化　繰り返し項目」で検索すれば説明してるサイトがみつかるよ。

189 ：NAME IS NULL：04/02/24 01:34 ID:???

すでに答えは出ていたが、候補キーが必ずしも必須である必要はない。
プライマリーキーは「なぜか必須」になる。
正規化には候補キーは必要だが「プライマリーキー」である必要はない。

複数のカラムで候補キーとする場合、それらがすべて必須ってのはちょっと違う。

>>「プライマリキーは、オートナンバーでも構わないので、作成しましょう」

本末転倒だな。

190 ：NAME IS NULL：04/02/27 00:20 ID:9O5906Ix

>>189
おっしゃっていることが、よくわかりませんが・・・

191 ：NAME IS NULL：04/02/27 01:33 ID:???

データのローディング作業のために PK を外したまま、戻し忘れて1年くらい稼動というのはあったな。
別件で調べててそのDBのDBAとともにｶﾞｸﾌﾞﾙしました。

192 ：NAME IS NULL：04/03/03 01:36 ID:???

結合する必要のないテーブルなら
主キーはいらないんじゃないかな

193 ：NAME IS NULL：04/03/10 18:44 ID:???

>>192
もまい、ネ申..._〆(ﾟ▽ﾟ*)

194 ：NAME IS NULL：04/03/13 13:56 ID:???

主キーもインデックスも無いテーブルを見たことがある。
しかも数十万レコードもデータが入ってるし、、、
恐るべきことに、他にもそんなテーブルがごろごろしてて、それらが結合されてた・・・

195 ：NAME IS NULL：04/03/13 16:24 ID:/t1ODX8R

>194
パーティション化してあるから大丈夫

196 ：NAME IS NULL：04/03/13 16:37 ID:???

>>195
そんな機能があればよかったんだけどねえ・・・

197 ：NAME IS NULL：04/03/13 19:20 ID:I4l0yLx2

外部キーっつうの？参照制約がかかってないシステムなら現在進行中。

198 ：NAME IS NULL：04/03/13 23:25 ID:/t1ODX8R

>197
アプリで制御できるなら問題なし

199 ：NAME IS NULL：04/03/13 23:42 ID:???

>>198
ちゅーか、要件が歪んでて参照制約が掛けられないことも珍しくは無いと思う。

200 ：NAME IS NULL：04/03/14 02:21 ID:eItUSnYs

なんだー。参照制約ってその程度の重みなのか。
システムを構築する上での必須制約かと思ってたよ。

201 ：NAME IS NULL：04/03/14 13:03 ID:B4c9J9Pd

注文どおり動けば、主キーなんてあろうが無かろうが問題無いでしょ？

202 ：NAME IS NULL：04/03/14 15:27 ID:xe/2CQpY

>>1
主キーがなければ索引はどうするんだ。

203 ：NAME IS NULL：04/03/14 16:09 ID:eItUSnYs

使わないシステムなんだろ。
しかし、この板人すくねーな。たのしめねーよ。

204 ：NAME IS NULL：04/03/14 18:25 ID:???

>>203
この板自体が不要。

205 ：NAME IS NULL：04/03/15 02:05 ID:???

DBネタよりも使ってる人間のネタが多くってさぁ
でも、下手に晒すとバレそうだし・・・

206 ：NAME IS NULL：04/03/17 17:55 ID:Uhc3+ibk

>>202
アクセスパスを定義する。

207 ：NAME IS NULL：04/04/10 18:20 ID:0lCIHzGk

ユーザ名、パスワード、ユーザの漢字名を扱っているテーブル
・ユーザ名は英数で名.姓　
・パスワードはユーザ本人が自由変更できる

のようなテーブルの場合、主キーはどうすればいいの？

208 ：NAME IS NULL：04/04/10 18:25 ID:???

名前だけ必要なシステムってなんなんだ

209 ：NAME IS NULL：04/04/10 18:52 ID:???

>>207
ユーザID

210 ：NAME IS NULL：04/04/11 00:01 ID:???

同性同名だったらどうすんの。

211 ：NAME IS NULL：04/04/11 00:21 ID:19/IzA4K

>202
主キー : 論理
索引 : 物理

直交するものだから別にどうにでもなる

212 ：NAME IS NULL：04/04/13 10:28 ID:vsQHurnf

郵便番号データをmysqlに挿入してつかおうとしてるんだけど
主キー入れる必要がないような。。。

213 ：NAME IS NULL：04/04/13 10:48 ID:???

>>212
同じくｗ
郵便番号がユニークでないのを始めて知った。
通し番号を振っても、市町村合併が盛んだし、メンテが大変。
結局、参考程度にしかならないんだよね。

214 ：NAME IS NULL：04/04/13 20:58 ID:uWW+pR+n

>>212
郵便番号が重複してもいいなら別に主KEY設定する必要も無さそう。
まぁでも正規化の思想からは外れるわな。

215 ：NAME IS NULL：04/04/14 01:17 ID:???

IDとか、ユニークで静的なデータが無いレコードの場合って、主キーどうしてる？

216 ：NAME IS NULL：04/04/14 09:32 ID:???

削除フラグ、システム日付、システム時間、担当者コード、微妙に重複する整理番号
テーブルによっては整理番号の枝番号。

それでも重複する場合は必要に応じてキーを増やす。

。。。遅え＿|￣|○

217 ：NAME IS NULL：04/04/14 21:35 ID:???

>>212-214
レコードをupdateしないのか？
まあ、updateキーを元の住所
にすればいいけど、そうなると、住所がPKか．．．

218 ：213：04/04/15 00:26 ID:???

>>217
合併が起きると住所そのものが変わるし、追加/廃止になった郵便番号とか考えると、
updateで対処できる範疇を超えるかと。住所録テーブルとうまく郵便番号テーブルを
リレーションさせるのには漏れには無理。入力時の参考程度にしか出来ない。

実際csvで公開されている郵便番号簿をみるとゾッとするぞｗ。

219 ：212：04/04/15 16:44 ID:5tDhWOhP

>>217
updateはしないよ
１つづつ書き換えるのは面倒だから
公開されているcsvがバージョンUPしてたら
データを総入れ替えします。
通常つかうsql文は
select 住所 from table where 郵便番号='val'というvalの値しか変わらない
sql文のみです

220 ：NAME IS NULL：04/04/17 22:33 ID:???

>>219
変更前のデータであることを条件にしている場合はどうするの。
古い住所が必要なときもあるよ。

221 ：NAME IS NULL：04/04/20 15:11 ID:???

>>220
古い住所が必要なら旧住所レコードを用意しておくか、
遡る必要があるなら住所履歴マスタでも作りましょう。

222 ：sage：04/04/21 02:08 ID:E7N2wz6i

いっちゃいけないのかもしれないけど、きちんと正規化してＥＲ図書いて
プライマリキーとインデックス貼り付けるのがＤＢ設計の８割じゃない？
プライマリキーとインデックスないＤＢなんか考えられない
後は日時バッチ用の各容量見積もりとか
ロールバック領域足りなくて落ちた時は死にかけた

223 ：NAME IS NULL：04/04/21 11:21 ID:???

>>222
落ちたときの回復と
設計変更でテーブル切り直し->移行
で、DB運用の9割を占めるウチの職場はどーなるんだ orz

224 ：NAME IS NULL：04/04/22 17:49 ID:???

検索条件が様々になるテーブルって、
どのように設計したら効率がいいですか？
検索条件になるカラムにインデックス貼りまくる位しか
思いつかないんですが。。。

例えば（データの）入力日付が検索条件になる時って
トランザクションテーブルは連番を主キーにしないで、
入力日付を主キーにした方がいいんでしょうか？

225 ：NAME IS NULL：04/04/22 20:01 ID:???

>224
「様々な条件」をパターン化し、優先順位を付けて対応。
後半は意味不明。主キーとインデックスは違う物だ。

226 ：NAME IS NULL：04/04/22 20:49 ID:???

>>224
設計して失敗するのも人生だ。
まずは自分にわかりやすいように組んでみなはれ。

失敗が許されないような案件だったら丸投げした方がマシ。

この場合の「トランザクション」は一部の業界でしか通じない用語の
ような気もする(転職組の後輩が使ったとき、10分間意思疎通できんかった)が、

俺がよくやってる組み方では、
入力日時・連番を複合プライマリキーにする。
連番は単に、日時の粒度を割ったときにユニークにするためだけに用いる
ワケだ。

Sybaseでは、プライマリキーの処理は UNIQUE INDEX と変わらないので、
日時による絞り込みも、上記のやり方でそこそこうまく行く。
(逆に、連番による絞り込みでは、連番のみにもインデクス張らないと
順次スキャンに走ろうとする)

227 ：NAME IS NULL：04/04/23 10:26 ID:???

>>225 >>226
質問スレじゃないのにアドバイスありがとうございます。
昔やったシステムを今振り返って
「こうやったらもっと効率よかったかな」と復習してる所です。
妄想先走りの質問でわかりにくかったかもしれないですね。すまんす。

設計段階ではどの検索条件が一番使われるかわからないんですよね。
入力日、仕入れ日、商品コードとか。
教訓としては、主キーとして作った「連番」では検索してくれないってことですね。
作る側から言えば、主キーで検索してくれるのが一番ありがたいんですがｗ
ユーザーレビューのときに、「そっち使うのかよ！！」とか思ったし。

228 ：NAME IS NULL：04/04/29 01:52 ID:???

リレーションの意味ねーじゃん。

229 ：228：04/04/29 01:56 ID:???

同じ顧客を同じテーブルに入れるっつー間違いする可能性大だね。
まぁ客先が満足してるなら、それはそれで問題ないとは思うけど。

230 ：NAME IS NULL：04/04/29 03:38 ID:???

なんか事情があったんでしょ
そんなに責めるなって

231 ：NAME AS 名無しさん：04/06/06 15:31 ID:???

　なんだかテーブル設計する上での「行を一意に識別できる列の組」である主キー(候補キー)と
DBMS 上にその表を乗せるときに「この列の組を使うと行を一意に識別できますよ～」と
DBMS に教えてあげる CONSTRAINT PRIMARY KEY がごっちゃになっている人が
見える希ガス。

　テーブル設計時に、「最低限この列(の組)で確実にひとつの行を取り出せる」という
候補キーは通常必ず見つけ出すものでないのかな?
　で、この候補キーのひとつを DBMS に PRIMARY KEY ですよ～、と教えてあげるのは、
DBMS の機能次第で CONSTRAINT PRIMARY KEY としたり、古い MS-SQL なら
NOT NULL にした上で UNIQUE INDEX をつけてあげるなりすればいいと。

　>1 の担当者は、そもそも PRIMARY KEY 制約がなんなのかを分かってないみたいだから
設計時点から候補キーが無かったのかな。それなら DBMS にテーブルを作ったときに
主キー制約を入れられるはずも無いし、付けても適当につけてみるだけだから「データが
入れにくい」だのという考えになるわけで。

　ｊ３、DBMS はアプリからの更新要求に対して
　「重複データを作ってはいけないところを PRIMARY KEY 制約や UNIQUE INDEX で保護する」
　「NULL を許可しないところを NOT NULL 制約で保護する」
　「外部キーを参照する列(の組み)が無効にならないよう FOREIGN KEY 制約で保護する」
といった役目を果たすものなのに、アプリがこれらを防ぐようにがんばっているのは
　「高い金だして人を雇ったが、すべてお膳立てした上で一挙手一投足全部指定しないと
　　ぬるぽなことをするやつだ」
ってなかんじで高いおきゃねを払って DBMS を導入した意味がなくなるわね。
＃我ながら分かりづらい例え且つ長文なので sage る

232 ：NAME AS 名無しさん：04/06/06 15:43 ID:???

ちなみにうちには Access で、相手先の会社ごとに分割された mdb があって
フォームの mdb 側では各担当者の担当する会社ごとに動的にリンクテーブルを
設定するというナイスシステムがあり申す。何でも上司から「同じファイルに違う会社の
情報が入るのはセキュリティ上よろしくない云々」とか言われたとか。…何じゃそりゃ。

　みたところ主キーの設定されていないテーブルはちらほらと、参照制約はなし
(担当者いわく「参照制約つけると更新とか面倒に(ry」そもそもクエリエディタで
自動的に JOIN させるための設定と思っていたモヨン)
　また顧客への資料送付で「顧客が求めた資料」列に "a100,b200,c300" と資料IDが
カンマ区切りで…これって、アリ?
’長文の後なので sage

233 ：NAME IS NULL：04/06/17 04:20 ID:f8HScxEM

何気に良ｽﾚですね。age

234 ：NAME IS NULL：04/07/03 17:30 ID:Km1DPrcI

結局よくわかんないんだけど、
例えばオラクルで、
PRIMARYにするのとUNIQUE + NOT NULLでは、
何が違うの？

235 ：NAME IS NULL：04/07/03 20:19 ID:???

もしかして・・・PRIMARYの意味がわかってないのか？
ﾋｨｨ((((；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

236 ：NAME IS NULL：04/07/03 20:46 ID:???

動作は変わんないじゃん

237 ：NAME IS NULL：04/07/03 21:06 ID:???

外部キーはどうすんだよ

238 ：NAME IS NULL：04/07/03 22:08 ID:???

UNIQUEでも外部キーにできるよ

239 ：NAME IS NULL：04/07/04 02:57 ID:???

外部キー　に　って？

240 ：234：04/07/04 12:05 ID:???

なんだみんな知らないの？
実行プランが変わるくらいじゃない？

241 ：NAME IS NULL：04/07/04 13:45 ID:???

UNIQUEで複合主キーって実現できるのか？
外部キーの親である主キーの役割をUNIQUEとNOT NULLが果たすのか？

242 ：NAME IS NULL：04/07/04 13:46 ID:???

234って宿題他人にやらせようとしてるだけじゃねーの？
アホか

243 ：NAME IS NULL：04/07/04 14:52 ID:???

>241
複合のユニーク？できるよ。
ユニークを外部キーの親にも使える。

244 ：NAME IS NULL：04/07/05 00:23 ID:???

>235
PRIMARYの概念上の意味はともかく、
RDMS実装上、どう違うかわかってるか？

245 ：NAME IS NULL：04/07/05 00:57 ID:???

１テーブル一個までとか？
つか上の方にまったく同じ質問があるな

246 ：NAME IS NULL：04/07/05 16:10 ID:cp2QZHNA

>>1
動いてりゃいいんだよ

247 ：NAME IS NULL：04/07/07 11:04 ID:???

>>246
禿同
ただ、「主キー付けるとデータを入れにくくない？」
という理由はどうかと思うが・・・

248 ：NAME IS NULL：04/07/12 10:43 ID:???

excelにテーブル設計書書くとcreate tableつくってくれるマクロがついてる
一見便利なモノを渡されたのでそいつらの流儀に則って書いてみた
Primary key?[x]という項目があるので一意なカラムをチェックさせて、はき出させてガツガツ作成した
・
・
・
excelから出されたのは、ただのindex指定であったしかも not unique
嫌な予感がしたので、他のテーブルをみたら50以上テーブルが出来ていたが
一つもprimary keyなどなかった。

249 ：NAME IS NULL：04/07/19 14:12 ID:???

>248
よーく見てみよう。ほら、作った覚えの無い[PrimaryKey]というautoincrement型の列が端っこに…Σ(ﾟДﾟ；ｷｬｱｧｧｧｰｰｰｰｰｰ

250 ：NAME IS NULL：04/08/20 02:07 ID:???

うちのＤＢ、コストベースなのにアナライズやってねーぞ。

俺もびびった。

251 ：NAME IS NULL：04/08/22 04:20 ID:???

ユーザには絶対にいじらせないテーブルでいくつか主キーなしつくったことある。
ユニークであることは直接データを入れたこの俺が保証する。

252 ：NAME IS NULL：04/08/25 01:12 ID:???

データベースの制約を利用せずに、アプリケーションで事前チェックをするのは馬鹿げている、と言う人がいるけど
実際の UI を考えると、アプリケーションでの事前チェックは事実上必須だと思います。

・一意制約
アプリケーションでは、伝票番号などの主キーを入力して、すでに存在すれば
編集モード(編集後は update)、存在しなければ新規作成(編集後は insert) と
することも多いと思います。つまり、一意制約に頼らずにレコードの存在チェックはしている。

・NULL許可, 外部参照制約
アプリケーションでは、商品コードを入力したらその名称を表示します。
つまり、この時点で外部テーブルが参照できるか確認しているわけです。
そして、該当データが見つからなければアプリケーションとして再入力を促す。

つまり、使い勝手を考慮したアプリケーションでは、データ更新を試みる前に
ある程度のチェックを行うのは一般的だと思うわけです。

もちろん、アプリケーション以外の汎用的な操作ツールでデータ操作される可能性もあるので、
私は、ちゃんとデータベースの制約を設定していますけどね。

253 ：NAME IS NULL：04/08/25 01:41 ID:???

>252
DBの制約とアプリケーション上のチェックは基本的に層が違う。
一意制約の役目は存在チェックじゃないべさ。
外部参照制約に関しても同様。
データ層において、矛盾するデータが存在しないように縛るのが制約の役目。
制約に引っかかった場合に何をどうするかはビジネスロジック層の話。

254 ：252：04/08/25 11:13 ID:???

一意制約 = 存在チェックではないけれど、アプリケーションで存在チェックを
行って上手くハンドリングすることで、一意性が保たれるということ。

DB でできることを、わざわざアプリケーションでやる必要はない、という意見もあるけど、
「わざわざ」やっているわけではなくて、一般的な UI を考えたら、「おのずと」
アプリケーションでの事前チェックは必要になる。そして、アプリケーションによって
一意性は保たれる。一意制約違反が出てから、それをハンドリングするなんていう
アプリケーション実装は考えられない。

外部参照制約についてもそう。アプリケーションでディメンションにデータがあることを確認してから、
ファクトテーブルに更新する。これも「わざわざ」ではなく、画面にディメンションの内容を表示する
都合があるので、アプリケーションで参照確認を事前に行うのは当たり前。

なので、データベースの制約違反をアプリケーションでハンドリングする、
というのが私には違和感があります。私は制約違反はあくまでも例外系という
位置付けでエラーが発生すれば、その内容を直接エラーダイアログで表示、
確認後、アプリケーション終了、という手法をとっています。

255 ：NAME IS NULL：04/08/25 11:19 ID:???

主キー制約ｲﾗﾈって事？
何が言いたいのかﾜｶﾝﾈ

256 ：252：04/08/25 11:33 ID:???

いや、制約は必要です。データ保証、セーフティネットとして。
ただ、制約違反(例外発生通知)を積極的に利用したビジネスロジックの実装なんて
現実的ではないと思っただけです。

257 ：NAME IS NULL：04/08/25 11:55 ID:???

大量一括更新処理においてなら珍しくも何とも無いし、データベース用のフレームワークで
DBからの制約違反通知を利用してUIを持つアプリ組む例を見たことがあるし、
結局の所、それで工数が削減できるとか保守性が上がるとかなら積極的に使えばいいし
そうでなければ使わなければいいだけの話でぁ

258 ：NAME IS NULL：04/08/25 23:11 ID:???

>257
そうやね。どんな状況でも DB まかせ、アプリまかせではいかんということで、
DB の制約は最後の砦、アプリはできる範囲で、一件ずつなら面倒見れば
いいし、一括登録ならアプリの判断は DB, NW 共に負担大だから DB に
お任せとかと使い分ければ DB や他の資源にかかる負担も減るしレスポンスも
良くなってユーザも管理者もみんなﾆｺﾆｺだ。

259 ：NAME IS NULL：04/08/25 23:16 ID:???

　【恐怖】といえば、某プロジェクトで「Update処理は
Delete→再Insertでしる！」って言われたんだけど、そ
んなのってアリなの？
　そう言った先輩も、この点は激しく疑問に感じている
らしく、「俺だって、上から言われて仕方なくやってる
んだ。」と言っていました。

260 ：NAME IS NULL：04/08/25 23:57 ID:???

>>259
うーん、どうなんだろうね。場合によっては悪くないと思うけど。

たとえば、明細データが5行あってアプリケーションで 3行目を削除する。
そうすると、旧4行目の明細の行番号を3にして、旧5行目の明細の行番号を4にして、
と行番号の書き換えを行わないといけない。これを update で実装するくらいなら、
delete してから、アプリケーション上のデータ構造をもとに insert しなおした方が
分かりやすいんじゃないかな。もちろん、delete から insert までトランザクションに
なっているわけで。

>>259 は具体的に何が問題だと思っているの？

261 ：NAME IS NULL：04/08/26 00:09 ID:???

>>260 いや、いくらなんでもその例はないだろ。

262 ：259：04/08/26 00:14 ID:???

>>260
そうですか、場合によってはそういう手法もありなんですね。
ただ今回は、そういった明確な目的はなくコーディングの都合で
そうしてクレ。と言われただけなので、今はUpdateを使わないの
が主流なのかと疑問に感じた次第です。

263 ：NAME IS NULL：04/08/26 00:32 ID:???

"Updateを使わないのが主流なのか"

　　　　んなわけない

260の例も、んなわけない

264 ：NAME IS NULL：04/08/26 01:23 ID:???

>>260
後で空き番を詰めるのなら、最初から行番号なんて振る必要ないのではないか?
つーか、参照整合性制約と参照操作を使ったことあるのか?

265 ：NAME IS NULL：04/08/26 03:18 ID:???

更新する列を決めるのが面倒なときは、delete して insert したりする。

266 ：NAME IS NULL：04/08/26 09:26 ID:???

>260のやり方って、主流かどうかはともかく、良く見るけどおかしいの？
>264で連番不要の話がでているけど、それだと並びが保証されなくなるし、
伝票-明細形式でデータを持っているときに明細行をすべて削除する事が
参照整合性制約にひっかかる訳無いし。

267 ：NAME IS NULL：04/08/26 13:32 ID:cVgrzJDR

（・∀・）

268 ：NAME IS NULL：04/08/26 15:20 ID:w3jOjJTf

>>259
どういうシステムかしらんが
作り手としてすごく違和感を感じるだろうな

その仕様を指定されたとして

269 ：260：04/08/26 19:39 ID:ps/wA+nf

これって、恥ずかしい実装だったのか。
いままで、当たり前のように使ってたよ orz

良かったら、何が悪いのかもう少し教えてください。
(1) delete/insert の代わりに update 文を使えば問題ない
(2) 行番号を振りなおすこと自体がおかしい
(3) 行番号という列が存在すること自体がおかしい

270 ：264：04/08/26 19:57 ID:???

並びの保証なら連番詰める必要もない。が、明細データの一意性と
画面出力等を考慮すると、連番不要は少し暴論だったかもしれない。

整合参照性制約については、UPDATEの代わりにDATELE/INSERTを
行うと発想する人は、そういった制約を設ける習慣が無いような感じが
したということ。

UPDATE文一発で全行の連番を維持しつつ隙間を埋めるのは難しいけど、
ストアドもしくはホスト言語でループしながら空き番を詰めるのは難しくないだろ。

271 ：NAME IS NULL：04/08/26 20:24 ID:???

行番号を詰める必要性って何？
並びの保障なら空き番あっても関係ないよね。
そもそも、行番号って主キーの一部になってない？
トランザクションの主キーを後で変更するのって
すごい違和感があるんだけど・・・

272 ：NAME IS NULL：04/08/26 20:48 ID:???

行番号が必要なら、サブクエリで数えて入れていけばいいかと。
10000行の１行目を削ったからといって9999行をdeleteしてinsert
なんかしてたら遅くてしょうがないし。

260のやりかたは行ロックのトランザクションおかしくならんか？

273 ：260：04/08/26 21:10 ID:ps/wA+nf

>>271 さっき出した例は削除で詰める例ですが、挿入で行番号を
増加方向へ振りなおさないといけないこともあるんです。
1. 商品A
2. 商品B
とあるときに、商品A のオプション商品や取り付け費用(商品扱い)を
追加した場合、伝票に印字の都合で、
1. 商品A
2. 商品Aオプション
3. 商品B
としたりすることもあります。このような要件を考えると、アプリケーションでの
操作時にデータベースのデータ構造も揃えたほうが分かりやすいと思うのですが･･･。

>>272
書き換えるのは行番号だけじゃないですよ？商品コードなども全部ずらさないといけません。
やはり、アプリケーションで持っているデータ構造を利用したほうが楽だと思ってしまうのですが。
伝票の話をしているのに、10000行というのも非現実的な話ですね。そんなことを
言いだしたら、サーバーカーソルをクライアントで使用することなんてできなくなってしまいますよ？

ロックについても問題ないと思います。READUNCOMMITTED 以下でなければ、
他のトランザクションからは読み取られませんから、ロックに関しては、
update と同等だと思っています。

･･･あまり納得のいく説明をしてくれる人がいないので、
今後もこの方法を使おうと思います。

274 ：264：04/08/26 21:18 ID:???

>>273
>商品コードなども全部ずらさないといけません。

ん? なんか話が飛躍しているような気が?
商品コードなどを差し替えるのなら、DELETE/INSERTが正しいと思うが、
>>260を読む限りにおいて、3行目を削除して行番号を詰めるのに、
商品コードをずらす必要性がﾜｶﾗﾝ。単純に行番号4と5を3と4に
書き換えるだけじゃないのか?

275 ：260：04/08/26 21:20 ID:ps/wA+nf

あー、そうですね。勘違いしました。行番号の振り付けだけで大丈夫です。
でも、これって事後振り付けですよね？削除して詰めることはできるけど、
挿入して増加方向に振りなおすことはできないと思います。

276 ：264：04/08/26 21:27 ID:???

>>275
>挿入して増加方向に振りなおすことはできないと思います。

行番号1-5まで挿入済みとして、そこへ新たに3行目を追加して、旧3行目以降をずらすってこと?
挿入する前に、UPDATE table SET rownum=rownum+1 WHERE rownum>=3;
としておいて、新たに3行目を挿入すれば済む話じゃないのか?
俺は勘違いしているのだろうか?

277 ：260：04/08/26 21:42 ID:???

age まくっててすみませんでした。

>>276 その方法は複雑すぎます。
1, 2, 3, 4, 5, 6, 7 とあって, 2と3の間、4と5の間、6と7の間に挿入。
3と7は削除、このような複数の操作をアプリケーション画面で行った場合、
うまくいきますか？

>>271
> トランザクションの主キーを後で変更するのってすごい違和感があるんだけど・・・

「トランザクション」って伝票明細のことを言っているんですか？
私のいままで仕事してきたところでは、
・固定的なマスターテーブルに対して、トラン(変化)データ, トランテーブルと呼ぶ。
・実績データ、実績テーブルと呼ぶ。
・(たぶんOLAPかぶれがいたからだと思うけど)ファクトテーブルと呼ぶ。
というのがありましたが、トランザクションと呼ぶのは初めて聞きました。
最小処理単位のトランザクションと紛らわしくないですか？

278 ：NAME IS NULL：04/08/26 22:14 ID:???

>>260
規約にする真意はわからんが、楽するために使うことはあるな。
既存行があればupdate、なければinsertとする必要がある場合、
key値でdelete→insertとか。

279 ：264：04/08/26 22:29 ID:???

>>277
複雑っていわれりゃそれまでだけど、連番に複数の穴を開けるのは
1行のSQL文でできるし、挿入そのものは1行分ずつでしょ。
削除後に複数の隙間を無くす方がさらに面倒だったりするが、
ストアドを定義してでもUPDATE処理するよう心がけるがな。

280 ：NAME IS NULL：04/08/26 22:30 ID:???

現行(9あたりから?)なOracleの人はupsertで解決してるの？

281 ：260：04/08/26 22:58 ID:???

>>279
うーん、なんか話が食い違ってるようですね…。
複雑なのはクエリではなく手順なんですよ。

delete 伝票明細 where 伝票番号 = X and 伝票行番号 in (3, 4, 5) みたいに
ひとつのクエリで複数の穴をあけられるのは分かりますよ。でも、3, 4, 5 という
穴をあける位置はどうやって覚えておくんですか？

画面ではユーザーの操作によって、明細を表示しているグリッドコントロールの
表示は都度変わっていきます。(削除行はグリッドコントロールに存在しない)
操作のたびに、操作シーケンスを記録して最後にクエリを組み立てますか？
それとも、操作のたびにクエリをサーバーに投げますか？さすがに都度クエリを
投げることはできないですよね。排他ロックがかかってしまうから。

そういうことを考えていくと、最終的に画面に表示されているグリッドコントロールを
元に delete/insert したほうが分かりやすいと思うんです。
ストアドでできるとか言ってますけど、与えるパラメータを準備するのも大変ですよ？

なんか話を聞いていると典型的データベース管理者って感じがします。
フロントエンドのアプリケーション実装の都合をまったく考えていないというか…。

282 ：264：04/08/26 23:31 ID:???

>>281
食い違っていそうなのと、誤解が生じしているのと、考え方が違いそうです。
で、違う点を書きかけたんだけど、止めましたｗ

ま、お互いのやり方でがんばりまひょ。

283 ：NAME IS NULL：04/08/26 23:46 ID:???

>>281 その方式だと、他の人が同時に同じ操作をすると、「最終的に表示されてる画面」を
両者が得ることはありえないような気がしますが。

まあ５行ならなんでもいいと思いますが。それこそtruncateして全部insertしても。

284 ：260：04/08/26 23:48 ID:???

>>282 できたら説明して欲しいんですが…。delete/insert に比べて
update派のほうが圧倒的に多いし、「お互いのやり方で…」ということではなく
「delete/insert ではまずい」という論調が多いようです。

どちらが、スマートに分かり易く記述できるか？という問題であれば、「お互いのやり方で…」という
締め方でもいいんですが、「delete/insert ではまずい」という論調で語られたまま、
放置されるというのはツライものがあります。

私だけでなく、delete/insert を使っている少数派の人は、
「update でもできる」という方法を聞きたいのではなく、「delete/insert では
こういう問題点がある」というのを聞きたいのだと思います。

285 ：260：04/08/26 23:55 ID:???

>>283 私のところでは「編集呼び出し」と言っているのですが、伝票の編集時には
更新ロックを獲得するようにしていますから(普通しますよね？)、同時に他の人が
同じ伝票を開くということはできません。もちろん、UI トランザクション中に
データの更新をすることはありませんから(最後にバッチ更新)、参照系業務が
ロックされることはありません。

> それこそtruncateして全部insertしても。
いや、さすがにそれはまずいっしょ。他の伝票消えちゃうし、トランザクションにできないし(w

286 ：NAME IS NULL：04/08/27 00:59 ID:???

>>285 そういう操作だと、編集用のテーブルにデータをコピーして
編集操作は毎回クエリを投げて（っていうかブラウザでやるし）
最後に戻す・・って感じでつくるかな。
それだと、最後にまとめてdelete/insertになりますね。
行番号の必要性はいまいちわからないけど。
ころころ変わるんだからプライマリキーじゃないだろうし、
それで編集なんかしていいのか？　みたいな。
プライマリキーあるならそれ使えばいいじゃん。ぐらいな。

たぶん、行番号の話でなんか混乱が生じてるんだと思います。
DB操作って100万行ぐらいよくあるし、「え～ずらすの～！」
みたいな～。そういう感覚がしみついてるから、抵抗を覚える
んだと思いますよ。

287 ：NAME IS NULL：04/08/27 01:12 ID:???

DBって結局のとこDISKが一番重いのであんまりデータ動かしたくないんだな。
delete/insertすると書き換えないとこのindexまで更新するので重いし。
ネットワークのトラフィックも食うし。JDBCのデータのパースも時間かかる。
必要なとこだけ書き換えたいのが人情。

288 ：266：04/08/27 01:24 ID:???

規模による違いなのかな。
多数クライアントからガンガン更新かかるようなシステムだとそのへんも気にしなきゃいけない？
おいらのところはせいぜいクライアント10以下の小規模なシステムばっかなので>260の手法には
違和感は感じないな。

289 ：264：04/08/27 01:45 ID:???

あ、まだ続いていた。。。
とりあえず、今回260さんが挙げている例では、

被参照カラムがない。
一旦commitされたデータでも主キー(もしくはその一部)を変更しても問題が無い。
一度の更新する行数が少ない。

という条件があり、一つでも欠けるとdelete/insertでは拙いと思う。
"仮"に、今後赤伝処理にて、既存の発行済み伝票を参照するようにした場合、
dalete/insertでは参照操作(CASCADE)等が出来ない。
もちろん、赤伝を発行するような時点では、もとの伝票を修正するようなことには
ならないと思う。ま、仮定の話に過ぎない。

#あと、何気に思うのだが、一度commitされて他所から参照可能になったデータが
#後から順序変更が起きたり、データが削除されて番号が詰まったりしていると、
#データの信憑性低下が起きないかな? もちろん案件やクライアントの要望で、
#絶対ダメなんてことはないのですが。

最初の論点に戻ると、「updateの代わりにdelete/insertで済ます」というのは
ある条件下で許せるテクニックかもしれませんが、「updateが面倒なので
dalete/insertで済ます」というのは、「そりゃ拙くないか!?」と思う。

#一応仕事中、明日は朝から出張。帰宅後爆睡予定なので、
#さらにレスを求められてもしばらくは来れません。

290 ：260：04/08/27 07:20 ID:???

> DBって結局のとこDISKが一番重いのであんまりデータ動かしたくないんだな。
> delete/insertすると書き換えないとこのindexまで更新するので重いし。

OLTP ですよ？そんな大量データが一括で書き換わる例じゃないし。
OLAPじゃないんだから、テーブル充填率100%になんて設定しません。
この程度の明細追加がパフォーマンス低下を引き起こすデータベースってなんですか？

>>289
> 被参照カラムがない。
> 一旦commitされたデータでも主キー(もしくはその一部)を変更しても問題が無い。
> 一度の更新する行数が少ない。

もちろん、そうですね。それで「場合による」と前置きしたうえで、
参照整合性違反の発生しない伝票明細の例を出したんですが…。

このスレの流れは、実務実装の話が聞けてためになりますね。
赤伝の話が出てますけど、赤伝なんてシステムとして実装しますか？
訂正伝票から旧伝票への参照を持つような実装をすることがあるんでしょうか？
わたしのところでは、基本的に請求更新までは伝票修正可能としています。
発行済み伝票であっても修正できます。(画面に発行済み伝票を破棄するよう表示される)

請求更新済みであったり、発行伝票がすでに顧客に渡っている場合は、
システム化されていない勝手に赤伝で対応します。勝手に赤伝とは、
通常の入力処理で、マイナスを入力するだけです。

赤伝ってオフコン時代の発想ですよね？入力伝票を訂正できないから、
マイナス打って、プラス打って、計3枚の伝票を作るという…。
システム化前の手書き伝票時代は、伝票を破って書き直すということもできたはずだから、
赤伝が基本運用に含まれているシステムは、手書き運用にすら劣っていると思っています。

291 ：NAME IS NULL：04/08/27 10:21 ID:???

「updateの代わりにdelete/insertで済ます」というのは、
DB操作ログをトリガーで残しているときに
実操作は編集なのに、ログには削除/追加で残ってしまうという欠点が存在する

しかし、プログラミングでupdate処理はめんどくさい。
伝票NOでdeleteして、伝票全行削除したあとにグリッド上の伝票をInsertするほうが楽だなぁ

292 ：NAME IS NULL：04/08/27 11:33 ID:???

>>290
>赤伝ってオフコン時代の発想ですよね？
会計を勉強してこい。

293 ：NAME IS NULL：04/08/27 12:26 ID:???

>>292
ちゃんと文脈読んだほうがいいぞ

294 ：NAME IS NULL：04/08/27 12:28 ID:???

ユーザに見せない明細管理番号PK
（シーケンスNo、連番でなくてもいい）と、
ユーザに見せる行番号カラムをつくって
update、insertの条件をPKで行い、
確定(290でいう伝票発行時）前は
画面上ではAPで動的に連番を作成して見せて
確定時に行番号を連番でDBに記録
ようにするだけでいいじゃん。

確定後の変更（顧客に渡る前に
入力ミス等が発覚した場合）
も管理番号をキーに
変更後の明細行連番データを
updateして振り直すだけ。

295 ：294：04/08/27 12:50 ID:???

ごめん
s/update、insertの条件をPKで行い
/update、deleteの条件をPKで行い

ちなみにモデルとしては
伝票ヘッダーテーブル
　伝票番号　PK

伝票明細テーブル
　明細管理番号　PK（シーケンスNo）
　伝票番号　FK-伝票ヘッダー.伝票番号
　明細行番号

伝票番号,明細番号でユニーク制約（インデックス）

296 ：294：04/08/27 12:52 ID:???

またまたごめん
伝票番号,明細番号でユニーク制約（インデックス）
は、付けたらダメだったね。

297 ：NAME IS NULL：04/08/27 12:53 ID:???

>>294
おいおい、それは自然キーの代わりに人工キーを用意しただけだろ。
それじゃあ、updateの複雑さほとんど軽減されないぞ？

298 ：294：04/08/27 12:59 ID:???

>>297
ロジック考えてみろよ。
オーバーヘッドは軽減されるじゃん。
確定時に明細行番を上から順に
振り直すだけだろうが。

299 ：NAME IS NULL：04/08/27 21:16 ID:???

>>298 お前あたま大丈夫か？
問題全然分かってないだろ？

300 ：260：04/08/27 22:44 ID:???

>>294 えーっと、なんて言ったらいいんだろう…。人工キー付けても
煩雑さは解消されないんですよ。それどころか、その方法だと
一意制約が失われてしまうという大きなデメリットがあります。

それに、>>294 で言っているのは「updateでもできる」ということで
あって、「delete/insertの問題点」については言及してないですね。
スキーマを崩してまで update にこだわる理由はなんなんでしょうか？

301 ：NAME IS NULL：04/08/28 00:48 ID:???

>>300
updateにこだわるというわけでなく、
あくまでも連番っていう仕様なら、>>286の様に
確定まで（さらに確定後も）ころころ変わるデータを
キーに持つより、例え人工キーでも確定されたデータ
をキーに作った方がレコードが扱いやすいと思ったまで。

伝票番号+連番がユニークでなくなるのと
トレードオフになるけど、確定までは仮の行番号の
意味合いであるし、極論、確定までは行番号は
無くてもいいわけだから、PK（ユニーク）にできない
という考え方もありじゃない？
ちなみに確定処理っていうのは、
伝票にこれ以上入力することがなく、
入力完了の処理であり、更新処理とは違う
（解っているとは思うけど）。

結果データだけみればdelete/insertもupdateも
同じだけど、既存データを書き換える
のであればupdateの方がdelete/insertより
余計な処理=オーバヘッドがないと思う。
まあ、そんなもんだけど。

あと、プログラマが考える範囲ではないが、
deleteされたデータ領域は、
最適化されるまで使用できない。
その為、常に編集時にdelete/insertを行う様な
仕様では、倍以上のデータ領域のコストがかかる。

言いたいことはこれだけ。これからは
後のカキコを参考にするよ。

302 ：NAME IS NULL：04/08/28 01:12 ID:???

ごめん、あともう一つ。
明細テーブルにおいて、
さらに子のテーブルがある場合
（分納可能な発送データテーブル等）
は、行番をキーにしてしまうと、
注文挿入による行番変更時
は大変だよね。
入力忘れでどうしても同じ伝票にしたい
ということもあるはず。

そういう場合に、常に不変な明細管理番号が
キーであれば、明細テーブルの行番を
直すだけで済む。

303 ：NAME IS NULL：04/08/28 01:21 ID:???

>>301
Postgresしか知らないの？実装はいろいろあるよ。

304 ：NAME IS NULL：04/08/28 01:55 ID:???

>>301
主旨から外れた所の突っ込みですみませんが一応。、
postgresの場合、UPDATEでも
領域は圧迫しますんです。
内部ではUPDATE前のデータを無効にして
UPDATE後のを新規データとして突っ込んでるんで。
無効データを掃除するのにVACUUMを使う。
豆知識。

305 ：NAME IS NULL：04/08/28 01:57 ID:???

Delete文でも領域が開放されず、
テーブル（スペース）の最適化が必要なのは
Oracle(Alter Tablespace)だろうが
MSSQL、Sybase(DBCC)だろうが
同じじゃないの？

306 ：NAME IS NULL：04/08/28 02:02 ID:???

あと、プログラマも一応領域とかBツリーとか
諸々DBの特性の事をちょっとでも考えて頂けると
大変有りがたい。

もう本番稼動後のレスポンス対策係はいやなんじゃー。

307 ：NAME IS NULL：04/08/28 02:07 ID:???

あっ、他の人が間に。
304=306です。

俺はPostgresとOracleしかやっとりませんが、
共にDeleteじゃ表領域は解放されません。
ただ、領域の確保はテーブル単位で行うから、
他のテーブルのデータに使用出来ないってだけで
Delete対象のテーブルへの新規データ追加だったら
領域を使いまわしてくれるんじゃなかったかな。
違ったらごめんなさいな。

308 ：NAME IS NULL：04/08/28 02:30 ID:???

>>307
oracle、MSSQL、sybase、DB2
で使い回しは、最適化以外
使われないはずだけど．．．
>他のテーブルのデータに使用出来ないってだけで
>Delete対象のテーブルへの新規データ追加だったら
>領域を使いまわしてくれるんじゃなかったかな。
それは初めて聞いたよ。ソースどこ？

あと、oracleの場合、truncate ～reuse;で
出来るはずだけど、delete文では解放されない。

postgresは知らないけど、updateについては
上記のDBMSはその領域に上書きされるはず。

まあ、誰がいっしょでもいいけど
301=305だよ。
>>303の実装方法って具体的に何なのか？

309 ：307：04/08/28 03:12 ID:???

>>308
すんません、表現が不適切でした。
表領域内で、エクステントを確保したり解放したり、が正しいですね。

エクステントはテーブル毎に持ってる訳で、
A表で大量にデータをDeleteしても
A表用に確保済みのエクステント内で空き領域が増えるだけで
B表がそのエクステントの空きを使うことは出来ない。

てな事が、DBマガジンの別冊の
『Oracleデータベース管理演習ガイド』に
コラムとして載ってました。

だから裏返せば、A表なら使える、と読んだんですが。
当然のごとくそう思ったんですが認識違ったかしらん。
うーん。

何せ買ったの3年も前なんで今あせって読み返して
当該箇所やっと見つけましたよ。

で、UPDATEの件はPostgresの特長で、
最初に聞いたときはもうべっくらこきました。
まめにVACUUMせんとすぐパンクするらしいです。
商用のPowergresでは、常時監視して自動で掃除するそうですが。

310 ：307：04/08/28 03:23 ID:???

あ、あと、TRUNCATE は確かにエクステント解放するけど、
REUSE を付けると読んで字のごとくエクステントをre-useするために
解放しないでとっておくはず。

311 ：NAME IS NULL：04/08/28 04:10 ID:???

>>309
> だから裏返せば、A表なら使える、と読んだんですが。
> 当然のごとくそう思ったんですが認識違ったかしらん。

正しいと思うよ。

Oracleの場合、
INSERT にはフリーリストに登録されているデータベースブロックが使用される。
データブロックの空きが PCTFREE を切るとフリーリストから除かれ、
又、更新や削除で使用量が PCTUSED を切ると再び FREELIST に登録され
INSERT 出来るようになる。

312 ：264：04/08/28 06:46 ID:???

>>290
書き方が悪かったかもしれないが論点がずれてる。
赤伝を持ち出したのは、delete/insertを行うテーブルが
未来永劫被参照テーブルになる仕様変更を受け付けないことを
言いたかっただけなのに。

>>300
>それに、>>294 で言っているのは「updateでもできる」ということで
>あって、「delete/insertの問題点」については言及してないですね。

私は>>289で問題点を挙げているのに、赤伝システムに対する追求。
要点をまとめなかった落ち度はあるかもしれないが、なんか逃げてませんか?

もう、おなかいっぱいです。

313 ：264：04/08/28 06:58 ID:???

PostgreSQLのUPDATE処理で上書きされず新しい行が追加されるのは
MVCCとシリアライザブルなトランザクション分離レベル実現の為じゃないかな。
このあたりは同機能を実現するほかのRDBMSでも同じだと思うのだけど。

ただ、PostgreSQLではVACUUMを実行しないと領域が再利用されないけど、
RDBMSによっては、自動で開放されるかどうかの違いかな。

314 ：260：04/08/28 10:41 ID:???

なんか良スレの予感じゃないですか。

> 私は>>289で問題点を挙げているのに、赤伝システムに対する追求。

>>289 で、あげてくれているのは「問題点」ではなく、
delete/insert が使用できる「条件」にすぎないですね。
delete/insert が使用可能な条件下において、delete/insert を使うことに
ついては、「拙い」と言っているだけなので問題点を指摘しているとは言えないと思います。

それと、「楽するために使用するのは拙い」とおっしゃってますが、楽をしようとするのは
むしろ良いことではないですか？楽できる場面で、update にこだわって煩雑な
アプリケーション処理をするのは良くないと思います。バグを作りこんでしまう
可能性も高くなるでしょうし。私からすると、実装効率を無視してデータベース論だけで
update に執着するほうが「拙い」と思います。

それと、赤伝については、独立したトピックとして興味を持っただけです。
通常の仕組みを利用してただマイナスを入力するだけじゃダメなのかな？って。
元伝へのチェーンを持たせる意図は？って。元伝へのチェーンを持たせる実装を
したことがないものですから。

315 ：U ◆CZtFsGiu0c ：04/08/28 15:26 ID:???

削除や更新で空いた領域を再利用しないRDBMSが存在するなんて知りませんでした。
＃Postgresは使ったことないですが、使うときは気をつけよう

最適化が必要なのは、たとえ再利用されてもページ内に再利用しきれない領域がボコボコ
できたり、ページの配置がバラバラになったりしてディスクのアクセス効率が悪くなるのを
解消するためですね。

316 ：NAME IS NULL：04/08/28 17:41 ID:???

>>315
>削除や更新で空いた領域を再利用しない
>RDBMSが存在するなんて知りませんでした。
だから、更新はともかく、削除についてはどんな
DBMS（メインフレームであろうが）
においても、データ連続性維持の為、それが
普通の動きなんだよ。

oracleの場合も基本的にはそういう動きをしていて、
領域の使用率がPCTUSEDの設定値以下になったら
delete領域を使用するということ。
ただし、そのような状態なったら最適化させた方が良い。

317 ：NAME IS NULL：04/08/28 18:39 ID:???

MSSQLは自動で最適化するみたいだ、さらに手動でも可能。
その辺りについてはoracleよりは優位性がありそうだ。
ttp://www.microsoft.com/japan/sql/evaluation/compare/prk/vsOracle4_2.asp

318 ：U ◆CZtFsGiu0c ：04/08/29 11:57 ID:???

>>316
なるほどね。Oracleは体系的に学習したことがないのでためになります。
でも>>260で例に挙げられているようなシステムであれば、削除領域の再利用が頻繁に
行われていることが予想されますね。もっともRDBMSが何を使っているか、ということは
特に限定されてないけど。

>>317
まあ、それはMicrosoftの文書なので割り引いて考えたほうがいいでしょう。SQLServerは
パラメータの調整などなんでも自動で実行する方向だけど、それもメリットとデメリットが
あるわけだから。

319 ：NAME IS NULL：04/08/29 17:13 ID:???

>317
自動と言えば聞こえはいいが、別の見方をすれば「設定不能」だったりｗ
管理者不在の小さめのシステムなら願ったり叶ったりなんだけどね。

320 ：NAME IS NULL：04/09/08 23:52 ID:OdGTWVcO

ここのグループウェア試したんですよ。
http://groupws.huu.jp/

そしたら、入れたはずのデータが消える。

おかしいな？と思ってデータベースみたら、
Accrssのテーブルで作られてて、全てのフィールドが「テキスト」（ﾟдﾟ）ﾎﾟｶｰﾝ

その上、画面上でID番号に振られてる項目が、ユーザー側で勝手にいじれちゃう。
その上主キーも無い。

これじゃデータが消える（画面上に出ない）はずだわ。
作者に指摘しても、返事も無し。

こんなんでお金とってていいのでしょうか？
（私はもちろん払ってないが）

321 ：NAME IS NULL：04/09/12 19:30:00 ID:yiGiGN7P

>>320
あんたが被害にあってるわけじゃないし別ににいんじゃないの
と見も蓋も無いことを言ってみる

322 ：NAME IS NULL：04/09/24 00:43:47 ID:/b7cPd/w

>>314

> それと、赤伝については、独立したトピックとして興味を持っただけです。
> 通常の仕組みを利用してただマイナスを入力するだけじゃダメなのかな？って。
> 元伝へのチェーンを持たせる意図は？って。元伝へのチェーンを持たせる実装を
> したことがないものですから。

電子帳簿保存法に対応するためには、一つの伝票がどのような変遷をたどったかというのを把握出来ないとならんのですよ。
そこまで必要なくても、「どのように訂正をしたのかをきちんと履歴管理をしたい」という要求もあるのだよ。
#でないと悪さをする人がいるという理由でね。

>>290
たまたま君が見たオフコンのシステムがそうなっていたと言うだけですね。
むかーしのDOSベースのシステムで手入力で赤黒を起こしていたのもあるし、自動でやってくれていた物もある。
オフコンでも手入力で赤黒起こしていた物もあるし、自動でやってくれていた物もある。
webインターフェイスのシステムで手入力で以下略

つまり、そのシステムの実装要求によって違ってくるんだよ。

323 ：NAME IS NULL：04/09/24 13:40:39 ID:???

> 電子帳簿保存法に対応するためには、一つの伝票がどのような
> 変遷をたどったかというのを把握出来ないとならんのですよ。

あなた、知ったか君ですか？赤伝を起こすということは元伝は生きているということですよ。
赤伝は元伝の訂正でも削除でもありません。黒伝,赤伝,黒伝の 3伝票がすべて生きていて、
結果として数字が合うようになっています。3枚の伝票はいずれも訂正・削除はされていないので
電子帳簿保存法の「訂正削除の履歴の確保」要件はなんら関係ありません。

また、納品書が顧客に渡っていなければ破りすてて伝票修正をすればいい、という話が出ていましたが、
これも電子帳簿保存法では(ほとんど)問題になりません。電子帳簿保存法では特例として
1週間以内の訂正・削除は履歴を残さなくても良い、としています。

324 ：NAME IS NULL：04/09/24 14:51:43 ID:WB0oCa9D

>>323
>あなた、知ったか君ですか？
はい、そうです。

って返せば満足？
間違ってるなら「間違ってますよ」と言ってくれればいいのに、なんでこう噛みつくのか。
とりあえず、教えてくれた事にはさんきゅう。

でももちょっと実装例にも注意しようね。
訂正削除を「赤黒処理」で実装するシステムもあるのだよ。
ていうか目の前にあるパッケージがそうなっているのだが。

325 ：NAME IS NULL：04/09/24 14:55:20 ID:WB0oCa9D

>>323
324でつ
ごめん、もう一つ。
>特例として 1週間以内の訂正・削除は履歴を残さなくても良い、としています。
これ、どこかにソースある？
いま、電子帳簿保存法関係でもめてるので、出来れば情報がほしい。

326 ：NAME IS NULL：04/09/24 15:29:33 ID:???

訂正履歴を残す実装を慣用的に「赤黒処理」と呼ぶ事はありますね。確かに。

ただ、「元伝票」「赤伝票」「黒伝票」といった言葉をタイトに考えると
>323が正しい。訂正でも削除でもない。
ちゃんと仕訳日記帳にも補助元帳にも載ります。

だから「赤黒処理」ってのを「履歴を残す処理」ってのに使うのは
私はあまり好きではありません。
せいぜいユーザーに「赤黒みたいにうんぬん」って説明するくらい。

にしてもいきなり知ったか君はきっついなあ。

327 ：NAME IS NULL：04/09/24 15:33:15 ID:???

叩き煽りがヤなら2ch来ないほうがいいぞ。

328 ：NAME IS NULL：04/09/24 16:46:59 ID:???

あっそうか。

329 ：NAME IS NULL：04/09/24 17:14:23 ID:WB0oCa9D

>>326
フォローサンクス。

たしかに「赤黒処理」と「(例えば)伝票の打ちミスを直すための修正」ってのは本来別の扱いであり、処理を分けるのがベストなのは確かです。
なんですけど、
＞せいぜいユーザーに「赤黒みたいにうんぬん」って説明するくらい。
ユーザーに「赤黒処理」と「修正」の時のオペレーションを分けるて覚えてもらう。というのがなかなかねぇ。
かえってトラブルになっちゃったこともあってさ。

「必ず赤いれてから黒入れます！」と宣言して、その通りやってるユーザは今までで一件かな。
そこは「だから修正モードはずしてください！」という気合いの入れようだったがｗ

>>327
合点承知

330 ：NAME IS NULL：04/09/24 17:53:11 ID:???

アッコちゃ～ん
アッコちゃ～ん
主キー主キー

331 ：NAME IS NULL：04/09/24 18:14:04 ID:???

> >特例として 1週間以内の訂正・削除は履歴を残さなくても良い、としています。
> これ、どこかにソースある？

ソースっていうか。ちゃんと通達読んでるの？　もめるような事じゃないと思うけど。
とりあえず、4条の項7（訂正削除の履歴の確保の特例）を読めば？

http://www.nta.go.jp/category/tutatu/kobetu/sonota/denshi/01/02/02_04.htm

332 ：NAME IS NULL：04/09/24 18:49:39 ID:WB0oCa9D

>>331

> ソースっていうか。ちゃんと通達読んでるの？
いいえまったく

> http://www.nta.go.jp/category/tutatu/kobetu/sonota/denshi/01/02/02_04.htm
さんきゅ

333 ：NAME IS NULL：04/09/24 19:18:43 ID:???

態度悪ぃなｗ

334 ：NAME IS NULL：04/09/24 19:56:44 ID:???

> いいえまったく

なんだよ。読んでもいないのに、電子帳簿保存法に対応するためには～とか
偉そうなこと言ってたのかよ。本当に知ったか君だったんだなｗ

335 ：NAME IS NULL：04/09/24 20:18:15 ID:WB0oCa9D

>>334

>>324

既に認めてますけど？

336 ：NAME IS NULL：04/09/24 20:19:25 ID:???

ID:WB0oCa9D まじでｳｻﾞｲいんですけど？

337 ：NAME IS NULL：04/09/24 20:30:13 ID:WB0oCa9D

>>336
フィルターをお使いください

338 ：NAME IS NULL：04/09/24 21:12:18 ID:???

ひさびさにスレが伸びていると思ったらこれか。
厨房はそろそろ寝ような？

339 ：NAME IS NULL：04/09/24 22:39:45 ID:???

なんか典型的ダメSEが出現したみたいだな。

340 ：NAME IS NULL：04/09/24 23:05:20 ID:???

なんか女の物言いに見える・・・

341 ：NAME IS NULL：04/09/25 00:08:27 ID:???

てかバカだろ。

342 ：NAME IS NULL：04/09/27 02:15:17 ID:???

主キー～のスレなのに、電子帳簿保存法のスレになってるw

343 ：NAME IS NULL：04/09/27 10:27:55 ID:???

そうなんだよ、ここグチスレのはずが
時々微妙に良スレになるんだよな。

344 ：NAME IS NULL：04/09/27 20:23:50 ID:???

アッコちゃ～ん
アッコちゃ～ん
主キー主キー

345 ：NAME IS NULL：04/10/09 19:50:20 ID:XnFb+TU9

主キーもインデックスも参照整合性すら満足に設定されてなく、適切な正規化もされず
検索処理は一行一行全ての列をプログラムで照合しているため高々1万件にも満たない
データの検索に20～30秒くらいかかるシステムがございますが、伺か?

346 ：NAME IS NULL：04/10/09 20:04:59 ID:???

そのシステムを改修する為に顧客から金取れてこそ一流ｗ

347 ：NAME IS NULL：04/10/09 20:45:32 ID:???

主キーってなに？
インデクッスだけあればいいと思うんですけど・・・。

まずいの？（・_・）

348 ：NAME IS NULL：04/10/09 21:58:19 ID:???

まあ、お前は固定長ファイルでも使っておけってこった。

349 ：NAME IS NULL：04/10/09 22:53:49 ID:???

>347 は高々数十行程度のマスタ系テーブル全列に意味も無く降順インデクッスを張っていると思われ

350 ：３４７：04/10/09 23:09:04 ID:???

ムダなインデクッスなんかつけてません！
重複を許可しなきゃいいんでしょ？

>>348

意味わからん

351 ：348：04/10/10 00:46:39 ID:???

>347にとっては高度すぎるネタだったようだな。
俺が悪かった。

352 ：NAME IS NULL：04/10/10 02:27:16 ID:O62Uz7l1

しかし、某客先で、
主キーのことを「プリマリーキー」と呼んでいたのには、萎えた。
仕様書のあらゆる個所にプリマリーキーが登場したからな。
プライマリーキーは一個も登場しなかったが。

353 ：３４７：04/10/10 09:31:09 ID:gYcBhHE/

>>348

ああ、わかった。それってBTRIEVEスレのでしょ？

354 ：NAME IS NULL：04/10/11 18:50:49 ID:???

>>352
べつにいいじゃん、それくらい。

俺が昔やってた案件では、ＳＥなのに、スプリクトとか言ってるやつ居たぞ orz

355 ：NAME IS NULL：04/10/11 18:56:31 ID:6QJihKaz

スティーブ・スティーブンス　を　スティーブン・スティーブス　みたいなもんだな。

356 ：NAME IS NULL：04/10/11 20:42:23 ID:???

>スプリクト
一瞬何がおかしいのか分からんかった。

357 ：NAME IS NULL：04/10/11 23:25:14 ID:???

俺の上司なんか、プロシキっていうぞ。
指摘出来ないこの気まずさ。
あとDisableをディスイネーブルって言ったりなー、
そっちのが言いにくいいよ！

専門用語だけでなくて、
破綻をはじょうって読んだりなー。

358 ：NAME IS NULL：04/10/12 08:22:27 ID:???

>260さん
続きを読みたい

359 ：NAME IS NULL：04/10/14 01:13:35 ID:???

>>259って、delete commitした領域を即座に再利用するRDBMSとかだと
フラグメントによるパフォーマンス低下が後々辛いんじゃないのかなぁ。
再利用しないならしないで管理の手間増えそうだし。
漏れDB2な奴ですが、間違ってたらごめんなさい。

360 ：NAME IS NULL：04/10/14 10:22:58 ID:XDlVasOF

ＤＷＨだと主キー必須でもないよね

361 ：NAME IS NULL：04/10/14 17:30:04 ID:???

そうなの？

362 ：NAME IS NULL：04/10/14 23:25:20 ID:???

>>359
検索に主キー使わないにしても、主キーあった方が追加、更新、削除の効率上がる気がする
DWHとはいえ主体は普通のDBと変わらんのが多いだろ

363 ：NAME IS NULL：04/10/16 06:05:33 ID:60wvvnPI

名前テーブル
name_id,name
1,(　´∀｀)
2,( ﾟДﾟ)
3,ミ,,ﾟДﾟ彡
...

品物テーブル
item_id,item
1,MD
2,CD
3,mp3
...

# name_idとitem_idはauto_incrementのプライマリキー
なテーブルが有ったとして、

持ち物テーブル
key,name_id,item_id
1,1,1
2,1,3
3,2,2
4,2,3
5,3,1
....

なテーブルを作成する際にkeyは必要？不必要？

364 ：NAME IS NULL：04/10/16 07:29:03 ID:???

name_id,item_idで複合キー
その他、数量を入れる項目作れ。

365 ：NAME IS NULL：04/10/16 08:38:24 ID:Pvrk2coC

>>362
いや、無記名のアンケート結果なんかをどんどん蓄積→集計して参照するようなシステムの場合は
主キーはいらない。
基本的にそういうテーブルの場合UPDATEはないし。
削除は、Oracleだとパーティショニングオプションつければいいし。

366 ：NAME IS NULL：04/10/16 09:58:18 ID:???

>>363
必要なし。

>>364
それ意味有るのか？
って言うか例の条件変えてどうする。

367 ：NAME IS NULL：04/10/16 10:11:43 ID:???

>>365
それはDB自体いらないぞ、気づけよ

368 ：NAME IS NULL：04/10/16 10:47:29 ID:Pvrk2coC

ごめんDWHじゃなくてDSSだったね

369 ：NAME IS NULL：04/10/16 10:48:35 ID:Pvrk2coC

あー、でもさスタースキーマ？だっけ？はやっぱり主キーはいらないよ

370 ：NAME IS NULL：04/10/16 11:19:18 ID:???

>>365 そういうのでも、最低通し番号はつけて、主キーにするよ．

371 ：NAME IS NULL：04/10/16 11:34:35 ID:???

領域のむだじゃない？

372 ：NAME IS NULL：04/10/16 14:11:21 ID:???

>>366
アホだろ、お前。

373 ：NAME IS NULL：04/10/16 15:29:11 ID:???

>>372
アホはお前、この条件の場合必要ない。
居るんだよな、やたらと無駄を付けたがる奴。

374 ：NAME IS NULL：04/10/16 18:57:35 ID:???

>>373
ああ、同じ話してたのか。
これってまさにスタースキーマにするべきだよね。
主キーはいらないでいいよね、やっぱり。

375 ：NAME IS NULL：04/10/16 20:31:59 ID:???

と言うより、>>363がどういう目的でそのデータをDB化したいのか不明。
計数管理を実用的にやるのなら>>364のようにするべきだし、
データ入れるだけなら、適当でいい。

でも、主キーなしで>>363そのままみたいな設計を客に出したら仕事切られるけどな。

376 ：NAME IS NULL：04/10/16 21:43:36 ID:???

恐ろしくレベルが低いスレだな。。。
色々なデータを整理して、関係をひも付けするのが、リレーショナルデータベースだろ。
それともここは、別にRDBで管理しなくてもいいようなデータをRDBに入れる時の話をしてるのか？

377 ：NAME IS NULL：04/10/16 22:45:19 ID:XRkKpCUI

誰が誰にレスしてるのかさっぱりわからん。DWHの設計はOLTPとは全く違うってことはさすがに分かってて、レスしてるよね？みんな。

378 ：NAME IS NULL：04/10/16 22:50:21 ID:???

>>376
最近のRDBMSの機能を知ってて言ってる？

379 ：NAME IS NULL：04/10/16 23:59:42 ID:???

>DWHの設計はOLTPとは全く違うってことはさすがに分かってて、レスしてるよね？みんな。

どっちにしろ、クソなものはクソだけどな
データウエアハウスだから、キー無しで順番に入れとけばOKというわけではないだろう
引き出すときにどうしたいかも考えんきゃならんし

とりあえずは
>と言うより、>>363がどういう目的でそのデータをDB化したいのか不明。
ということだろう

380 ：NAME IS NULL：04/10/17 00:27:20 ID:???

http://www.sw.nec.co.jp/word/az/az005.html

DWH（ディー・ダブリュ・エイチ）

Data Warehouse
データウェアハウス
●用語説明

意思決定支援のためのデータベースのこと。
データウェアハウスの提唱者であるW.H.インモン氏によると、
(1)意思決定のために目的別に編成され(2)統合された
(3)時系列で(4)更新されないデータの集まりと定義されている。
日々の情報を時系列に蓄積することにより、問題点の発見や、原因の究明が可能となる。

381 ：NAME IS NULL：04/10/17 00:30:59 ID:???

>>379
分かってない・・・・

382 ：NAME IS NULL：04/10/17 00:39:20 ID:???

ＲＤＢの技法でＤＷＨがまかなえるなら、
ＲＤＢＭＳにＤＷＨ用の個別機能なんて付けんだろ。

383 ：NAME IS NULL：04/10/17 00:50:11 ID:???

結論
昔はキーなしだとだめだめだった
最近は工夫されてキーなしでもそこそこになった
でも古い形式のDBも現役なのでキー萌え

384 ：NAME IS NULL：04/10/17 01:52:20 ID:???

>>380-381

385 ：NAME IS NULL：04/10/17 01:53:22 ID:???

ところで、いつからデータウエアハウスという前提に決まったんだ？

386 ：NAME IS NULL：04/10/17 02:16:16 ID:???

データウェアハウスって言ってみたいだけの奴が煽ってるようにしか見えないんだけど．．．

387 ：NAME IS NULL：04/10/17 04:25:15 ID:???

そもそもこのスレの趣旨は、データウェアハウスだからキーが無くても機能するという話ではないだろ
うんこみたいな実装やってて、キーがなくてびっくりって話でしょ

俺の予感としては>>380-381あたりが、調べたてで一番よく解ってないような気もするが

388 ：NAME IS NULL：04/10/17 06:07:10 ID:???

データウェアハウス
魔法の言葉だと思ったんだろうな…

389 ：NAME IS NULL：04/10/17 08:20:20 ID:???

いやいやＤＷＨの場合、いらない場合もあるよねと
いう話だったと思うが・・・。
そしたらレベルが低いだの煽る奴が出てきて
こうなったと。

390 ：NAME IS NULL：04/10/17 08:30:31 ID:???

>>360　あたりからの流れはそうだよね。

391 ：NAME IS NULL：04/10/17 14:13:24 ID:???

おいおい、>>363見て、誰ががDWHだと思うんだよ。
明らかに、誰が何を持っているか管理する向けに考えてるだろ。

392 ：NAME IS NULL：04/10/17 14:15:55 ID:???

３６６は確かにどうかと思うが、
それ以外は別に３６３に対してのレスじゃ
ないと思うけど、違うかな？

393 ：NAME IS NULL：04/10/17 15:31:50 ID:???

流れ見ると、>>363に突っ込んでるあたりから荒れてるから、
>>364を支持するか支持しないかで話が始まってた。
しかし、勘違いしたバカが、DWHならキー不要とか言い出したんだと思う。

394 ：NAME IS NULL：04/10/17 15:36:25 ID:???

>>368で>>360のDWHの話は終わってる品
しかも>>363とDWHの話は、別にシンクロしてなかったのに

395 ：NAME IS NULL：04/10/17 16:00:59 ID:???

>>374でむしかえしてますが？

396 ：NAME IS NULL：04/10/17 16:05:17 ID:???

で、>>363はどこへ行った？
ついでに>>364は正しいのか他にもっと良い方法が有るのか。

397 ：NAME IS NULL：04/10/17 16:48:29 ID:???

>>396
お前が分かってないことだけは分かった

398 ：NAME IS NULL：04/10/18 01:05:36 ID:???

>>396
計数管理やるなら、>>364にした方がいいし、
誰かさんの言うようにDWHなら、間違い。

399 ：NAME IS NULL：04/10/20 10:18:53 ID:???

>>396
一人で同じ item を２つ以上持つのでないなら name_id と item_id の
複合キーのみでOK。一人で同じ item を複数持つことがあるのなら、
>>364の言うとおり数量の項目を追加すれ、というだけの話。

>>363は、さしづめ count(*) で item の個数を求めようとしたんだと
思われるが、入手時刻などを考慮しないならその必要はないと。

入手時刻も考慮したい場合は>>363みたいにして key を主キーに。
ついでに入手日時の項目も追加。
で、WHERE で日付を絞りつつ count(*) で個数を求めるといいはず。

400 ：NAME IS NULL：04/10/20 22:15:22 ID:???

>>396ってただの関連付けじゃないのか？
漏れにはそう見えた。

401 ：NAME IS NULL ：04/10/23 17:28:52 ID:CZ5lSRSV

【恐怖】VIEWを使わないシステムみたことありますか？

理由：遅くなるから。おかげで、コードとそれに１：１でリンクする名前が
同じテーブルに入ってます。また、Viewの命名規則にはVXX000の連番を使う
という記述もあります。

402 ：NAME IS NULL：04/10/23 17:42:28 ID:???

>>401
Viewを使わないことが恐怖なの？
使いすぎるほうがよっぽど恐怖に思えますが。

403 ：NAME IS NULL：04/10/23 19:35:20 ID:???

SQL鯖なんかだと、EditionによってはView使うとIndex効かなくなるなんて事もあるからな。

404 ：NAME IS NULL：04/10/23 19:35:54 ID:???

はぶ氏もひが氏もここの話題に反応してくれてますな

っと、話ふり逃げに思われると残念なので書いとこう

405 ：NAME IS NULL：04/10/23 19:36:14 ID:???

おっと誤爆失敬

406 ：NAME IS NULL：04/10/24 13:13:12 ID:???

しぃさーっすか。

407 ：NAME IS NULL：04/10/24 23:26:07 ID:???

ですわ。おはずかし。

408 ：NAME IS NULL：04/10/24 23:47:26 ID:qYETNpDv

>>403
けったいな制限だな・・・

409 ：NAME IS NULL：04/10/25 07:18:12 ID:???

OracleでもViewを入れ子にするとオプティマイザがへんな実行計画たてちゃうとかあったね

410 ：NAME IS NULL：04/10/26 20:17:46 ID:???

日付項目に、日付型使わず数値8桁使ってるシステムってどうよ？

411 ：NAME IS NULL：04/10/26 22:52:11 ID:???

COBOLerかよ

412 ：NAME IS NULL：04/10/26 23:44:42 ID:???

計上日とか日数計算しない項目なんかは
文字列8桁の方が管理しやすい場合はあるな。
特定月の集計値を取得する時もLIKEが使えるので
レスポンスも早い、はず。メンテ楽だし。

413 ：NAME IS NULL：04/10/27 00:52:06 ID:???

>>412
DATEでもLIKE使えるだろ。
Oracleでも無ければ、DATE型とDATETIME型とあるし。

414 ：NAME IS NULL：04/10/27 00:52:51 ID:???

>412
ﾋｿ( ´д)ﾋｿ(Д｀⊂)ｴｰｯ

415 ：NAME IS NULL：04/10/27 01:52:56 ID:???

帳票に出したりする時にいちいちTO_CHARかますの難儀なので
俺も日数計算と関係ない、半分文言みたいな日付は
文字列にしてますよ。それこそ計上日とか。
まあ慣習みたいなものなんですが。

そういう項目の場合、DATE型だと
FROM～TO条件などでの挙動に不安があるんですが。
秒ではじかれたりしないかと。
やった事ないので漠然とした不安ですけど。

Oracle以外だと秒を管理しない型もあるんですか？
それなら関係ないか。

あとADO関連のメーリングリストだかで
DATE型だとデータが変になるとか見た事ありました。

416 ：NAME IS NULL：04/10/27 02:17:59 ID:???

ORACLEってシェアあるだけで実は一番使いにくいんちゃうか・・・

417 ：NAME IS NULL：04/10/27 02:48:01 ID:???

そうかもなあ。
でも、管理ツールで使いやすいのが一杯出てるから。
でも高いんだよなあ。

9iでだいぶやさしくなったんですけどね。
エクステントもデフォルトが一番最適だったりするようになったし。

418 ：NAME IS NULL：04/10/27 05:05:53 ID:???

俺は8iしか詳しくないが、正規表現が使えないのが痛すぎ。

419 ：NAME IS NULL：04/10/27 07:14:48 ID:???

もう10gでてるのにいまさら8iのことで文句を言う418は痛すぎでないとでも？

420 ：NAME IS NULL：04/10/27 07:49:33 ID:???

で、10gってどこで使われてるの？
実績重視なんかで、未だに8iを新規に入れるところは多いよ。

421 ：NAME IS NULL：04/10/27 12:04:40 ID:???

俺には419が一番痛いヤシに見えるがな

422 ：NAME IS NULL：04/10/30 08:37:40 ID:???

新規に入れるなら9iR2じゃないの？

423 ：NAME IS NULL：04/10/30 10:15:16 ID:???

9iって意外に人気無いよ。
いまだに動作保証が8iだけっていう

424 ：NAME IS NULL：04/10/30 10:15:58 ID:???

ERPもあったりするし。
9iのプラチナ持ってる奴も会ったことないし。

途中で送信してしまった…

425 ：NAME IS NULL：04/10/30 19:01:35 ID:???

だって高いんだもん。

426 ：NAME IS NULL：04/11/01 13:33:05 ID:???

9iの旧プラチナ持ちの人なら一人知ってる
あれはあれでレアか

427 ：NAME IS NULL：04/11/13 01:15:00 ID:???

>>410
2004/13/99 の様な実際には無い日付を使う場合がある
例えば、月末をYYYY/MM/７７で、会計締め日をYYYY/MM/88など

428 ：NAME IS NULL：04/11/13 01:22:32 ID:???

>>427
あるある。でもそういう場合でも文字列だよね大概。
数値ってのは聞いた事ない。

429 ：NAME IS NULL：04/11/13 09:03:25 ID:???

文字列なら
2004/11/末
2004/11/〆
でいいじゃん。

430 ：NAME IS NULL：04/11/13 18:59:53 ID:???

>>427
とてつもなくセンスないな

431 ：NAME IS NULL：04/11/14 10:25:55 ID:???

業務用件でDate型ではなく、char型を使うのが適しているってのはあったぞ
営業がフランチャイズ店舗開拓のデータを整理するという案件だったのだが

・新店オープン決定　オープン日も決まっている　→　オープン日を YYYY/MM/DD で入力
・新店オープン決定　オープン日も大体決まっている　→　オープン日を YYYY/MM で入力　後日メンテしてオープン日を YYYY/MM/DD にUPDATE
・新店オープン決定　オープン日は決まっていない　→　レコード作成する　オープン日はNULL
・新店オープンするかもしれない　→ レコード作成する　オープン日はNULL 後日メンテでDELETEするかもしれない

432 ：NAME IS NULL：04/11/14 15:41:28 ID:???

・新店オープン決定　オープン日は決まっていない　→　レコード作成する　オープン日はNULL
・新店オープンするかもしれない　→ レコード作成する　オープン日はNULL 後日メンテでDELETEするかもしれない

433 ：NAME IS NULL：04/11/14 19:23:41 ID:???

DATE型にして、その他に日付決定区分みたいの作った方がいいんじゃない？
確実に決まってるのなら、そのズバリのひづけと区分が１、
だいたい決まってるのなら、区分は２にして、その月の１日の日付でも入れておいた方がいいと思う。
そうすると、月単位でだいたいというひづけだけではなく、
多分12月2日だけど、11月30日とか月をまたいで前後するかもとか、そう言うデータも入れられる。
もしくは、区分じゃなくて、最高で何日前後するかの数値を入れるとか。
ズバリならゼロを入れておく。

434 ：NAME IS NULL：04/11/27 04:12:12 ID:QWDujoZt

age

435 ：a：04/11/27 09:54:39 ID:SLvZscV9

そういうあいまいなのだと、大体のオープン日を日付まで入力さ
せて、それで決定、未定区分を作るかなあ。
どの日付を入れるかは入力者の判断にまかせるとして。

436 ：NAME IS NULL：04/11/27 10:36:29 ID:???

>>431-432は何が言いたいの？

437 ：NAME IS NULL：04/11/27 12:28:41 ID:nifHq9rI

http://i-bbs.sijex.net/servlet/ImageOutput?pa=1071840476618o.jpg&id=godscanty&t=107184048297

438 ：NAME IS NULL：04/11/30 11:32:18 ID:7mFRMBlL

話を蒸し返して申し訳ないが、Delete/Insertに関して質問。

たとえば
・何日に、どの店からどの商品を何個購入したか
（主キー：購入日・店ID・商品ID）
というようなテーブルに１行ずつ追加するような処理の場合、
Delete/Insertのデメリットは少ないと考えていいのか？

Upsertできれば楽で安全で確実なんだけどなあ…。

439 ：NAME IS NULL：04/11/30 14:35:37 ID:g2H0vwRp

主キーがないのもあれですが、やたらたくさんの複合キーから構成され
る主キーってどうですか。あるDBMSから別のDBMSに移植するとき複合キ
ー数の制限に引っかかってしまったことがあります。
よく見たら無理やりユニークにするために無駄な枝番号がいくつもつい
てました。結合とかやりにくくてかないません。
私は枝番号はあまり好きではありませんが、皆さんは枝番号の扱いって
どうしてますか？

440 ：NAME IS NULL：04/11/30 15:05:03 ID:???

枝番の扱いなんて改めて考えた事もないなあ・・・・
設計する中で正規化をしていくうちに
キーなんて決まっていくもんだし。

関連テーブルなんかで、キーが3つ4つあるのは
（流石に4つは見たことないかも）確かに多く感じられますが、
業務分析の結果それが正しければそうすべきだと思います。

関連テーブルなのに独自にIDを振って
主キー1つのみにするなんて人もみた事ありますが
ありゃやめてほしいなあ・・・・。
ヘッダ - 明細の親子関係で明細独自ID振るのも
かんべんして欲しい。

441 ：NAME IS NULL：04/11/30 15:05:50 ID:???

あ、勿論エラーではじかれるほどの
複合キーの数ってのは問題外ですよ。

442 ：NAME IS NULL：04/11/30 16:05:04 ID:???

>>440
＞ヘッダ - 明細の親子関係で明細独自ID振るのも
＞かんべんして欲しい。
じつは最近この方法のほうが自然かなぁって思っているんです。
親のキーをリファレンスにした外部キーを子が持っていて、
それに逆参照用の非NULL重複索引がついてる方が親子関係っぽ
くはないかと。もっといってしまえば子テーブルには主キーは
いらないってこのスレの主題に戻るわけですが。
普通のやり方だと、親のキーと同じ情報をキーの一部にたまたま
持ってるって感じですよね。

443 ：NAME IS NULL：04/11/30 16:06:30 ID:???

＞主キー1つのみにするなんて人もみた事ありますが
＞ありゃやめてほしいなあ・・・・

複合キーは好まれないとおもっていたよ
それは運用上融通がきかない設計だから。。。。。
理由をきかせてほすぃです
たぶん、キーが明確でなくなるから？？？

444 ：NAME IS NULL：04/11/30 16:47:34 ID:???

普通に正規化したつもりで、>>438みたいなテーブル設計してたけど。
ひょっとしてマズかったのか？

関係テーブルに独自IDふって主キーにするのって、主キーがないのも
同然な気がするけど。一意制約逃れ以外に独自IDの意味はあるの？

445 ：NAME IS NULL：04/11/30 19:09:51 ID:???

>438が言ってるのはUpdateの代わりにDELETE/INSERTするって事でぁ？

446 ：NAME IS NULL：04/11/30 21:01:38 ID:???

>440
複合キー列が多くなりすぎてわかりづらくなった場合に代替キーとして別のユニークな列を
用意するのはアリだとおもう。もちろん、本来の複合キー項目にも一意性制約をつけて
おくのはお約束だ。

447 ：NAME IS NULL：04/11/30 21:06:50 ID:At4YbhlE

出向先で主キーにNULLが入ってても「それで良いんだよ！！！」と言い張る奴がいたｗ

448 ：NAME IS NULL：04/11/30 21:21:16 ID:???

それは NULL という文字列が本当に入っていたのです。こっちのNULLはうにコード、あっちは
EUCでそっちはSJIS、そしてこいつはEBCDIC…

449 ：NAME IS NULL：04/11/30 23:17:41 ID:At4YbhlE

>>448
いや、俺が行った所は違いましたよｗ
NULL値です。
複合キーだからいいの！！って言われたんで
とりあえずハイ分かりました。って言って仰せのままにやったけどね

450 ：NAME IS NULL：04/12/01 00:08:35 ID:???

>>446
検索性が高まりますよってことかな。㌧クス。

451 ：NAME IS NULL：04/12/01 01:38:05 ID:???

>>438
通常は、登録したデータは消さないのが一番いいだろ。
使わないなら、削除フラグでも立てるべき。
履歴にもなるから、業務でトラブったときに便利。
メンテナンスの時に、本当にいらなければ、まとめて消せばいい。

452 ：NAME IS NULL：04/12/01 01:39:34 ID:???

>>444
商品IDって別にDBの一意制約逃れのためにつけるものじゃないだろ。
普通に伝票で管理してても、違う商品に違う商品コードはつけないわけで。

453 ：452：04/12/01 01:40:35 ID:???

あ、うそうそ。
>>438は取引IDでも作るべきだな。

454 ：NAME IS NULL：04/12/01 06:45:57 ID:???

>445
>438 は最後に UPSERT と書いてあるから、同じデータが無ければ INSERT、同じデータがあれば
UPDATE したいと言うことと思料。だからこれを実現するには
1. データの存在を確認して INSERT と UPDATE を使い分ける。
2. データの有無にかかわらず DELETE を発行してデータが無いことを保証した後 INSERT する。
のどちらかしかないと。>438 の言う「Delete/Insert」は 2. の方法と。

455 ：NAME IS NULL：04/12/01 07:40:17 ID:???

>>444
主キーが存在しないか必要でないレコードに独自IDで主キーを付けるのは、
テクニカルな理由だと思うな。
プログラムからレコードを操作する場合にカーソルが使えるか、ROWIDのような
DBMSの独自機能を使えれば問題ないが、それ以外の方法では主キーがないと更新
時にレコードの特定に困る。
それから、ODBCカーソルで更新可能な結果セットを使う場合は主キーが必要だ。
クライアント側に保持した主キーのリストが更新可能な結果セットの正体だから
単純で小さな主キーの方がパフォーマンスがいい。よくは知らないがOLE-DBや
JDBCも同じ仕掛けだと思う。

456 ：NAME IS NULL：04/12/01 07:43:59 ID:???

>>454
1.の変形ですが、とりあえずUPDATEして更新件数が０件ならINSERTする
方法もありますね。

457 ：NAME IS NULL：04/12/01 07:57:15 ID:???

INSERT と UPDATE の使い分けで
SQL99準拠のMERGEがぼちぼち使えるようになってるらしいけど、
やっぱりDBMSで実装の違いや方言とかあるのでしょうか？

458 ：NAME IS NULL：04/12/01 09:10:58 ID:???

>454
どっちが一般的っすか？
2の方法はトリガが使えなくなりそうでイヤーン

459 ：438：04/12/01 09:26:47 ID:???

>>456
正直、目から鱗。
どうしてそんな単純な方法が思い浮かばなかったんだろう。
マジで感謝。

460 ：NAME IS NULL：04/12/01 10:10:16 ID:???

ちょっとスレ違いネタになるが、
DB側から見て、INSERTとUPDATEが同一視されてしまうシステム(アプリ)に問題は無いのか?
ケースバイケースつわれりゃそれまでなんだろうけど、新規追加か更新かをアプリ側で判断せず
そのままDBへ投げて旧データがあれば更新、無ければ追加ってなんか安易な考えのような気もしてきた。

ここら辺はどうでしょう。 > ｴﾛｲ人

あぁ、手入力じゃなくてバッチ処理で更新するときはありなんかな?

461 ：NAME IS NULL：04/12/01 11:12:24 ID:???

>>460
むしろ、アプリ側だけで追加/更新を判断するのは危険な予感。

462 ：NAME IS NULL：04/12/01 11:34:28 ID:???

>>443
明細独自のキーをつくっちゃうのは
キーがひとつっていう実装面での
便利さは確かにあるんだけど
設計が見えてこないのが気持ち悪いんです。

ヘッダ-明細の集約関連なのか、ただの関連なのか、とか。

それと、まれに実装面でも大変な事になります。
大量の受注データをファイルからインポートする場合、
明細ＩＤが「YYMMDDXXXX」(Xは連番)みたいなフォーマットの場合
採番テーブルで管理するとなると、1明細ずつSELECTが走る事になって
オーバーヘッドになったり、下手すると桁溢れの可能性も格段に高くなる。

シーケンスで数字でふっちゃえばいいじゃんって話もありますが、
保守を考えるとちょいと不安です。

ただし、>446のいう通り、あまりにも複合キーが複雑な場合は
別の独自キーを構えるのはアリだと思います。
そこらへんは柔軟に考えるのが吉ですよね。

でもめんどいからえいやっでなんでも独自キーはいや。
「エンティティ」の意味をもう一回考えて欲しいと思う。

463 ：NAME IS NULL：04/12/01 14:39:21 ID:???

本来なら、DB設計以前に、業務として、受注ID見たいのをもっとくべきだと思うが。
紙の伝票だって、紙の領収書だって、レジのジャーナルだって、
取引毎にユニークなNoがついていて、それで管理してるわけで。

>下手すると桁溢れの可能性も格段に高くなる

それは設計が下手だからでは…

464 ：NAME IS NULL：04/12/01 16:52:24 ID:???

おっしゃる通り、「取引単位」にみなユニークなキーをもってる訳で、
明細はその中の何行目くらいの意識しか業務上ないでしょう、普通。

取り敢えず、実装面での利便性はさておいて
そういった業務内容を設計に落とすんだったら、
明細テーブルのキーは、受注番号 + 連番にすべきですよね。

ここで問題になってるのは、明細単位に明細ＩＤを持って
受注番号はただの属性になってるモデルはいかんなあ、
いやそれも便利だしアリでしょ、いやでもなあ、って話。

＞それは設計が下手だからでは…
だから、そういう話の例としてあげてみたのよ。

465 ：NAME IS NULL：04/12/01 16:54:21 ID:???

この話の論点って、下記スレと同じですね。

制約っていらなくね？
http://pc5.2ch.net/test/read.cgi/db/1087483786/l50

出発点は主キーと制約で違うけど。

466 ：443 ：04/12/01 18:48:54 ID:???

＞便利さは確かにあるんだけど
＞設計が見えてこないのが気持ち悪いんです。
なーる

ところで、複合キーの一部にＮＵＬＬは許されなかったかな？
いや、移行システムの場合、移行データの主キーに平気でＮＵＬＬ
あったんで、ＩＤは必要かなって思った

467 ：NAME IS NULL：04/12/01 19:16:39 ID:???

RDBは理想と現実というか設計と実装が乖離することが多いと思う。
正規化をばっちり行って制約も完璧に付けたE-R図を作ったとして、
実装するときは正規化を崩して制約の大半はアプリ側ロジックに
移動させることになる。E-R図からSQLを生成する設計ツールが
あるけど使えないことが多いのはこのため。
独自キーの使用は設計と実装の区別がきちんとついてればいいんじ
ゃないかな。

>>466
複合主キーの一部にＮＵＬＬは私の知ってる範囲ではどれもだめ
だったと思います。

468 ：NAME IS NULL：04/12/01 19:26:07 ID:???

理想と現実って話からはずれるけど、
意識的に正規化崩しが出来るって事は
けっこう設計力があるって事だと思うじょー

前にも書いたけど、グチスレのはずが
本当に良スレだなあここは。

469 ：NAME IS NULL：04/12/01 20:53:04 ID:???

最近のDBだとINSERTで、既存レコードがあればUPDATE、なければINSERTになるじゃん。

470 ：NAME IS NULL：04/12/01 20:59:27 ID:???

それって、MARGEのこと？

471 ：454：04/12/01 21:08:36 ID:???

>456
そうか、UPDATE も 0件であっても問題なく実行されるのか。
(ﾟﾛﾟ )そいつは名案気が付かなかった早速帰ってやってみよーっと!!
でも、UPDATE された件数を取得する方法ってあるの?当方 Jet と MSDE しか知らないけど。

>464
> 明細テーブルのキーは、受注番号 + 連番にすべきですよね。
　受注Tbl の子Tbl という扱いになるからそうよねぇ。pkey(受注番号, 明細番号) で明細番号が
シーケンスなりでつけられると。
> ここで問題になってるのは、明細単位に明細ＩＤを持って
> 受注番号はただの属性になってるモデルはいかんなあ、
　外部キー制約が DELETE( ,UPDATE) CASCADE でついてれば次善ではあるけれど…。

472 ：NAME IS NULL：04/12/01 22:32:40 ID:???

>>471
oracleだったら、SQL%ROWCOUNTってのがあるでー。
MSDEのストアドにもあると思うよ。

ADOだったら確かExecuteNonQueryの返り血（ぎゃー）が
更新処理した行数だでー。

473 ：472：04/12/01 22:34:07 ID:???

MSDEにもあると思うってのは、
似たようなのが、って事ね。
そのまんまはないわいな。

474 ：NAME IS NULL：04/12/02 06:40:30 ID:???

MSSQLServerならこんな感じ
UPDATE xxxx
IF @@ROWCOUNT = 0
INSERT INTO xxx

475 ：正規化初心者：04/12/12 23:11:18 ID:???

「品名、型番、製造メーカー、数量」の項目があります。
この項目を正規化して、主キーにするならどれになりますか。
現在のところ品名ＩＤなどは利用していません。
上記の項目で主キーになるものがなければ商品ＩＤ
などのカラムを追加するべきですか。

476 ：NAME IS NULL：04/12/12 23:38:46 ID:???

そんだけの情報でどうやって主キーを決めろなんて無理ですよ。
業務を反映しない形でパカパカテーブル定義作られちゃかなわん。

477 ：NAME IS NULL：04/12/12 23:39:11 ID:???

あまりの事に日本語が変になっちゃいましたよ！すまん！

478 ：NAME IS NULL：04/12/13 08:18:23 ID:???

>>475
間違いなく数量がキーだな。
教えてやったんだから、そのとおり設計しろよ。

479 ：NAME IS NULL：04/12/13 11:12:42 ID:???

あっそうやって答えればいいのか。

480 ：NAME IS NULL：04/12/13 11:55:51 ID:???

>478は素人だな。
この場合は品名・型番・製造メーカー、数量の先頭1文字を結合して主キーとするのがベストさ！

481 ：NAME IS NULL：04/12/13 12:05:31 ID:???

あっこちゃんだけが主キー

482 ：NAME IS NULL：04/12/13 12:33:35 ID:???

481はお客さんが納豆売りだった場合のみ有効。

483 ：NAME IS NULL：04/12/13 20:55:42 ID:???

「キィ」若しくは「ID」といった名前の列を追加して、それに主キー制約を張るべきだ。

484 ：NAME IS NULL：04/12/18 11:39:11 ID:???

とある業務パッケージで主キーがなくテーブル項目も
１項目のみで char(512)で定義されてるだけで
ビューで項目を分けてた。全テーブル・・・

目から鱗が落ちた。

485 ：NAME IS NULL：04/12/18 11:54:26 ID:???

主キーが無いと、トランザクションログがやたら増えるって聞いたけどマジ？

486 ：NAME IS NULL：04/12/18 18:45:27 ID:???

普通はかわらないと思うけどね。なんてDB使ってんの？

487 ：NAME IS NULL：04/12/29 17:44:18 ID:???

62フィールドで120万件以上データがあるテーブルに
主キーが無いんですけどこれくらいじゃ甘いですか？
もちろんUPDATE作業もあって120万件中一件だけ
UPDATEする作業を全件分(120万回)行わないといけない。
しかもしっかりINDEXがついてます。

普通に半年以上かかると思う・・・
oracle9iをoo4oで操作してますがどうやったらテーブル変更しないで
二日以内に全件終了できますか？

聞くまでもなさそうだけどorz

488 ：NAME IS NULL：04/12/29 20:07:37 ID:???

>487
UPDATEするときだけINDEXを削除して、UPDATE完了したらINDEX張りなおし。
塚主キー関係ない希ガス

489 ：NAME IS NULL：05/01/26 23:47:07 ID:???

主キーがないどころか、同じデータが重複しまくりの
Excelファイルを繋げといわれた・・・
データが重複してるのは、重複してる数だけ必要だからで、
主キーはつけずに上のデータから消しこみしたいとか。

Excel的にはありなのかもしれんが、レコードの「上から順に」って
斬新な発想だなと。嫌がられても無理矢理に主キー設定したが。

490 ：NAME IS NULL：05/01/27 09:41:28 ID:???

>>489
そんな斬新でもないだろ。
昔のシステムいじった事ない人なのかな？

491 ：NAME IS NULL：05/01/28 04:41:31 ID:???

>>490
「斬新」てのは皮肉でそ。

492 ：NAME IS NULL：2005/03/28(月) 16:25:37 ID:FaNfWzuJ

age

493 ：NAME IS NULL：2005/03/29(火) 21:31:41 ID:rB3ZIFyp

学校でDBの講習を受けているときに
「～を～してWEB上で管理するシステムを作成せよ
新規登録・検索・一覧表示・更新・削除の各機能が必要
ただし各データに固有番号を付与する事は禁止とする」
みたいな問題をやたらと出されてた

DBに詳しい奴も主キーさえ使えたら…と頭を抱えてた

494 ：NAME IS NULL：2005/03/29(火) 23:34:59 ID:???

自然キーの中から主キーを捜させるのがテーマなんだろうけど、
すごい複合キーになったらいやだね。

495 ：NAME IS NULL：2005/03/30(水) 01:54:56 ID:???

>>493
実務でも、ユニークにするだけのために関係ないキー使ったら（パフォーマンスの都合とかは別）、
ダサイ実装なんて言われるぞ。

496 ：NAME IS NULL：2005/03/30(水) 22:55:36 ID:???

代理キー使うのがふつーだと思うが

497 ：NAME IS NULL：2005/03/30(水) 23:50:40 ID:???

それが普通だと思ってるのなら、RDBMSを使う意味を解ってないのでは…

498 ：NAME IS NULL：2005/03/31(木) 03:00:16 ID:???

いるんだよな
意味としての主キーと識別子としての主キーを同列に考えるやつ

複合主キーつかいまくった挙句、仕変でデスマってたバカがいたなあ…

499 ：NAME IS NULL：皇紀2665/04/01(金) 01:27:32 ID:???

意味のないキーを使ってる方が、仕様変更時にデータの整合性が
解らなくなって、デスマる確率が高いな。
intで入れた順番にシーケンスなんてやってたら、後からデータだけ見ても意味解らなくなる。

一応金融系や産業系で長いことやってるが、Oracleプラチナみたいな奴が
設計してるような大きなシステムで、識別のためだけにキーを設定してデータ
突っ込んでるシステムは見たことがない。
読み出すソフトが無くても、データだけ見て業務の流れが解るように作るのがプロだろ。

小規模のとりあえず動けばみたいなシステムでは、腐るほど見たことはあるけど。

500 ：NAME IS NULL：皇紀2665/04/01(金) 02:18:09 ID:???

いい加減な固有番号を付けてとにかくユニークにすればいいとは誰も言ってないと思う。
自然キーが主キーとして用を成さないくらいの複合キーになってしまうのは、コード化が
必要なデータがコード付けがなされてないために起きることが多い。本来従属した属性
であるはずの登録日や入力場所などが主キーに含まれてしまっているケースなどがそれ。
これだと主キーに仕様変更が発生しやすい。
本来ならば適切なコード付けを行ってそれが自然キーになるような設計にするのが
ベストだが、>>493の講習のように適切にコード付けされていないレコードを押し付けられる
ことがほとんど。次善の策で代理キーを使うことになる。
データベースの設計者にコンピュータだけではなく業務全体に対してよほどの能力と権限
がなければ適切なコード化は難しい。理論だけの人か恵まれた現場にいる人でなければ代理
キーやむなしという考え方をしてもおかしくないと思うよ。

501 ：NAME IS NULL：皇紀2665/04/01(金) 07:56:29 ID:???

やむなしっていうかビジネスの都合をデータベースまで持ち込みたくない

502 ：NAME IS NULL：皇紀2665/04/01(金) 09:32:45 ID:???

>>501
データベースシステムの都合とビジネスの都合でうまく調整がつけばいいのだが、
力関係は技術屋＜＜＜＜実務屋だからしゃーないよ。

503 ：NAME IS NULL：皇紀2665/04/01(金) 10:11:16 ID:???

>>499

「業務の流れ」てのは変わるものだから

504 ：NAME IS NULL：皇紀2665/04/01(金) 11:54:49 ID:???

DB上のプライマリキーは、業務上の意味から自由なIDにしとく。
シーケンスとか使ったっていい。

かつ、業務上意味のあるコードを、ユニーク制約やNOT NULL制約などを
要件に従ってつけておく。

これなら業務要件もDB設計から把握しやすいし
突如コードの洗替なんてとんでもな依頼が来ても対処はらくちん。

両方いいとこどりでいいじゃん。
原理主義的宗教論争に陥る前に、現実解を優先するべき。

ただ、見出し-明細とかの親子関連の場合、子に独自IDつけると
参照関連にしか見えなくて、そこが悩ましい。

な訳で、俺は注文-顧客みたいな参照関連の場合は上記の方法、
注文見出し-明細みたいな親子の場合は、
子は親ID+連番の複合キーにしてます。

505 ：NAME IS NULL：皇紀2665/04/01(金) 17:30:37 ID:???

>>499
金融だとコード系が業界標準で決まってたりするから499のような考え方でいいのかもしれないね。
Oracleプラチナみたいな痛い例を引き合いに出さず立場や環境の違い認め合おうではないか。

506 ：NAME IS NULL：皇紀2665/04/01(金) 21:19:23 ID:soTwNKQ0

現場から一言
「能書きは良いから動かしてくれ！」

507 ：NAME IS NULL：皇紀2665/04/01(金) 22:44:03 ID:???

OracleマスターってＯｒａｃｌｅに特化した技術で、
データモデリングとはあまり関係なかったような。
最近のはよく知らんのでなんとも言えないが。

508 ：NAME IS NULL：皇紀2665/04/02(土) 00:41:33 ID:???

>>505
立場や環境と言うよりも、技術力の差のような気がするが…
プラチナな奴が作れば、小規模システムだって素晴らしくできるわけで

509 ：NAME IS NULL：2005/04/02(土) 15:06:05 ID:a2Szs17Q

>>508
うちの案件でプラチナな奴を使ったら人件費だけで予算オーバー

510 ：NAME IS NULL：2005/04/02(土) 16:36:24 ID:DclvoDbo

主キー２つ作ってもいいの？

511 ：NAME IS NULL：2005/04/02(土) 23:47:58 ID:???

いや作れないし

512 ：NAME IS NULL：2005/04/03(日) 06:52:39 ID:???

ところで20年前に主キーってあったかな。

513 ：NAME IS NULL：2005/04/03(日) 11:55:21 ID:???

無かったら銀行から瞬時に金おろせないな。

514 ：NAME IS NULL：2005/04/03(日) 16:56:58 ID:???

ORACLEのVersion5くらいではPRIMARY KEY の指定をした記憶がない。
単に私が知らなかったのか、それともVersion6くらいから入ったのか。
という意味。

515 ：NAME IS NULL：2005/04/03(日) 18:48:43 ID:???

SQL Serverも６．０くらいまではPrimary key制約はなかったような、
unique + not null でやってた記憶が。

516 ：NAME IS NULL：2005/04/03(日) 18:51:29 ID:???

概念と実装はまた別だと思うが

517 ：NAME IS NULL：2005/04/03(日) 19:34:59 ID:???

主キーというのは、実装レベルの「概念」だな。
実装されないとほとんど意味のないもの。
純粋に使い勝手の問題。

518 ：NAME IS NULL：2005/04/03(日) 19:55:51 ID:???

DBに実装されて無くても、簡単にデータ取り出そうとしたら、
例えば口座番号とかで主キーを昔から作ってるって事でしょ

519 ：NAME IS NULL：2005/04/03(日) 22:14:39 ID:???

主キー制約というより主索引として意識してた。COBOLのISAMやKSDSからの
移植が多かったからどうしても複合キーになりがちだった。
さらに上の世代の人たちから、初期の汎用機のDB2でメーカーのSEから索引は
使ったらいけないといわれたと証言を得ているが同時は何か事情があったの
だろうか。

520 ：NAME IS NULL：2005/04/04(月) 09:32:53 ID:???

>>518-519 DB2は知らないが、安定性、安全性の観点からは
索引はない方がよかった。insert したが、索引は更新されず、
Tableには存在するが、ある条件だと照会できない、ということが
現実にORACLEでは起きていた。ワークスペースの設定の問題とか
エラー時のエラーコードが正しく返ってきていたかとか、Btreeの
管理にバグがあったりとか原因は色々考えられるが、それこそ20年近く
前だとこういうことは度々起こったから、索引はできるだけつけない
ようにというのはマニュアルの類にさえ書かれていた。

521 ：NAME IS NULL：2005/04/04(月) 09:49:25 ID:???

まあアレですよ。
この業界、去年はベストだった解が今年にゃタブーになってるなんてよくある話ですから。
で、過去のベストを脳みそに刻んでいる上の人間がそれを頑なに守っているという。
現物さわってる現場の下っ端の発言なんか聞きもしないし権限も無い、と。

522 ：NAME IS NULL：2005/04/04(月) 10:19:39 ID:???

既に1000万件を超える組を持つテーブルだと、システムの節目でないと、
設定を変えるチャンスがない。だから、自由度という点からすれば、
主キー設定なんてない方がいいんだろうけど、パフォーマンスもあるし・・。

523 ：NAME IS NULL：2005/04/04(月) 14:27:22 ID:???

>>520
ANSI-SQLのデータ定義言語(DDL)にCREATE INDEX命令は含まれてなくて
各メーカーの独自実装扱いだった。いまのANSI規格でもそうなのだろうか。

524 ：NAME IS NULL：2005/04/04(月) 19:46:08 ID:???

>>522
パフォーマンスより、データが二重になってしまう方が怖い
無理矢理キーでも、同じデータが入ってしまう可能性もあるし
なにかユニークな自然キーが欲しいよ、やっぱり
業務上で、口座番号とか伝票番号とかあれば、確かに楽なんだけどね…

525 ：NAME IS NULL：2005/04/05(火) 09:45:58 ID:???

百歩譲ってINDEXは無しでも良いがUNIQUEは無いと困るにょ

526 ：NAME IS NULL：2005/04/06(水) 12:34:13 ID:???

PRIMARY KEYの指定を使わず、アプリケーションで完全なUNIQUE検査を
するには、テーブルをロックする以外に方法はないのですか。
もちろんマルチユーザのデータベースですが。

527 ：NAME IS NULL：2005/04/06(水) 12:38:23 ID:bsFmYDLm

>>526
検査だけだったら、検索してヒットすれば制約違反で良いのでは？

この結果を踏まえて追加や更新を行う場合は、もうちょっと複雑な処理がいるだろうがな。

528 ：NAME IS NULL：2005/04/06(水) 13:02:01 ID:???

採番テーブルを使うとか。

529 ：NAME IS NULL：2005/04/06(水) 13:19:15 ID:???

JAVAのO/Rマッピングでも参考にすると良いかも。

530 ：NAME IS NULL：2005/04/06(水) 19:43:48 ID:E+G6fNQP

>511
作れるよ。

531 ：NAME IS NULL：2005/04/07(木) 16:33:36 ID:???

>>530
主キーはひとつだけだが候補キーはいくつも作れる。
どちらも非NULLでUNIQUEだから実質いくつも作れるという認識でもいいと思う。
このスレで話題になっている代理キーは主キーのほかに候補キーを持つという話で、
キーがないレコードに適当な主キーをつけるという話ではない。

532 ：NAME IS NULL：2005/04/10(日) 01:18:54 ID:???

主キーというテーマでこんな立派なスレができるのだから、
RDBも捨てたものではないな。

533 ：NAME IS NULL：2005/04/15(金) 21:07:09 ID:???

>>519 亀レス　もともと主キーなどという概念はRDBにはない
実用上の理由からCODASYLから借りてきたもの。

534 ：NAME IS NULL：2005/04/22(金) 15:14:42 ID:Ep3EiPSo

確かに主キーの概念はRDB以前からあったかも知れないが、
データベースは関係の集まりであるとするRDBにおいては、
一意識別はより切実であって、借り物云々は当たらないと思う。

535 ：NAME IS NULL：2005/04/22(金) 15:48:42 ID:???

主キー付けるとデータを入れにくくない？
そんなこともしらないの

536 ：NAME IS NULL：2005/04/22(金) 21:14:39 ID:???

ないほうが入れにくい

537 ：NAME IS NULL：2005/04/26(火) 02:31:40 ID:9zw9nuFP

candidate key
primary key
alternate key
surrogate key

538 ：NAME IS NULL：2005/04/26(火) 20:03:58 ID:???

syu key

539 ：NAME IS NULL：2005/04/29(金) 23:58:25 ID:???

主キー無し作ったことあります
履歴を取る必要があって、条件を考えていたら主キーにするために項目が多くなってしまうし
シーケンスも考えたんですけどね

540 ：NAME IS NULL：2005/05/02(月) 13:13:08 ID:???

私は主キーありの方が少数派かな。なんでもすぐテーブルにしちゃうから、
そんなこと考えてられない。

541 ：NAME IS NULL：2005/05/02(月) 13:48:23 ID:???

何言ってんの

542 ：NAME IS NULL：2005/05/02(月) 14:00:04 ID:???

アプリケーションの中でcreate table と drop table を繰り返すようなのが
結構ある。こういう場合、主キーも何もないね。

543 ：NAME IS NULL：2005/05/02(月) 22:48:18 ID:???

>542
>結構ある。

すげぇな

544 ：NAME IS NULL：2005/05/03(火) 00:33:41 ID:???

>>542
一時表じゃダメなのか・・・？

545 ：NAME IS NULL：2005/05/03(火) 06:44:00 ID:???

ローカルにMDBもってワークに使ってるほうがまだマシか。
と思ったらそのMDBから鯖にリンクテーブル張られててワケワカメ

546 ：NAME IS NULL：2005/05/03(火) 06:51:26 ID:???

>>543-544 create drop を連続して使うというのは言いすぎでした。ただ、
「データこそすべて」的身上でプログラミングしていると、どんどんtableを
作らなくてはならなくなる。たとえば、勤務表でAさんとBさんは不仲で同一
時間帯の勤務は不可と言う場合、不仲テーブルをつくり
A,Bの一レコードだけ書いておくことになる。前向き推論のようなロジックでは
データベースの煙詰めみたいなこともやる。プログラムロジックの大半を
データベースが担うとなるとほとんどのテーブルは極めて小さなもので
そんな場合、一々、主キーのことなんか考えないでしょ、というのが真意です。

547 ：NAME IS NULL：2005/05/03(火) 16:44:54 ID:???

何言ってんだか

548 ：NAME IS NULL：2005/05/03(火) 21:47:13 ID:???

>>547
女が多い職場の管理職は大変だよってことさ

549 ：NAME IS NULL：2005/05/04(水) 00:26:35 ID:???

不仲具合によって行数が変わったりしてな。
SELECT COUNT(*) FROM 不仲 GROUP BY 不仲名;

A,B | 500
A,C | 145
B,C | 1.67E16

550 ：NAME IS NULL：2005/05/04(水) 04:26:33 ID:???

ますます訳分からん。なんでいちいちテーブルを作る必要があるんだ？

551 ：NAME IS NULL：2005/05/05(木) 02:04:59 ID:???

DQNの子沢山と似たようjなもんか。

552 ：NAME IS NULL：2005/05/05(木) 03:53:22 ID:???

ｳﾏｲﾈ

553 ：NAME IS NULL：2005/05/08(日) 14:02:00 ID:???

不仲テーブル作って、合わないようにすればよいだけのような気がするが。

名前,不仲な人
山田,田中
山田,佐藤
佐藤,鈴木
鈴木,田中
田中,山田

ってやって、シフト更新するときになめればいいだろ。

554 ：NAME IS NULL：2005/05/10(火) 19:01:56 ID:???

主キーは本当にインデックスをフル活用しようとすると邪魔になる。
外部キーは心底テーブルのメンテナンスをしようとすると邪魔になる。

555 ：NAME IS NULL：2005/05/10(火) 23:59:05 ID:???

外部キーってのは参照「制約」だからそりゃ当然だ

556 ：NAME IS NULL：2005/05/11(水) 01:25:20 ID:???

>主キーは本当にインデックスをフル活用しようとすると邪魔になる。

詳しく。

557 ：NAME IS NULL：2005/05/11(水) 01:31:47 ID:???

主キーはともかく、外部キー制約は使いづらいことが多い。
リファレンス先のキーが複数のテーブルで使われてる場合は、
設計上外部キーであっても実装では制約にはしないことが多い。
リファレンス先に索引が必要なのは当然として、外部キー側にも索引が
必要なケースがほとんどであるがデフォルトでは索引は生成されない。
逆方向の索引なしでリファレンス先のキーを変更や削除した場合、
外部キー側にテーブルスキャンが発生することに注意しよう。
ただこういうレベルで外部キーを嫌がられても困るのだが。
「外部キー付けるとデータを入れにくくない？」

558 ：NAME IS NULL：2005/05/11(水) 02:03:54 ID:???

あーわかるわー。

559 ：NAME IS NULL：2005/05/11(水) 07:45:15 ID:+lelbHvj

外部キー制約は更新する場合に遅くなるしな！

560 ：NAME IS NULL：2005/05/11(水) 09:46:37 ID:???

「そんなこともしらないの」

561 ：NAME IS NULL：2005/05/12(木) 09:10:56 ID:???

正規化スレ落ちやがった…

562 ：NAME IS NULL：2005/05/12(木) 09:27:22 ID:???

頼むから正規化してください

563 ：NAME IS NULL：2005/05/12(木) 10:27:25 ID:???

○○
U

564 ：NAME IS NULL：2005/05/12(木) 12:48:28 ID:???

え～落ちたの。この板ではまれにみるまともなスレだったのに。

565 ：NAME IS NULL：2005/05/13(金) 12:46:49 ID:???

>>556
多分今だと改善されてるのも多いだろうと言う前提で、かつて設計担当した漏れの考え。

DBMSが勝手に名前付けちゃうと、使用するインデックスを明示して検索するのが面倒。
条件が限定されるが、参照する際の「該当無し」レコード用等でNULLを用いる事が出来ない。
インデックスを比較的頻繁に変更する事が想定される場合、主キーのみ手続きが別になる。

以上より、確かにフル活用する計画だと主キーは張らないかもしれない。

566 ：NAME IS NULL：2005/05/13(金) 13:06:27 ID:???

>DBMSが勝手に名前付けちゃうと

付けちゃわないと思うけど

567 ：NAME IS NULL：2005/05/13(金) 17:05:25 ID:???

ん？主キー宣言して自動的に付くインデックスの名前の事じゃないの？

568 ：NAME IS NULL：2005/05/13(金) 18:13:59 ID:???

RDBMSによって違うと思うけど、
Oracleの場合はﾃｰﾌﾞﾙ作成時にPK制約を付けると自動で名前が付くわな。

569 ：NAME IS NULL：2005/05/13(金) 18:39:25 ID:???

RDBMSによるけど明示的に名前をつける方法もあったと思う。
使ってる処理系では制約名がそのまま索引名になってました。
CONSTRAINT name PRIMARY KEY (col1, col2)
後からの追加はこんな感じでできる。
ALTER TABLE ADD CONSTRAINT name PRIMARY KEY (col1, col2)

570 ：NAME IS NULL：2005/05/13(金) 19:01:17 ID:???

>>565
索引を明示的に指定するのはAccessをISAM風に使うとき以外に
使ったことはないのですが、ヒントとかで指定するのでしょうか？

571 ：NAME IS NULL：2005/05/13(金) 22:57:42 ID:???

DB2なんかは>>569みたいな感じだな。
Oracleでも自動で振られた名前を変更できるんでしょ?
だったら主キーが邪魔になる事など殆ど無いと思うのだが。

572 ：NAME IS NULL：2005/05/14(土) 21:31:51 ID:???

>564

俺が最後に見たときで983いってたから時間の問題だったと思われ
誰か次スレ立てよろ

573 ：NAME IS NULL：2005/05/15(日) 03:57:48 ID:???

>>572
立てました。よろしくお願いします。

頼むから正規化しろよ　第二正規形
http://pc8.2ch.net/test/read.cgi/db/1116097001/

574 ：NAME IS NULL：2005/05/15(日) 22:33:00 ID:p5AU4cZr

昔にいた会社で上司いわく、自称もDB専門っていう奴がいて、
ユーザデータを管理するテーブルを

CREATE TableUser
(
ID int,
Value Text
);

みたいに定義して
あるユーザ番号のユーザのデータを取り出すには
IDが10から20のデータを取り出すみたいなことやってた奴がいた。
一部上場の某企業。

575 ：NAME IS NULL：2005/05/15(日) 23:17:24 ID:???

>574

情報が足りないから、その上司がおかしいのかそうじゃないのか判断がつかんな。
人のこと言うのはそういうところキチッと説明できるようになってからにするがよろし。

576 ：NAME IS NULL：2005/05/15(日) 23:42:32 ID:???

Valueってのが、コードとか名前とか住所とかもろもろ入ってて、
一人のユーザーの情報を取得するのにID10～20とか取るって
奴なんじゃないの？

森羅万象テーブルって奴ですか。
古い人はいまだに結構やるみたいですね。

577 ：NAME IS NULL：2005/05/16(月) 00:26:16 ID:???

>>576
それだったらまだマシ(w

名前
住所
電話

の項目をそれぞれ1レコードに格納して、
上のようにカラムが3つだと、ユーザ1の
データはID1からID3を取得するってやってた。

578 ：NAME IS NULL：2005/05/16(月) 00:50:33 ID:???

>>576
>>577

同じことを言っているような気がするが‥
問題は、ユーザー番号、データ種類のそれぞれとTableUser
レコードとの関係をどう表現しているかだ。

579 ：NAME IS NULL：2005/05/16(月) 00:58:12 ID:???

>>577
ユーザ1とID1・ID2は、どうやって結び付けてるの？

それを管理するﾃｰﾌﾞﾙが別途用意されてるの？

580 ：NAME IS NULL：2005/05/16(月) 02:08:22 ID:???

単純に10～19 20～29 みたいにやってそうな悪寒

581 ：NAME IS NULL：2005/05/16(月) 11:09:12 ID:???

>>577
すんません、言葉足らずで。同じ事言ってました。
森羅万象テーブルっていうそうなんです。

まだこの場合、ユーザー情報限定だけど、

・ID
・データ種別
・値

で、データ種別で区別して色んな情報を値につっこむなんてのが
本当にあるんだって！こわー。
リソースが貧弱だった頃の苦肉の策なんでしょうかね。

582 ：NAME IS NULL：2005/05/16(月) 12:27:52 ID:???

>>581
システム的にどーでもいいデータならいいんじゃない？
データ種別が TEL代表、TEL裏口、FAX、携帯、とか。

583 ：NAME IS NULL：2005/05/16(月) 12:31:41 ID:???

PostgreSQLあたりでテーブル継承駆使すると基底がそんな感じになりそうな気がしないでもない
継承使ったことないけど

584 ：NAME IS NULL：2005/05/16(月) 13:20:13 ID:???

継承をイメージしてそんな感じになったのならあるな
元のは実際には使わないpureクラスということで・・

585 ：NAME IS NULL：2005/05/16(月) 13:21:35 ID:???

>>582
それ森羅万象じゃなくて電話番号じゃないですか

586 ：NAME IS NULL：2005/05/16(月) 14:31:55 ID:???

森羅万象テーブルってのは
これか
http://www.amazon.co.jp/exec/obidos/ASIN/4534034733/
こっちか
http://www.amazon.co.jp/exec/obidos/ASIN/4534032501/
に出てた言葉だな。

業務に関わる所じゃ絶対にやらないけど
システム全体で使う定数の内、
後で変更される可能性がある場合なんかは
ソースで定数書かないでDBに持っておいたけど
森羅万象っちゃ森羅万象ぽかったな、あれは。

587 ：NAME IS NULL：2005/05/16(月) 17:58:28 ID:???

>>574-586 データ長に厳しい制限があった頃の設計かな。
10レコード取り出してconcatしてからsubstrするとか。
現在でも、長い項目を持つ組を作っておいて、substr()で分割する
viewを定義するテクニックは生きてますよね。

588 ：574：2005/05/16(月) 18:02:02 ID:d95wnL3s

こんな感じになっちゃいます。

1
山田タロウ
111-1111
2
田中ハナコ
222-2222
3
梅田とゑ子
333-3333

これで合計9レコード。２番目のユーザのデータ取得はIDが
４から６までって感じで。
遠まわしに上司に進言しても、彼にまかせているからで終わり。
DBバックアップすると自動的にソートがされるDBもあると思うけど、
どうなったのだろうか。

589 ：NAME IS NULL：2005/05/16(月) 19:25:35 ID:???

>>588
最悪だな・・・・

例えば、苗字に"梅田"が付く人の電話番号を取得するにはどうしたら良いんだ？

590 ：NAME IS NULL：2005/05/16(月) 19:40:17 ID:???

select t2.field from table as t1, table as t2 where t1.field = "梅田" and t1.id +1 = t2.id

591 ：589：2005/05/16(月) 20:46:08 ID:???

>>590
そうするしか無いよね･･･

ﾏﾝﾄﾞｸｾ･･･

592 ：NAME IS NULL：2005/05/16(月) 22:26:11 ID:???

ビューを作ればいいんだよ！

なら最初からテーブル作れってのは、無しよこの際。

593 ：NAME IS NULL：2005/05/18(水) 00:09:30 ID:Tq87rojf

>>581
すいません、教えてください。
区分やコード化されている全ての項目はユーザーが画面で管理できるようにメンテ画面を用意し
名称等は適用年月日を見て取得するルールだった場合、項目の種類毎にテーブルを作るのですか？
たとえ数が100以上あろうと。

594 ：NAME IS NULL：2005/05/18(水) 03:28:45 ID:???

>>593
パラメータテーブルつまりパラメータ名をキーにパラメータ値というのはありだと思う。
ユーザ毎に固有のパラメータをもつ場合にユーザー＋パラメータ名でキーとういのは許容範囲。
ここの例のようにデータの並び順に依存するようなものは許容外。
許容内でもRDB的にはパラメータとその値としてしか識別できないのでそのパラメータの
意味や関連はアプリケーション側で管理する必要がある。

595 ：NAME IS NULL：2005/05/18(水) 10:37:06 ID:???

>>594
パラメータテーブルって
>586が言ってる定数をハードコーディングしないで
DB側で持つ、ってのと同じ？
ならよくやりますね。

>593のはよく汲み取れないんだけど、適用年月日ってなんだろう。

596 ：NAME IS NULL：2005/05/18(水) 11:23:45 ID:???

>>593 もう一つ言ってる意味が理解できないのだが、多分、
最終的には私ならどんどん項目の種類ごとにテーブルを
作っちゃうな。

597 ：NAME IS NULL：2005/05/19(木) 13:28:25 ID:???

>>594
個人テーブル
個人ID, 名前, 更新日, その他検索等に使う項目....

個人その他項目テーブル
個人ID, 項目ID, 値

項目テーブル
項目ID, 種別名

って感じ？

598 ：NAME IS NULL：2005/05/19(木) 14:51:03 ID:???

同じテーブルの別々のレコードの同じカラムが
まったく別の意味を持ったデータなのが問題なんだって

599 ：NAME IS NULL：2005/05/24(火) 18:35:25 ID:???

市町村合併で同じ郵便番号で住所が変わる、みたいな感じ？
それがあらかじめわかってればレコードに埋め込んじゃうかなあ。

600 ：NAME IS NULL：2005/05/24(火) 19:09:38 ID:???

そりゃ混ざってても住所は住所なんでないかい？

601 ：NAME IS NULL：2005/05/24(火) 22:30:44 ID:???

わかってない人が多いみたいですね。

つまり、それだけ非道い設計って事だよね。

602 ：NAME IS NULL：2005/05/24(火) 22:51:39 ID:???

ここで語られている流れが理解できない奴は、
そんな設計など思いもよらないマトモな思考の持ち主か、
そんな設計に全く疑問を抱かない狂人かのどちらかに違いない。

603 ：NAME IS NULL：2005/05/25(水) 07:51:54 ID:???

>>594 のいうパラメータテーブルは
フィールドの内容と同時に意味もデータとして管理する手法でISAM的には間違いではないが、
関連や結合や集合演算などリレーショナルデータベースの特徴的な機能が使えなくなる。
他と関連があるデータ項目には使うべきではない。必要がある場合は自己責任で使うこと。
>>588 は順次編成ファイルでまれに見られる手法で、ISAMから見てもセオリーから外れる。
>>599 は住所のキーとして郵便番号が不適切だという話であまり関係なさそうだ。

604 ：NAME IS NULL：2005/10/29(土) 02:04:15 ID:???

複合キーはそろそろ絶滅してくれ

605 ：NAME IS NULL：2005/10/31(月) 10:11:59 ID:???

基本的に複合キーってビジネスロジックだもんな

606 ：NAME IS NULL：2005/10/31(月) 12:20:25 ID:???

Webシステムで複合キーだとFormの書き出し/受け取りで結構めんどくさいことせにゃならん上に
必然的に自然キーなので変更されてビュー側まで含めた大改修になることがしばしばあるよなぁ

607 ：NAME IS NULL：2005/11/03(木) 17:48:35 ID:???

（以前）ウチトコで他社と共有していたデータは
主キーが入ってたり入ってなかったりしてたがね。

抜けてるんだけどって聞いたら、まだ入れてないって返答が。

どーすりゃいいのかと。しかもマスターデータは他社にあるので
こっちで入力した分は他社に返すという。ｱｯﾋｬｯﾋｬ!ヽ(ﾟ∀ﾟ)ﾉｱｯﾋｬｯﾋｬ!

この案件は案の定潰れたがね。( ﾟДﾟ)y─┛~~

608 ：NAME IS NULL：2005/11/18(金) 11:22:54 ID:???

主キーがないテーブルよりも、
主キーの列を丸々切り捨てられたテーブルの方が恐怖だと思うが････

エクセルしか知らない社長さんが、
自社の顧客管理システムのDBでやらかしたって話を聞いたことがある

609 ：NAME IS NULL：2005/11/18(金) 11:39:55 ID:???

>>1->>50 辺りに戻るけど
そもそのキーっているのかな。

610 ：NAME IS NULL：2005/11/18(金) 11:41:31 ID:???

そもそのキーって -> そもそもキーって

611 ：NAME IS NULL：2005/11/18(金) 12:39:02 ID:???

その行を一意に指定できて作成時から変わらないもの

612 ：NAME IS NULL：2005/11/20(日) 18:54:02 ID:???

主キーの更新難しくしてくれりゃいいのに

613 ：NAME IS NULL：2005/11/21(月) 00:11:04 ID:???

DBA権限をきちんと管理するだけでいいような・・・

614 ：NAME IS NULL：2005/12/08(木) 18:08:58 ID:???

全部見終わった。

* 主キーが必要なテーブルなのに付いてなくて冷や汗出てる場合。
* 主キーが不要なのに、無いテーブルを見つけて騒いでる痛い場合。

があるように見える。

業務自体をうまくビジネスロジックに分析して、主キーの有無やどれを主キーにするかって設計が必要な感じだな。
ところで業務の都合上で項目追加に成った場合は、主キーも再検討が必要ってこと？
業務の内容が変わって行くとビジネスロジックも変更が必要で、いかに汎用性の有るビジネスロジックと主キー設計が出来るかって設計者の腕の見せ所だけど、やっぱり失敗を繰り返して苦労して経験として養って行くしか無い？

伝票でも帳簿でもログ処理でも通用するような、有る程度汎用性を考慮したレシピ的な理論が欲しいかも。

615 ：NAME IS NULL：2006/01/13(金) 12:24:45 ID:???

>>614
>ところで業務の都合上で項目追加に成った場合は、主キーも再検討が必要ってこと？
つうより、そのテーブルに追加管理したい項目をどこのテーブルに追加するべきかを検討するんでしょ。
無いなら新規テーブルじゃない？

>伝票でも帳簿でもログ処理でも通用するような、有る程度汎用性を考慮したレシピ的な理論が欲しいかも。
くれくれくんかよｗ。そんななら自分で決めて他人に強制すればいい。

616 ：白馬の玉子 ◆PqSzNbkqDo ：2006/04/12(水) 12:23:39 ID:???

某N社が作った、文教系のシステム見たことあるけど、
DBがOraだったけど、もろオフコン。
主キーなくて、フィールド4つ以上でやっと複合キーになるし、
同じ内容なのに、テーブル3つに分かれてるし・・・。
それなりの設計思想なんだろうけど、
時代を感じたな。
それでｘｘ億円くらいとってたらしいけど・・・。
高速化のため！とか主張してたが、
見た感じ、遅くなる要素、満載だった・・・・・・・・。
ほとんどの更新系が、VBで Select - While not EOF - Select Case - Update - Loop のレコード総当りで書かれてて、
うわぁぁぁぁ！！！って感じ・・・・・。
それで高速化！とか威張られても、ねぇ・・・大手のN社さん！
Oraの機能、まったく活用してねージャン。

617 ：NAME IS NULL：2006/04/17(月) 14:15:09 ID:???

ウチのシステムは、オフコン時代の名残で
論理ファイル (ビューとインデックスのセットみたいなもん) が200ぐらいある。
そして、画面とロジックと使用テーブル宣言のセットで1プログラム。
再利用とか保守性とかの概念が生まれてなかったらしい・・・

618 ：NAME IS NULL：2006/04/18(火) 01:19:28 ID:/VTC9Lb+

>>617
ストレートにAS/400と書けｗ
しかし、ホントに再利用とか保守性とか考えねーよな。
なぜ楽をするための努力を惜しむのかと。
いくらでも楽できる機能があるのに、だれもつかいやしねぇ。

619 ：617：2006/04/18(火) 10:08:48 ID:???

うはw ばればれww

620 ：NAME IS NULL：2006/04/18(火) 21:07:36 ID:???

>>617
うちもその口(AS400)だったけど
保守性の概念がない⇒
いくらでも残業代が出る
＆毎日徹夜してシステムを守るのがシステム部門の美徳みたいな風習があった
＆独身で家庭がない人が担当者
再利用の概念がない⇒
ステップ数で開発費が決まる
＆担当システムの規模が大きい方が会社は俺が背負ってるんだみたいな気になれる
＆独身で家庭がない人が担当者
大抵こんな所に原因がある気がしたyo

621 ：NAME IS NULL：2006/04/19(水) 09:49:17 ID:???

うちのｵﾌｺﾝ組も同じ感じだな。
特にSQLを理解できない、しようとしないPMと言われている人に、その傾向が強い。

ERwinが社内標準なのにEXCELでファイル設計するよ(T-T)
↓
漏れが、ERwinで打ち直す。
↓
2重管理＆正規化大混乱。
↓
どうやら漏れが悪い事になってるらしい
↓
管理方法等を相談
↓
PM精神論にﾊｼﾙ or 丸投げ↓
　＿
.＿
（　゜ A ゜；）

こんな毎日ですが、ﾜﾀｼﾊｹﾞﾝｷﾃﾞｽ。

622 ：NAME IS NULL：2006/04/19(水) 11:12:42 ID:???

悪いのは全部他人？自分の問題点が分かってないようだね…。

623 ：NAME IS NULL：2006/04/19(水) 12:06:42 ID:???

>>622
何が言いたいのか分からん。
言葉が足りないのでは？

624 ：白馬の玉子 ◆PqSzNbkqDo ：2006/04/19(水) 12:53:02 ID:???

以前仕事した某大学の担当(一応、中堅の管理職)は、
VisualStudio＋SQLServerで組んでるっつーのに、

「作業工数管理したいから、ステップ数出して！」

だって・・・・。

その瞬間３秒ほど、回答詰まって体が固まったYO・・・・。

クラス数とか、オブジェクト構成とか、そういった要望なら理解できるけど、

「ステップ数」！！！

だよ！？

あとでうわさ聞いたら、頭の中がCOBOLな人らしい。

前世紀の遺物だな、あーいう管理職は・・・・。
プロジェクト進行の邪魔だから、馬鹿な管理職はさっさと進でください！

625 ：NAME IS NULL：2006/04/19(水) 13:32:39 ID:???

ステップ数・・・
プログラムのソースならともかく、DBの場合はどう出すつもりなんだろう。

626 ：NAME IS NULL：2006/04/19(水) 15:46:10 ID:???

まぁ、クラス数とかオブジェクト数ともに、
言われたとおりステップ数もだせばいいじゃん。

627 ：白馬の玉子 ◆PqSzNbkqDo ：2006/04/19(水) 17:18:44 ID:???

>>626

オブジェクト構成の詳細は図式数値ともに、あえて出さなかったよ。
出しても、誰も読めないらしくって、以前設計時にUML3パターンほど出したら、
なにこれ、こんなもん必要ない！ってつっぱねられたのさ。
それより、操作説明書出せ！だってさ・・・
設計時に操作説明書出せって、その要求、なによ・・・・。
しまいには、客先の年間業務スケジュールまで分析させられて、
いわく、「部署内の誰も、完全な年間のスケジュール、わからないんだよねぇ～」だと。
っつーか、それが管理職であるおまえの仕事だろう！とつっこみたかった。。。。

で、とりあえず、PGのステップ数は提出したけど、
業務効率悪いねぇ～～～だってさ。
UIデザインにどれほど時間がかかって、
背後でどれほどのストアドが記述されてると思ってんだ、このばかちんがぁ！

ちなみにこの大学の旧システムの学生テーブルの主キーは、
5桁「学生番号」なんですが、
この学生番号の年度を表現する桁が1桁しかなくて、
10年ごとに過去の学生を別のOBテーブルに変換格納しないとOBが消滅するしくみに
なってました。すばらすぃ・・・・。
それは「主キー」とは言わないのでは？？
こんな馬鹿システム作った某社、最高っす！
おかげで、俺は、学生の管理のために、複合キー地獄です・・・。
高速化なんて、できやしねーってよ。
おまけに、過去のゴミデータがいて、絶対的にキーになる複合キーフィールド群において、
重複データが存在する始末・・・。
もういやです、ほんと、文教系の仕事って・・・。
アカデミズムからは程遠いですよ、ほんとに。
学校の職員教員って、馬鹿ばっか・・・・・。
（っていうか、「自分で責任取れない君」、ばっかり・・・。）

あぁ・・・・仕事しよっと・・・。

628 ：元COBOL使い：2006/04/19(水) 17:32:27 ID:???

一行に一命令のCOBOLなら意味があるやもしれんが。

無駄と思っている事を、無理強いすると、いい加減な仕事ふえるよ。
目的って重要です。

629 ：NAME IS NULL：2006/04/20(木) 21:15:32 ID:ds1Y0fKR

ステップ数を出すだけなら、出来合いのソフトもあるだろうし、
簡単でいいじゃん。上がそれで納得するならｗ

自分が欲するものを作るんじゃなくて、相手が欲しいものを作るのが
PGやSEの仕事なんだし。客だけじゃなくて上司でも同じだと思う。
まあ、社内改革するのなら徹底的に闘ってくれｗ

630 ：NAME IS NULL：2006/04/20(木) 21:19:29 ID:ds1Y0fKR

>>627
大学事務員と、教授～講師をいっしょにしないように。
事務員はプログラムなんて知らない。
ふつうの会社の事務と同じ。

631 ：白馬の玉子 ◆PqSzNbkqDo ：2006/04/20(木) 22:08:55 ID:???

>>629

「上がそれで納得するならｗ」
　↑
この時点で、俺と仕事への姿勢が違うもんね。
理解できなくて当然っすよ。

なんか、スレの主旨とあわなくなっちゃったので、ごめんなさい＞＞みなさん。
このネタはしゅーりょーしときます。

632 ：NAME IS NULL：2006/04/20(木) 22:27:43 ID:ds1Y0fKR

>>631
>>627を読んでも、どこかで勘違いしている臭いがプンプンするけどね。
ま、ひとりよがりで突っ走ってくれｗ

633 ：元COBOL使い：2006/04/20(木) 22:57:17 ID:???

(　´∀｀)ｵﾏｴﾓﾅｰ>>632

>自分が欲するものを作るんじゃなくて、相手が欲しいものを作るのが
客が本当に欲っしているのは、正確な見積もりとその根拠だと思うが。

>まあ、社内改革するのなら徹底的に闘ってくれｗ
無馬犬...(ﾟ∀ﾟ)ｱﾋｬﾋｬﾋｬﾋｬ

634 ：NAME IS NULL：2006/04/21(金) 10:01:25 ID:CX6yg83T

>>633
＞客が本当に欲っしているのは、正確な見積もりとその根拠だと思うが。
何？このずれた会話は。

マ板でよく見るがCOBOL使いの設計は最悪らしいが、>>633のレスで確信した。

635 ：元ＣＯＢＯＬ使い：2006/04/21(金) 19:12:24 ID:???

飛躍しすぎと言う突っ込みならば、納得もしたが。。
まぁ、ｵﾏｲさんの受け身な姿勢とﾚﾍﾞﾙは分かったよ。

ｽﾚ違いｽﾏｿ

636 ：NAME IS NULL：2006/04/21(金) 21:04:01 ID:HfZIsICF

＞ｽﾚ違いｽﾏｿ
わかっているなら最初から来るな、ヴォケ。

637 ：元ＣＯＢＯＬ使い：2006/04/21(金) 22:23:26 ID:???

必死だな（ﾌﾟ

638 ：NAME IS NULL：2006/04/22(土) 00:08:01 ID:???

複合主キーは悪くないじゃん。
現実には存在しない代用キーを多用されるほうが嫌だな

639 ：NAME IS NULL：2006/04/22(土) 01:12:48 ID:???

ローが一意になればなんでもいいよ
たとえUUIDでも無いより100万倍マシ

640 ：NAME IS NULL：2006/04/22(土) 01:38:52 ID:???

まぁ、元COBOL使いとか言ってるところ見ると30才過ぎてること明白だが。
30過ぎて2chやっててはずかしくないのかな？？
俺が同じ立場なら2chなんかやらん。
それに2chやってるところ見ると未婚者っぽさそうだけど、システムをしっかり設計できるなら、
システムよりも自分の人生をしっかり設計したほうがいいぞ。

641 ：NAME IS NULL：2006/04/22(土) 01:41:39 ID:???

それに誰に対して必死だなとか言ってるのかよくしらんが、
30過ぎたおじさんが、年下っぽさそうな相手に必死だなとか言ってる方が
俺は必死に見える。

642 ：NAME IS NULL：2006/04/22(土) 01:42:18 ID:???

2ちゃんで説教するのはさらに恥ずかしい

643 ：NAME IS NULL：2006/04/22(土) 08:46:27 ID:???

>>640
＞俺が同じ立場なら2chなんかやらん。
こういうことを言っている奴ほど、
将来、２ちゃんでなくても似たようなことは絶対やっていると思う。
未来のことに対して言い切る奴って、だいたい無責任だし。

644 ：NAME IS NULL：2006/04/22(土) 09:22:12 ID:???

俺も640は30過ぎても2chに来るに3000カラム

645 ：NAME IS NULL：2006/04/22(土) 10:20:17 ID:???

>>641
しらじらしい切り口から始まり
次の行で、さっそく矛盾
最後の行は、棚上げで締める

ヘタな政治家の人みたいで、おもしろいとおもいました。
又、ここへ来た30代以上を、全てを敵にまわす発言も、
すごい勇気だとおもいました。

えーと、主キーの話だっけ？
あれは、いいよねぇ～

646 ：NAME IS NULL：2006/04/22(土) 14:20:26 ID:+UsjqiTM

1の言ってるシステムは
CSVの代わりにセキュリティ高くなるからと勘違いしてDBに移行したケースじゃねえか？
CSVで作るシステムにわざわざPK設定しねえし
CSVの代用ならそれでもいいけど
どっちにしろPKつけた方が楽になるけどね

647 ：NAME IS NULL：2006/04/22(土) 14:58:51 ID:???

PKK

648 ：NAME IS NULL：2006/04/23(日) 01:42:55 ID:???

で、おまえらは既に30歳すぎてるわけ？？

649 ：NAME IS NULL：2006/04/23(日) 01:48:32 ID:???

で、ぶっちゃけそうじゃねぇ？？30才すぎてこんなとこいたら、普通の人は
あんまいい人生送ってないっていうか、人生設計した方がいい人たちばっかって普通は思うよ。
それとも、おまえらは特殊すぎて、普通の友達とかいないから、普通の考えわからんかな。

650 ：NAME IS NULL：2006/04/23(日) 05:58:01 ID:6VARQ0Cr

・・・と書いて自分を安心させたい30代の>>649でしたｗ

651 ：側近中の側近 ◆0351148456 ：2006/04/23(日) 08:53:52 ID:???

>>649
(っ´▽｀)っ
データベース設計より人生設計しろってか。
座布団3枚だね☆

652 ：NAME IS NULL：2006/04/23(日) 10:45:24 ID:???

>>651
その座布団は>>640に渡すべきだな。

653 ：NAME IS NULL：2006/04/23(日) 12:39:43 ID:???

というか、このｽﾚこんなに人がいたんだな。
わしゃ、後もう少しで30代の仲間入りさ～。

まぁ、2chは混沌としているが、過信しなければ、
いい情報源だよ？　と、正当化してみるﾃｽﾄ。

654 ：NAME IS NULL：2006/04/23(日) 15:14:42 ID:???

ﾃｸﾃﾞ取得の平均年齢が、30代前半という事からも、
実は、その辺の年齢層が一番多く
かつ、ﾁｮｳﾄﾞ気になり始めている頃と考えられる。

確かにｽｺﾞｲ勇気だ
　　_、_
（　._ノ` )y━・~~~

655 ：NAME IS NULL：2006/04/24(月) 03:06:21 ID:???

>>653の人しか答えないね。
他の人は答えるの避けて、他の俺に対する発言してんのかな？？
やっぱ、避けてんでしょ？？
>>654
君の言葉を借りると、俺の発言に反応してる人は君も含めて、30代前半であたってるから、
反応してるってことでＯＫ？

656 ：NAME IS NULL：2006/04/24(月) 12:37:03 ID:???

>>653ていうか、あんた誰？

657 ：NAME IS NULL：2006/04/24(月) 15:08:05 ID:???

>>656
元COBOL使いですがﾅﾆｶ？

658 ：NAME IS NULL：2006/04/24(月) 19:37:36 ID:???

>>655
俺はお前が誰なのかが疑問だ

659 ：NAME IS NULL：2006/04/24(月) 23:30:24 ID:z7GeGS14

>>646
ORACLEで主キーを指定できるようになったのは何時頃から
だろう。バージョンは?　私は詳しく知らないが、たぶん
1990年頃、version6.0くらいからだろう。つまり、Excelが
流行し始めた頃でそんなむかしのことではない。それまでは
主キーの概念は理解していたが、実装となると単にindexファイルを
作成するだけだった。
ということは、1980年代に作成されたORACLEのシステムだと、
主キーなんてなくて当たり前のことなのだ!!

660 ：NAME IS NULL：2006/04/25(火) 03:12:41 ID:???

へー

661 ：NAME IS NULL：2006/04/25(火) 23:58:52 ID:???

>>658
オラ、悟空

662 ：NAME IS NULL：2006/04/26(水) 20:13:48 ID:???

>>639
>たとえUUIDでも無いより100万倍マシ
実はちょっと前からこれが気になっているんだが、
冷静に考えてみて、これって悪いのかな、と。
どっかでこれの是非とか読んだような気もするんだが、
思い出せん。
(なんかMSのASP.NETのProfileとかがUUIDなんだとかも聞いた気がする)

663 ：NAME IS NULL：2006/04/26(水) 20:24:38 ID:???

UPDATE時に、どの行を更新するの？

664 ：NAME IS NULL：2006/04/26(水) 21:36:27 ID:???

まぁ、適当に、良きに謀らいますが、結果には責任持ちません。

665 ：NAME IS NULL：2006/04/27(木) 11:02:09 ID:???

プログラム上はUUIDでいいけどな
結合無しでデータ見る場合連番より分かりにくくなるけど

666 ：NAME IS NULL：2006/05/10(水) 01:08:44 ID:???

同じテーブル２世代間の差分を取ってくれって言われたんだが主キーがなかった。

667 ：NAME IS NULL：2006/05/11(木) 15:59:02 ID:???

全カラム使って差分だせば？
その結果を見て違うと言う人がルールを知ってるのでしょう。。

668 ：NAME IS NULL：2006/05/23(火) 02:08:54 ID:???

MS SQL ServerのバックアップをAccessのMDBファイルに取ってるやつが
いたのね。「データのエクスポート」で取るとき、設定次第でどうなのか
知らないけどそいつの環境の設定は、MDB側に主キーの情報が反映
されてなかったのよ。それでそいつ、知らずに何度もおなじMDBに
エクスポートしてて、同じ主キー値のレコードが複数出来ちゃって
困ってた。
もうちっと仕事覚えてくれよ・・・

669 ：NAME IS NULL：2006/05/23(火) 20:37:32 ID:???

最初はそうやって覚えていくもんさ

670 ：NAME IS NULL：2006/06/04(日) 17:08:59 ID:???

>>MS SQL ServerのバックアップをAccessのMDB

データ型が変わるから、気をつけろー。（長井風　古いか。。

ってか、開発時のデータならまだしも、本番データをMDBに
バックアップって、問題ないの？

671 ：NAME IS NULL：2006/10/28(土) 18:48:42 ID:GOZLHMAZ

医療系は、もう最悪だよ・・・

oracle+VBで、ヘルプで参加した際、まずPKないなんて普通。
カラム名は日本語で300カラム以上。（備考1、備考2・・・みたいに）

SQL書くだけでも、もううんざりした上に、納品後、カラム名が可変とか言い出した。

もう死ね！！氏ねじゃなくて死ね！！エクセルでも使ってろ！！

672 ：NAME IS NULL：2006/11/04(土) 10:09:33 ID:ww13bNDf

１０年後>>649は「40才すぎてこんなとこいたら」
と言ってると思う。

673 ：NAME IS NULL：2006/11/04(土) 18:31:05 ID:???

主キーはあるんだけど、主キーに対してガンガンUPDATEをかけるテーブルがあるアプリなら経験がある。

key1 key2 data1 data2 data3 とカラムがあるテーブルで、data1、data2、data3をキーとしてkey1、key2に対してアップデートをかける。
「これおかしいお！」とリーダーに言ったら、「本当はこのテーブルはdata1、data2、data3が（業務的には）キーなんだよね」だって。
業務的にキーならそっちをキーにしろよと・・・。

674 ：NAME IS NULL：2006/11/05(日) 07:22:44 ID:AbI7e55r

つうかお前ら全員ﾃﾞｰﾀﾍﾞｰｽの試験受けて来いよｗ

675 ：NAME IS NULL：2006/11/05(日) 22:09:34 ID:???

テクニカルエンジニア(データベース)なら合格したがこないだASIDをちゃんと説明できなかった俺が来ましたよ

……もっぺん勉強せにゃorz

676 ：NAME IS NULL：2006/11/05(日) 23:16:22 ID:???

>>671

ﾜﾛﾀwｗ
リレーション概念ないんだな、それｗｗｗ

677 ：NAME IS NULL：2006/11/28(火) 00:42:42 ID:2uKzX2xW

今までデータベース使ったことないのに、今度オラクルを使うプロジェクトに投入されました。
プロジェクトで使うテーブルは作成完了していたんですが、
キーとしているのが製品名で、製品名をキーにもつ関連テーブルが全部で１３０個くらいあります。
製品名を変更したりする場合は「製品名保持テーブル一覧テーブル」を使って
ループしながら１３０個のテーブルの製品名をアップデートしたりしています。世の中のプロジェクトでは
こういうテーブル設計は一般的なんでしょうか？
製品名テールを作って、内部的にはユニークな番号を使って管理すれば製品名変更は
テーブルひとつ書き換えるだけですむのでは？という話をしたところ「HDDを余計に食いつぶすし、
番号使ったら直感的に分からなくなるしクソ設計だ」といわれてしまいました。

678 ：NAME IS NULL：2006/11/28(火) 01:38:39 ID:???

ネタだよなあ・・・

679 ：NAME IS NULL：2006/11/28(火) 02:10:56 ID:???

ネタだろうけど、どっかには本当にいそうでこわひ

680 ：NAME IS NULL：2006/11/28(火) 02:30:35 ID:???

俗にでんぱつ（伝票発行）システムと呼ばれるものにはこういうのも無くは無いな。
なぜか取引毎にテーブルがあって数だけは多いとか。

681 ：NAME IS NULL：2006/11/28(火) 09:27:00 ID:???

本当だったら鼻でピーナツ食ってやる

682 ：NAME IS NULL：2006/11/28(火) 21:39:20 ID:???

みなさんの反応から、今のプロジェクトのテーブル設計が一般的でなく、
悪いものだという事が分かりました。ありがとうございます。

683 ：NAME IS NULL：2006/11/28(火) 22:00:56 ID:???

>>680
伝票の場合は過去の製品名で表示したいとかあるので
名称も項目として持つことがありますな

684 ：NAME IS NULL：2006/11/29(水) 00:31:20 ID:???

>>683
tgkさん？

685 ：NAME IS NULL：2006/11/29(水) 03:43:07 ID:???

>>683
製品名の履歴として管理すればいいだけでは・・・

686 ：NAME IS NULL：2006/11/29(水) 06:16:04 ID:???

>>685
数百万レコード超となることが多いので
重いJOIN減らすため埋め込むのれす

687 ：NAME IS NULL：2006/11/29(水) 08:18:21 ID:???

単価なんかはトランザクションデータに
スナップショットをとっておく事が多かったな。

最近販売管理関係やってないなあ。

688 ：NAME IS NULL：2006/11/29(水) 09:37:35 ID:???

そりゃT/Rはキーの従属項目も取るけどな。必要だし。
>>680 の場合は
>キーとしているのが製品名で、製品名をキーにもつ関連テーブルが全部で１３０個くらい

うへぇ or2=3

689 ：NAME IS NULL：2006/11/29(水) 10:52:00 ID:???

キーを更新するなんてあり得ない！
糞重たくなると思うのだが？

690 ：NAME IS NULL：2006/11/29(水) 16:50:32 ID:???

主キーとインデックスの違いがわからない。
インデックスのカラムで検索させれば検索速度あがるんだよね？状況によっては遅くなるらしいけど。
んで、主キーは何に使うの？同じく、検索速度あがるの？

691 ：NAME IS NULL：2006/11/29(水) 17:09:23 ID:???

ごめんいま面白い事いえない。

692 ：NAME IS NULL：2006/11/29(水) 19:44:04 ID:???

>>690
このスレを眺めて自分なりの結論を出せ。（ｗ

【恐怖】主キーがないテーブルみたことありますか？
http://pc8.2ch.net/test/read.cgi/db/1069324950/

693 ：NAME IS NULL：2006/11/29(水) 20:12:58 ID:???

>>692
＞【恐怖】主キーがないテーブルみたことありますか？
このスレがこれなので無限ループに陥りそうだ

>>690
主キーは行を一意に識別するもので、
ユニークで非NULLであるという制約を持つ。これが主キー制約。
主キー制約を実現するためにＲＤＢでは索引を使用している。

CREATE INDEX命令はANSI SQLには含まれていないよね確か？

694 ：NAME IS NULL：2006/12/02(土) 01:48:42 ID:???

恐怖だもんな

695 ：NAME IS NULL：2006/12/04(月) 14:58:02 ID:???

昨日までこれがユニークKeyだと言われてた項目が
ユニークではなかった。

仕様策定者のせりふが忘れられない、

「えぇ。では、○○もKeyという事にしましょう。」

世の中、「では」なんて軽い言葉では済まされない事もあるんだよ・・・

696 ：NAME IS NULL：2006/12/04(月) 17:18:05 ID:???

あぁ。なんか俺よく言ってそうだそれ。

697 ：NAME IS NULL：2006/12/04(月) 18:44:00 ID:???

システム的には「では」で簡単に済ませられない問題だけど
お客さんにとってはそんなもんだよなあ。
しかたないと思うよ、その策定者のセリフは。

698 ：NAME IS NULL：2006/12/04(月) 19:22:52 ID:???

>>697
ユニークと聞いていたのに、対向システムでいつの間にか崩れていたことがあったな。
ダブったデータはどうすればいいかとお客さん経由で問い合わせたら、
「適当に処理しといて」という返事寄越しやがって、お客さんも怒ってた。(w

699 ：NAME IS NULL：2006/12/05(火) 12:41:25 ID:???

>>698
ﾊﾞﾛｽ

700 ：NAME IS NULL：2006/12/06(水) 00:22:38 ID:???

主キーがだいしゅきーとか言ったりしてなゲハハ

701 ：NAME IS NULL：2006/12/06(水) 12:00:47 ID:???

誰か、>>700も適当に処理しといて

702 ：NAME IS NULL：2006/12/06(水) 13:11:45 ID:???

DROP >>700

703 ：NAME IS NULL：2006/12/06(水) 13:55:48 ID:???

アッコちゃんアッコちゃん主キー主キー
って超定番でもう誰もいわない。

704 ：NAME IS NULL：2006/12/06(水) 14:59:50 ID:l9nu+9X3

>>703
こうやって誤魔化しながらいってるやつってのは、ほんとうはそれを言いたいわけだ。
１行目が本音で２行目が照れ隠し。

705 ：NAME IS NULL：2006/12/06(水) 15:24:47 ID:???

えへへ、いじわる。

でもほんとは>>330で既出なの。
俺じゃないけど。

706 ：NAME IS NULL：2006/12/06(水) 15:43:38 ID:???

>>330 = >>703
親父ギャグは笑うまで繰り返すの法則。

707 ：703=705：2006/12/06(水) 15:53:12 ID:???

えーちがうよ
でもがんばって繰り返すよ

708 ：NAME IS NULL：2006/12/06(水) 16:57:49 ID:???

じゃあ次のステップは「笑わないと怒る」だ

709 ：703=705：2006/12/06(水) 17:46:14 ID:???

なんだと！バカにするな！

710 ：NAME IS NULL：2006/12/06(水) 21:22:52 ID:???

>>700-709までは一人芝居じゃねーの？と思う俺であった・・・南無南無

711 ：ISNULL(NAME, NULL)：2006/12/16(土) 14:24:46 ID:???

>690
　主キーはその表に入るデータ(行)を一意に識別することができる1列以上の列の組み合わせの
うち、もっとも重要な列(の組み合わせ)に対して与える称号。
　インデックスは、よく検索される列を検索しやすいようにあらかじめ作っておく索引。本の索引と
同じようなもの。インデックスは項目が一意になるユニークインデックスと項目が重複してよい
(普通の)インデックスがある。
　主キー制約をつけると、「その表に入る行を一意に識別することができる1列以上の列の
組み合わせ」という制約を実現するために勝手にユニークインデックスがつく。

　主キーはモデルを作るときに「その表に入る行を一意に識別することができる1列以上の列の
組み合わせのうち、もっとも重要な列」をあらわすしるしで、それを実装で実現する手段が
ユニークインデックスなのだ。

712 ：NAME IS NULL：2006/12/17(日) 23:38:44 ID:c8T56vdc

ID生成器が他にあるのなら要らないんじゃないかな。

713 ：NAME IS NULL：2006/12/18(月) 21:30:35 ID:???

次スレがあるなら、「主キーが20列以上のテーブルみたことありますか？」

714 ：NAME IS NULL：2006/12/19(火) 01:01:11 ID:???

>>713
どうやったらそんな気色悪いテーブルが作れるのだろう？
１列＝１バイト？？？

715 ：NAME IS NULL：2006/12/19(火) 01:28:30 ID:???

ユニーク特性のために5つくらい主キーってのは見る。
まあ代理キー＋ユニークも綺麗とは思わんから構わん。

716 ：NAME IS NULL：2006/12/23(土) 00:14:16 ID:fExmKA+s

主キーがないとはちょっと違うんですが、今のプロジェクトではフィールド数が可変なテーブルが出てきて難儀しています。
使わなくなったフィールドは無視するだけなんで基本的に減ることはないんですが、仕様が追加されたらそれにともなって
フィールドをどんどん追加していくそうで。
フィールド数の変化するテーブルに関しては、フィールド名テーブルを別に作って管理するらしーんですが、
フィールドが増えてくっていうのに慣れなくて、、、
いろんな設計があるんだなぁ、と思う今日この頃です。

717 ：NAME IS NULL：2006/12/23(土) 10:24:23 ID:???

＞フィールド数が可変なテーブル
まあ、最初からそれを想定しているならそれもアリだろうけど
使わなくなったフィールドを無視するのは単に頭が悪いと言うか
正規化の概念がないだけだとｵﾓ。

あと、多くのRDBはフィールド情報を保持したテーブルを
システムで自動的に管理しているので、
「フィールド名テーブルを別に作って管理」と言うのは
正直なところ、アホの子と思わなくもない。

718 ：NAME IS NULL：2006/12/23(土) 12:34:29 ID:???

2，3年前に逝ってた会社（とある投信会社）で主キーが無い奴作った。というか、
「これを参考にして作れ」っていわれたのがそういう奴だったんで、
「はぁ、そうですか」というわけで。

作ってる最中から「これでいいのか｝」とは思ってたけど、どうせ俺の知ったこっちゃ
ねーし。

719 ：NAME IS NULL：2006/12/24(日) 15:06:06 ID:???

いろんなレイアウトのCSVを一時的に取り込むために主キー無しのテーブル使ってる

720 ：NAME IS NULL：2006/12/24(日) 20:38:04 ID:???

>>719
その場合でも後から処理順とかを追えるように、
シーケンス使って連番振らない？
まぁほんとのワークテーブルならそれも不要ってことかな？
手間と整合性のトレードオフですか。

721 ：NAME IS NULL：2006/12/26(火) 00:45:46 ID:???

>>719
俺の場合、そういうデータは外からスクリプトでゴニョゴニョするので、
データ特定のためのシーケンスは必ずつけるようにしている。

722 ：NAME IS NULL：2006/12/26(火) 01:50:54 ID:???

シーケンス振るにしてもそれをPKにするかどうかは別問題じゃない？
10万件取り込んで数回SELECTして終わり、とかだと
PK無しにすることによるパフォーマンス面でのメリットが大きかったり

723 ：NAME IS NULL：2006/12/26(火) 21:53:08 ID:???

そこまでテンポラリなデータならシーケンシャルファイルにそのまま置いとくけどね。
＞パフォーマンス面でのメリット
ってそれほどのもの？

724 ：NAME IS NULL：2006/12/26(火) 23:32:32 ID:0tnnv+Jg

>>716
その辺決めた奴、COBOLERじゃね？

後ろにフィラーをあらかじめ多めにとっておいて、必要になったら取り崩していく。
レイアウトはdata-division(だっけ？)に台帳からコピーして修正。

725 ：NAME IS NULL：2006/12/27(水) 22:55:55 ID:???

間違いなくコボラだなw

726 ：NAME IS NULL：2006/12/27(水) 23:16:42 ID:???

せめてPro*COBOL使え＞＞ばかコボラー

727 ：NAME IS NULL：2006/12/27(水) 23:18:20 ID:???

悪かったな

728 ：NAME IS NULL：2006/12/28(木) 01:52:59 ID:???

JCLとCOBOLマンセーでありますよ

729 ：NAME IS NULL：2006/12/28(木) 09:49:13 ID:???

SQL SERVER の TIMESTAMP を Primarykey にしておｋ

730 ：NAME IS NULL：2006/12/28(木) 10:11:18 ID:???

>>729
あれはRowVersionだから、主キーが勝手に書き換わってまずいんじゃない。
出来たかどうかは知らんが。

731 ：NAME IS NULL：2006/12/28(木) 17:24:41 ID:???

つ[UPDATE CASCADE]

732 ：NAME IS NULL：2006/12/28(木) 22:24:25 ID:???

>>726
いや、ここはCOBOL.NETに挑戦してもらいたいw

733 ：NAME IS NULL：2006/12/29(金) 02:04:45 ID:???

NETを付けたCOBOLは

　腐　っ　て　い　る

734 ：NAME IS NULL：2006/12/29(金) 23:52:06 ID:???

>733
.NETを付けなくても(ry

735 ：NAME IS NULL：2006/12/31(日) 07:32:16 ID:???

COBOLって言うほど悪い?どんなものでも言語の特性を無視してCOBOL風に作りこむ
ｺﾎﾞﾗｰは腐ってると言えるけど。

736 ：NAME IS NULL：2007/01/02(火) 18:06:22 ID:???

>>735
コボラーって揶揄されるのはそういう人だよね。
COBOLやってた人で凄い人はやっぱ凄いよ。

737 ：NAME IS NULL：2007/01/02(火) 21:00:46 ID:???

COBOLerにかぎらず凄い人は凄いんだろうが、
COBOL上がりの人が圧倒的にDQN率が高いだけだろう。
漏れが現場で合う連中だと、とりあえず100%くらいDQNだなぁ。

738 ：NAME IS NULL：2007/01/03(水) 18:37:48 ID:???

>>737
DQNってよりもCOBOLの固定概念がありすぎて、
話が噛み合わないってほうが多いなぁ。

739 ：NAME IS NULL：2007/01/04(木) 10:59:14 ID:???

>>736
COBOLやっていた人がいかに凄くても､RDBの概念を理解して動作させている人は非常に少ない｡

740 ：NAME IS NULL：2007/01/04(木) 11:31:50 ID:???

だからテーブルの設計させるととんでもないものが挙がってくる、ってか
プログラムかかせても1行ずつフェッチするとかホントにやりやがる奴いるしな

741 ：NAME IS NULL：2007/01/06(土) 14:00:23 ID:???

無知だから、問題視すらしないのが見てて痛いよね。
あげくにDB遅いなとか。遅くしてるのはおまいらだって(w

742 ：NAME IS NULL：2007/01/06(土) 16:07:12 ID:???

カラムが200も300もあるテーブルを作りまくってたり
必ずFILLERがあるとかｗ

まあ単に勉強不足なだけなんだよね
しかし無知であるのは仕方ないとしても勉強する気がないのは最悪
仕事なんだからさー
主キーのないテーブル云々ってのも結局そこに起因するのが殆どな気がする

743 ：NAME IS NULL：2007/01/06(土) 18:26:52 ID:???

COBOLの場合のキーは主キーというよりソート・マッチングのためのキーなんだよ。
必要な属性が複合キーとしてズルズル並んでるイメージ。
それをそのままＲＤＢに持ち込もうとするとおかしくなる。
逆にＲＤＢしかやってないのにCOBOL的なバッチ処理を書かせると、
OLTP処理が変更トランザクションの数だけ動くように書いてしまう。

744 ：NAME IS NULL：2007/01/06(土) 19:58:51 ID:???

コボラーもおいおい居なくなっていくから
もうすぐアホジャヴァー役たたねえといわれ日がくるな

745 ：NAME IS NULL：2007/01/06(土) 20:08:50 ID:???

なんでそこでVB厨がスルーされているのか不思議でしょうがないんだが･･･。

746 ：NAME IS NULL：2007/01/06(土) 20:31:16 ID:???

むしろJavaって早いねって言われる時代が来て欲しいよ。
裏で動いてるRDBがもったいない。

747 ：NAME IS NULL：2007/01/06(土) 21:56:13 ID:???

おまいの書いたプログラムがへぼいだけじゃね？

748 ：NAME IS NULL：2007/01/06(土) 22:17:15 ID:???

Javaが遅いと思うならCでもC++でも使えばいいと思うんだが。

漏れはどっちも使えるけど、速度が気になるならSQLのストアドとかで
事足りているのでJavaが遅い云々はそれほど致命的でもない感がある。

つかJavaで遅いとか言っている人はCでも遅いと思うけど。

749 ：NAME IS NULL：2007/01/07(日) 21:29:42 ID:???

そりゃDBとかWeb関連の土方仕事ならjavaのスピードでも十分でしょ

750 ：NAME IS NULL：2007/01/07(日) 21:39:30 ID:???

javaが遅いだのなんだの言ってる奴はヘタレPGか、そもそも要件に合ってないのに
適用しようとするマヌケSEだろｗ

751 ：NAME IS NULL：2007/01/07(日) 23:05:34 ID:???

まー、Javaの開発IDEが重いのはあるが、Java自体はあんなもんだろ。

ただ最近の開発は全てドカタなので、デスマの原因やらトロいってグチを言語に
なすりつける時点で相当にDQNなSE&PGだって事を自覚した方がいいな。

752 ：NAME IS NULL：2007/01/08(月) 02:52:25 ID:???

JAVAのバイトコードをネイティブに解釈できるJAVAｺﾌﾟﾛｾｯｻを導入すればおｋ。

753 ：NAME IS NULL：2007/01/08(月) 03:22:14 ID:???

Javaチップか・・・なつかしいなあ

754 ：NAME IS NULL：2007/01/08(月) 08:39:22 ID:???

Javaのサーバーサイド以外への展開も盛り上がって欲しいな。
さてoracleがJavaのストアドが書けたり、MSSQL2005で.NETのストアドが書けたりするけど、
どのくらい使われてるのだろう？一回目の起動に時間がかかっていや～んな感じなのだが。

755 ：sage：2007/01/14(日) 00:56:15 ID:jZSYQ9d5

OracleのJavaで書いたストアドって、PL/SQLで書いた奴と比べると
パフォーマンスとかどんな感じなの？

別に変わんない？

756 ：NAME IS NULL：2007/01/16(火) 05:00:31 ID:???

一万PVとか１０万PVとか捌くバックエンドだと、JavaやPHPは遅いけどな。
鯖いっぱい用意して物量で対応できないと氏ねる。

そういう大規模トランザクションでJavaがあってないのは認めるけど、他にまともで安価なミドルウェアがほぼ無いのも事実。
Javaのミドルウェアを他に移植して無料で公開してくれ(w

757 ：NAME IS NULL：2007/01/16(火) 23:38:44 ID:???

>756
つ「言い出しっぺの法則」

　ってのは冗談として「他」って具体的に何だ? これ、と指定があればやってやろか、ってな猛者も
いなくもないかもしれないかも(ry

# ちなみに俺は凡人の中の凡人なのでJava VMのメモリマネジメント性能をぶっちぎるプログラム書くのは諦めたorz

758 ：NAME IS NULL：2007/01/17(水) 09:02:18 ID:???

そだ、、Javaチップってどうなったん？あの夢のハードはどこにいったん？

759 ：NAME IS NULL：2007/01/17(水) 09:06:52 ID:???

JavaチップじゃないけどJava OSのPDAならあったな。

ttp://www.wince.ne.jp/snap/ceSnapView.asp?PID=874

760 ：NAME IS NULL：2007/01/17(水) 09:58:03 ID:???

JavaApplet もどっかいったなぁ。
Ajax とか Flash とか Curl とか組み合わせなくても
Java でバックエンドもフロントエンド ( UI ) も作れて便利そうなのに。

761 ：NAME IS NULL：2007/01/18(木) 00:35:43 ID:???

つ[Java Web Start]

これこそがJREだけを入れて実現できる
現時点で最も簡単に環境構築できるリッチクライアントなんですが。
多分、動作環境がインスコ済みという意味では一番なのに
開発言語自体も一大勢力を築き上げてるのに

762 ：NAME IS NULL：2007/01/19(金) 22:20:54 ID:???

Javaっていきなりの方針転換で消えるから、変な物には手を出しにくい。
王道中の王道の部分しか使えないよな。

763 ：NAME IS NULL：2007/01/19(金) 22:29:51 ID:???

電子署名にたよる技術は普及しないとかジンクスがありそうですね。
MSのActiveXやノータッチデプロイメントも同じ穴の狢。

764 ：NAME IS NULL：2007/01/19(金) 22:30:26 ID:???

Javaの技術でなんか消えたのってあったっけ？

765 ：NAME IS NULL：2007/01/20(土) 11:28:20 ID:???

王道中の王道の予定だったEJBが
そうだったりして。

3.0で、邪道を取り込んで
なんとか生き延びたって感じですか。

766 ：NAME IS NULL：2007/01/20(土) 11:44:04 ID:???

EJBは最初から流行っていなかった技術だと認識していたが…。

敷居が高かったし、漏れの扱う案件ではあそこまでの機能は
いらんかったのでスルーしていたし、今後もスルーだろうなぁ。

JSF辺りでいーや、って思うし。(これもEJB一部なのか？)

消えつつある感のある技術と言うか言語といえばperlじゃねーの。
PHPがでてきているし。

767 ：NAME IS NULL：2007/01/20(土) 14:39:31 ID:???

思いっきりEJB使ってた。orz

perlはUNIX方面の一発スクリプト廚の道具で、PHPはperlのCGIに手を出せなかった低レベルウェブデザの言語ってイメージ。
これからはrubyかなあと思いつつ、まだまだ採用できるレベルにはほど遠い。

768 ：NAME IS NULL：2007/01/20(土) 15:21:13 ID:???

>>766
EJBとJSFではドメインが違いすぎる

理解してないキーワードをよく知りもせず並べ立てても
鼻で笑われるだけだぞ

769 ：NAME IS NULL：2007/01/20(土) 15:50:56 ID:???

IBMの開発キット(WebSphere)だとEJBもJSPもJSFもstrutsも全て同根されているから、
別にドメインがどーこーとか思うモノか？

EJB+JSP+JSF+strutsのアプリも作れる。別の意味で感動できたが。

なんか使ったことのない人間が語っても鼻で笑われるだけだぞ。

770 ：NAME IS NULL：2007/01/20(土) 16:39:27 ID:???

しかし、それは出来なくもない事例ではあるがメンテとか考えると
死ねるアプリだな。（ｗ

771 ：NAME IS NULL：2007/01/20(土) 22:18:55 ID:???

そこで華麗にPythonが通りますよ

772 ：NAME IS NULL：2007/01/22(月) 00:30:03 ID:???

>>769
何でそんなの作ることになったの？
キーワード語って仕事取ってきた営業の陰謀か？

773 ：NAME IS NULL：2007/01/22(月) 01:03:25 ID:???

>>772
別に複雑な事情があったワケでもなく、
servlet+JSP+EJBで動いていたアプリと
strutsで動いていたアプリがあって、
まとめる事になった。

漏れがJSF派の人なので、JSFメインで
組んでいったが、JSFでは手の届かないトコロが
あったりするワケで、JSFとstrutsが共存できるのは
ワリと知れ渡っていて、ついでにJSPも共存できるのは
知っていたから、「できるかなー」って思って、
やってみたら出来た。というだけ。

営業から言われたのは「工数節約」くらいなので、
節約してみますた。（w

現行バージョンのWebSphereがJ2EE1.4止まりなんで、
WebSphereがJ2EE5以降をマトモに実装するようになって、
ついでにDBのテーブル設計と現行の文字コードがEBCDICなので
これをUTF-8に移行してスッキリしたら、JSFでリプレースしようと
思っています。

774 ：NAME IS NULL：2007/01/22(月) 18:01:29 ID:???

>>773
AS400かい?

775 ：NAME IS NULL：2007/01/22(月) 21:53:34 ID:???

>>774
i5ですｗ

776 ：NAME IS NULL：2007/01/24(水) 00:27:07 ID:???

AS400だとIBMが全部面倒見てメンテしてくれるからねえ。
うごくものをリリースしてくれるので、そのままか新しくするか決めるだけ。

その腕前なら、AS400をJavaとかのオープン系にしたくて困っていた元居た会社に紹介して上げたい(w
そう言う案件ってあんまり出来るところ少ないと思う。
つーかやらされそうになったので逃げた漏れ。orz
最初はPHPとか移植したら楽で良いなあと、妄想してた時期も有りました(w

777 ：NAME IS NULL：2007/01/24(水) 01:12:57 ID:???

AS400でオープン系の技術を導入する場合メリット・デメリットがあるから
そこら辺を理解しないと死ねるだけだと思う。

主なデメリットはドキュメントはないわ、Internetも情報がメチャ少ないし、
マニュアルであるiSeriesのWebSphereのｲﾝﾌｫﾒｰｼｮﾝｾﾝﾀｰは英語版しかないし。ｗ
AIX版を参考にしてOS/400に置き換える脳は必要かな。

IBMのソフト自体は重いが出来はいいのでRPG&CLからJava&SQLに移行すれば
劇的に生産性は上がるしAS400の安定性と堅牢さが利用できるので、
漏れは積極的にオープン系の技術は取り込むようにしている。

あと、IBMは面倒というか相談には乗ってくれるがJSF辺りだと日本の普及率がｲﾏｲﾁな
性か漏れが人柱状態な気もしなくもない。
結局IBMの人にRedbooks（英語版)のヒントを貰ってなんとか解決するってノリだしなぁ。

まあ、某日立とかに比べればIBMは面倒みてくれるのは確かだな。ｗ

778 ：NAME IS NULL：2007/01/25(木) 01:30:35 ID:???

z方面の情報も置き換えて使えそうなのが多い。
まあAS400なんて手間の割に実入りが少ないからねえ。ミニコンよりも汎用機やった方が儲かる。

779 ：NAME IS NULL：2007/01/25(木) 07:35:16 ID:???

汎用機はCOBOLerがﾌﾞｲﾌﾞｲ言わせてる世界だから、
ﾋﾞﾐｮｰなんだよなぁ。

知ってる汎用機チームだと一部の人は週休0.5日制になってるし
と思えば、定時上がりのﾔﾂもいるしな・・・。

780 ：NAME IS NULL：2007/01/28(日) 02:22:13 ID:???

ていうかいいかげん主キーの話に戻れもまいら

781 ：NAME IS NULL：2007/01/28(日) 04:20:17 ID:???

主キー以外にもNOT NULL制約を付けたがらないｱﾌｫにむかつくことが多い

782 ：NAME IS NULL：2007/01/28(日) 10:40:28 ID:???

制約つけるの嫌いな人はいるよね。

でも、ER図やテーブル定義書に
「受注と受注明細は"0...*"の関係にある」
「受注.確定フラグは、0:未確定、1:仮受注、2:確定の意」
って書くなら、foreign-key制約つけてcheck制約つけてほしい。

「だってテストデータ作るときに面倒じゃないですか」とか
言われるんだけど、設計はしたけど実装しないってのは
手抜き工事みたいなもんだ。

783 ：NAME IS NULL：2007/01/28(日) 15:15:55 ID:???

FKは遅くなるから付けないってのが一般的では

784 ：NAME IS NULL：2007/01/28(日) 15:46:26 ID:???

制約に関しては、ケースバイケースなんだろうなぁ。

漏れはNOT NULLは積極的につける派だけど、
FKは時と場合で、フレームワークとかの比較的最新の技術で
組む時はFKだけど、COBOLとかの古代言語系の時は
つけない。と言うかCOBOLerが理解できないだろうし、
更新系で速度命の場合は、つけないけど。

ただ速度云々に関しては制約つけた方が安全性が高まるから
少しばかし遅くなっても制約つけるべきだとｵﾓ。

オペレータが２重にJOB起動させたけど制約で例外が発生して
助かった例もあるしな。

785 ：NAME IS NULL：2007/01/28(日) 16:03:11 ID:???

FKは逆方向の索引をつけるかどうか悩む。

786 ：NAME IS NULL：2007/01/28(日) 22:00:55 ID:???

制約の話は定期的に出てくるなあ。

787 ：NAME IS NULL：2007/01/29(月) 10:03:31 ID:???

制約はデータの整合性を保つ最後の砦だと思ってるので付けるなぁ

788 ：NAME IS NULL：2007/01/29(月) 20:50:17 ID:???

うちではこんな感じで使い分けています。

主キー制約、ユニーク制約：索引と密接にかかわるのでもちろん使う
NOT NULL制約：もちろん使う
CHECK制約：アプリ任せでほとんど使わない
参照整合性制約：
　　親子レコードのケースでは基本的に使う
　　複数の箇所で使うようなコードには基本的に使わない

789 ：NAME IS NULL：2007/02/01(木) 21:52:15 ID:???

とりあえず制約は付けておくね。
最後にパフォーマンスが微妙に足りないときに削るかどうか考えるw
結合テスト段階で制約違反出した奴はペナルティww

790 ：NAME IS NULL：2007/02/02(金) 22:26:15 ID:???

参照整合制約の何が嫌かって、インポート時に制約で引っかかるのが嫌

791 ：NAME IS NULL：2007/02/04(日) 04:05:45 ID:???

>>788
参照整合性制約はたとえば
注文と注文詳細では使うが
店舗と都道府県では使わない（都道府県コードを複数箇所で使う）
ってことですか？

792 ：NAME IS NULL：2007/02/06(火) 01:02:22 ID:???

>790
インポート時に制約を無効にすればいいじゃない

793 ：NAME IS NULL：2007/02/20(火) 13:18:33 ID:???

DB設計について教えて欲しいんだが

認可DBを作っていてDBは
　T01[認可相手の名前・住所等のDB]
　T02[認可期間、認可した日付、申請日、認可合計料金]
　T03[認可した場所別連番ID、単価、数量、計算金額]

という感じでT01-T02-T03という感じのリレーションをしている。（Access2003です）
データ件数はT01で700件前後、データ全体で1.5MB程度

キーとして
　T01:認可番号
　T02:認可番号＋認可期間年月日（自）＋（至）
　T03:認可番号＋（自）＋（至）＋連番ID
としているんだけど、俺ってそんなにアホな子かな？

本職なかたの指摘プリーズ！

794 ：793：2007/02/20(火) 13:22:58 ID:???

指摘される前に

○T02にT03集計値の金額が入っていることについて
　旧システムの金額を移行したためデータ化している。
　というのも、旧システムの金額が単純な計算では導き出せない数値もあったので

○T03に計算結果である金額が入っている件
　同上

○単価について
　単価はコード化しているが、その単価自体は毎年変わるので
　実際に使用した単価をデータで持っている

795 ：NAME IS NULL：2007/02/20(火) 13:35:04 ID:???

まず日本語を勉強した方がいいｗｗ

1. テーブルそれぞれの目的がいまいち不明確
2. 各テーブルの関係が不明確 T1:T2 は 1:1？ T1:T3 は 1:n？
3. T3 の(自)(至)って何？

796 ：793：2007/02/20(火) 14:13:01 ID:???

>>795
1．T1が認可先の名前・住所・Tel、認可場所など、T2が認可１件単位の履歴、T3が1認可当たりの内訳

2．T1－－－T2－－－T3
　　　　1対n　　　　1対n　　の関係

3．略してスマソ。期間年月日（自）、期間年月日（至）です

797 ：NAME IS NULL：2007/02/20(火) 14:28:19 ID:???

T2 と T3 の関係がよくわからん。

認可1履歴（T2）ごとに、複数の認可期間を持つ内訳（T3）があるの？
認可期間は内訳（T3）ごとに異なるの？

798 ：793：2007/02/20(火) 14:36:50 ID:???

>>797
そうです。
認可物件が継続の場合もありますが、それでも単価が異なってきますし
認可の内容自体がガラリと変わるケースもあるので

799 ：NAME IS NULL：2007/02/20(火) 15:58:55 ID:???

>>793
とりあえず、認可期間は属性だな。もちろん索引はあってもいいが主キーではない。
T01:認可番号
T02:認可番号＋履歴番号　　　属性として、認可期間年月日（自）＋（至）
T03:認可番号＋履歴番号＋明細番号

COBOLなんかだとこれでＯＫなのだがRDB的には３つ以上の複合キーはできるだけ避けたほうがいいので
履歴番号をユニークなものにする。
T01:認可番号
T02:履歴番号　　属性として認可番号（外部キー）と認可期間年月日（自）＋（至）
T03:履歴番号＋明細番号

ＯＲマッピングなど使う場合は複合キーは使わないようにするので明細番号をユニークな番号として
T03:明細番号　　属性として履歴番号（外部キー）

800 ：793：2007/02/20(火) 20:27:12 ID:???

>>799
教えてくれてありがとう！
やっぱりテーブル設計っていろいろとむずかしいな

アホな子ということがわかったので、もっと勉強しないといかんわ

801 ：NAME IS NULL：2007/02/22(木) 18:23:54 ID:8aAyMxNp

郵便番号と住所の関係に近いのだが…

N対Nのデータが毎月届くのだよ
主キーも無く…

そんなの差分更新出来ないし、おまけに年変わりで
旧年度データがもう来なくなるんだよ

全件入れ替えも厳しい…
おまけに年が変わった後の前年度更新もある…

そんなのデータ渡すから更新しろと言われても…

直近三ヶ月のデータをもらって、置き換え
前年度が変われば、前年度の最新全件置き換え

ってするしか思いつかん…

なんか他にあるか？

802 ：NAME IS NULL：2007/02/22(木) 22:16:30 ID:???

>前年度が変われば、前年度の最新全件置き換え

ちょっと待て

803 ：NAME IS NULL：2007/02/22(木) 23:46:39 ID:???

>>801
どうアクセスするのかわからなきゃ答えようがなかろう。
それを度外視していいなら「来ただけ全件入れとけ」って言うぞ。

804 ：８０１：2007/02/23(金) 00:36:58 ID:pvcSq1o7

どうアクセスもなにも、住所と郵便番号で例えれば、ひとつの郵便番号には複数の住所があるからそれをキーに住所データ更新出来ないし。。。
住所が変わっただけでは、その郵便番号は複数あるからどれを置き換えればいいかわからない

つまり全件入れ替えしかないわけだが
年をまたぐと来ないデータがあるから、全消しー全件置き換えも出来ないだろ

うーん。
謎。。。
なんか、うまいやり方ねーかなー(ｗ

805 ：NAME IS NULL：2007/02/23(金) 00:42:12 ID:???

消さなきゃいいじゃん。

806 ：NAME IS NULL：2007/02/23(金) 00:47:04 ID:???

つか、この手の相談ってボカして例を出してるから答えられんよ。

801の話を信じると、そんなデータはそもそもSELECTで照会も
マトモに動いていない事になるしな。

本気で困っているならテーブルの詳細とキーとインデックスと
中身のデータを晒せ。

話はそれからだ。

807 ：NAME IS NULL：2007/02/23(金) 02:00:50 ID:???

>804
どうも見てると、お前さんの扱うデータというのは、
「表の形にはなるが、行を特定する術がない」
かのように思えるんだが。
ってことは、どの行を取っても、別の行と「等しい」と判定できないんじゃないか?
だったら毎回全件追加でいいんじゃないのか。
そうやってため込んだデータをどう使うのかは神のみぞ知るだけど。

808 ：NAME IS NULL：2007/02/23(金) 09:46:29 ID:???

ソートかけて差分取って消えてるデータはホントに消えてていいのか確認してぜんぶ入れ替える、くらいしか思いつかんなぁ
DB関係ねーな

809 ：NAME IS NULL：2007/02/23(金) 11:25:22 ID:???

ヤヲイスレか。

810 ：NAME IS NULL：2007/02/28(水) 12:01:00 ID:???

腐女子きもい

811 ：NAME IS NULL：2007/03/06(火) 00:57:19 ID:???

すべてプラズマで説明できる

812 ：NAME IS NULL：2007/03/09(金) 13:36:18 ID:VlRmkENp

主キーって何のために必要なんでしょうか？
自主開発のRelationalDBのデータをAccessに移そうとしたんですが、主キーの意味が分からず、ただの連番データが増えてるだけなんですが…

813 ：NAME IS NULL：2007/03/09(金) 16:45:33 ID:f5uYvLc4

ログ入れるテーブル。

814 ：NAME IS NULL：2007/03/09(金) 17:08:23 ID:???

>>812
DBを逆移行してるから、Keyも劣化していいんじゃね？(w

815 ：NAME IS NULL：2007/03/09(金) 18:52:20 ID:???

今時だと主キーがないとO/Rマッパーが激しく使いにくいと思うんだが。

816 ：NAME IS NULL：2007/03/09(金) 23:11:14 ID:???

>>812

DBエンジンを自主開発できるお方に私ごときは意見できませぬｗ

817 ：NAME IS NULL：2007/03/10(土) 17:45:28 ID:???

「主キーの意味が分からず」な人が「自主開発のRelationalDB」て。

818 ：NAME IS NULL：2007/03/10(土) 21:01:54 ID:???

>>816
DBとDBMSを混同するのは初心者によくみられる間違いだね。

819 ：NAME IS NULL：2007/03/11(日) 10:12:18 ID:???

>>812 たいした意味はありませんよ。キー部分の重複をチェックして排除して
くれるRDBMS側のサービスに利用されるだけですね。RDBの場合、理論的には
集合だから重複データはあり得ないので、こういう概念が強調されますね。

820 ：NAME IS NULL：2007/03/20(火) 06:57:17 ID:???

ユニークな値が必要となるとなんでも所謂GUIDを使う人がいる。
当然主キーもGUID。"{xxxx-xxx....xxx}"みたいな文字列で。

821 ：NAME IS NULL：2007/03/20(火) 10:03:25 ID:???

それだけだと何が問題か分からん

822 ：NAME IS NULL：2007/03/20(火) 14:08:50 ID:???

エクスポート・インポートするとどうなるの？

823 ：NAME IS NULL：2007/03/20(火) 14:53:07 ID:???

どうなるんだ？

824 ：NAME IS NULL：2007/03/20(火) 16:00:59 ID:???

ただの長い文字列でしょ

825 ：NAME IS NULL：2007/03/20(火) 20:59:21 ID:???

GUIDを主キーにするのは自由だけど、という事は32BYTEくらい使うワケ？
普通にINTかBIGINTでナンバリングしてけばいいと思うんだが。
なんかINSERTとか遅そうだし。

826 ：NAME IS NULL：2007/03/20(火) 21:38:40 ID:???

32バイトくらいいいんじゃねー？富豪富豪！

827 ：NAME IS NULL：2007/03/20(火) 21:45:29 ID:???

主キーGUIDで32バイトだと1000年くらい2chのログを保管できそうな
容量なんじゃねーのか？

828 ：NAME IS NULL：2007/03/20(火) 22:17:25 ID:???

よそのテーブルから参照しててJOINとかしたら遅そう

829 ：NAME IS NULL：2007/03/21(水) 00:28:57 ID:???

>>825
GUIDって16進で32桁だから16BYTEじゃねーの？

830 ：NAME IS NULL：2007/03/25(日) 13:41:22 ID:???

DBの移行を視野にいれていて、
auto incrementを使わずに、
ユニークな値をinsertしたいとかなら、
実はそれなりにいい解だったりしない？>GUID

831 ：NAME IS NULL：2007/03/25(日) 13:50:48 ID:???

うん移行とかレプリとか色々考えるとautoincrementな主キーは色々と
取り回しが面倒やね
んでもGUIDは生成が重そうだな
どんぐらい性能に差が出るんだろう

832 ：NAME IS NULL：2007/10/27(土) 22:18:25 ID:???

主キーとユニークインデックスの違いは？
って、マジにきかれました。

833 ：NAME IS NULL：2007/10/27(土) 22:21:50 ID:???

たしか、４Dって、主キーがなかったような
むかし、４Dの売り込みに来ていたおっさんが言っていた記憶がある

834 ：NAME IS NULL：2007/10/29(月) 00:47:58 ID:???

>>832
違いは何？

835 ：NAME IS NULL：2007/10/29(月) 19:56:03 ID:???

普通主キーは一組のみ定義出来る。

データによっては排他的な項目によるユニーク性を求められる場合もあるので
その場合はユニークインデックスが(複数)必要となる。

極限まで正規化すれば主キーは一つになるのかもしれないが、ジャーナルとかだと全く無意味になる場合もある。

836 ：NAME IS NULL：2007/10/29(月) 22:04:33 ID:???

>>834
主キーは、Nullを認めない
ユニークインデックスは、Nullを認める

主キーは、一つのテーブル一つ
ユニークインデックスは、複数可能

837 ：NAME IS NULL：2007/10/29(月) 22:08:52 ID:???

＞ユニークインデックスは、Nullを認める

認めないRDBMSもあると思ったが。

838 ：NAME IS NULL：2007/10/30(火) 00:40:35 ID:???

NULLを認めないユニークインデックスと主キーとの違いって何？

839 ：NAME IS NULL：2007/10/30(火) 09:09:48 ID:???

主キーはデータベース設計上の概念で、
それを実現するための仕掛けがNOT NULLのユニーク索引。
主キー制約といったりする。

840 ：NAME IS NULL：2007/10/30(火) 10:21:25 ID:???

>>838
主キーは、一つのテーブル一つ
ユニークインデックスは、複数可能

あとは839のいうように
考え方の問題。

841 ：NAME IS NULL：2007/10/30(火) 22:53:22 ID:???

>>837
SQLServerはたしかnullを1つしか許さなかったと思うけど、
uniqueが強制not nullになるDBMSってのは聞いたことがないなぁ。

842 ：NAME IS NULL：2007/10/30(火) 22:56:37 ID:???

>>838
NOT NULL
UNIQUE
INDEX

これらは主キーの必要条件だけど
十分条件じゃない。

ってことでいいんじゃない？
違いうんぬんて話だとどうも違和感が。

843 ：NAME IS NULL：2007/10/30(火) 23:26:47 ID:???

＞uniqueが強制not nullになるDBMSってのは聞いたことがないなぁ。

DB2って・・・

844 ：NAME IS NULL：2007/10/30(火) 23:32:23 ID:???

各製品が同じように実装しているかと言うとまた別だからね
Null一つにしても、OracleとSQL Serverでは、
>>841 の言うように必ずしも同じ扱いではない

主キーは、”制約”で
ユニークインデックスは、索引

一意制約とユニークインデックスの違いは？
各製品によって実装が変わってくる。
作成するときのSQL文が異なるだけで、一意制約を作っても、
バックでユニークインデックスを作成している場合がほとんど
結局は、同じ動きをしたりする。

845 ：NAME IS NULL：2007/11/05(月) 01:08:44 ID:???

>>835
普通も何も、リレーショナルモデル上で主キーは一組だけだ。
（候補キーは複数ある場合があるけど）
リレーショナルモデルを実装したRDBで、複数組の主キーを定義できる
製品なんてあるのか？

846 ：NAME IS NULL：2007/11/05(月) 20:31:59 ID:???

複数のUNIQUE INDEXの制約をつけるのは普通にあると思うが。

847 ：NAME IS NULL：2007/11/05(月) 21:18:52 ID:???

>>846
一体今までどういう話してたと思ってんだよ。
振り出しに戻っちゃうじゃん。

848 ：NAME IS NULL：2007/11/05(月) 22:33:51 ID:???

>>845
最後の１行くらい読んでくれ。
全てを完全正規化テーブルなんてやってらんない現場も有るんよ。

849 ：NAME IS NULL：2007/11/05(月) 22:47:17 ID:???

＞リレーショナルモデルを実装したRDBで、複数組の主キーを定義できる
＞製品なんてあるのか？

IBMのDB2とO/Rﾏｯﾊﾟｰ(SDO)はそこらに対応していたな。

あとコレは漏れがIBMに染まっているだけかもしれんが、
主キーもUNIQUEも同じ「制約」だったと思うが。

OracleやSQLServerは違ったのか？

850 ：NAME IS NULL：2007/11/06(火) 04:12:28 ID:???

>>849
索引としての一意な索引と
制約としての一意制約がある
どうも、この二つが混同していると思われ

主キー制約は、一意制約の内の一つ
一意制約の内の特別なものと考えたら良い
DB2でも、主キー制約は、一つのテーブルに一つしか定義できない

851 ：NAME IS NULL：2007/11/06(火) 06:56:31 ID:???

>>850
＞DB2でも、主キー制約は、一つのテーブルに一つしか定義できない

DB2/400は複数定義できた。
つーか、PRIMARY KEYと言う指定がない。w
UNIQUEを指定汁！って事らすぃ。

852 ：NAME IS NULL：2007/11/06(火) 07:58:30 ID:???

　「"主"キー」なんだから、それが複数あるというのは言葉の定義としておかしいよ。
・1列で行を一意に特定できる列「キー」
・2列以上を組み合わせて行を一意に特定できる列の組「複合キー」
→表内の「キー」または「複合キー」の中でも、それらを代表する
　キーに対する呼称「主キー」

　「主キー」と宣言すると、たいていの DBMS はキーとして備えるべき「UNIQUE」「NOT NULL」
を自動的につけてくれる。
　その他の「キー」を「キー」としてDBMSに認識させたいのであれば、「UNIQUE」「NOT NULL」
をつけておけばよい。すると、その列がキーとして成り立つよう重複する値を排除したり、
外部キーを使うときにその列または列の組を一側の列の候補として自動的に処理してくれる。

　そう考えればどうだろう。

853 ：NAME IS NULL：2007/11/06(火) 12:57:02 ID:???

>>851
その場合は、

DB2では主キーを定義できない

というのが正しくないですか？

854 ：NAME IS NULL：2007/11/06(火) 16:23:16 ID:???

>>833
>たしか、４Dって、主キーがなかったような
>むかし、４Dの売り込みに来ていたおっさんが言っていた記憶がある

あんなRDBとはとても言えない不良品を引き合いに出さないでください｡

855 ：NAME IS NULL：2007/11/06(火) 21:54:19 ID:???

>>851
それは、>>853 の言うとおり、主キーを定義できない（Primary Key制約を作成できない）。
Primary Key制約が実装されていなくて
ユニークインデックスで代用する製品も >>854 のように稀に存在している。
Not Null ＋ Unique Index で代用することは可能

856 ：851：2007/11/06(火) 22:40:05 ID:???

>>853
＞DB2では主キーを定義できない
＞というのが正しくないですか？

言葉遊びの領域にあると思うが、古参のAS/400のエンジニアに
「このテーブルの主キーってなんですか？」と質問しても
答えられない人が多いと思う。

比較的マトモ(?)な教育を受けた新人は「このPFに指定されている
UNIQUEキーが主キーです」と答えるとｵﾓ

昔のAS/400のDBは基本的に全てのカラムがNOT NULLでした。

OS/400上で稼動するRDBMSはOSﾈｲﾃｨﾌﾞ駆動と
SQL定義に合わせたOS上で稼動ｴﾝｼﾞﾝと両方使えるので、
主キー（相当）が二つあったり切り替えたりする動作は気にしないなぁ。
どうせ内部的には同じ動作するワケだし。

857 ：NAME IS NULL：2007/11/06(火) 23:32:56 ID:???

PRIMARY KEYなどの制約が追加されたのがSQL89で実際に実装され始めたのがSQL92以降。
古くからあるRDBの当時のバージョンにはPRIMARY KEYがなかったり、
別のキーワードがその意味だったりしていた。
その当時でも主キー・候補キーや正規化などの概念はあったから、
それを実現するためにユニークキーを付けるとかやってたと思う。
NULLがデフォルトでNOT NULL制約ができたのもSQL89からで、
以前はNOT NULLが標準のものが多かったように記憶している。

ちなみにCREATE INDEX文はANSI SQLでまだ規格化されてないキーワード。
（すくなくともSQL92時点ではまだだったと思う。）

858 ：NAME IS NULL：2007/11/08(木) 04:31:41 ID:???

テーブル設計上の意味的な上での主キーの話と
実際にDBMS上でのPRIMARY KEY定義の話を分けた方がいいかも

テーブル設計で主キーを決めないことってないよね。
ログファイルとかジャーナルみたいに、垂れ流して貯めておくだけのテーブルは別にして。

実際にDBMSでは、製品によっては、PRIMARY KEY制約をサポートしていないものもある。
製品がPRIMARY KEY制約をサポートしていなくても、UNIQUE INDEX＋NOT NULLで代用しているはず。

859 ：uDVmhUDTEly：2007/11/20(火) 21:47:20 ID:???

iY5ek7 <a href="http://cvqfthvwmamh.com/">cvqfthvwmamh</a>, [url=http://tnapgmifdude.com/]tnapgmifdude[/url], [link=http://gphilryaumqj.com/]gphilryaumqj[/link], http://rxdcwbuvffgc.com/

860 ：fWSqFRnSJkpHZv：2007/11/23(金) 00:24:28 ID:???

http://haimba.cn windows mp3 downloads

861 ：uFvlxkBszTpua：2007/11/23(金) 10:58:24 ID:???

http://iqlveq.cn cheap mp3 downloads

862 ：zMuZbosNrA：2007/11/23(金) 21:15:22 ID:???

http://kgnsye.cn/imax-california.html Imax california
http://kgnsye.cn/california-dept-of-corporation-htm.html California dept of corporation htm
http://kgnsye.cn/single-family-homes-carlsbad-california.html Single family homes carlsbad california
http://kgnsye.cn/archangel-tattoo-design.html Archangel tattoo design
http://kgnsye.cn/blue-book-pricings-for-atv.html Blue book pricings for atv

863 ：izuqmUah：2007/11/24(土) 08:14:04 ID:???

http://bdzwbn.cn/best-mp3 best mp3

864 ：lugEIFgFnNtIXdB：2007/11/24(土) 21:54:08 ID:???

http://bfsnbw.cn/mp32 call me

865 ：NAME IS NULL：2007/12/01(土) 00:47:58 ID:???

今俺の携わっているPJでは100個くらいのテーブルがまさに

　主　キ　ー　の　張　ら　れ　て　い　な　い　状　態　！！！

いや、だからどうしたという事もなく淡々と仕事してますけどね、ﾊﾊﾊ

866 ：NAME IS NULL：2007/12/01(土) 10:05:36 ID:???

>>865
さらっと「なんで主キーとかインデックスとかないんですかね」って聞いてみて報告よろ～

議論したり啓蒙したりはしなくていいから

867 ：NAME IS NULL：2007/12/01(土) 13:56:48 ID:???

>>866
既に説明受けている。
最初の設計・構築が素人さんだったそうだ。
運用してから１０年以上で何がどうなっているか社内にも判る人が居ない。
だから、「これ主キーじゃね？」と思ってもどんなデータが入るか予測が付かないから
主キーを張る事すら出来ない。

インデックスというか帳票・画面用のソートキーは付いている程度。
今回俺は金さえ貰えれば良いから議論も啓蒙もしていないｗ

868 ：NAME IS NULL：2007/12/03(月) 00:11:09 ID:FZGtjY5k

>>867
いや、主キーが必要ないテーブルなら張る必要ないだろ

869 ：NAME IS NULL：2007/12/03(月) 00:41:38 ID:???

>>868
「主キーが必要ないテーブル」が100個用意されるって
どこの業界のどんな業務が頭に浮かんでんだよｗ

>>867
依頼主が改修に費用が出してんのが不思議だな。金あるなら作り直ししそうなもんだろ。
料金取りっぱぐれないうちに手ぇ引いとけw

870 ：NAME IS NULL：2007/12/03(月) 21:40:52 ID:???

>>869
何処も受けきれずに断ったらしい。
俺はあと数ヶ月で勤務先変わるから関係ない。
貰う予定期間で予定のモノ貰えばさっさと㌧ずら!!!

871 ：NAME IS NULL：2007/12/29(土) 01:37:35 ID:???

単純にCOBOLシステム時代のシーケンシャルファイル感覚なんだよなｗ

もうそういうファイル要らない設計に出来るんだから頭使えよな！ってことだよね

872 ：NAME IS NULL：2008/02/23(土) 03:31:02 ID:???

UNIQUEが複数あって、

優越付けがたいので主キー設定してません。ｗ

全く問題なし。

873 ：NAME IS NULL：2008/02/23(土) 21:11:49 ID:???

>>872
優柔不断・・・

874 ：NAME IS NULL：2008/03/06(木) 02:54:33 ID:???

意見の違いはあるが、このスレにいる人って
総じて全員優秀だと思う。いやマジで。
誰かうちの会社に来てくれないかな・・・。

ちなみにうちの会社、主キーどころか
ExcelとDBの理解していない人が何人もいる。
正規化って食べ物？って言いかねないくらい
レベルが低い。indexは無いし全部可変文字列なんて
当たり前。

言い訳が得意なら、努力しない豚でも生きて
いけるのだなと感じる今日この頃。

875 ：NAME IS NULL：2008/04/16(水) 14:29:02 ID:???

>>874
あなたのレスどこかで見たなｗ

876 ：NAME IS NULL：2008/05/06(火) 18:09:19 ID:???

主キーどころか正規化もされてません。
でもところどころUNIQUEとかNOTNULLが設定されてる（規則性なし）
かんべんしてくれ

877 ：NAME IS NULL：2008/05/08(木) 22:05:45 ID:???

こっちのは正規化もされてないしインデックスも無いから安心してくれ
日時の主キーはあるぞ

878 ：NAME IS NULL：2008/05/11(日) 08:31:48 ID:???

全てのカラムにインデックスが付いてるが、複合インデックスが無いw

879 ：NAME IS NULL：2008/08/21(木) 02:59:39 ID:???

>>876
進研模試の偏差値でいうと２ちゃんねるのニュース速報がおよそ45、民放地上波の報道ステーションが約40、
ニュース速報＋は35程度の読者を想定しています。

880 ：NAME IS NULL：2008/08/23(土) 23:35:13 ID:???

はいはい誤爆

881 ：NAME IS NULL：2008/08/26(火) 17:41:50 ID:???

主キーを複合キーにしたがるのはAccess屋の陰謀？
個人的には内部にIDを別に作るほうがいいと思うんだけど…。
名称が欲しいだけなのに3つも4つもWHERE句に書かないと取れないのがめんどくせえ。

＃今検索したらそういうのは「サロゲートキー」というんだな。
＃初めて知ったｗ

882 ：NAME IS NULL：2008/08/26(火) 21:10:13 ID:???

用途次第。

883 ：NAME IS NULL：2008/08/26(火) 21:55:12 ID:???

>>881
国の人間も同じ事を考えてるよ。

名前？　生年月日？　住所？　性別？　ざけんな！
こちとら年金督促状を送りたいだけなんだよ！
生まれたらすぐに一意タグでも埋めろよ！

ってな（´・ω・`）

884 ：NAME IS NULL：2008/08/26(火) 22:33:07 ID:???

別にぜんぜんかまわないだろ。ていうか、いやなやつは後ろめたいことを考えているに違いない。
２ちゃんねらーが潔癖症なくらい身元がばれるのを恐れてるようなもん。

885 ：NAME IS NULL：2008/08/27(水) 21:17:28 ID:???

いや、技術的にも可能だし、俺もいっこうに構わないんだが、
国がいやがるのよ。国を支えていると言い張る馬鹿な奴らが。

自分たちと取り巻きの素行がばれるのをめっちゃ嫌がっている。

886 ：NAME IS NULL：2008/08/28(木) 11:47:20 ID:???

主キーなんてたいして意味ないよ。

887 ：NAME IS NULL：2008/09/05(金) 21:14:06 ID:Aklfn9i/

良くわかんないから、全部に主キーつけてみた。

888 ：NAME IS NULL：2008/09/05(金) 21:18:35 ID:+fyrMg5z

手記ーって何や

ｼｭｯｼｭｯしながら

889 ：NAME IS NULL：2008/09/05(金) 22:38:09 ID:???

そういえばこの前distinctを知らないような、全カラムgroup byしてるのを見た。
辞めたいです。

890 ：NAME IS NULL：2008/09/05(金) 23:38:15 ID:???

>889
俺もたまに見る
特定のDBの特定のバージョンまでに限って
GROUP BY使った方が速かった、らしいが……
(というか、そのDBのdistinct使った時の実行計画がアフォすぐるシロモノだったようだ)
何のDBだったかは忘れた

891 ：NAME IS NULL：2008/09/05(金) 23:51:51 ID:???

主キーがないテーブルはいっぱい作ったな…

でも、一意性制約をユニークインデックスの上乗せして作るより、
ユニークインデックスが一つあれば良いかな。

運用側の意見としては。

あ、もちろんユニークインデックスが無いテーブルを作れとゆう話は、
打ち合わせの時点で私は却下しますけどね。

892 ：NAME IS NULL：2008/09/06(土) 06:40:03 ID:???

>>889
distinct なんて単なるシンタックスシュガー
group by を知っていれば distinct は不要だが逆は言えん

893 ：NAME IS NULL：2008/09/06(土) 07:01:36 ID:???

>>892
同意。

894 ：NAME IS NULL：2008/09/06(土) 07:14:47 ID:???

>>891
「主」キーってのは観念的なものだからな。技術的にはキーであればいいわけだ。

895 ：NAME IS NULL：2008/09/23(火) 22:24:55 ID:???

小さいテーブルだとINDEX使った検索より、全表走査させた方がいいから、
あえてPRIMARY KEY作らない場合もあるよ。と言ってみるテスト

896 ：NAME IS NULL：2008/09/23(火) 22:39:19 ID:???

そりゃ、性別みたいなカス(?)なテーブルはつけないと早く動作するRDBMSもあるからなぁ。

897 ：NAME IS NULL：2008/09/23(火) 23:00:27 ID:???

いまどきのコストベースオプティマイザなら大概その程度のことは
やってくれると思うがな。
できないDBMSってどれ？

898 ：NAME IS NULL：2008/09/24(水) 00:57:33 ID:???

だよな
キーだのインデックスがあると無条件に使っちゃうって、どんだけバカなのよw

899 ：NAME IS NULL：2008/09/24(水) 20:08:04 ID:???

>>897
4th Dimension

900 ：NAME IS NULL：2008/10/10(金) 21:47:18 ID:???

外部キーを持つテーブルが一切ないDBってのは見たことがある。

……いま面倒見てる人事システムがそうなんだが。
最初見たときは結構ビックリしたが、そのうち慣れてしまった。

あ、さすがに主キーはちゃんとあったよ。

901 ：NAME IS NULL：2008/10/11(土) 00:12:41 ID:???

>900
よう俺

てゆーか外部キー使ってるとこってほとんど見たことない
多分俺はろくな現場を回ってこなかったのだろうなorz
# そこ、現場よりお前が(ry)って突っ込みはやめてくれろ

902 ：NAME IS NULL：2008/10/11(土) 10:15:15 ID:???

>>900
見たことあるって言うか自分が設計したものを除いて外部キーがあるテーブルを
ほとんどどころか全く見たことがない。

…というオレも外部キーの有用性が分かったのは数年前なんだけどね。

903 ：NAME IS NULL：2008/10/11(土) 15:47:35 ID:???

外部キーに索引をつけるかどうかは判断に迷う

904 ：NAME IS NULL：2008/10/12(日) 08:44:01 ID:???

最近のDBは外部キーで実行計画が勝手に変わるね。
だからつけた方がいいといえばいい。

905 ：NAME IS NULL：2008/10/12(日) 11:33:23 ID:???

参照整合性制約であれば、参照先のテーブルでの削除の頻度と参照元の
テーブルの削除のパフォーマンスから索引の要否は判断できると思うが。
そのオーバーヘッドすらも許容できなくて、あえて制約を付加しない設計も
ありはするね。

906 ：NAME IS NULL：2008/11/06(木) 23:40:53 ID:oi3DlEtx

MS-SQLのデータマイニングアルゴリズムでパターン判別の分析するために、CSVを読み込んだだけのDB

907 ：NAME IS NULL：2008/11/15(土) 00:19:02 ID:???

主キーはあって困るもんじゃない
いわば保険みたいなもん

908 ：NAME IS NULL：2009/02/06(金) 21:14:13 ID:CAltmj0N

そう？

909 ：NAME IS NULL：2009/02/06(金) 22:50:32 ID:???

主キーがないとトランザクションが爆発的に増えるDBがあってﾜﾗﾀ

910 ：NAME IS NULL：2009/02/07(土) 06:28:53 ID:???

一体どーゆー設計手法を用いれば、主キーのないテーブルができるワケ？

911 ：NAME IS NULL：2009/02/07(土) 07:45:28 ID:???

必要に応じてテーブルを追加的に定義する。

912 ：NAME IS NULL：2009/02/07(土) 07:57:33 ID:???

GeneralDatabaseに主キーはないよねｗ

913 ：NAME IS NULL：2009/02/24(火) 11:42:57 ID:???

データベース(テーブル)の運用中に主キーの変更を
余儀なくされるのはどんな場合でしょうか？

914 ：NAME IS NULL：2009/02/24(火) 23:25:31 ID:???

>>913
運用中との話だから仕様追加ではないかと。

915 ：NAME IS NULL：2009/02/25(水) 05:44:09 ID:???

>>914
事業部制の導入などでは、大量発生する？

916 ：NAME IS NULL：2009/07/02(木) 21:52:04 ID:???

桐には主キーがあるけど、桐ユーザーの多くは主キーを知らない。

917 ：NAME IS NULL：2009/12/06(日) 16:18:54 ID:???

みたことあるよ。
主キーを必ず設定しなければならない決まりはないからね。

918 ：NAME IS NULL：2009/12/07(月) 15:37:06 ID:???

>>917
重複排除以外に積極的(RDBとして本質的?)な意味はないからね。

919 ：NAME IS NULL：2009/12/08(火) 22:58:44 ID:???

>>918 create table にプライマリーキー指定を組み込んだことが設計の誤り。便利だけどね。誰が始めたのかな？

920 ：NAME IS NULL：2010/02/15(月) 03:22:15 ID:???

SQL 文を２回流すと仕事が増えるよねw

921 ：NAME IS NULL：2010/02/19(金) 23:24:01 ID:???

>>2
は七年ぶりに反省するべき

922 ：NAME IS NULL：2010/06/08(火) 05:32:35 ID:???

恐

923 ：NAME IS NULL：2011/03/24(木) 07:39:09.09 ID:GoXeNBk+

結論として、主キーが設定されているかいないかなどは、
どうでもよいことなのだ。

924 ：NAME IS NULL：2011/03/26(土) 12:33:57.03 ID:ndRK6ZD0

よくねーよカス

925 ：NAME IS NULL：2011/04/09(土) 19:34:48.52 ID:GHq/rX2P

>923
>924
アクセスは適当に付与してくれるじゃないか。

926 ：NAME IS NULL：2011/04/14(木) 21:28:13.19 ID:F/sxykTL

あ

927 ：NAME IS NULL：2011/04/23(土) 21:29:11.66 ID:???

基本主キーがない。
定義されているものは、ユニークの保証がない。
テーブル定義はカオス、、、(-_-;)
そんなシステムのメンテをしたことがあるな。

928 ：NAME IS NULL：2011/04/25(月) 22:57:53.14 ID:???

自動でいれてくれるソフトをすすめろ

929 ：NAME IS NULL：2011/04/27(水) 14:43:22.06 ID:???

>>927
あまりにもひどい既設テーブルだらけだったので､知らんぷりして悉く自動採番つきの主キーを定義したフィールドを仕込んだことがあるw

930 ：NAME IS NULL：2011/04/27(水) 20:25:50.41 ID:???

なんか意味あんのか？それ

931 ：NAME IS NULL：2011/04/28(木) 13:18:56.16 ID:???

DBによっては主キーを明示しないと更新できないものがあるんじゃなかったかな？
OracleはROWIDがあるのでその心配はないのだが｡

932 ：NAME IS NULL：2011/04/28(木) 17:53:55.38 ID:???

>>931
Primary Key 指定が規格に入ったのは、
89年からだと思うが、それ以後の製品？

933 ：NAME IS NULL：2011/05/14(土) 11:02:39.85 ID:???

>>931
確かそんな話をDBmagaginで読んだような記憶があるな。

基本主キーなりuniqueなキーは必要だと思うけど
よそから貰ってくるマスターデータなどは、
キャッシュされてfullscanだから無くても支障は無かったな。
主キーに従属するindexのコストを考えると
一意の値が保障されている通貨換算レートなどは不要だと思っている。

934 ：NAME IS NULL：2011/07/21(木) 23:28:46.62 ID:uYI4xppD

idには必ず主キー付けた方がいいんですか？

只今勉強中です。

935 ：NAME IS NULL：2011/07/30(土) 13:02:19.71 ID:???

>>934
一般的には付けたほうがいい。
HACKしたわけではないけど列指向データベースとかは余り有益ではないかも。

936 ：NAME IS NULL：2011/08/21(日) 14:12:10.62 ID:???

DB初心者です。
今、改修してるシステムのDBは9割以上のテーブルに主キーが設定されていません。
その代わり、全てのテーブルにインデックスは設定されています。
これは主キーを設定してもしなくても同じなのでしょうか。

937 ：NAME IS NULL：2011/08/21(日) 18:05:16.45 ID:???

これ次スレ必要なんかしら

938 ：NAME IS NULL：2011/08/21(日) 20:42:39.03 ID:22rNpbGh

>>936
同じではないけど、問題ないなら主キーの設定はしなくてもいい。
そもそも、主キーの設定は必須ではないからね。

939 ：NAME IS NULL：2011/08/21(日) 21:35:44.80 ID:???

インデックスってのが、ユニークインデックスなら、実用上問題は少ない
ほとんどのDBMS実装では、主キー=Not NULL制約+ユニークインデックスだと思っていいかと

ユニークでないインデックスなら、そのテーブルは行を特定できない可能性がある
それで問題ないなら主キーなくてもいいんじゃね

940 ：NAME IS NULL：2011/09/08(木) 18:24:23.93 ID:???

>>1
全カラムでユニークであることは維持しないと。
完全に重複してるデータがどんどん入ってしまうと、さすがに後の処理が厄介だね。
データ設計段階で冗長なカラムを付加してでも主キーを設定してデータベースシステムに任せるか、
すべてプログラム側で一意性を維持させるかということかな。

941 ：NAME IS NULL：2011/09/13(火) 16:34:44.58 ID:YBAEI4zg

主キーはあるが、参照制約は全く無い
単なるインデックス+UNIQUE+NOT NULL制約のためだけに使ってる感じ

そういうのって、どうなんだろう

942 ：NAME IS NULL：2011/09/13(火) 19:04:50.73 ID:???

ari

943 ：NAME IS NULL：2011/09/14(水) 00:01:37.44 ID:???

>>941
汎用的なスキーマにするにはそうせざるを得ないな。
ERPとかそうなってるだろ。
無論論理設計段階で要件がかちっと決められる場合はそうではないけど、
ソーシャルとかで大量のクエリを捌かないとならないばあいはあえて参照整合性は付けないかな。遅いから。

944 ：NAME IS NULL：2011/09/14(水) 01:12:47.01 ID:???

参照制約も、参照先テーブルと参照元テーブルを、何がしらかの拡張系JOINを使って
結合すると、ON句を指定しないでもその参照制約を用いての自然な外部結合結果を
返してくれる、みたいなメリットがあったら、もっとみんな使うんじゃないのかなぁ、とか
妄想することがあるんだが、そういう実装ってあるのかな?

945 ：NAME IS NULL：2011/09/14(水) 01:36:56.36 ID:???

MSACCESS

946 ：NAME IS NULL：2011/09/15(木) 13:20:39.23 ID:???

tablename_pkey ってインデックス名だからプライマリキーだと思ったら単なるunique indexだった……

947 ：NAME IS NULL：2011/09/21(水) 14:54:55.64 ID:???

プライマリキーが複数（組）設定されてるTBLを
見たことがある人は手をあげて

948 ：NAME IS NULL：2011/09/21(水) 15:30:00.08 ID:???

Alternative Keyなら設定すっぞ
インデックス名をPK_<TABLENAME>_1とかしたら
一瞬頭をひねるだろう。
フハハハ

949 ：NAME IS NULL：2011/09/21(水) 17:09:25.64 ID:???

>>947
Oracleでは設定できんのだが、できる実装があるのか?

950 ：NAME IS NULL：2011/10/12(水) 19:56:15.22 ID:???

Oracleでも出来ますよ

CONSTRAINT <TABLE名> PRIMARY KEY (<KEY1>,<KEY2>,...) USING INDEX

951 ：NAME IS NULL：2011/10/12(水) 19:58:18.98 ID:???

○<制約名>
×<TABLE名>

952 ：NAME IS NULL：2011/10/12(水) 21:19:50.02 ID:???

それは単に、複数列によるプライマリキーってことなのでは

953 ：NAME IS NULL：2011/10/12(水) 22:00:40.10 ID:???

DB初心者で馬鹿な俺に教えてくれ

PKとは唯一無二のカラム（例えば顧客マスタの「顧客コード」）で、
所謂複数列によるPKとやらはユニークキーという認識で合っているのか？

954 ：NAME IS NULL：2011/10/12(水) 22:32:47.19 ID:???

>>953
RDBに限っていうと、列が単一でも、複数でもキー候補となりうる。
列またはその集合(複数の列)を指定するとテーブルの中の組を
一意に識別できるならばその列またはその集合はキー候補です。
キー候補のうちで、任意のものをプライマリーキーに指定できます。
任意のものだから、どれでもよい。
プライマリーキーは多くの場合、テーブル生成時に指定することが
許されているので特別な何かと思いがちですが、データベースシステムが
常にプライマリーキーの存在に注意して動作してくれるという点を除けば
論理的には他のキー候補と何等差はありません。

955 ：NAME IS NULL：2011/10/13(木) 06:54:27.19 ID:???

>>954
教科書的な答えなら、このスレの >>1 - >>150 くらいの中で出尽くしてる
のではないか。プライマリーキーに関する議論としては、ウェブやブログでは
ほとんど見つけることのできない情報源になっていると思う。

956 ：NAME IS NULL：2011/10/14(金) 20:40:04.71 ID:???

>>944
キャシエ

957 ：NAME IS NULL：2011/11/23(水) 01:47:14.60 ID:???

仕事でよく新規テーブルを作るんだが、
レコード数が１年で１万行程度だったら主キーとかインデックスとかつけないな。
理由は考えるのがめんどくせーから。

シンプルに、よりシンプルに！がモットーです。

958 ：NAME IS NULL：2011/11/23(水) 12:55:37.48 ID:???

主キーはつけないと後で泣き見るぞ

959 ：NAME IS NULL：2011/11/23(水) 15:20:08.35 ID:???

主キー無しで数千万レコードもあるトランザクションテーブルの面倒見ているから、主キー無しの酷さはよく知っている。
全く同じ行が複数ヒットするんだが、別々の注文なのか、１つの注文が不具合で２行になったのか。
インサート日は時間まで無くて困る。

960 ：NAME IS NULL：2011/11/23(水) 23:34:14.47 ID:???

>>957が設計してそれを>>959が保守していると....

961 ：NAME IS NULL：2011/11/23(水) 23:35:18.86 ID:???

ｶﾜｲｿｽ

962 ：NAME IS NULL：2011/11/24(木) 08:00:38.45 ID:???

>>960
数千年・・・

963 ：NAME IS NULL：2011/11/25(金) 04:36:40.14 ID:???

用途による

964 ：NAME IS NULL：2011/12/02(金) 21:45:52.90 ID:kohrfEHA

つけといて困ることはないけど
つけとかないと困る

965 ：NAME IS NULL：2011/12/03(土) 06:32:22.42 ID:???

>>964
必要のない **ID といった項目が無闇と多くなる。

966 ：NAME IS NULL：2011/12/03(土) 07:02:20.99 ID:???

それはサロゲートキーといいます

967 ：NAME IS NULL：2011/12/04(日) 17:32:35.30 ID:???

UUIDでもいいから主キーはつけておいてくれ。

968 ：NAME IS NULL：2011/12/04(日) 19:03:07.68 ID:???

その目的は？

969 ：NAME IS NULL：2011/12/05(月) 07:52:19.83 ID:???

ないと行が特定できない可能性があるからだろ

970 ：NAME IS NULL：2011/12/05(月) 19:21:50.51 ID:???

サロゲートキーに意味はないんだから行は特定できないでしょ
っていんたいんだろう

971 ：NAME IS NULL：2011/12/05(月) 22:39:00.10 ID:???

特定できりゃ何でもいいってわけじゃないからねぇ。
設計中に全フィールド足しても主キーにならないテーブルなんてものが出てきてしまったら普通は
設計あるいはモデリングの失敗だから、そこで立ち返って検討しなおすべきであって、勝手なキーを
くっつけて「主キーができたから大丈夫」なんて済ませるべきじゃないってことだろう。
例えば>>959の例で、このテーブルに何かユニークなキーを追加したところでほとんど何の
解決にもならんし。

972 ：NAME IS NULL：2011/12/07(水) 22:00:19.82 ID:???

特定の1行を削除できなくなるからだろ
（サロゲートキーのどの行でもいいけど、とにかくそのデータから1行だけ消したいって場合もある）

973 ：NAME IS NULL：2011/12/07(水) 23:14:12.91 ID:???

あー、ホスト移行とかDWH系のテーブルはGUIツールとかでポチッと消せなくて面倒くさいときがあるな

974 ：NAME IS NULL：2011/12/07(水) 23:16:15.62 ID:???

同じレコードが何件存在するかが情報として必要な場合？
そういうのは明示的に件数を持とうよ。

975 ：NAME IS NULL：2011/12/07(水) 23:27:45.89 ID:???

結論
DB設計をしっかりやればおｋ
それを適当にやってたらクズ

976 ：NAME IS NULL：2011/12/07(水) 23:55:18.93 ID:???

>>973
俺DWHの開発してたことあるけどネティーザって主キー設定しても
実際には主キーが効かないっていうイミフな仕組みだったな
データ突っ込むときに自分で気をつけろってマヌアルに書いてあった

あれは二度とやりたくない

977 ：NAME IS NULL：2011/12/12(月) 23:26:01.17 ID:???

データがどう入るか分からんから
リーダーに主キーを消されたことあったな。

そのどうデータが入るかわからないテーブルで
バグ出したら、こっちの責任になるんだが。。

978 ：NAME IS NULL：2011/12/13(火) 05:11:19.30 ID:???

どう入るか判らんから制約つけるのに馬鹿みたい

979 ：NAME IS NULL：2011/12/13(火) 06:03:07.92 ID:???

>>978
最初に集合ありき。それを見つめて制約がでてくる。
そういう帰納論理的な考え方も魅力はあるよ。

980 ：NAME IS NULL：2011/12/13(火) 22:10:14.24 ID:???

どういうデータが来るかとどういうデータを入れるべきかは区別して考えないとな。

981 ：NAME IS NULL：2011/12/16(金) 02:18:31.93 ID:???

キリッ、を忘れてるな

982 ：NAME IS NULL：2011/12/16(金) 07:59:53.30 ID:???

朝のダイニングは少し広々としていた．
彼女はいつもきちんとしていて，忘れ物などあろうはずもない．
ただ微かな残り香だけがのこっていた．

朝食の用意をしよう．
一人分だからといきなりの手抜きは，なんだかあのひとに申し訳ないように思えた．
いつものメニューでいこう．

ふと食卓の紙片に目がいった．小ぶりの花瓶に隠れるように置いてある紙片を
取り上げたとたんに抑えていた涙がこぼれる．

一言「すき」とだけ書いたあのひとは一体，どんな思いでこれを書いたのだろう．
紙片を握りしめ，もういちど視線をもどすとそこにはいつものテーブル．
もうそこに「すき」と書いた紙片はない．「すき」はもうテーブルにないのだ．
シュキーのないテーブルとはまさにこのことだ．デービーってほんとに素晴らしいものですね．

983 ：NAME IS NULL：2011/12/16(金) 09:59:34.65 ID:???

ちょっとワロタ

984 ：NAME IS NULL：2011/12/16(金) 15:34:03.97 ID:???

三流だな