5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 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
「斬新」てのは皮肉でそ。

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

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

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)