2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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 がなくても、それほどすごいことはないと思うが。
確かに、1行単位での削除とかできないが、それは用途の問題だし。
uniqueでないindexでもべつにいいわけだし、
意味のない行番号ならつける必要ないんじゃない?

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

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

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


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 って何だ。w


19 :NAME IS NULL:03/11/21 21:28 ID:???
主キーがあるのと無いので全然検索速度変わるDBMSもめずらしかないだろ。

20 :NAME IS NULL:03/11/21 22:17 ID:???
メインキーなくてもmultiなindexでも検索速度かわらないDBもめずらしくないしなあ。
1はちょっといいすぎかと。やっぱ用途次第だと思うな。
「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条件に指定する。w


28 :NAME IS NULL:03/11/22 21:17 ID:???
>>24
>テーブルに主キーが1つも設定されていませんでした。
>しかも全テーブルに。

こんなシステム引継ぎさせられたら、暴れちゃう(w
多分、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
あるある(w
そういえば、もっと凄いのも見たことあった。。。
1レコードinsertするのに6時間くらいかかってたシステム。。。

ヽ(`Д´)ノ 思い出したくないよー。

33 :NAME IS NULL:03/11/22 21:40 ID:???
主キーがGUIDだったっていう何の為のキーなんだか分からんのも見たことはあるな(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のエクステントも1Mくらいのが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:???
だんだん登録が遅くなって、昼間は登録禁止、から
運用ルールが出来上がっていったんだろうなw

43 :NAME IS NULL:03/11/23 13:13 ID:???
>>1のDBがAccessなら許すw

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


1.素人は主キーを設定してはならない

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
主キーはDB設計上の概念
INDEXはDB操作上の概念。

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

69 :NAME IS NULL:03/12/04 01:45 ID:???
>>68
>主キーはDB設計上の概念

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

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:???
>(内容が全く同一な行は複数存在してはいけない)

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


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
別にPKがない表があってもおかしくないでしょう?
単に全カラムを同じように更新したいだけなのでは?
そもそも、PKとは制約のひとつでしょ? 決して必須ではないはず。
もっと柔軟に考えたら? >>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 :89: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 文に全カラムを入れれば無問題。
つか、最近のDBは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 | 季節限定

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

何も考えないと「商品カテゴリテーブル」に主キーはないですよね、
[商品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」でPKだろ?

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
RDBで多:多のリレーションを実現するために中間テーブルの
商品カテゴリテーブルを実装するのは全く無問題。

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

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

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
なんでEJBの話が出てくるんだ?


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させると「主キー」の数量がNULLになっちまう。
ま、こんなTBL設計をする香具師は居ないが。

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を使わずに日付最小値を入れて未入力としている厨な分けだが。w


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
すいません、すごい初心者的な質問なんですが。

表A

コード  内容
-------------------
01 AAA
02 BBB
03 CCC

表B

コード  内容
-------------------
01 AAA
03 CCC

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

コード  内容
-------------------
02 BBB

上記1行を出力したい場合、INとEXISTSとANY以外の問い合わせ
の仕方がありませんでしょうか?本当に初心者的な質問で申し訳ありません
が、お願いします。

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
あるよぉーーー AS400のPFでぇー

171 :NAME IS NULL:04/01/23 20:40 ID:???
一部、参照するためだけに使われるテーブルには主キーをつけない
っていうテクニックはあるけれどそれ以外にはありえない。


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

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

172 :NAME IS NULL:04/01/23 22:46 ID:???
「リレーションはる」ってなんだよ...

173 :NAME IS NULL:04/01/24 10:35 ID:???
まぁ、なんとなく言いたい事は分かる(w
でも、DB5つもあってそれぞれにテーブル1個ずつでも
びっくりすると思う。

ってMS-Accessの話かな?

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

┌┬┬┬┐
    ―――┴┴┴┴┴―――――、
   /.  ̄ ̄ ̄//. ̄ ̄| || ̄ ̄ ̄||| ̄ ||     __________
  /.    ∧// ∧ ∧| ||      |||   ||  /
 [/____(゚_//[ ].゚Д゚,,) ||___|||   || <  >>59を迎えに来ました
 ||_. *  _|_| ̄ ̄ ∪|.|.       |ヽ. _||  \__________
 lO|o―o|O゜.|二二 東|.|京 精神病院 ||
 | ∈口∋ ̄_l__l⌒l_|_____|_l⌒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でアクセスすると「なんで主キーがないんじゃー!!」って怒りたくなるのが不思議だw

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

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で公開されている郵便番号簿をみるとゾッとするぞw。

219 :212:04/04/15 16:44 ID:5tDhWOhP
>>217
updateはしないよ
1つづつ書き換えるのは面倒だから
公開されている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
いっちゃいけないのかもしれないけど、きちんと正規化してER図書いて
プライマリキーとインデックス貼り付けるのがDB設計の8割じゃない?
プライマリキーとインデックスないDBなんか考えられない
後は日時バッチ用の各容量見積もりとか
ロールバック領域足りなくて落ちた時は死にかけた

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

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


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 にテーブルを作ったときに
主キー制約を入れられるはずも無いし、付けても適当につけてみるだけだから「データが
入れにくい」だのという考えになるわけで。

 j3、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:???
1テーブル一個までとか?
つか上の方にまったく同じ質問があるな

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:???
うちのDB、コストベースなのにアナライズやってねーぞ。

俺もびびった。

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行の1行目を削ったからといって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
食い違っていそうなのと、誤解が生じしているのと、考え方が違いそうです。
で、違う点を書きかけたんだけど、止めましたw

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

283 :NAME IS NULL:04/08/26 23:46 ID:???
>>281 その方式だと、他の人が同時に同じ操作をすると、「最終的に表示されてる画面」を
両者が得ることはありえないような気がしますが。

まあ5行ならなんでもいいと思いますが。それこそ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
自動と言えば聞こえはいいが、別の見方をすれば「設定不能」だったりw
管理者不在の小さめのシステムなら願ったり叶ったりなんだけどね。

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
フォローサンクス。

たしかに「赤黒処理」と「(例えば)伝票の打ちミスを直すための修正」ってのは本来別の扱いであり、処理を分けるのがベストなのは確かです。
なんですけど、
>せいぜいユーザーに「赤黒みたいにうんぬん」って説明するくらい。
ユーザーに「赤黒処理」と「修正」の時のオペレーションを分けるて覚えてもらう。というのがなかなかねぇ。
かえってトラブルになっちゃったこともあってさ。

「必ず赤いれてから黒入れます!」と宣言して、その通りやってるユーザは今までで一件かな。
そこは「だから修正モードはずしてください!」という気合いの入れようだったがw



>>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:???
態度悪ぃなw

334 :NAME IS NULL:04/09/24 19:56:44 ID:???
> いいえまったく

なんだよ。読んでもいないのに、電子帳簿保存法に対応するためには〜 とか
偉そうなこと言ってたのかよ。本当に 知ったか君だったんだなw

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:???
そのシステムを改修する為に顧客から金取れてこそ一流w

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 :347: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 :347:04/10/10 09:31:09 ID:gYcBhHE/
>>348

ああ、わかった。それってBTRIEVEスレのでしょ?


354 :NAME IS NULL:04/10/11 18:50:49 ID:???
>>352
べつにいいじゃん、それくらい。

俺が昔やってた案件では、SEなのに、スプリクトとか言ってるやつ居たぞ 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
DWHだと主キー必須でもないよね

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:???
RDBの技法でDWHがまかなえるなら、
RDBMSにDWH用の個別機能なんて付けんだろ。

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:???
いやいやDWHの場合、いらない場合もあるよねと
いう話だったと思うが・・・。
そしたらレベルが低いだの煽る奴が出てきて
こうなったと。

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:???
366は確かにどうかと思うが、
それ以外は別に363に対してのレスじゃ
ないと思うけど、違うかな?

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 を2つ以上持つのでないなら 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を使わないシステムみたことありますか?

理由:遅くなるから。おかげで、コードとそれに1:1でリンクする名前が
同じテーブルに入ってます。また、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/77で、会計締め日を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型にして、その他に日付決定区分みたいの作った方がいいんじゃない?
確実に決まってるのなら、そのズバリのひづけと区分が1、
だいたい決まってるのなら、区分は2にして、その月の1日の日付でも入れておいた方がいいと思う。
そうすると、月単位でだいたいというひづけだけではなく、
多分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)
というようなテーブルに1行ずつ追加するような処理の場合、
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が入ってても「それで良いんだよ!!!」と言い張る奴がいたw

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
いや、俺が行った所は違いましたよw
NULL値です。
複合キーだからいいの!!って言われたんで
とりあえずハイ分かりました。って言って仰せのままにやったけどね

450 :NAME IS NULL:04/12/01 00:08:35 ID:???
>>446
検索性が高まりますよってことかな。dクス。

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して更新件数が0件なら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
明細独自のキーをつくっちゃうのは
キーがひとつっていう実装面での
便利さは確かにあるんだけど
設計が見えてこないのが気持ち悪いんです。

ヘッダ-明細の集約関連なのか、ただの関連なのか、とか。

それと、まれに実装面でも大変な事になります。
大量の受注データをファイルからインポートする場合、
明細IDが「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:???
おっしゃる通り、「取引単位」にみなユニークなキーをもってる訳で、
明細はその中の何行目くらいの意識しか業務上ないでしょう、普通。

取り敢えず、実装面での利便性はさておいて
そういった業務内容を設計に落とすんだったら、
明細テーブルのキーは、受注番号 + 連番にすべきですよね。

ここで問題になってるのは、明細単位に明細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:???
>便利さは確かにあるんだけど
>設計が見えてこないのが気持ち悪いんです。
なーる

ところで、複合キーの一部にNULLは許されなかったかな?
いや、移行システムの場合、移行データの主キーに平気でNULL
あったんで、IDは必要かなって思った


467 :NAME IS NULL:04/12/01 19:16:39 ID:???
RDBは理想と現実というか設計と実装が乖離することが多いと思う。
正規化をばっちり行って制約も完璧に付けたE-R図を作ったとして、
実装するときは正規化を崩して制約の大半はアプリ側ロジックに
移動させることになる。E-R図からSQLを生成する設計ツールが
あるけど使えないことが多いのはこのため。
独自キーの使用は設計と実装の区別がきちんとついてればいいんじ
ゃないかな。

>>466
複合主キーの一部にNULLは私の知ってる範囲ではどれもだめ
だったと思います。

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(受注番号, 明細番号) で明細番号が
シーケンスなりでつけられると。
> ここで問題になってるのは、明細単位に明細IDを持って
> 受注番号はただの属性になってるモデルはいかんなあ、
 外部キー制約が 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:???
「品名、型番、製造メーカー、数量」の項目があります。
この項目を正規化して、主キーにするならどれになりますか。
現在のところ品名IDなどは利用していません。
上記の項目で主キーになるものがなければ商品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:???
とある業務パッケージで主キーがなくテーブル項目も
1項目のみで 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マスターって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
主キー2つ作ってもいいの?

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も6.0くらいまでは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レコード。2番目のユーザのデータ取得はIDが
4から6までって感じで。
遠まわしに上司に進言しても、彼にまかせているからで終わり。
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
>ところで業務の都合上で項目追加に成った場合は、主キーも再検討が必要ってこと?
つうより、そのテーブルに追加管理したい項目をどこのテーブルに追加するべきかを検討するんでしょ。
無いなら新規テーブルじゃない?

>伝票でも帳簿でもログ処理でも通用するような、有る程度汎用性を考慮したレシピ的な理論が欲しいかも。
くれくれくんかよw。そんななら自分で決めて他人に強制すればいい。

616 :白馬の玉子 ◆PqSzNbkqDo :2006/04/12(水) 12:23:39 ID:???
某N社が作った、文教系のシステム見たことあるけど、
DBがOraだったけど、もろオフコン。
主キーなくて、フィールド4つ以上でやっと複合キーになるし、
同じ内容なのに、テーブル3つに分かれてるし・・・。
それなりの設計思想なんだろうけど、
時代を感じたな。
それでxx億円くらいとってたらしいけど・・・。
高速化のため!とか主張してたが、
見た感じ、遅くなる要素、満載だった・・・・・・・・。
ほとんどの更新系が、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と書けw
しかし、ホントに再利用とか保守性とか考えねーよな。
なぜ楽をするための努力を惜しむのかと。
いくらでも楽できる機能があるのに、だれもつかいやしねぇ。

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で組んでるっつーのに、

「作業工数管理したいから、ステップ数出して!」

だって・・・・。

その瞬間3秒ほど、回答詰まって体が固まった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
ステップ数を出すだけなら、出来合いのソフトもあるだろうし、
簡単でいいじゃん。上がそれで納得するならw

自分が欲するものを作るんじゃなくて、相手が欲しいものを作るのが
PGやSEの仕事なんだし。客だけじゃなくて上司でも同じだと思う。
まあ、社内改革するのなら徹底的に闘ってくれw

630 :NAME IS NULL:2006/04/20(木) 21:19:29 ID:ds1Y0fKR
>>627
大学事務員と、教授〜講師をいっしょにしないように。
事務員はプログラムなんて知らない。
ふつうの会社の事務と同じ。

631 :白馬の玉子 ◆PqSzNbkqDo :2006/04/20(木) 22:08:55 ID:???
>>629

「上がそれで納得するならw」
 ↑
この時点で、俺と仕事への姿勢が違うもんね。
理解できなくて当然っすよ。


なんか、スレの主旨とあわなくなっちゃったので、ごめんなさい>>みなさん。
このネタはしゅーりょーしときます。


632 :NAME IS NULL:2006/04/20(木) 22:27:43 ID:ds1Y0fKR
>>631
>>627を読んでも、どこかで勘違いしている臭いがプンプンするけどね。
ま、ひとりよがりで突っ走ってくれw

633 :元COBOL使い:2006/04/20(木) 22:57:17 ID:???
( ´∀`)オマエモナー>>632

>自分が欲するものを作るんじゃなくて、相手が欲しいものを作るのが
客が本当に欲っしているのは、正確な見積もりとその根拠だと思うが。

>まあ、社内改革するのなら徹底的に闘ってくれw
無 馬犬...(゚∀゚)アヒャヒャヒャヒャ

634 :NAME IS NULL:2006/04/21(金) 10:01:25 ID:CX6yg83T
>>633
>客が本当に欲っしているのは、正確な見積もりとその根拠だと思うが。
何?このずれた会話は。

マ板でよく見るがCOBOL使いの設計は最悪らしいが、>>633のレスで確信した。

635 :元COBOL使い:2006/04/21(金) 19:12:24 ID:???
飛躍しすぎと言う突っ込みならば、納得もしたが。。
まぁ、オマイさんの受け身な姿勢とレベルは分かったよ。

スレ違いスマソ

636 :NAME IS NULL:2006/04/21(金) 21:04:01 ID:HfZIsICF
>スレ違いスマソ
わかっているなら最初から来るな、ヴォケ。


637 :元COBOL使い: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なんかやらん。
こういうことを言っている奴ほど、
将来、2ちゃんでなくても似たようなことは絶対やっていると思う。
未来のことに対して言い切る奴って、だいたい無責任だし。

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でしたw

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代前半であたってるから、
反応してるってことでOK?


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:???
同じテーブル2世代間の差分を取ってくれって言われたんだが主キーがなかった。



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
10年後>>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
つうかお前ら全員データベースの試験受けて来いよw

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

ワロタww
リレーション概念ないんだな、それwww

677 :NAME IS NULL:2006/11/28(火) 00:42:42 ID:2uKzX2xW
今までデータベース使ったことないのに、今度オラクルを使うプロジェクトに投入されました。
プロジェクトで使うテーブルは作成完了していたんですが、
キーとしているのが製品名で、製品名をキーにもつ関連テーブルが全部で130個くらいあります。
製品名を変更したりする場合は「製品名保持テーブル一覧テーブル」を使って
ループしながら130個のテーブルの製品名をアップデートしたりしています。世の中のプロジェクトでは
こういうテーブル設計は一般的なんでしょうか?
製品名テールを作って、内部的にはユニークな番号を使って管理すれば製品名変更は
テーブルひとつ書き換えるだけですむのでは?という話をしたところ「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 の場合は
>キーとしているのが製品名で、製品名をキーにもつ関連テーブルが全部で130個くらい

うへぇ 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
このスレを眺めて自分なりの結論を出せ。(w

【恐怖】主キーがないテーブルみたことありますか?
http://pc8.2ch.net/test/read.cgi/db/1069324950/

693 :NAME IS NULL:2006/11/29(水) 20:12:58 ID:???
>>692
>【恐怖】主キーがないテーブルみたことありますか?
このスレがこれなので無限ループに陥りそうだ

>>690
主キーは行を一意に識別するもので、
ユニークで非NULLであるという制約を持つ。これが主キー制約。
主キー制約を実現するためにRDBでは索引を使用している。

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
こうやって誤魔化しながらいってるやつってのは、ほんとうはそれを言いたいわけだ。
1行目が本音で2行目が照れ隠し。


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
どうやったらそんな気色悪いテーブルが作れるのだろう?
1列=1バイト???

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 にしておk

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

192 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)