【恐怖】主キーがないテーブルみたことありますか？
レス数が950を超えています。1000を超えると書き込みができなくなります。
0001NAME IS NULL
03/11/20 19:42ID:tPSXAOuFテーブルに主キーが1つも設定されていませんでした。
しかも全テーブルに。
担当者に問い合わせたところ、
「主キー付けるとデータを入れにくくない？」
っていわれました。
しかも「そんなこともしらないの」っていわれました。
システムは無事に完成。
納品されて、今も動いてます。
でも、主キー無しです。
良いのでしょうか？
0002NAME IS NULL
03/11/20 20:06ID:???0003NAME IS NULL
03/11/20 20:51ID:B2SQACwz0004NAME IS NULL
03/11/20 21:29ID:???CREATE TABLE PRIMARY_KEY_LESS_TABLE (id integer, data varchar(100));
見たーなーーー.
0005NAME IS NULL
03/11/20 21:33ID:uR4aexea0006NAME IS NULL
03/11/20 21:58ID:Nph1AJCd0007NAME IS NULL
03/11/20 22:25ID:???0008NAME IS NULL
03/11/20 23:42ID:???Joinとかしてたら最悪だね
0009NAME IS NULL
03/11/21 01:16ID:???確かに、１行単位での削除とかできないが、それは用途の問題だし。
uniqueでないindexでもべつにいいわけだし、
意味のない行番号ならつける必要ないんじゃない？
0010NAME IS NULL
03/11/21 09:36ID:0VNv31XXなってないとしても、レコードの挿入時に商品コードの値が
テーブル中で重複しないようにプログラムがチェックする
ようになっていればいい。なぜなら、ユニーク指定なしの
インデックスでも検索できるから。
そんな調子で全テーブルをユニークキーなしで開発する
ことは可能ではある。
でもそれって、本来はＤＢＭＳがやるはずの重複検査の
仕事をプログラムがやっているってことで、開発や保守で
必要以上の苦労をしょいこむことになるな。そうでなくても、
プログラムのコードをよく読まなければテーブルの関係を
理解できないってことになってこれはつらい。
データベースの構造を見ただけでどんなシステムかがわかる
くらいでないと、開発でも保守でもラクできないよね。
0011NAME IS NULL
03/11/21 11:16ID:???これが全てをものがたってるな
0012NAME IS NULL
03/11/21 12:33ID:8f3l89hg1の担当者はエクセルシートの代わりにDBを使いたかっただけなんだよ
なぜDBにしたかというと、そのほうが儲かるからだろう
実際、どうでもいいようなシステムなんだろ？
0013NAME IS NULL
03/11/21 13:02ID:???「カード1枚でユニークになってるだろ！」とゆー半端ユーザーの声が聞こえてきそうだ（涙
0014NAME IS NULL
03/11/21 15:30ID:???かならず主キーが必要と考えている>>1は問題あるぜ
主キーが何なのかを理解できているのか?
>>13
カード型DBって懐かしいな(w
Ninjaを思い出してしまった。
0015NAME IS NULL
03/11/21 18:07ID:???多分、必要と言っている分野の人はOracle派で、
どうでもいいと言っている人はMySQLとかMSSQLとか使いだと思う。
0016NAME IS NULL
03/11/21 18:13ID:???入れにくい、という理由でキーを廃止するのは違うと思う・・・
0017NAME IS NULL
03/11/21 20:56ID:???理論上 RDB には主キーなど必要無い。
但し、行全体でユニークにはなっていないといけない。
同じ内容の行が二つあったら駄目なところが Excal と違うとこ。
001817
03/11/21 20:57ID:???0019NAME IS NULL
03/11/21 21:28ID:???0020NAME IS NULL
03/11/21 22:17ID:???１はちょっといいすぎかと。やっぱ用途次第だと思うな。
「indexのないDB」だったらすごいけどな。
0021NAME IS NULL
03/11/21 22:21ID:???0022NAME IS NULL
03/11/21 22:22ID:???データ設計ってどういうんだよ・・のほうが突っ込むとこだな。
正規化スレ的だけど。JOINとかしないんだろうなー。
0023NAME IS NULL
03/11/22 02:49ID:???主キーが行全体になっていればいいんだな(w
0024NAME IS NULL
03/11/22 19:52ID:wXJ2Fokq要するに主キーを用いないで「他人にわかりやすい、
保守しやすいシステム」になるかどうかだ。
そういう意味ではどうなんだろう。
0025NAME IS NULL
03/11/22 20:26ID:???0026NAME IS NULL
03/11/22 21:10ID:???思うが。
アプリケーションログとかね。
0027NAME IS NULL
03/11/22 21:16ID:???全部のカラムをwhere条件に指定する。ｗ
0028NAME IS NULL
03/11/22 21:17ID:???＞テーブルに主キーが1つも設定されていませんでした。
＞しかも全テーブルに。
こんなシステム引継ぎさせられたら、暴れちゃう（ｗ
多分、1年ぐらいしたらレスポンス悪い部分がぼろぼろ出てきて
悲しくなるんだろうなぁ。。。
0029NAME IS NULL
03/11/22 21:17ID:???それをDBで管理するのは・・・どうよ？
0030NAME IS NULL
03/11/22 21:20ID:???うん。テキストファイルやCSVに書き出せとか言われそうだけど、
ファイルオブジェクト使うのが面倒とか、バックアップ・リカバリ
などはDBMSで一元管理したいとかね。
0031NAME IS NULL
03/11/22 21:28ID:???まぁでも主キーを設定したからって、それを使ってない不毛な
アプリをこれまで結構見てきたよ。
あくまで一意制約としてのみしか扱ってない。
実行計画みたら、全部テーブルスキャンとか。
003228
03/11/22 21:40ID:???あるある（ｗ
そういえば、もっと凄いのも見たことあった。。。
1レコードinsertするのに6時間くらいかかってたシステム。。。
ヽ（｀Д´）ﾉ 思い出したくないよー。
0033NAME IS NULL
03/11/22 21:40ID:???0034NAME IS NULL
03/11/22 21:46ID:???どうやったら、そんなに時間が掛かるんだ？
インデックスが全カラムにあるとかか？
0035NAME IS NULL
03/11/22 21:52ID:???OLTPなら間違いなくSessionTimeoutだな(藁
0036NAME IS NULL
03/11/23 09:52ID:???ユーザが痺れを切らしてタイムアウト、つか、ｺﾞﾙｧｰされるのが早い。
003728
03/11/23 10:19ID:???で見てみると、Oracleなのに表領域もテーブルもサイズ指定しないで
作成されてて、自動拡張し放題。
その上、データベースのディスクに通常のデータ(excel,waord,access等)
も一緒に放り込んでるので、フラグメンテーションし放題。
(´-`)．。oO（あぁ、oracleもmsaccess見たいに使うとこうなるのか・・・）
とか思いつつ。
動作しているサーバマシンを見るとメモリが128M。( Д ) ﾟ ﾟ
「もう、お願いしますからマシン買ってください」と言ってサーバを新しいのにして貰った。
＃余談：1データ登録するのに帰宅ときに登録、翌朝出社したら登録終了という
＃使い方をしてたらしい。。。
DBがどうとか、言う話じゃないっすね。スレ汚しすまんです。
0038NAME IS NULL
03/11/23 12:08ID:???時間がかかってるとしたら、主キーがないとかディスクがどうだとか
じゃあ説明つかないような気もするが。
実はビューだったとか、挿入トリガーが仕掛けてあったとかじゃない？
003928
03/11/23 12:26ID:???ぃゃ、そんな上等な話じゃなかったと思います。。。たぶん。。。
常時スワップしててディスクアクセスしっぱなしで、
メモ帳すらろくに動かん状態だったので。
oracleのエクステントも１Mくらいのが100超えてたし。
0040NAME IS NULL
03/11/23 12:38ID:???Oracle 9i でメモリ128だとありえない話では無いな。。
それに何も考えずにOracleフルインスコしてるんだろ？ 必要無いものまで。
0041NAME IS NULL
03/11/23 12:41ID:???＞＃余談：1データ登録するのに帰宅ときに登録、翌朝出社したら登録終了という
＞＃使い方をしてたらしい。。。
そんなんで運用できるとはどんなアプリなんだ？？
0042NAME IS NULL
03/11/23 12:48ID:???運用ルールが出来上がっていったんだろうなｗ
0043NAME IS NULL
03/11/23 13:13ID:???お客「検索が遅いんだけど速くしてくれない？？」
担当「え？主キーってなんですか？？」
のちの保守で地獄を見そうですな・・・。
１．素人は主キーを設定してはならない
0044NAME IS NULL
03/11/23 17:39ID:???Access使ってるシステムなんて企業の中枢システムなわけが無いから
テキトーでいいんです。テキトーで。
0045NAME IS NULL
03/11/23 17:48ID:???いや、中小の工場系では意外とマジに基幹だったりする・・・
納めたことありますもの。
0046NAME IS NULL
03/11/23 18:00ID:???あっ。。うちも400万ぐらいの仕事であったかも。。
新人が中心に作ってたな。
ﾊﾞｯｸｱｯﾌﾟ･ﾘｶﾊﾞﾘの立案も出来ないしﾃﾞｨｽｸ飛んだら
終了ですみたいなことを平然と言ってのけたらしい。
0047NAME IS NULL
03/11/23 18:05ID:???日次しかできないけど、バックアップ(コピー)ぐらいはしてるよね？
ウチは他に圧縮？(名前忘れた)も日次でしてるよ。
0048NAME IS NULL
03/11/23 18:16ID:???ごめん。直接携わってないからそこらへんはよくわかりません。
日次バックアップくらいはやってのかなぁ？
でも完全なスタンドアローンシステムでサーバなんてのは
無かったと思うし、業務終了したら多分パソコンの電源落としちゃう
運用だからバックアップなんてしてないかもね。
0049NAME IS NULL
03/11/23 18:30ID:???ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
ACCESSは業務に使うと定期的に壊れますた。
0050NAME IS NULL
03/11/24 04:38ID:???主キーがなくても通るのはODBC経由の話で、MSSQL自体は主キーがないと許さんよ。
0051NAME IS NULL
03/11/24 12:20ID:???いや、主キーがなくてもテーブル自体は定義出来るし、
ODBCでもアクセス出来るでしょ。
0052NAME IS NULL
03/11/24 15:27ID:???オラクルも主キーなしでテーブル作れるんだが…
0053NAME IS NULL
03/11/24 15:57ID:???警告が出るのは見たことあるけど
0054NAME IS NULL
03/11/24 22:51ID:???無いね。俺の汁限り。
0055NAME IS NULL
03/12/02 03:45ID:BGR/fIxz主キーと、ユニークインデックスってどう違うのでしょうか?
0056NAME IS NULL
03/12/02 03:48ID:RebitiAp1.（神が喘息であるかないかを決める）
Y I
2.喘息でない人 喘息の人は
は体力がある 体力がない
Y I
3. 行動力、
五感（嗅覚）が鈍り感性が変化
する
Y I
4.神は異常な感性の人間は本来人に迷惑をかけるから外に出てはいけないと思っている。
Y I
5.変化なし アトピーになる
Y I
6.正常な感性 外に出なくなりさらに異常な感 性になる
Y I
7.正常な人間 異常な人間（レッテル）
0057NAME IS NULL
03/12/02 03:49ID:RebitiAp8. 死
Y I
9. 来世
Y I
10.神は異常な人間は人に迷惑をかけるので行動を抑制する必要がある
Y I
11.神は異常な人間は人に迷惑をかけるので行動を抑制する必要があると思っている。
Y I
12.神が喘息であるかないかを決める
Y I
13.喘息でない 喘息である
Y I
1.に戻る
神は事態の収拾に必死、頑張れよー。
0058NAME IS NULL
03/12/02 03:50ID:RebitiAp行動力=ガッツ=体力
アトピー性皮膚炎の患者は、
感覚の鈍い人間が多い。
それはなぜか。
幼少期喘息になるから、
体力がつかないため、
五感が弱るからである。
解決方法は、
五感を強くしてやればいい。
体力をつけることですぐに五感が正常になり、
行動力も湧くのである。
五感が正常になり、体力もつけば、
アトピー性皮膚炎も不思議と消えることが多い。
0059NAME IS NULL
03/12/02 06:07ID:???プライマリキーの設定ができないDB（古いバージョンのSQL Serverなど）
を利用している場合、ユニークなインデックスを作成して、
プライマリキーと同等の効果を得ていた。
ちなみに
主キーとは
「表の行を唯一に識別できる列または列の組」のことで、
主キーの列にNULLを入れることは可。
プライマリキーの列にNULLを入れることは不可。
1が言っている主キーとは、おそらくプライマリキーのこと。
ユニークインデックスも主キーとして扱うことは可能。
0060NAME IS NULL
03/12/02 22:02ID:8caVKpbN昔は知らんが今は主キーとプライマリキーは同義だろ。
0061NAME IS NULL
03/12/02 23:19ID:???0062NAME IS NULL
03/12/03 00:23ID:???同義とはいえないな。
プライマリキーとは主キーに設定するものだ。
プライマリキーがない場合は、ユニークインデックスで代用しても可
ということだ。
0063NAME IS NULL
03/12/03 01:30ID:gFmAVNYs0064NAME IS NULL
03/12/03 01:57ID:???言語そろえてくれー
0065NAME IS NULL
03/12/03 15:17ID:???昔のことを知らない若造なのだが、
昔は「主キー」と「Primary key」が別物だったのか?
単なる訳語じゃないの?
教えろ。
0066NAME IS NULL
03/12/03 20:41ID:???0067NAME IS NULL
03/12/03 22:00ID:???今時、そんな設計する奴がどうかしてる。
ユニークインデックス設定する前にプライマリキーを設定しろ。
0068NAME IS NULL
03/12/04 00:40ID:dWNHaRO0INDEXはDB操作上の概念。
ドメインが違う。んでぇ、主キーが無いって事はRDBではない事だ。
0069NAME IS NULL
03/12/04 01:45ID:???>主キーはＤＢ設計上の概念
つまりはそういうことなんだろうな
0070NAME IS NULL
03/12/04 20:44ID:???＞んでぇ、主キーが無いって事はRDBではない事だ。
それは違ぁ～～～～う。
0071NAME IS NULL
03/12/05 07:02ID:???なぜだ？
0072NAME IS NULL
03/12/05 10:23ID:???0073NAME IS NULL
03/12/05 23:21ID:???嫁！ 主キーはRDBの必須条件ではない。
http://www.amazon.co.jp/exec/obidos/ASIN/4621042769/qid=1070631476/sr=1-1/ref=sr_1_2_1/250-0170725-0347471
0074NAME IS NULL
03/12/06 14:15ID:3t6cgsvv2.行が同一であることを見分ける属性の組み合わせを候補キーという
これは複数あってもよい。
3.候補キーのうち、一つを主たるものとするとき、これを主キーという。
RDBMSとしては、主キーがなくてもよいが、候補キーは必ず必要。
(内容が全く同一な行は複数存在してはいけない)
・・・ただ、それは理論的な話で、各社のRDBMSの実装としては、
内容が同一な行を追加できたりする。
現在、RDBMSとして売られているもので、完全なRDBMSという
(理論を完全に実装している)ものはない。
0075NAME IS NULL
03/12/06 21:30ID:???そ、これがＲＤＢの必須条件。
でも、主キーが無いテーブルは激しく使いにくいわーなぁ～。
0076NAME IS NULL
03/12/06 21:49ID:2T8SCnGq違うね。RDB理論では。
内容が全く同一な行は複数存在していけない。
かつその行の一意性を定めるのが主キーだ。
つまり、RDB理論では一意性が担保されるなら
日付時間（OSと同等の分解能）商品名 こんなテーブルも許可される。
テーブルの行全体が主キーなのだ。
これを誤解してそんな風に書いたのだろう。
0077NAME IS NULL
03/12/06 21:51ID:2T8SCnGq主キーにインデックスを張る必要は無いし、事実
そーゆう事はパフォーマンスの為にやることも有る。
RDBMSが主キーをどのように扱うかによるが。
0078NAME IS NULL
03/12/06 21:54ID:2T8SCnGq修正、
×かつその行の一意性を定めるのが主キーだ。
○かつその行の一意性を定める最小のカラム構成が主キーだ。
この方が分かり易い
0079NAME IS NULL
03/12/06 22:45ID:pWhb2iV/>>そーゆう事はパフォーマンスの為にやることも有る。
さっぱり理解できん。
0080NAME IS NULL
03/12/06 23:48ID:KSojWVKeテーブルにもいろいろあり、
マスター系のテーブルには主キーは必要かと。
データ系のテーブルには、インデックスを張っています。
（インデックスが壊れたときのため、ジャーナルナンバーと言う枠で最低限のデータのINDEXは保っています。）
それでもINDEXがないと（DATA量5Gぐらい：TXTベース）50％ぐらい処理能力は落ちます。
今後の為、意見等ございましたらお聞かせください。（当方SYBASE）
0081NAME IS NULL
03/12/07 00:28ID:rke3J8dh単に全カラムを同じように更新したいだけなのでは？
そもそも、ＰＫとは制約のひとつでしょ？ 決して必須ではないはず。
もっと柔軟に考えたら？ >>1
0082NAME IS NULL
03/12/07 00:35ID:???主キーはRDBなら必須。主キー制約を設定するかは任意。
0083NAME IS NULL
03/12/07 02:47ID:???データを入れにくい、という理由であえてPKを設定しないんだぜ？
0084NAME IS NULL
03/12/07 17:44ID:???0085NAME IS NULL
03/12/07 20:03ID:9CZAJDDr理論をわかった上でゆってほしいものです。
0086NAME IS NULL
03/12/08 00:02ID:WQRwbA5Pその心は？ただの釣り？
0087NAME IS NULL
03/12/08 03:13ID:9+dnfNsoデータを入れにくいからPKの設定しないような人たちの事だと思う。
てか、PKの設定をするとデータ入れにくいようなDBの設計をする人
の事だと思う。
0088NAME IS NULL
03/12/08 06:07ID:???データがかぶって重複エラーがうっとーしーのか
重複しない値を出すのがめんどーなのか・・
0089NAME IS NULL
03/12/08 15:07ID:???おそらく前者
おれも前に「は？」っていうテーブルにでくわしたことがある
下のようなデータをいれるテーブルで、
--------------
顧客 訪問日
--------------
A社 20030101
A社 20030110
B社 20030101
B社 20031010
C社 20030201
--------------
で、テーブル設計書には「顧客」がPKとなっていた。
担当者（上司）に「これは無理です！」って訴えたら、
「無理とかいうんじゃない！やってみなければわからんだろ！！」
って。。
わかるだろ。
0090８９
03/12/08 15:12ID:???このときは、PKの設定やめました。
上司の言う通り、やってみなくちゃわからないってことですね。
0091NAME IS NULL
03/12/08 16:00ID:???0092NAME IS NULL
03/12/08 16:48ID:???0093NAME IS NULL
03/12/08 21:14ID:???念のため聞くが、この場合はどのような切り方が正しいと思う?
0094NAME IS NULL
03/12/08 21:14ID:WQRwbA5Pネタとしか思えん。
0095NAME IS NULL
03/12/08 21:29ID:WQRwbA5P訪問履歴みたいなトランザクション系のテーブルと仮定したら
シーケンス番号(PrimaryKey)+顧客コード+訪問日
ってとこかな？
0096NAME IS NULL
03/12/08 22:48ID:???漏れなら
顧客コード＋訪問日＋枝番でPrimaryKeyかな。
0097NAME IS NULL
03/12/08 22:53ID:JXurB7u3全てのDBとのリンクは顧客コード中心場合によっては訪問日
なんて場合、PrimaryKeyに一意制約を付けて、顧客コードに
そのRDBMSで一番早いKeyを設定する（物凄く古いRDBMSだと重複可の主キーだったりする）
0098NAME IS NULL
03/12/08 23:27ID:???もちつけ
面白そうなんでもう少し分かりやすく説明してYO
009997では無いが
03/12/08 23:46ID:???PrimaryKeyには一意制約（重複しない条件）ために使用し、検索のスピード
を上げるためのキーとしては顧客コードの欄を用いる。その際に用いる値は
全てのテーブルで利用しかつ検索スピードが早くなるコードを考える。
こんなとこでOK？
010197
03/12/08 23:59ID:JXurB7u3ありがとう、ウンコこらえて一気に書いたら無茶な文章だった。
>>100
DWHなら俺はPrimaryKeyを外す（定義しない）。
やっぱデータ配置が密なほうが絶対早い。
と思う。ソフトによって違うのかもしれないが。
010297
03/12/09 00:02ID:i0WwMHTk0104NAME IS NULL
03/12/09 01:55ID:???顧客テーブル（顧客コード（PK）,顧客名）
ではだめなの？
0105NAME IS NULL
03/12/09 23:23ID:???0106NAME IS NULL
03/12/09 23:51ID:???0107NAME IS NULL
03/12/10 22:33ID:???0108NAME IS NULL
03/12/10 23:16ID:???回避策はたいていあるな。
0109NAME IS NULL
03/12/11 00:27ID:???というのは？
0110NAME IS NULL
03/12/12 03:52ID:???RDB対応に改造したとき、
主キーを設定していないテーブルがいくつもあったよ。
0111マハgogogo
03/12/13 01:22ID:???外部キーとかで操作って言うけど、それってあえてテーブル
に主キー付けないで、外部キー使うってことでしょ。
データ入れにくいから主キー付けないって考えとは雲泥の差があると思う。
0112NAME IS NULL
03/12/14 16:16ID:???sequence 使って捏造してでも primary key は付ける。
現場で手で UPDATE 文叩くことだって皆無じゃないから。
0113NAME IS NULL
03/12/14 19:14ID:???＞現場で手で UPDATE 文叩くことだって皆無じゃないから。
update の where 文に全カラムを入れれば無問題。
つか、最近のＤＢはExcel風のGUIツールがあるが。
0114NAME IS NULL
03/12/14 21:04ID:???primary key や unique key が存在しない場合、
内容の同じレコードが複数存在することがあります。
そのため where に全部書けばいいとは限りません。
普通は primary key がなくても相当の unique key を
付けますので、普通は unique index の付いた項目をすべて
where 句に書けば大丈夫ですね。
0115NAME IS NULL
03/12/15 00:13ID:3F1uDrzr>内容の同じレコードが複数存在することがあります。
>そのため where に全部書けばいいとは限りません。
そもそも、全く同一の内容のレコードの片方をUpdateするとき、
その片方を選ぶ根拠は何？
0116NAME IS NULL
03/12/15 00:36ID:???一方を変更したい場合って、まったく同じ内容のレコードが
あると困るときだとおもうな。うっかり出来ちゃったみたいな。
0117NAME IS NULL
03/12/15 00:58ID:???普通はキー無しの表を設計しませんからね…。
内容が同じでも別レコードとして単独にupdateしたいことは
皆無とは言えないと思います。>>113で言及されているデータ
保守用アプリの利用時がまさしくその例だと思いますし。
on delete cascade のために delete before insert が使えな
い可能性もあります。
どうしてもupdateするしかない場合はOracleのROWID等、RDBMSの
拡張機能として提供されている擬似列を使うことになると思い
ます。
0118NAME IS NULL
03/12/15 18:07ID:???主要なカラムがBLOBで構成されてたら…
0119NAME IS NULL
03/12/16 22:50ID:yTgNTNXB主キーなくても、索引つけりゃなんも問題ないだろ。
それにinsert処理なら、主キーなんてじゃま。
余計に遅くなる。
こんなんもしらんのけ
012000
03/12/16 23:00ID:iLPHMQmIえーと
SQL鯖で、前あったな～。
いきなり投入されたシステムの運用支援で、
プログラムからのdelete 文が実行されてなくて、
「？」と思ったのがきっかけ。
(当時SQL鯖初心者)
追加削除ができないので困った。
accessからも削除ができない。
で、項目「製造番号」のところ(12桁の数字)に、
「2E+18」とか入っているレコードがあった。。
おっさん、レコードをエクセル使っていじるんじゃねぇ…！
012100
03/12/16 23:02ID:iLPHMQmI(テーブルが不必要にforeign key 参照しまくりでがんじがらめ)
一年経たずに廃止になりましたけどね…。
0122NAME IS NULL
03/12/17 00:36ID:???索引はユニークな項目に対してより有効にききます。
0123NAME IS NULL
03/12/17 01:59ID:???データ突っこまれそうで恐いからforeign key使いまくる。
Oracle には deferrable initially deferred という宝刀もある
から、がんじがらめにしても無問題かもなー。
0124NAME IS NULL
03/12/17 02:48ID:0STEiHn4-------+--------
商品ID | 商品名
商品カテゴリテーブル
-------+------------
商品ID | カテゴリID
カテゴリテーブル
----------+------------
カテゴリID | カテゴリ名
この場合の「商品カテゴリテーブル」はどうなん？
0125NAME IS NULL
03/12/17 06:40ID:???商品カテゴリテーブルはそれでいいんじゃない？
・・そういうことではない？
0126NAME IS NULL
03/12/17 12:44ID:???012700
03/12/17 12:53ID:???それはどういう決断？
開発が終わってから(開発メンバーが去ってから)のほうが長いんだから、
そんなことを考慮してテーブル構造を変えたりしないと思うのだが…。
プロジェクトにもよるのかかな。
妙なデータの発生はコーディングのほうで回避する、ってのが筋ではないかとおもう。
そもそもforeign keyの機能って、必要に迫られたためしがない…。
考え方にもよるのかな～
012800
03/12/17 13:09ID:???「商品カテゴリテーブル」
↑このふたつのテーブルは、実質、同じ件数が格納されることになるのではないか？
現状だと、別テーブルにする意味がないような。
(「商品テーブル」の項目数の軽減のためかな?)
おおごとだけれど、
商品IDの頭2-3桁(例)がカテゴリCDで、それ以降の桁が商品ID、っていう構造にすれば
「商品カテゴリテーブル」の妙な肥大は回避できると思うんだけどねぇ。
もう動いているのなら変えられないけどねぇ。
0129124
03/12/17 15:31ID:0STEiHn4商品テーブル
---+---------
10 | ごぼう
11 | にんじん
商品カテゴリテーブル
---+---------
10 | 10
11 | 10
11 | 12
カテゴリテーブル
---+-------------
10 | 根菜
11 | 葉物
12 | 緑黄色野菜
13 | 季節限定
例えばこんな感じで「にんじん」が「根菜」で「緑黄色野菜」だったりして
商品とカテゴリが１：多の関係になってるときって、どういう風に管理するのが
納得な感じなのでしょうか。
何も考えないと「商品カテゴリテーブル」に主キーはないですよね、
[商品ID,カテゴリID]の組み合わせで一意になる制約はありますけど。
いや、それすら必要ないかな？
013000
03/12/17 15:47ID:???ああ、なるほど。
だとしたらテーブル構成はこのままで良いのではないかな？
すっきりしたPKつけたいのなら、
「商品カテゴリテーブル」に、「枝番」をつけて、
「商品ID」「枝番」でPK、だよね。。
商品カテゴリテーブル
-------+------------
商品ID |枝番| カテゴリID
11 |01 | 10
11 |02 | 12
運用上問題なければ、PKなくても問題ない一例かもしれない。
0131NAME IS NULL
03/12/17 21:44ID:???「商品ID」「カテゴリID」でＰＫだろ？
0132NAME IS NULL
03/12/17 23:25ID:???>>130
なんか、とてつもなくダサダサな設計論を紹介しているように見えるんだが...。
0133NAME IS NULL
03/12/17 23:58ID:???眩暈を覚えるテーブル設計ですな。
0134NAME IS NULL
03/12/18 00:17ID:???商品とカテゴリは多：多でないの？
-----------------
「ごぼう」は、「根菜」である
「にんじん」は、「根菜」であり、「緑黄色野菜」である
-----------------
「根菜」は「ごぼう」と「にんじん」である
「緑黄色野菜」は「にんじん」である。
0135124
03/12/18 01:28ID:oeMQRp8lなるほどカテゴリ側から見れば多：多ですね。
設計の視点が間違っている予感はするのですが、
だからといってこの方向が良いって言える解が見つからなくて...
皆さんだったらどのように設計します？
0137NAME IS NULL
03/12/18 22:18ID:???ＲＤＢで多：多のリレーションを実現するために中間テーブルの
商品カテゴリテーブルを実装するのは全く無問題。
が、商品をカテゴリ分類する場合は商品の属するカテゴリは
１つだけにするのが普通でないの？
商品＞商品分類＞商品中分類＞商品大分類 みたいに
0138NAME IS NULL
03/12/19 01:22ID:ULu1+Dg6連関エンティティ
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
0139124
03/12/19 22:31ID:???んー、普通の設計なんですね。
EJBコンテナとか使わないとエンティティ管理の実装がシンプルじゃないかもと
思ったので、違った視点が必要かなと思ったのでした。
# 商品＞商品分類＞商品中分類＞商品大分類 ってなんか教科書的と言うかみかか的(w
# 商品のナビゲーションはカテゴリからが自然なので、様々なカテゴリから
# 商品にアクセスできた方が良いかも。
0140NAME IS NULL
03/12/19 22:40ID:???なんでＥＪＢの話が出てくるんだ？
0141NAME IS NULL
03/12/20 00:31ID:tLfIozE0DB設計の不味い部分を辞書クラス使って、SELECT文何十回も発行てな、
クールな設計する奴はいるぞ。
>>139
商品分類が旧世代の教科書的てなイメージを持つのは、馬鹿の証拠。
教科書は大切。
＞# 商品のナビゲーションはカテゴリからが自然なので、様々なカテゴリから
＞# 商品にアクセスできた方が良いかも。
問題は、する必要が有るのか？無いのか？それがシステム設計だ馬鹿。
0142NAME IS NULL
03/12/20 01:19ID:tvcIIntnテーブル上には
腐ったみかんと食べ残しのカップ麺が散乱してます
ちなみ主キーは置いてありません
車のキーならたまに置きます
0143NAME IS NULL
03/12/20 04:53ID:???食卓テーブル | 腐ったみかん
+---------------
| 食べ残しのカップ麺1
+---------------
| 食べ残しのカップ麺2
+---------------
| 車のキー（たまに置く）
-------------+---------------
↑非正規形
あれ？「車のキーを時々置く」っていう場合は、
どういうテーブル設計にすればいいんだ？
0144143
03/12/20 04:55ID:???0145NAME IS NULL
03/12/20 20:26ID:???クールな(=寒い）設計？
>>143
--------+---------+--------
食卓CD ｜ 物品CD ｜ 数量
--------+---------+--------
001 ｜001 ｜ 3
001 ｜002 ｜ 5
001 ｜003 ｜ 1
001 ｜004 ｜ 0
--------+--------
食卓CD ｜ 食卓名
--------+--------
001 ｜うちの食卓
--------+--------
物品CD ｜ 物品名
--------+--------
001 ｜食べ残しのｶｯﾌﾟ麺
002 ｜腐ったみかん
003 ｜車のキー
004 ｜主キー
0146NAME IS NULL
03/12/21 00:54ID:???0147NAME IS NULL
03/12/21 10:20ID:???--------+--------
食卓CD ｜ 物品CD
--------+---------
001 ｜001
001 ｜002
001 ｜003
001 ｜004
食卓在庫数
--------+---------+--------
食卓CD ｜ 物品CD ｜ 数量
--------+---------+--------
001 ｜001 ｜ 3
001 ｜002 ｜ 5
001 ｜003 ｜ 1
JOINさせると「主キー」の数量がＮＵＬＬになっちまう。
ま、こんなＴＢＬ設計をする香具師は居ないが。
0148NAME IS NULL
03/12/21 11:11ID:???inner joinすりゃ、結果表に物品が現れない場合と数量0で現れる
場合とが混在する可能性があるから、「テーブルの上に存在しない」
ことをどっちの方法で表現するのか、きちっと決めとくべきだね。
0149NAME IS NULL
03/12/21 11:33ID:jMVBpQ+5日付型のフィールドなんかどうしてる？
漏れはNULLを使わずに日付最小値を入れて未入力としている厨な分けだが。ｗ
0150NAME IS NULL
03/12/23 23:35ID:teG3e5joDBMSはどうなの？
0151NAME IS NULL
03/12/23 23:50ID:???NULLを評価するとNULLじゃないの？ふつう。
3値論理だから、trueじゃないからといってfalseとは限らないんだが。
0152NAME IS NULL
03/12/24 17:21ID:???主キーがなくても問題ないといった香具師は今すぐ転職しろ。
0153NAME IS NULL
03/12/24 20:14ID:???ネタだよ。きっとネタなんだよ。ありえねーもん。
0154NAME IS NULL
03/12/25 06:52ID:???「主キーがなくても問題ない」≠「明示的にプライマリーキーを設定しなくても問題ない」
0155NAME IS NULL
03/12/25 23:41ID:qujOKXeg「主キーが無いと正規化できない」＝ 「候補キーがないと正規化できない」
0156NAME IS NULL
04/01/06 01:14ID:Y7tiwV5D表Ａ
コード 内容
-------------------
01 ＡＡＡ
02 ＢＢＢ
03 ＣＣＣ
表Ｂ
コード 内容
-------------------
01 ＡＡＡ
03 ＣＣＣ
上記のような表があったとき、
コード 内容
-------------------
02 ＢＢＢ
上記１行を出力したい場合、ＩＮとＥＸＩＳＴＳとＡＮＹ以外の問い合わせ
の仕方がありませんでしょうか？本当に初心者的な質問で申し訳ありません
が、お願いします。
0157156
04/01/06 01:15ID:Y7tiwV5D本当にすいません。
0158NAME IS NULL
04/01/06 18:43ID:tMR0UX3m郵政省が配布しているデータが
郵便番号と住所が1:1対応してないじゃん。
★意味の無い住所CDを全レコードに振る
か、
★郵便番号に枝番号を振れば
主キーの設定もできるけど。
郵政省以外に更新しない郵便番号データなんて、インデックスを振れば十分だと思うだけど。
参照しかしないし
0159NAME IS NULL
04/01/06 21:17ID:???0160159
04/01/06 21:21ID:???首吊ってくる
0161NAME IS NULL
04/01/07 01:03ID:???1年程前Oracleで全テーブルPrimary Keyなし＆indexもなしの
DB＋C/Sアプリ引継ぎさせられますた。。
最初アプリのレビューしてて
「やけにレスポンス悪いねー。VBだから？」
とか言っててOracleの中身見て吐血
0162161
04/01/07 01:07ID:???当然Viewもストアドも一切使用してなかった。
もともと作ったのはロートルPGだったが、そいつに突っ込み入れたところ
「漏れは長年データベース組んでんだ。RDBMSつーのは云々...」
といいつつISAMのことを語ってくれました。
今思うとコボちゃんだったのかな...
0163NAME IS NULL
04/01/15 00:06ID:h83lfTYGサイズ小とかの理由でindex使われないこともあるが。
ストアドはパフォーマンス向上には寄与しないとおもふ。。
0164NAME IS NULL
04/01/15 00:19ID:NrCWc0uY概念スキーマと外部スキーマの役割を区別して設計してるんだろうな？
0165NAME IS NULL
04/01/15 01:38ID:h83lfTYG0166NAME IS NULL
04/01/15 01:43ID:mutL718k非正規形データはRDBMSに保存できませんが何か？
0167掃除屋
04/01/15 09:18ID:NrCWc0uYRDB設計の基礎知識であり必須作業である正規化すらできずに
人並みの仕事をしているつもりか？マヌケな野郎だ。
そうやって無駄に複雑なSQLでしかデータを取り出せない冗長性だらけで
現実のモデルとかけ離れたテーブル作って
周りに迷惑かけてろや。
どうせお前は現場でオラクルの使い方をかじっただけでデータベースの設計ができると
勘違いしちゃったクチだろ？
金槌の使い方を覚えただけで自分が建築技術者だと
言ってるようなものだ、恥ずかしい奴だな。
お前のような見込みのないシロートに業界に居座られると迷惑だ。
どうせソフ開すらもてないような奴なんだろ？資格は必要ないとかいってな。
そんな調子だからいつまでたっても自分の無知に気づかないんだよ。
0168NAME IS NULL
04/01/15 09:48ID:jgmx8aMICOBOLERはどこまでもCOBOLERだからな～。
COBOLER＝おじさん＝新しいものを取り込まない。
0169NAME IS NULL
04/01/21 19:17ID:nARDT7b3でもアクセスパスを定義しまくって、
検索はスムーズにおこなえるようにしている。
0170仕様書
04/01/23 01:23ID:CYawNWdo0171NAME IS NULL
04/01/23 20:40ID:???っていうテクニックはあるけれどそれ以外にはありえない。
っていうか、俺は過去に５つのテーブルが存在しリレーションすらはら
れておらずそれぞれが完結しているというとんでもないものを見かけた
ことがある。
それひとつひとつにフォームをあてているだけなので、結果としては、
単体のDBが５つあるのと同じ事になっている。アホだ
0172NAME IS NULL
04/01/23 22:46ID:???0173NAME IS NULL
04/01/24 10:35ID:???でも、DB５つもあってそれぞれにテーブル１個ずつでも
びっくりすると思う。
ってMS-Accessの話かな？
0174NAME IS NULL
04/01/26 19:03ID:???┌┬┬┬┐
―――┴┴┴┴┴―――――、
/. ￣￣￣//.￣￣| ||￣￣￣|||￣ |｜ ＿＿＿＿＿＿＿＿＿＿
/. ∧// ∧ ∧| || ||| |｜ ／
[/＿＿__(ﾟ_//[ ].ﾟДﾟ,,) ||＿＿＿||| |｜ ＜ >>59を迎えに来ました
||_. * ＿|_|￣￣ ∪|.|. |ヽ. _|｜ ＼＿＿＿＿＿＿＿＿＿＿
lO|o―o|O゜.|二二 東|.|京 精神病院 ||
| ∈口∋￣_l＿＿ｌ⌒ｌ_|＿＿＿__|_ｌ⌒ｌ_||
￣￣`ー'￣ `ー' `ー' `ー'
0175NAME IS NULL
04/01/26 19:03ID:???0176NAME IS NULL
04/01/26 21:51ID:???0177NAME IS NULL
04/02/02 01:34ID:sQ5PbkJpAS/400だとよく見かけるね。
RPGでだけアクセスしてると別に何も感じないんだが、SQLでアクセスすると「なんで主キーがないんじゃー！！」って怒りたくなるのが不思議だｗ
0178NAME IS NULL
04/02/03 14:40ID:bgMlnR6c「プライマリキーは、オートナンバーでも構わないので、作成しましょう」
とのこと。
0179NAME IS NULL
04/02/04 11:11ID:6xEmbT4Jあたりまえ
0180いなむらきよし
04/02/07 11:49ID:3tu0zbdS0181NAME IS NULL
04/02/08 01:00ID:???MSSQLServerの話だろ。
0182NAME IS NULL
04/02/08 13:08ID:???遅いYO! ﾌﾟﾝﾌﾟﾝ
0183NAME IS NULL
04/02/13 14:08ID:???だからあれほど主キーを入れろといったのに
0184NAME IS NULL
04/02/15 19:09ID:???0185NAME IS NULL
04/02/16 16:04ID:???繰り返し項目ってなに？
※おおりぢゃないよ
0186NAME IS NULL
04/02/16 22:59ID:???0187NAME IS NULL
04/02/17 02:21ID:???0189NAME IS NULL
04/02/24 01:34ID:???プライマリーキーは「なぜか必須」になる。
正規化には候補キーは必要だが「プライマリーキー」である必要はない。
複数のカラムで候補キーとする場合、それらがすべて必須ってのはちょっと違う。
>>「プライマリキーは、オートナンバーでも構わないので、作成しましょう」
本末転倒だな。
0190NAME IS NULL
04/02/27 00:20ID:9O5906Ixおっしゃっていることが、よくわかりませんが・・・
0191NAME IS NULL
04/02/27 01:33ID:???別件で調べててそのDBのDBAとともにｶﾞｸﾌﾞﾙしました。
0192NAME IS NULL
04/03/03 01:36ID:???主キーはいらないんじゃないかな
0193NAME IS NULL
04/03/10 18:44ID:???もまい、ネ申..._〆(ﾟ▽ﾟ*)
0194NAME IS NULL
04/03/13 13:56ID:???しかも数十万レコードもデータが入ってるし、、、
恐るべきことに、他にもそんなテーブルがごろごろしてて、それらが結合されてた・・・
0195NAME IS NULL
04/03/13 16:24ID:/t1ODX8Rパーティション化してあるから大丈夫
0196NAME IS NULL
04/03/13 16:37ID:???そんな機能があればよかったんだけどねえ・・・
0197NAME IS NULL
04/03/13 19:20ID:I4l0yLx20198NAME IS NULL
04/03/13 23:25ID:/t1ODX8Rアプリで制御できるなら問題なし
0199NAME IS NULL
04/03/13 23:42ID:???ちゅーか、要件が歪んでて参照制約が掛けられないことも珍しくは無いと思う。
0200NAME IS NULL
04/03/14 02:21ID:eItUSnYsシステムを構築する上での必須制約かと思ってたよ。
0201NAME IS NULL
04/03/14 13:03ID:B4c9J9Pd0202NAME IS NULL
04/03/14 15:27ID:xe/2CQpY主キーがなければ索引はどうするんだ。
0203NAME IS NULL
04/03/14 16:09ID:eItUSnYsしかし、この板人すくねーな。たのしめねーよ。
0204NAME IS NULL
04/03/14 18:25ID:???この板自体が不要。
0205NAME IS NULL
04/03/15 02:05ID:???でも、下手に晒すとバレそうだし・・・
0206NAME IS NULL
04/03/17 17:55ID:Uhc3+ibkアクセスパスを定義する。
0207NAME IS NULL
04/04/10 18:20ID:0lCIHzGk・ユーザ名は英数で 名.姓
・パスワードはユーザ本人が自由変更できる
のようなテーブルの場合、主キーはどうすればいいの？
0208NAME IS NULL
04/04/10 18:25ID:???0209NAME IS NULL
04/04/10 18:52ID:???ユーザID
0210NAME IS NULL
04/04/11 00:01ID:???0211NAME IS NULL
04/04/11 00:21ID:19/IzA4K主キー : 論理
索引 : 物理
直交するものだから別にどうにでもなる
0212NAME IS NULL
04/04/13 10:28ID:vsQHurnf主キー入れる必要がないような。。。
0213NAME IS NULL
04/04/13 10:48ID:???同じくｗ
郵便番号がユニークでないのを始めて知った。
通し番号を振っても、市町村合併が盛んだし、メンテが大変。
結局、参考程度にしかならないんだよね。
0214NAME IS NULL
04/04/13 20:58ID:uWW+pR+n郵便番号が重複してもいいなら別に主KEY設定する必要も無さそう。
まぁでも正規化の思想からは外れるわな。
0215NAME IS NULL
04/04/14 01:17ID:???0216NAME IS NULL
04/04/14 09:32ID:???テーブルによっては整理番号の枝番号。
それでも重複する場合は必要に応じてキーを増やす。
。。。遅え＿|￣|○
0217NAME IS NULL
04/04/14 21:35ID:???レコードをupdateしないのか？
まあ、updateキーを元の住所
にすればいいけど、そうなると、住所がPKか．．．
0218213
04/04/15 00:26ID:???合併が起きると住所そのものが変わるし、追加/廃止になった郵便番号とか考えると、
updateで対処できる範疇を超えるかと。住所録テーブルとうまく郵便番号テーブルを
リレーションさせるのには漏れには無理。入力時の参考程度にしか出来ない。
実際csvで公開されている郵便番号簿をみるとゾッとするぞｗ。
0219212
04/04/15 16:44ID:5tDhWOhPupdateはしないよ
１つづつ書き換えるのは面倒だから
公開されているcsvがバージョンUPしてたら
データを総入れ替えします。
通常つかうsql文は
select 住所 from table where 郵便番号='val'というvalの値しか変わらない
sql文のみです
0220NAME IS NULL
04/04/17 22:33ID:???変更前のデータであることを条件にしている場合はどうするの。
古い住所が必要なときもあるよ。
0221NAME IS NULL
04/04/20 15:11ID:???古い住所が必要なら旧住所レコードを用意しておくか、
遡る必要があるなら住所履歴マスタでも作りましょう。
0222sage
04/04/21 02:08ID:E7N2wz6iプライマリキーとインデックス貼り付けるのがＤＢ設計の８割じゃない？
プライマリキーとインデックスないＤＢなんか考えられない
後は日時バッチ用の各容量見積もりとか
ロールバック領域足りなくて落ちた時は死にかけた
0223NAME IS NULL
04/04/21 11:21ID:???落ちたときの回復と
設計変更でテーブル切り直し->移行
で、DB運用の9割を占めるウチの職場はどーなるんだ orz
0224NAME IS NULL
04/04/22 17:49ID:???どのように設計したら効率がいいですか？
検索条件になるカラムにインデックス貼りまくる位しか
思いつかないんですが。。。
例えば（データの）入力日付が検索条件になる時って
トランザクションテーブルは連番を主キーにしないで、
入力日付を主キーにした方がいいんでしょうか？
0225NAME IS NULL
04/04/22 20:01ID:???「様々な条件」をパターン化し、優先順位を付けて対応。
後半は意味不明。主キーとインデックスは違う物だ。
0226NAME IS NULL
04/04/22 20:49ID:???設計して失敗するのも人生だ。
まずは自分にわかりやすいように組んでみなはれ。
失敗が許されないような案件だったら丸投げした方がマシ。
この場合の「トランザクション」は一部の業界でしか通じない用語の
ような気もする(転職組の後輩が使ったとき、10分間意思疎通できんかった)が、
俺がよくやってる組み方では、
入力日時・連番 を複合プライマリキーにする。
連番は単に、日時の粒度を割ったときにユニークにするためだけに用いる
ワケだ。
Sybaseでは、プライマリキーの処理は UNIQUE INDEX と変わらないので、
日時による絞り込みも、上記のやり方でそこそこうまく行く。
(逆に、連番による絞り込みでは、連番のみにもインデクス張らないと
順次スキャンに走ろうとする)
0227NAME IS NULL
04/04/23 10:26ID:???質問スレじゃないのにアドバイスありがとうございます。
昔やったシステムを今振り返って
「こうやったらもっと効率よかったかな」と復習してる所です。
妄想先走りの質問でわかりにくかったかもしれないですね。すまんす。
設計段階ではどの検索条件が一番使われるかわからないんですよね。
入力日、仕入れ日、商品コードとか。
教訓としては、主キーとして作った「連番」では検索してくれないってことですね。
作る側から言えば、主キーで検索してくれるのが一番ありがたいんですがｗ
ユーザーレビューのときに、「そっち使うのかよ！！」とか思ったし。
0228NAME IS NULL
04/04/29 01:52ID:???0229228
04/04/29 01:56ID:???まぁ客先が満足してるなら、それはそれで問題ないとは思うけど。
0230NAME IS NULL
04/04/29 03:38ID:???そんなに責めるなって
0231NAME AS 名無しさん
04/06/06 15:31ID:???DBMS 上にその表を乗せるときに「この列の組を使うと行を一意に識別できますよ～」と
DBMS に教えてあげる CONSTRAINT PRIMARY KEY がごっちゃになっている人が
見える希ガス。
テーブル設計時に、「最低限この列(の組)で確実にひとつの行を取り出せる」という
候補キーは通常必ず見つけ出すものでないのかな?
で、この候補キーのひとつを DBMS に PRIMARY KEY ですよ～、と教えてあげるのは、
DBMS の機能次第で CONSTRAINT PRIMARY KEY としたり、古い MS-SQL なら
NOT NULL にした上で UNIQUE INDEX をつけてあげるなりすればいいと。
>1 の担当者は、そもそも PRIMARY KEY 制約がなんなのかを分かってないみたいだから
設計時点から候補キーが無かったのかな。それなら DBMS にテーブルを作ったときに
主キー制約を入れられるはずも無いし、付けても適当につけてみるだけだから「データが
入れにくい」だのという考えになるわけで。
ｊ３、DBMS はアプリからの更新要求に対して
「重複データを作ってはいけないところを PRIMARY KEY 制約や UNIQUE INDEX で保護する」
「NULL を許可しないところを NOT NULL 制約で保護する」
「外部キーを参照する列(の組み)が無効にならないよう FOREIGN KEY 制約で保護する」
といった役目を果たすものなのに、アプリがこれらを防ぐようにがんばっているのは
「高い金だして人を雇ったが、すべてお膳立てした上で一挙手一投足全部指定しないと
ぬるぽなことをするやつだ」
ってなかんじで高いおきゃねを払って DBMS を導入した意味がなくなるわね。
＃我ながら分かりづらい例え且つ長文なので sage る
0232NAME AS 名無しさん
04/06/06 15:43ID:???フォームの mdb 側では各担当者の担当する会社ごとに動的にリンクテーブルを
設定するというナイスシステムがあり申す。何でも上司から「同じファイルに違う会社の
情報が入るのはセキュリティ上よろしくない云々」とか言われたとか。…何じゃそりゃ。
みたところ主キーの設定されていないテーブルはちらほらと、参照制約はなし
(担当者いわく「参照制約つけると更新とか面倒に(ry」そもそもクエリエディタで
自動的に JOIN させるための設定と思っていたモヨン)
また顧客への資料送付で「顧客が求めた資料」列 に "a100,b200,c300" と資料IDが
カンマ区切りで…これって、アリ?
’長文の後なので sage
0233NAME IS NULL
04/06/17 04:20ID:f8HScxEM0234NAME IS NULL
04/07/03 17:30ID:Km1DPrcI例えばオラクルで、
PRIMARYにするのとUNIQUE + NOT NULLでは、
何が違うの？
0235NAME IS NULL
04/07/03 20:19ID:???ﾋｨｨ((((；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
0236NAME IS NULL
04/07/03 20:46ID:???0237NAME IS NULL
04/07/03 21:06ID:???0238NAME IS NULL
04/07/03 22:08ID:???0239NAME IS NULL
04/07/04 02:57ID:???0240234
04/07/04 12:05ID:???実行プランが変わるくらいじゃない？
0241NAME IS NULL
04/07/04 13:45ID:???外部キーの親である主キーの役割をUNIQUEとNOT NULLが果たすのか？
0242NAME IS NULL
04/07/04 13:46ID:???アホか
0243NAME IS NULL
04/07/04 14:52ID:???複合のユニーク？できるよ。
ユニークを外部キーの親にも使える。
0244NAME IS NULL
04/07/05 00:23ID:???PRIMARYの概念上の意味はともかく、
RDMS実装上、どう違うかわかってるか？
0245NAME IS NULL
04/07/05 00:57ID:???つか上の方にまったく同じ質問があるな
0246NAME IS NULL
04/07/05 16:10ID:cp2QZHNA動いてりゃいいんだよ
0247NAME IS NULL
04/07/07 11:04ID:???禿同
ただ、「主キー付けるとデータを入れにくくない？」
という理由はどうかと思うが・・・
0248NAME IS NULL
04/07/12 10:43ID:???一見便利なモノを渡されたのでそいつらの流儀に則って書いてみた
Primary key?[x]という項目があるので一意なカラムをチェックさせて、はき出させてガツガツ作成した
・
・
・
excelから出されたのは、ただのindex指定であった しかも not unique
嫌な予感がしたので、他のテーブルをみたら50以上テーブルが出来ていたが
一つもprimary keyなどなかった。
0249NAME IS NULL
04/07/19 14:12ID:???よーく見てみよう。ほら、作った覚えの無い[PrimaryKey]というautoincrement型の列が端っこに…Σ(ﾟДﾟ；ｷｬｱｧｧｧｰｰｰｰｰｰ
0250NAME IS NULL
04/08/20 02:07ID:???俺もびびった。
0251NAME IS NULL
04/08/22 04:20ID:???ユニークであることは直接データを入れたこの俺が保証する。
0252NAME IS NULL
04/08/25 01:12ID:???実際の UI を考えると、アプリケーションでの事前チェックは事実上必須だと思います。
・一意制約
アプリケーションでは、伝票番号などの主キーを入力して、すでに存在すれば
編集モード(編集後は update)、存在しなければ新規作成(編集後は insert) と
することも多いと思います。つまり、一意制約に頼らずにレコードの存在チェックはしている。
・NULL許可, 外部参照制約
アプリケーションでは、商品コードを入力したらその名称を表示します。
つまり、この時点で外部テーブルが参照できるか確認しているわけです。
そして、該当データが見つからなければアプリケーションとして再入力を促す。
つまり、使い勝手を考慮したアプリケーションでは、データ更新を試みる前に
ある程度のチェックを行うのは一般的だと思うわけです。
もちろん、アプリケーション以外の汎用的な操作ツールでデータ操作される可能性もあるので、
私は、ちゃんとデータベースの制約を設定していますけどね。
0253NAME IS NULL
04/08/25 01:41ID:???DBの制約とアプリケーション上のチェックは基本的に層が違う。
一意制約の役目は存在チェックじゃないべさ。
外部参照制約に関しても同様。
データ層において、矛盾するデータが存在しないように縛るのが制約の役目。
制約に引っかかった場合に何をどうするかはビジネスロジック層の話。
0254252
04/08/25 11:13ID:???行って上手くハンドリングすることで、一意性が保たれるということ。
DB でできることを、わざわざアプリケーションでやる必要はない、という意見もあるけど、
「わざわざ」やっているわけではなくて、一般的な UI を考えたら、「おのずと」
アプリケーションでの事前チェックは必要になる。そして、アプリケーションによって
一意性は保たれる。一意制約違反が出てから、それをハンドリングするなんていう
アプリケーション実装は考えられない。
外部参照制約についてもそう。アプリケーションでディメンションにデータがあることを確認してから、
ファクトテーブルに更新する。これも「わざわざ」ではなく、画面にディメンションの内容を表示する
都合があるので、アプリケーションで参照確認を事前に行うのは当たり前。
なので、データベースの制約違反をアプリケーションでハンドリングする、
というのが私には違和感があります。私は制約違反はあくまでも例外系という
位置付けでエラーが発生すれば、その内容を直接エラーダイアログで表示、
確認後、アプリケーション終了、という手法をとっています。
0255NAME IS NULL
04/08/25 11:19ID:???何が言いたいのかﾜｶﾝﾈ
0256252
04/08/25 11:33ID:???ただ、制約違反(例外発生通知)を積極的に利用したビジネスロジックの実装なんて
現実的ではないと思っただけです。
0257NAME IS NULL
04/08/25 11:55ID:???DBからの制約違反通知を利用してUIを持つアプリ組む例を見たことがあるし、
結局の所、それで工数が削減できるとか保守性が上がるとかなら積極的に使えばいいし
そうでなければ使わなければいいだけの話でぁ
0258NAME IS NULL
04/08/25 23:11ID:???そうやね。どんな状況でも DB まかせ、アプリまかせではいかんということで、
DB の制約は最後の砦、アプリはできる範囲で、一件ずつなら面倒見れば
いいし、一括登録ならアプリの判断は DB, NW 共に負担大だから DB に
お任せとかと使い分ければ DB や 他の資源にかかる負担も減るしレスポンスも
良くなってユーザも管理者もみんなﾆｺﾆｺだ。
0259NAME IS NULL
04/08/25 23:16ID:???Delete→再Insertでしる！」って言われたんだけど、そ
んなのってアリなの？
そう言った先輩も、この点は激しく疑問に感じている
らしく、「俺だって、上から言われて仕方なくやってる
んだ。」と言っていました。
0260NAME IS NULL
04/08/25 23:57ID:???うーん、どうなんだろうね。場合によっては悪くないと思うけど。
たとえば、明細データが5行あってアプリケーションで 3行目を削除する。
そうすると、旧4行目の明細の行番号を3にして、旧5行目の明細の行番号を4にして、
と行番号の書き換えを行わないといけない。これを update で実装するくらいなら、
delete してから、アプリケーション上のデータ構造をもとに insert しなおした方が
分かりやすいんじゃないかな。もちろん、delete から insert までトランザクションに
なっているわけで。
>>259 は具体的に何が問題だと思っているの？
0261NAME IS NULL
04/08/26 00:09ID:???0262259
04/08/26 00:14ID:???そうですか、場合によってはそういう手法もありなんですね。
ただ今回は、そういった明確な目的はなくコーディングの都合で
そうしてクレ。と言われただけなので、今はUpdateを使わないの
が主流なのかと疑問に感じた次第です。
0263NAME IS NULL
04/08/26 00:32ID:???んなわけない
260の例も、んなわけない
0264NAME IS NULL
04/08/26 01:23ID:???後で空き番を詰めるのなら、最初から行番号なんて振る必要ないのではないか?
つーか、参照整合性制約と参照操作を使ったことあるのか?
0265NAME IS NULL
04/08/26 03:18ID:???0266NAME IS NULL
04/08/26 09:26ID:???>264で連番不要の話がでているけど、それだと並びが保証されなくなるし、
伝票-明細形式でデータを持っているときに明細行をすべて削除する事が
参照整合性制約にひっかかる訳無いし。
0267NAME IS NULL
04/08/26 13:32ID:cVgrzJDR0268NAME IS NULL
04/08/26 15:20ID:w3jOjJTfどういうシステムかしらんが
作り手としてすごく違和感を感じるだろうな
その仕様を指定されたとして
0269260
04/08/26 19:39ID:ps/wA+nfいままで、当たり前のように使ってたよ orz
良かったら、何が悪いのかもう少し教えてください。
(1) delete/insert の代わりに update 文を使えば問題ない
(2) 行番号を振りなおすこと自体がおかしい
(3) 行番号という列が存在すること自体がおかしい
0270264
04/08/26 19:57ID:???画面出力等を考慮すると、連番不要は少し暴論だったかもしれない。
整合参照性制約については、UPDATEの代わりにDATELE/INSERTを
行うと発想する人は、そういった制約を設ける習慣が無いような感じが
したということ。
UPDATE文一発で全行の連番を維持しつつ隙間を埋めるのは難しいけど、
ストアドもしくはホスト言語でループしながら空き番を詰めるのは難しくないだろ。
0271NAME IS NULL
04/08/26 20:24ID:???並びの保障なら空き番あっても関係ないよね。
そもそも、行番号って主キーの一部になってない？
トランザクションの主キーを後で変更するのって
すごい違和感があるんだけど・・・
0272NAME IS NULL
04/08/26 20:48ID:???10000行の１行目を削ったからといって9999行をdeleteしてinsert
なんかしてたら遅くてしょうがないし。
260のやりかたは行ロックのトランザクションおかしくならんか？
0273260
04/08/26 21:10ID:ps/wA+nf増加方向へ振りなおさないといけないこともあるんです。
1. 商品A
2. 商品B
とあるときに、商品A のオプション商品や取り付け費用(商品扱い)を
追加した場合、伝票に印字の都合で、
1. 商品A
2. 商品Aオプション
3. 商品B
としたりすることもあります。このような要件を考えると、アプリケーションでの
操作時にデータベースのデータ構造も揃えたほうが分かりやすいと思うのですが･･･。
>>272
書き換えるのは行番号だけじゃないですよ？ 商品コードなども全部ずらさないといけません。
やはり、アプリケーションで持っているデータ構造を利用したほうが楽だと思ってしまうのですが。
伝票の話をしているのに、10000行というのも非現実的な話ですね。そんなことを
言いだしたら、サーバーカーソルをクライアントで使用することなんてできなくなってしまいますよ？
ロックについても問題ないと思います。READUNCOMMITTED 以下でなければ、
他のトランザクションからは読み取られませんから、ロックに関しては、
update と同等だと思っています。
･･･あまり納得のいく説明をしてくれる人がいないので、
今後もこの方法を使おうと思います。
0274264
04/08/26 21:18ID:???>商品コードなども全部ずらさないといけません。
ん? なんか話が飛躍しているような気が?
商品コードなどを差し替えるのなら、DELETE/INSERTが正しいと思うが、
>>260を読む限りにおいて、3行目を削除して行番号を詰めるのに、
商品コードをずらす必要性がﾜｶﾗﾝ。単純に行番号4と5を3と4に
書き換えるだけじゃないのか?
0275260
04/08/26 21:20ID:ps/wA+nfでも、これって事後振り付けですよね？ 削除して詰めることはできるけど、
挿入して増加方向に振りなおすことはできないと思います。
0276264
04/08/26 21:27ID:???>挿入して増加方向に振りなおすことはできないと思います。
行番号1-5まで挿入済みとして、そこへ新たに3行目を追加して、旧3行目以降をずらすってこと?
挿入する前に、UPDATE table SET rownum=rownum+1 WHERE rownum>=3;
としておいて、新たに3行目を挿入すれば済む話じゃないのか?
俺は勘違いしているのだろうか?
0277260
04/08/26 21:42ID:???>>276 その方法は複雑すぎます。
1, 2, 3, 4, 5, 6, 7 とあって, 2と3の間、4と5の間、6と7の間に挿入。
3と7は削除、このような複数の操作をアプリケーション画面で行った場合、
うまくいきますか？
>>271
> トランザクションの主キーを後で変更するのってすごい違和感があるんだけど・・・
「トランザクション」って伝票明細のことを言っているんですか？
私のいままで仕事してきたところでは、
・固定的なマスターテーブルに対して、トラン(変化)データ, トランテーブルと呼ぶ。
・実績データ、実績テーブルと呼ぶ。
・(たぶんOLAPかぶれがいたからだと思うけど)ファクトテーブルと呼ぶ。
というのがありましたが、トランザクションと呼ぶのは初めて聞きました。
最小処理単位のトランザクションと紛らわしくないですか？
0278NAME IS NULL
04/08/26 22:14ID:???規約にする真意はわからんが、楽するために使うことはあるな。
既存行があればupdate、なければinsertとする必要がある場合、
key値でdelete→insertとか。
0279264
04/08/26 22:29ID:???複雑っていわれりゃそれまでだけど、連番に複数の穴を開けるのは
1行のSQL文でできるし、挿入そのものは1行分ずつでしょ。
削除後に複数の隙間を無くす方がさらに面倒だったりするが、
ストアドを定義してでもUPDATE処理するよう心がけるがな。
0280NAME IS NULL
04/08/26 22:30ID:???0281260
04/08/26 22:58ID:???うーん、なんか話が食い違ってるようですね…。
複雑なのはクエリではなく手順なんですよ。
delete 伝票明細 where 伝票番号 = X and 伝票行番号 in (3, 4, 5) みたいに
ひとつのクエリで複数の穴をあけられるのは分かりますよ。でも、3, 4, 5 という
穴をあける位置はどうやって覚えておくんですか？
画面ではユーザーの操作によって、明細を表示しているグリッドコントロールの
表示は都度変わっていきます。(削除行はグリッドコントロールに存在しない)
操作のたびに、操作シーケンスを記録して最後にクエリを組み立てますか？
それとも、操作のたびにクエリをサーバーに投げますか？ さすがに都度クエリを
投げることはできないですよね。排他ロックがかかってしまうから。
そういうことを考えていくと、最終的に画面に表示されているグリッドコントロールを
元に delete/insert したほうが分かりやすいと思うんです。
ストアドでできるとか言ってますけど、与えるパラメータを準備するのも大変ですよ？
なんか話を聞いていると典型的データベース管理者って感じがします。
フロントエンドのアプリケーション実装の都合をまったく考えていないというか…。
0282264
04/08/26 23:31ID:???食い違っていそうなのと、誤解が生じしているのと、考え方が違いそうです。
で、違う点を書きかけたんだけど、止めましたｗ
ま、お互いのやり方でがんばりまひょ。
0283NAME IS NULL
04/08/26 23:46ID:???両者が得ることはありえないような気がしますが。
まあ５行ならなんでもいいと思いますが。それこそtruncateして全部insertしても。
0284260
04/08/26 23:48ID:???update派のほうが圧倒的に多いし、「お互いのやり方で…」ということではなく
「delete/insert ではまずい」という論調が多いようです。
どちらが、スマートに分かり易く記述できるか？ という問題であれば、「お互いのやり方で…」という
締め方でもいいんですが、「delete/insert ではまずい」という論調で語られたまま、
放置されるというのはツライものがあります。
私だけでなく、delete/insert を使っている少数派の人は、
「update でもできる」という方法を聞きたいのではなく、「delete/insert では
こういう問題点がある」というのを聞きたいのだと思います。
0285260
04/08/26 23:55ID:???更新ロックを獲得するようにしていますから(普通しますよね？)、同時に他の人が
同じ伝票を開くということはできません。もちろん、UI トランザクション中に
データの更新をすることはありませんから(最後にバッチ更新)、参照系業務が
ロックされることはありません。
> それこそtruncateして全部insertしても。
いや、さすがにそれはまずいっしょ。他の伝票消えちゃうし、トランザクションにできないし(w
0286NAME IS NULL
04/08/27 00:59ID:???編集操作は毎回クエリを投げて（っていうかブラウザでやるし）
最後に戻す・・って感じでつくるかな。
それだと、最後にまとめてdelete/insertになりますね。
行番号の必要性はいまいちわからないけど。
ころころ変わるんだからプライマリキーじゃないだろうし、
それで編集なんかしていいのか？ みたいな。
プライマリキーあるならそれ使えばいいじゃん。ぐらいな。
たぶん、行番号の話でなんか混乱が生じてるんだと思います。
DB操作って100万行ぐらいよくあるし、「え～ずらすの～！」
みたいな～。そういう感覚がしみついてるから、抵抗を覚える
んだと思いますよ。
0287NAME IS NULL
04/08/27 01:12ID:???delete/insertすると書き換えないとこのindexまで更新するので重いし。
ネットワークのトラフィックも食うし。JDBCのデータのパースも時間かかる。
必要なとこだけ書き換えたいのが人情。
0288266
04/08/27 01:24ID:???多数クライアントからガンガン更新かかるようなシステムだとそのへんも気にしなきゃいけない？
おいらのところはせいぜいクライアント10以下の小規模なシステムばっかなので>260の手法には
違和感は感じないな。
0289264
04/08/27 01:45ID:???とりあえず、今回260さんが挙げている例では、
被参照カラムがない。
一旦commitされたデータでも主キー(もしくはその一部)を変更しても問題が無い。
一度の更新する行数が少ない。
という条件があり、一つでも欠けるとdelete/insertでは拙いと思う。
"仮"に、今後赤伝処理にて、既存の発行済み伝票を参照するようにした場合、
dalete/insertでは参照操作(CASCADE)等が出来ない。
もちろん、赤伝を発行するような時点では、もとの伝票を修正するようなことには
ならないと思う。ま、仮定の話に過ぎない。
#あと、何気に思うのだが、一度commitされて他所から参照可能になったデータが
#後から順序変更が起きたり、データが削除されて番号が詰まったりしていると、
#データの信憑性低下が起きないかな? もちろん案件やクライアントの要望で、
#絶対ダメなんてことはないのですが。
最初の論点に戻ると、「updateの代わりにdelete/insertで済ます」というのは
ある条件下で許せるテクニックかもしれませんが、「updateが面倒なので
dalete/insertで済ます」というのは、「そりゃ拙くないか!?」 と思う。
#一応仕事中、明日は朝から出張。帰宅後爆睡予定なので、
#さらにレスを求められてもしばらくは来れません。
0290260
04/08/27 07:20ID:???> delete/insertすると書き換えないとこのindexまで更新するので重いし。
OLTP ですよ？ そんな大量データが一括で書き換わる例じゃないし。
OLAPじゃないんだから、テーブル充填率100%になんて設定しません。
この程度の明細追加がパフォーマンス低下を引き起こすデータベースってなんですか？
>>289
> 被参照カラムがない。
> 一旦commitされたデータでも主キー(もしくはその一部)を変更しても問題が無い。
> 一度の更新する行数が少ない。
もちろん、そうですね。それで「場合による」と前置きしたうえで、
参照整合性違反の発生しない伝票明細の例を出したんですが…。
このスレの流れは、実務実装の話が聞けてためになりますね。
赤伝の話が出てますけど、赤伝なんてシステムとして実装しますか？
訂正伝票から旧伝票への参照を持つような実装をすることがあるんでしょうか？
わたしのところでは、基本的に請求更新までは伝票修正可能としています。
発行済み伝票であっても修正できます。(画面に発行済み伝票を破棄するよう表示される)
請求更新済みであったり、発行伝票がすでに顧客に渡っている場合は、
システム化されていない勝手に赤伝で対応します。勝手に赤伝とは、
通常の入力処理で、マイナスを入力するだけです。
赤伝ってオフコン時代の発想ですよね？ 入力伝票を訂正できないから、
マイナス打って、プラス打って、計3枚の伝票を作るという…。
システム化前の手書き伝票時代は、伝票を破って書き直すということもできたはずだから、
赤伝が基本運用に含まれているシステムは、手書き運用にすら劣っていると思っています。
0291NAME IS NULL
04/08/27 10:21ID:???DB操作ログをトリガーで残しているときに
実操作は編集なのに、ログには削除/追加で残ってしまうという欠点が存在する
しかし、プログラミングでupdate処理はめんどくさい。
伝票NOでdeleteして、伝票全行削除したあとにグリッド上の伝票をInsertするほうが楽だなぁ
0292NAME IS NULL
04/08/27 11:33ID:???>赤伝ってオフコン時代の発想ですよね？
会計を勉強してこい。
0293NAME IS NULL
04/08/27 12:26ID:???ちゃんと文脈読んだほうがいいぞ
0294NAME IS NULL
04/08/27 12:28ID:???（シーケンスNo、連番でなくてもいい）と、
ユーザに見せる行番号カラムをつくって
update、insertの条件をPKで行い、
確定(290でいう伝票発行時）前は
画面上ではAPで動的に連番を作成して見せて
確定時に行番号を連番でDBに記録
ようにするだけでいいじゃん。
確定後の変更（顧客に渡る前に
入力ミス等が発覚した場合）
も管理番号をキーに
変更後の明細行連番データを
updateして振り直すだけ。
0295294
04/08/27 12:50ID:???s/update、insertの条件をPKで行い
/update、deleteの条件をPKで行い
ちなみにモデルとしては
伝票ヘッダーテーブル
伝票番号 PK
伝票明細テーブル
明細管理番号 PK（シーケンスNo）
伝票番号 FK-伝票ヘッダー.伝票番号
明細行番号
伝票番号,明細番号でユニーク制約（インデックス）
0296294
04/08/27 12:52ID:???伝票番号,明細番号でユニーク制約（インデックス）
は、付けたらダメだったね。
0297NAME IS NULL
04/08/27 12:53ID:???おいおい、それは自然キーの代わりに人工キーを用意しただけだろ。
それじゃあ、updateの複雑さほとんど軽減されないぞ？
0299NAME IS NULL
04/08/27 21:16ID:???問題全然分かってないだろ？
0300260
04/08/27 22:44ID:???煩雑さは解消されないんですよ。それどころか、その方法だと
一意制約が失われてしまうという大きなデメリットがあります。
それに、>>294 で言っているのは「updateでもできる」ということで
あって、「delete/insertの問題点」については言及してないですね。
スキーマを崩してまで update にこだわる理由はなんなんでしょうか？
0301NAME IS NULL
04/08/28 00:48ID:???updateにこだわるというわけでなく、
あくまでも連番っていう仕様なら、>>286の様に
確定まで（さらに確定後も）ころころ変わるデータを
キーに持つより、例え人工キーでも確定されたデータ
をキーに作った方がレコードが扱いやすいと思ったまで。
伝票番号+連番がユニークでなくなるのと
トレードオフになるけど、確定までは仮の行番号の
意味合いであるし、極論、確定までは行番号は
無くてもいいわけだから、PK（ユニーク）にできない
という考え方もありじゃない？
ちなみに確定処理っていうのは、
伝票にこれ以上入力することがなく、
入力完了の処理であり、更新処理とは違う
（解っているとは思うけど）。
結果データだけみればdelete/insertもupdateも
同じだけど、既存データを書き換える
のであればupdateの方がdelete/insertより
余計な処理=オーバヘッドがないと思う。
まあ、そんなもんだけど。
あと、プログラマが考える範囲ではないが、
deleteされたデータ領域は、
最適化されるまで使用できない。
その為、常に編集時にdelete/insertを行う様な
仕様では、倍以上のデータ領域のコストがかかる。
言いたいことはこれだけ。これからは
後のカキコを参考にするよ。
0302NAME IS NULL
04/08/28 01:12ID:???明細テーブルにおいて、
さらに子のテーブルがある場合
（分納可能な発送データテーブル等）
は、行番をキーにしてしまうと、
注文挿入による行番変更時
は大変だよね。
入力忘れでどうしても同じ伝票にしたい
ということもあるはず。
そういう場合に、常に不変な明細管理番号が
キーであれば、明細テーブルの行番を
直すだけで済む。
0303NAME IS NULL
04/08/28 01:21ID:???Postgresしか知らないの？実装はいろいろあるよ。
0304NAME IS NULL
04/08/28 01:55ID:???主旨から外れた所の突っ込みですみませんが一応。、
postgresの場合、UPDATEでも
領域は圧迫しますんです。
内部ではUPDATE前のデータを無効にして
UPDATE後のを新規データとして突っ込んでるんで。
無効データを掃除するのにVACUUMを使う。
豆知識。
0305NAME IS NULL
04/08/28 01:57ID:???テーブル（スペース）の最適化が必要なのは
Oracle(Alter Tablespace)だろうが
MSSQL、Sybase(DBCC)だろうが
同じじゃないの？
0306NAME IS NULL
04/08/28 02:02ID:???諸々DBの特性の事をちょっとでも考えて頂けると
大変有りがたい。
もう本番稼動後のレスポンス対策係はいやなんじゃー。
0307NAME IS NULL
04/08/28 02:07ID:???304=306です。
俺はPostgresとOracleしかやっとりませんが、
共にDeleteじゃ表領域は解放されません。
ただ、領域の確保はテーブル単位で行うから、
他のテーブルのデータに使用出来ないってだけで
Delete対象のテーブルへの新規データ追加だったら
領域を使いまわしてくれるんじゃなかったかな。
違ったらごめんなさいな。
0308NAME IS NULL
04/08/28 02:30ID:???oracle、MSSQL、sybase、DB2
で使い回しは、最適化以外
使われないはずだけど．．．
>他のテーブルのデータに使用出来ないってだけで
>Delete対象のテーブルへの新規データ追加だったら
>領域を使いまわしてくれるんじゃなかったかな。
それは初めて聞いたよ。ソースどこ？
あと、oracleの場合、truncate ～reuse;で
出来るはずだけど、delete文では解放されない。
postgresは知らないけど、updateについては
上記のDBMSはその領域に上書きされるはず。
まあ、誰がいっしょでもいいけど
301=305だよ。
>>303の実装方法って具体的に何なのか？
0309307
04/08/28 03:12ID:???すんません、表現が不適切でした。
表領域内で、エクステントを確保したり解放したり、が正しいですね。
エクステントはテーブル毎に持ってる訳で、
A表で大量にデータをDeleteしても
A表用に確保済みのエクステント内で空き領域が増えるだけで
B表がそのエクステントの空きを使うことは出来ない。
てな事が、DBマガジンの別冊の
『Oracleデータベース管理演習ガイド』に
コラムとして載ってました。
だから裏返せば、A表なら使える、と読んだんですが。
当然のごとくそう思ったんですが認識違ったかしらん。
うーん。
何せ買ったの3年も前なんで今あせって読み返して
当該箇所やっと見つけましたよ。
で、UPDATEの件はPostgresの特長で、
最初に聞いたときはもうべっくらこきました。
まめにVACUUMせんとすぐパンクするらしいです。
商用のPowergresでは、常時監視して自動で掃除するそうですが。
0310307
04/08/28 03:23ID:???REUSE を付けると読んで字のごとくエクステントをre-useするために
解放しないでとっておくはず。
0311NAME IS NULL
04/08/28 04:10ID:???> だから裏返せば、A表なら使える、と読んだんですが。
> 当然のごとくそう思ったんですが認識違ったかしらん。
正しいと思うよ。
Oracleの場合、
INSERT には フリーリストに登録されているデータベースブロックが使用される。
データブロックの空きが PCTFREE を切るとフリーリストから除かれ、
又、更新や削除で使用量が PCTUSED を切ると再び FREELIST に登録され
INSERT 出来るようになる。
0312264
04/08/28 06:46ID:???書き方が悪かったかもしれないが論点がずれてる。
赤伝を持ち出したのは、delete/insertを行うテーブルが
未来永劫被参照テーブルになる仕様変更を受け付けないことを
言いたかっただけなのに。
>>300
>それに、>>294 で言っているのは「updateでもできる」ということで
>あって、「delete/insertの問題点」については言及してないですね。
私は>>289で問題点を挙げているのに、赤伝システムに対する追求。
要点をまとめなかった落ち度はあるかもしれないが、なんか逃げてませんか?
もう、おなかいっぱいです。
0313264
04/08/28 06:58ID:???MVCCとシリアライザブルなトランザクション分離レベル実現の為じゃないかな。
このあたりは同機能を実現するほかのRDBMSでも同じだと思うのだけど。
ただ、PostgreSQLではVACUUMを実行しないと領域が再利用されないけど、
RDBMSによっては、自動で開放されるかどうかの違いかな。
0314260
04/08/28 10:41ID:???> 私は>>289で問題点を挙げているのに、赤伝システムに対する追求。
>>289 で、あげてくれているのは「問題点」ではなく、
delete/insert が使用できる「条件」にすぎないですね。
delete/insert が使用可能な条件下において、delete/insert を使うことに
ついては、「拙い」と言っているだけなので問題点を指摘しているとは言えないと思います。
それと、「楽するために使用するのは拙い」とおっしゃってますが、楽をしようとするのは
むしろ良いことではないですか？ 楽できる場面で、update にこだわって煩雑な
アプリケーション処理をするのは良くないと思います。バグを作りこんでしまう
可能性も高くなるでしょうし。私からすると、実装効率を無視してデータベース論だけで
update に執着するほうが「拙い」と思います。
それと、赤伝については、独立したトピックとして興味を持っただけです。
通常の仕組みを利用してただマイナスを入力するだけじゃダメなのかな？って。
元伝へのチェーンを持たせる意図は？って。元伝へのチェーンを持たせる実装を
したことがないものですから。
0315U ◆CZtFsGiu0c
04/08/28 15:26ID:???＃Postgresは使ったことないですが、使うときは気をつけよう
最適化が必要なのは、たとえ再利用されてもページ内に再利用しきれない領域がボコボコ
できたり、ページの配置がバラバラになったりしてディスクのアクセス効率が悪くなるのを
解消するためですね。
0316NAME IS NULL
04/08/28 17:41ID:???>削除や更新で空いた領域を再利用しない
>RDBMSが存在するなんて知りませんでした。
だから、更新はともかく、削除についてはどんな
DBMS（メインフレームであろうが）
においても、データ連続性維持の為、それが
普通の動きなんだよ。
oracleの場合も基本的にはそういう動きをしていて、
領域の使用率がPCTUSEDの設定値以下になったら
delete領域を使用するということ。
ただし、そのような状態なったら最適化させた方が良い。
0317NAME IS NULL
04/08/28 18:39ID:???その辺りについてはoracleよりは優位性がありそうだ。
ttp://www.microsoft.com/japan/sql/evaluation/compare/prk/vsOracle4_2.asp
0318U ◆CZtFsGiu0c
04/08/29 11:57ID:???なるほどね。Oracleは体系的に学習したことがないのでためになります。
でも>>260で例に挙げられているようなシステムであれば、削除領域の再利用が頻繁に
行われていることが予想されますね。もっともRDBMSが何を使っているか、ということは
特に限定されてないけど。
>>317
まあ、それはMicrosoftの文書なので割り引いて考えたほうがいいでしょう。SQLServerは
パラメータの調整などなんでも自動で実行する方向だけど、それもメリットとデメリットが
あるわけだから。
0319NAME IS NULL
04/08/29 17:13ID:???自動と言えば聞こえはいいが、別の見方をすれば「設定不能」だったりｗ
管理者不在の小さめのシステムなら願ったり叶ったりなんだけどね。
0320NAME IS NULL
04/09/08 23:52ID:OdGTWVcOhttp://groupws.huu.jp/
そしたら、入れたはずのデータが消える。
おかしいな？と思ってデータベースみたら、
Accrssのテーブルで作られてて、全てのフィールドが「テキスト」 （ ﾟдﾟ）ﾎﾟｶｰﾝ
その上、画面上でID番号に振られてる項目が、ユーザー側で勝手にいじれちゃう。
その上主キーも無い。
これじゃデータが消える（画面上に出ない）はずだわ。
作者に指摘しても、返事も無し。
こんなんでお金とってていいのでしょうか？
（私はもちろん払ってないが）
0321NAME IS NULL
04/09/12 19:30:00ID:yiGiGN7Pあんたが被害にあってるわけじゃないし別ににいんじゃないの
と見も蓋も無いことを言ってみる
0322NAME IS NULL
04/09/24 00:43:47ID:/b7cPd/w> それと、赤伝については、独立したトピックとして興味を持っただけです。
> 通常の仕組みを利用してただマイナスを入力するだけじゃダメなのかな？って。
> 元伝へのチェーンを持たせる意図は？って。元伝へのチェーンを持たせる実装を
> したことがないものですから。
電子帳簿保存法に対応するためには、一つの伝票がどのような変遷をたどったかというのを把握出来ないとならんのですよ。
そこまで必要なくても、「どのように訂正をしたのかをきちんと履歴管理をしたい」という要求もあるのだよ。
#でないと悪さをする人がいるという理由でね。
>>290
たまたま君が見たオフコンのシステムがそうなっていたと言うだけですね。
むかーしのDOSベースのシステムで手入力で赤黒を起こしていたのもあるし、自動でやってくれていた物もある。
オフコンでも手入力で赤黒起こしていた物もあるし、自動でやってくれていた物もある。
webインターフェイスのシステムで手入力で以下略
つまり、そのシステムの実装要求によって違ってくるんだよ。
0323NAME IS NULL
04/09/24 13:40:39ID:???> 変遷をたどったかというのを把握出来ないとならんのですよ。
あなた、知ったか君ですか？ 赤伝を起こすということは元伝は生きているということですよ。
赤伝は元伝の訂正でも削除でもありません。黒伝,赤伝,黒伝 の 3伝票がすべて生きていて、
結果として数字が合うようになっています。3枚の伝票はいずれも訂正・削除はされていないので
電子帳簿保存法の「訂正削除の履歴の確保」要件はなんら関係ありません。
また、納品書が顧客に渡っていなければ破りすてて伝票修正をすればいい、という話が出ていましたが、
これも電子帳簿保存法では(ほとんど)問題になりません。電子帳簿保存法では特例として
1週間以内の訂正・削除は履歴を残さなくても良い、としています。
0324NAME IS NULL
04/09/24 14:51:43ID:WB0oCa9D>あなた、知ったか君ですか？
はい、そうです。
って返せば満足？
間違ってるなら「間違ってますよ」と言ってくれればいいのに、なんでこう噛みつくのか。
とりあえず、教えてくれた事にはさんきゅう。
でももちょっと実装例にも注意しようね。
訂正削除を「赤黒処理」で実装するシステムもあるのだよ。
ていうか目の前にあるパッケージがそうなっているのだが。
0325NAME IS NULL
04/09/24 14:55:20ID:WB0oCa9D324でつ
ごめん、もう一つ。
>特例として 1週間以内の訂正・削除は履歴を残さなくても良い、としています。
これ、どこかにソースある？
いま、電子帳簿保存法関係でもめてるので、出来れば情報がほしい。
0326NAME IS NULL
04/09/24 15:29:33ID:???ただ、「元伝票」「赤伝票」「黒伝票」といった言葉をタイトに考えると
>323が正しい。訂正でも削除でもない。
ちゃんと仕訳日記帳にも補助元帳にも載ります。
だから「赤黒処理」ってのを「履歴を残す処理」ってのに使うのは
私はあまり好きではありません。
せいぜいユーザーに「赤黒みたいにうんぬん」って説明するくらい。
にしてもいきなり知ったか君はきっついなあ。
0327NAME IS NULL
04/09/24 15:33:15ID:???0328NAME IS NULL
04/09/24 16:46:59ID:???0329NAME IS NULL
04/09/24 17:14:23ID:WB0oCa9Dフォローサンクス。
たしかに「赤黒処理」と「(例えば)伝票の打ちミスを直すための修正」ってのは本来別の扱いであり、処理を分けるのがベストなのは確かです。
なんですけど、
＞せいぜいユーザーに「赤黒みたいにうんぬん」って説明するくらい。
ユーザーに「赤黒処理」と「修正」の時のオペレーションを分けるて覚えてもらう。というのがなかなかねぇ。
かえってトラブルになっちゃったこともあってさ。
「必ず赤いれてから黒入れます！」と宣言して、その通りやってるユーザは今までで一件かな。
そこは「だから修正モードはずしてください！」という気合いの入れようだったがｗ
>>327
合点承知
0330NAME IS NULL
04/09/24 17:53:11ID:???アッコちゃ～ん
主キー主キー
0331NAME IS NULL
04/09/24 18:14:04ID:???> これ、どこかにソースある？
ソースっていうか。ちゃんと通達読んでるの？ もめるような事じゃないと思うけど。
とりあえず、4条の項7（訂正削除の履歴の確保の特例）を読めば？
http://www.nta.go.jp/category/tutatu/kobetu/sonota/denshi/01/02/02_04.htm
0332NAME IS NULL
04/09/24 18:49:39ID:WB0oCa9D> ソースっていうか。ちゃんと通達読んでるの？
いいえまったく
> http://www.nta.go.jp/category/tutatu/kobetu/sonota/denshi/01/02/02_04.htm
さんきゅ
0333NAME IS NULL
04/09/24 19:18:43ID:???0334NAME IS NULL
04/09/24 19:56:44ID:???なんだよ。読んでもいないのに、電子帳簿保存法に対応するためには～ とか
偉そうなこと言ってたのかよ。本当に 知ったか君だったんだなｗ
0336NAME IS NULL
04/09/24 20:19:25ID:???0337NAME IS NULL
04/09/24 20:30:13ID:WB0oCa9Dフィルターをお使いください
0338NAME IS NULL
04/09/24 21:12:18ID:???厨房はそろそろ寝ような？
0339NAME IS NULL
04/09/24 22:39:45ID:???0340NAME IS NULL
04/09/24 23:05:20ID:???0341NAME IS NULL
04/09/25 00:08:27ID:???0342NAME IS NULL
04/09/27 02:15:17ID:???0343NAME IS NULL
04/09/27 10:27:55ID:???時々微妙に良スレになるんだよな。
0344NAME IS NULL
04/09/27 20:23:50ID:???アッコちゃ～ん
主キー主キー
0345NAME IS NULL
04/10/09 19:50:20ID:XnFb+TU9検索処理は一行一行全ての列をプログラムで照合しているため高々1万件にも満たない
データの検索に20～30秒くらいかかるシステムがございますが、伺か?
0346NAME IS NULL
04/10/09 20:04:59ID:???0347NAME IS NULL
04/10/09 20:45:32ID:???インデクッスだけあればいいと思うんですけど・・・。
まずいの？（・_・）
0348NAME IS NULL
04/10/09 21:58:19ID:???0349NAME IS NULL
04/10/09 22:53:49ID:???0351348
04/10/10 00:46:39ID:???俺が悪かった。
0352NAME IS NULL
04/10/10 02:27:16ID:O62Uz7l1主キーのことを「プリマリーキー」と呼んでいたのには、萎えた。
仕様書のあらゆる個所にプリマリーキーが登場したからな。
プライマリーキーは一個も登場しなかったが。
0353３４７
04/10/10 09:31:09ID:gYcBhHE/ああ、わかった。それってBTRIEVEスレのでしょ？
0354NAME IS NULL
04/10/11 18:50:49ID:???べつにいいじゃん、それくらい。
俺が昔やってた案件では、ＳＥなのに、スプリクトとか言ってるやつ居たぞ orz
0355NAME IS NULL
04/10/11 18:56:31ID:6QJihKaz0356NAME IS NULL
04/10/11 20:42:23ID:???一瞬何がおかしいのか分からんかった。
0357NAME IS NULL
04/10/11 23:25:14ID:???指摘出来ないこの気まずさ。
あとDisableをディスイネーブルって言ったりなー、
そっちのが言いにくいいよ！
専門用語だけでなくて、
破綻をはじょうって読んだりなー。
0358NAME IS NULL
04/10/12 08:22:27ID:???続きを読みたい
0359NAME IS NULL
04/10/14 01:13:35ID:???フラグメントによるパフォーマンス低下が後々辛いんじゃないのかなぁ。
再利用しないならしないで管理の手間増えそうだし。
漏れDB2な奴ですが、間違ってたらごめんなさい。
0360NAME IS NULL
04/10/14 10:22:58ID:XDlVasOF0361NAME IS NULL
04/10/14 17:30:04ID:???0362NAME IS NULL
04/10/14 23:25:20ID:???検索に主キー使わないにしても、主キーあった方が追加、更新、削除の効率上がる気がする
DWHとはいえ主体は普通のDBと変わらんのが多いだろ
0363NAME IS NULL
04/10/16 06:05:33ID:60wvvnPIname_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は必要？不必要？
0364NAME IS NULL
04/10/16 07:29:03ID:???その他、数量を入れる項目作れ。
0365NAME IS NULL
04/10/16 08:38:24ID:Pvrk2coCいや、無記名のアンケート結果なんかをどんどん蓄積→集計して参照するようなシステムの場合は
主キーはいらない。
基本的にそういうテーブルの場合UPDATEはないし。
削除は、Oracleだとパーティショニングオプションつければいいし。
0366NAME IS NULL
04/10/16 09:58:18ID:???必要なし。
>>364
それ意味有るのか？
って言うか例の条件変えてどうする。
0367NAME IS NULL
04/10/16 10:11:43ID:???それはDB自体いらないぞ、気づけよ
0368NAME IS NULL
04/10/16 10:47:29ID:Pvrk2coC0369NAME IS NULL
04/10/16 10:48:35ID:Pvrk2coC0370NAME IS NULL
04/10/16 11:19:18ID:???0371NAME IS NULL
04/10/16 11:34:35ID:???0372NAME IS NULL
04/10/16 14:11:21ID:???アホだろ、お前。
0373NAME IS NULL
04/10/16 15:29:11ID:???アホはお前、この条件の場合必要ない。
居るんだよな、やたらと無駄を付けたがる奴。
0374NAME IS NULL
04/10/16 18:57:35ID:???ああ、同じ話してたのか。
これってまさにスタースキーマにするべきだよね。
主キーはいらないでいいよね、やっぱり。
0375NAME IS NULL
04/10/16 20:31:59ID:???計数管理を実用的にやるのなら>>364のようにするべきだし、
データ入れるだけなら、適当でいい。
でも、主キーなしで>>363そのままみたいな設計を客に出したら仕事切られるけどな。
0376NAME IS NULL
04/10/16 21:43:36ID:???色々なデータを整理して、関係をひも付けするのが、リレーショナルデータベースだろ。
それともここは、別にRDBで管理しなくてもいいようなデータをRDBに入れる時の話をしてるのか？
0377NAME IS NULL
04/10/16 22:45:19ID:XRkKpCUI0378NAME IS NULL
04/10/16 22:50:21ID:???最近のRDBMSの機能を知ってて言ってる？
0379NAME IS NULL
04/10/16 23:59:42ID:???どっちにしろ、クソなものはクソだけどな
データウエアハウスだから、キー無しで順番に入れとけばOKというわけではないだろう
引き出すときにどうしたいかも考えんきゃならんし
とりあえずは
>と言うより、>>363がどういう目的でそのデータをDB化したいのか不明。
ということだろう
0380NAME IS NULL
04/10/17 00:27:20ID:???DWH（ディー・ダブリュ・エイチ）
Data Warehouse
データウェアハウス
●用語説明
意思決定支援のためのデータベースのこと。
データウェアハウスの提唱者であるW.H.インモン氏によると、
(1)意思決定のために目的別に編成され(2)統合された
(3)時系列で(4)更新されないデータの集まりと定義されている。
日々の情報を時系列に蓄積することにより、問題点の発見や、原因の究明が可能となる。
0381NAME IS NULL
04/10/17 00:30:59ID:???分かってない・・・・
0382NAME IS NULL
04/10/17 00:39:20ID:???ＲＤＢＭＳにＤＷＨ用の個別機能なんて付けんだろ。
0383NAME IS NULL
04/10/17 00:50:11ID:???昔はキーなしだとだめだめだった
最近は工夫されてキーなしでもそこそこになった
でも古い形式のDBも現役なのでキー萌え
0384NAME IS NULL
04/10/17 01:52:20ID:???0385NAME IS NULL
04/10/17 01:53:22ID:???0386NAME IS NULL
04/10/17 02:16:16ID:???0387NAME IS NULL
04/10/17 04:25:15ID:???うんこみたいな実装やってて、キーがなくてびっくりって話でしょ
俺の予感としては>>380-381あたりが、調べたてで一番よく解ってないような気もするが
0388NAME IS NULL
04/10/17 06:07:10ID:???魔法の言葉だと思ったんだろうな…
0389NAME IS NULL
04/10/17 08:20:20ID:???いう話だったと思うが・・・。
そしたらレベルが低いだの煽る奴が出てきて
こうなったと。
0390NAME IS NULL
04/10/17 08:30:31ID:???0391NAME IS NULL
04/10/17 14:13:24ID:???明らかに、誰が何を持っているか管理する向けに考えてるだろ。
0392NAME IS NULL
04/10/17 14:15:55ID:???それ以外は別に３６３に対してのレスじゃ
ないと思うけど、違うかな？
0393NAME IS NULL
04/10/17 15:31:50ID:???>>364を支持するか支持しないかで話が始まってた。
しかし、勘違いしたバカが、DWHならキー不要とか言い出したんだと思う。
0394NAME IS NULL
04/10/17 15:36:25ID:???しかも>>363とDWHの話は、別にシンクロしてなかったのに
0395NAME IS NULL
04/10/17 16:00:59ID:???0396NAME IS NULL
04/10/17 16:05:17ID:???ついでに>>364は正しいのか他にもっと良い方法が有るのか。
0397NAME IS NULL
04/10/17 16:48:29ID:???お前が分かってないことだけは分かった
0398NAME IS NULL
04/10/18 01:05:36ID:???計数管理やるなら、>>364にした方がいいし、
誰かさんの言うようにDWHなら、間違い。
0399NAME IS NULL
04/10/20 10:18:53ID:???一人で同じ item を２つ以上持つのでないなら name_id と item_id の
複合キーのみでOK。一人で同じ item を複数持つことがあるのなら、
>>364の言うとおり数量の項目を追加すれ、というだけの話。
>>363は、さしづめ count(*) で item の個数を求めようとしたんだと
思われるが、入手時刻などを考慮しないならその必要はないと。
入手時刻も考慮したい場合は>>363みたいにして key を主キーに。
ついでに入手日時の項目も追加。
で、WHERE で日付を絞りつつ count(*) で個数を求めるといいはず。
0400NAME IS NULL
04/10/20 22:15:22ID:???漏れにはそう見えた。
0401NAME IS NULL
04/10/23 17:28:52ID:CZ5lSRSV理由：遅くなるから。おかげで、コードとそれに１：１でリンクする名前が
同じテーブルに入ってます。また、Viewの命名規則にはVXX000の連番を使う
という記述もあります。
0402NAME IS NULL
04/10/23 17:42:28ID:???Viewを使わないことが恐怖なの？
使いすぎるほうがよっぽど恐怖に思えますが。
0403NAME IS NULL
04/10/23 19:35:20ID:???0404NAME IS NULL
04/10/23 19:35:54ID:???っと、話ふり逃げに思われると残念なので書いとこう
0405NAME IS NULL
04/10/23 19:36:14ID:???0406NAME IS NULL
04/10/24 13:13:12ID:???0407NAME IS NULL
04/10/24 23:26:07ID:???0408NAME IS NULL
04/10/24 23:47:26ID:qYETNpDvけったいな制限だな・・・
0409NAME IS NULL
04/10/25 07:18:12ID:???0410NAME IS NULL
04/10/26 20:17:46ID:???0411NAME IS NULL
04/10/26 22:52:11ID:???0412NAME IS NULL
04/10/26 23:44:42ID:???文字列8桁の方が管理しやすい場合はあるな。
特定月の集計値を取得する時もLIKEが使えるので
レスポンスも早い、はず。メンテ楽だし。
0413NAME IS NULL
04/10/27 00:52:06ID:???DATEでもLIKE使えるだろ。
Oracleでも無ければ、DATE型とDATETIME型とあるし。
0414NAME IS NULL
04/10/27 00:52:51ID:???ﾋｿ( ´д)ﾋｿ(Д｀⊂)ｴｰｯ
0415NAME IS NULL
04/10/27 01:52:56ID:???俺も日数計算と関係ない、半分文言みたいな日付は
文字列にしてますよ。それこそ計上日とか。
まあ慣習みたいなものなんですが。
そういう項目の場合、DATE型だと
FROM～TO条件などでの挙動に不安があるんですが。
秒ではじかれたりしないかと。
やった事ないので漠然とした不安ですけど。
Oracle以外だと秒を管理しない型もあるんですか？
それなら関係ないか。
あとADO関連のメーリングリストだかで
DATE型だとデータが変になるとか見た事ありました。
0416NAME IS NULL
04/10/27 02:17:59ID:???0417NAME IS NULL
04/10/27 02:48:01ID:???でも、管理ツールで使いやすいのが一杯出てるから。
でも高いんだよなあ。
9iでだいぶやさしくなったんですけどね。
エクステントもデフォルトが一番最適だったりするようになったし。
0418NAME IS NULL
04/10/27 05:05:53ID:???0419NAME IS NULL
04/10/27 07:14:48ID:???0420NAME IS NULL
04/10/27 07:49:33ID:???実績重視なんかで、未だに8iを新規に入れるところは多いよ。
0421NAME IS NULL
04/10/27 12:04:40ID:???0422NAME IS NULL
04/10/30 08:37:40ID:???0423NAME IS NULL
04/10/30 10:15:16ID:???いまだに動作保証が8iだけっていう
0424NAME IS NULL
04/10/30 10:15:58ID:???9iのプラチナ持ってる奴も会ったことないし。
途中で送信してしまった…
0425NAME IS NULL
04/10/30 19:01:35ID:???0426NAME IS NULL
04/11/01 13:33:05ID:???あれはあれでレアか
0427NAME IS NULL
04/11/13 01:15:00ID:???2004/13/99 の様な実際には無い日付を使う場合がある
例えば、月末をYYYY/MM/７７で、会計締め日をYYYY/MM/88など
0428NAME IS NULL
04/11/13 01:22:32ID:???あるある。でもそういう場合でも文字列だよね大概。
数値ってのは聞いた事ない。
0429NAME IS NULL
04/11/13 09:03:25ID:???2004/11/末
2004/11/〆
でいいじゃん。
0430NAME IS NULL
04/11/13 18:59:53ID:???とてつもなくセンスないな
0431NAME IS NULL
04/11/14 10:25:55ID:???営業がフランチャイズ店舗開拓のデータを整理するという案件だったのだが
・新店オープン決定 オープン日も決まっている → オープン日を YYYY/MM/DD で入力
・新店オープン決定 オープン日も大体決まっている → オープン日を YYYY/MM で入力 後日メンテしてオープン日を YYYY/MM/DD にUPDATE
・新店オープン決定 オープン日は決まっていない → レコード作成する オープン日はNULL
・新店オープンするかもしれない → レコード作成する オープン日はNULL 後日メンテでDELETEするかもしれない
0432NAME IS NULL
04/11/14 15:41:28ID:???・新店オープンするかもしれない → レコード作成する オープン日はNULL 後日メンテでDELETEするかもしれない
0433NAME IS NULL
04/11/14 19:23:41ID:???確実に決まってるのなら、そのズバリのひづけと区分が１、
だいたい決まってるのなら、区分は２にして、その月の１日の日付でも入れておいた方がいいと思う。
そうすると、月単位でだいたいというひづけだけではなく、
多分12月2日だけど、11月30日とか月をまたいで前後するかもとか、そう言うデータも入れられる。
もしくは、区分じゃなくて、最高で何日前後するかの数値を入れるとか。
ズバリならゼロを入れておく。
0434NAME IS NULL
04/11/27 04:12:12ID:QWDujoZt0435a
04/11/27 09:54:39ID:SLvZscV9せて、それで決定、未定区分を作るかなあ。
どの日付を入れるかは入力者の判断にまかせるとして。
0436NAME IS NULL
04/11/27 10:36:29ID:???0437NAME IS NULL
04/11/27 12:28:41ID:nifHq9rI0438NAME IS NULL
04/11/30 11:32:18ID:7mFRMBlLたとえば
・何日に、どの店からどの商品を何個購入したか
（主キー：購入日・店ID・商品ID）
というようなテーブルに１行ずつ追加するような処理の場合、
Delete/Insertのデメリットは少ないと考えていいのか？
Upsertできれば楽で安全で確実なんだけどなあ…。
0439NAME IS NULL
04/11/30 14:35:37ID:g2H0vwRpる主キーってどうですか。あるDBMSから別のDBMSに移植するとき複合キ
ー数の制限に引っかかってしまったことがあります。
よく見たら無理やりユニークにするために無駄な枝番号がいくつもつい
てました。結合とかやりにくくてかないません。
私は枝番号はあまり好きではありませんが、皆さんは枝番号の扱いって
どうしてますか？
0440NAME IS NULL
04/11/30 15:05:03ID:???設計する中で正規化をしていくうちに
キーなんて決まっていくもんだし。
関連テーブルなんかで、キーが3つ4つあるのは
（流石に4つは見たことないかも）確かに多く感じられますが、
業務分析の結果それが正しければそうすべきだと思います。
関連テーブルなのに独自にIDを振って
主キー1つのみにするなんて人もみた事ありますが
ありゃやめてほしいなあ・・・・。
ヘッダ - 明細の親子関係で明細独自ID振るのも
かんべんして欲しい。
0441NAME IS NULL
04/11/30 15:05:50ID:???複合キーの数ってのは問題外ですよ。
0442NAME IS NULL
04/11/30 16:05:04ID:???＞ヘッダ - 明細の親子関係で明細独自ID振るのも
＞かんべんして欲しい。
じつは最近この方法のほうが自然かなぁって思っているんです。
親のキーをリファレンスにした外部キーを子が持っていて、
それに逆参照用の非NULL重複索引がついてる方が親子関係っぽ
くはないかと。もっといってしまえば子テーブルには主キーは
いらないってこのスレの主題に戻るわけですが。
普通のやり方だと、親のキーと同じ情報をキーの一部にたまたま
持ってるって感じですよね。
0443NAME IS NULL
04/11/30 16:06:30ID:???＞ありゃやめてほしいなあ・・・・
複合キーは好まれないとおもっていたよ
それは運用上融通がきかない設計だから。。。。。
理由をきかせてほすぃです
たぶん、キーが明確でなくなるから？？？
0444NAME IS NULL
04/11/30 16:47:34ID:???ひょっとしてマズかったのか？
関係テーブルに独自IDふって主キーにするのって、主キーがないのも
同然な気がするけど。一意制約逃れ以外に独自IDの意味はあるの？
0445NAME IS NULL
04/11/30 19:09:51ID:???0446NAME IS NULL
04/11/30 21:01:38ID:???複合キー列が多くなりすぎてわかりづらくなった場合に代替キーとして別のユニークな列を
用意するのはアリだとおもう。もちろん、本来の複合キー項目にも一意性制約をつけて
おくのはお約束だ。
0447NAME IS NULL
04/11/30 21:06:50ID:At4YbhlE0448NAME IS NULL
04/11/30 21:21:16ID:???EUCでそっちはSJIS、そしてこいつはEBCDIC…
0449NAME IS NULL
04/11/30 23:17:41ID:At4YbhlEいや、俺が行った所は違いましたよｗ
NULL値です。
複合キーだからいいの！！って言われたんで
とりあえずハイ分かりました。って言って仰せのままにやったけどね
0450NAME IS NULL
04/12/01 00:08:35ID:???検索性が高まりますよってことかな。㌧クス。
0451NAME IS NULL
04/12/01 01:38:05ID:???通常は、登録したデータは消さないのが一番いいだろ。
使わないなら、削除フラグでも立てるべき。
履歴にもなるから、業務でトラブったときに便利。
メンテナンスの時に、本当にいらなければ、まとめて消せばいい。
0452NAME IS NULL
04/12/01 01:39:34ID:???商品IDって別にDBの一意制約逃れのためにつけるものじゃないだろ。
普通に伝票で管理してても、違う商品に違う商品コードはつけないわけで。
0454NAME IS NULL
04/12/01 06:45:57ID:???>438 は最後に UPSERT と書いてあるから、同じデータが無ければ INSERT、同じデータがあれば
UPDATE したいと言うことと思料。だからこれを実現するには
1. データの存在を確認して INSERT と UPDATE を使い分ける。
2. データの有無にかかわらず DELETE を発行してデータが無いことを保証した後 INSERT する。
のどちらかしかないと。>438 の言う 「Delete/Insert」 は 2. の方法と。
0455NAME IS NULL
04/12/01 07:40:17ID:???主キーが存在しないか必要でないレコードに独自IDで主キーを付けるのは、
テクニカルな理由だと思うな。
プログラムからレコードを操作する場合にカーソルが使えるか、ROWIDのような
DBMSの独自機能を使えれば問題ないが、それ以外の方法では主キーがないと更新
時にレコードの特定に困る。
それから、ODBCカーソルで更新可能な結果セットを使う場合は主キーが必要だ。
クライアント側に保持した主キーのリストが更新可能な結果セットの正体だから
単純で小さな主キーの方がパフォーマンスがいい。よくは知らないがOLE-DBや
JDBCも同じ仕掛けだと思う。
0456NAME IS NULL
04/12/01 07:43:59ID:???1.の変形ですが、とりあえずUPDATEして更新件数が０件ならINSERTする
方法もありますね。
0457NAME IS NULL
04/12/01 07:57:15ID:???SQL99準拠のMERGEがぼちぼち使えるようになってるらしいけど、
やっぱりDBMSで実装の違いや方言とかあるのでしょうか？
0458NAME IS NULL
04/12/01 09:10:58ID:???どっちが一般的っすか？
2の方法はトリガが使えなくなりそうでイヤーン
0460NAME IS NULL
04/12/01 10:10:16ID:???DB側から見て、INSERTとUPDATEが同一視されてしまうシステム(アプリ)に問題は無いのか?
ケースバイケースつわれりゃそれまでなんだろうけど、新規追加か更新かをアプリ側で判断せず
そのままDBへ投げて旧データがあれば更新、無ければ追加ってなんか安易な考えのような気もしてきた。
ここら辺はどうでしょう。 > ｴﾛｲ人
あぁ、手入力じゃなくてバッチ処理で更新するときはありなんかな?
0461NAME IS NULL
04/12/01 11:12:24ID:???むしろ、アプリ側だけで追加/更新を判断するのは危険な予感。
0462NAME IS NULL
04/12/01 11:34:28ID:???明細独自のキーをつくっちゃうのは
キーがひとつっていう実装面での
便利さは確かにあるんだけど
設計が見えてこないのが気持ち悪いんです。
ヘッダ-明細の集約関連なのか、ただの関連なのか、とか。
それと、まれに実装面でも大変な事になります。
大量の受注データをファイルからインポートする場合、
明細ＩＤが「YYMMDDXXXX」(Xは連番)みたいなフォーマットの場合
採番テーブルで管理するとなると、1明細ずつSELECTが走る事になって
オーバーヘッドになったり、下手すると桁溢れの可能性も格段に高くなる。
シーケンスで数字でふっちゃえばいいじゃんって話もありますが、
保守を考えるとちょいと不安です。
ただし、>446のいう通り、あまりにも複合キーが複雑な場合は
別の独自キーを構えるのはアリだと思います。
そこらへんは柔軟に考えるのが吉ですよね。
でもめんどいからえいやっでなんでも独自キーはいや。
「エンティティ」の意味をもう一回考えて欲しいと思う。
0463NAME IS NULL
04/12/01 14:39:21ID:???紙の伝票だって、紙の領収書だって、レジのジャーナルだって、
取引毎にユニークなNoがついていて、それで管理してるわけで。
>下手すると桁溢れの可能性も格段に高くなる
それは設計が下手だからでは…
0464NAME IS NULL
04/12/01 16:52:24ID:???明細はその中の何行目くらいの意識しか業務上ないでしょう、普通。
取り敢えず、実装面での利便性はさておいて
そういった業務内容を設計に落とすんだったら、
明細テーブルのキーは、受注番号 + 連番にすべきですよね。
ここで問題になってるのは、明細単位に明細ＩＤを持って
受注番号はただの属性になってるモデルはいかんなあ、
いやそれも便利だしアリでしょ、いやでもなあ、って話。
＞それは設計が下手だからでは…
だから、そういう話の例としてあげてみたのよ。
0465NAME IS NULL
04/12/01 16:54:21ID:???制約っていらなくね？
http://pc5.2ch.net/test/read.cgi/db/1087483786/l50
出発点は主キーと制約で違うけど。
0466443
04/12/01 18:48:54ID:???＞設計が見えてこないのが気持ち悪いんです。
なーる
ところで、複合キーの一部にＮＵＬＬは許されなかったかな？
いや、移行システムの場合、移行データの主キーに平気でＮＵＬＬ
あったんで、ＩＤは必要かなって思った
0467NAME IS NULL
04/12/01 19:16:39ID:???正規化をばっちり行って制約も完璧に付けたE-R図を作ったとして、
実装するときは正規化を崩して制約の大半はアプリ側ロジックに
移動させることになる。E-R図からSQLを生成する設計ツールが
あるけど使えないことが多いのはこのため。
独自キーの使用は設計と実装の区別がきちんとついてればいいんじ
ゃないかな。
>>466
複合主キーの一部にＮＵＬＬは私の知ってる範囲ではどれもだめ
だったと思います。
0468NAME IS NULL
04/12/01 19:26:07ID:???意識的に正規化崩しが出来るって事は
けっこう設計力があるって事だと思うじょー
前にも書いたけど、グチスレのはずが
本当に良スレだなあここは。
0469NAME IS NULL
04/12/01 20:53:04ID:???0470NAME IS NULL
04/12/01 20:59:27ID:???0471454
04/12/01 21:08:36ID:???そうか、UPDATE も 0件であっても問題なく実行されるのか。
(ﾟﾛﾟ )そいつは名案気が付かなかった早速帰ってやってみよーっと!!
でも、UPDATE された件数を取得する方法ってあるの?当方 Jet と MSDE しか知らないけど。
>464
> 明細テーブルのキーは、受注番号 + 連番にすべきですよね。
受注Tbl の子Tbl という扱いになるからそうよねぇ。pkey(受注番号, 明細番号) で明細番号が
シーケンスなりでつけられると。
> ここで問題になってるのは、明細単位に明細ＩＤを持って
> 受注番号はただの属性になってるモデルはいかんなあ、
外部キー制約が DELETE( ,UPDATE) CASCADE でついてれば次善ではあるけれど…。
0472NAME IS NULL
04/12/01 22:32:40ID:???oracleだったら、SQL%ROWCOUNTってのがあるでー。
MSDEのストアドにもあると思うよ。
ADOだったら確かExecuteNonQueryの返り血（ぎゃー）が
更新処理した行数だでー。
0473472
04/12/01 22:34:07ID:???似たようなのが、って事ね。
そのまんまはないわいな。
0474NAME IS NULL
04/12/02 06:40:30ID:???UPDATE xxxx
IF @@ROWCOUNT = 0
INSERT INTO xxx
0475正規化初心者
04/12/12 23:11:18ID:???この項目を正規化して、主キーにするならどれになりますか。
現在のところ品名ＩＤなどは利用していません。
上記の項目で主キーになるものがなければ商品ＩＤ
などのカラムを追加するべきですか。
0476NAME IS NULL
04/12/12 23:38:46ID:???業務を反映しない形でパカパカテーブル定義作られちゃかなわん。
0477NAME IS NULL
04/12/12 23:39:11ID:???0478NAME IS NULL
04/12/13 08:18:23ID:???間違いなく数量がキーだな。
教えてやったんだから、そのとおり設計しろよ。
0479NAME IS NULL
04/12/13 11:12:42ID:???0480NAME IS NULL
04/12/13 11:55:51ID:???この場合は品名・型番・製造メーカー、数量の先頭1文字を結合して主キーとするのがベストさ！
0481NAME IS NULL
04/12/13 12:05:31ID:???0482NAME IS NULL
04/12/13 12:33:35ID:???0483NAME IS NULL
04/12/13 20:55:42ID:???0484NAME IS NULL
04/12/18 11:39:11ID:???１項目のみで char(512)で定義されてるだけで
ビューで項目を分けてた。全テーブル・・・
目から鱗が落ちた。
0485NAME IS NULL
04/12/18 11:54:26ID:???0486NAME IS NULL
04/12/18 18:45:27ID:???0487NAME IS NULL
04/12/29 17:44:18ID:???主キーが無いんですけどこれくらいじゃ甘いですか？
もちろんUPDATE作業もあって120万件中一件だけ
UPDATEする作業を全件分(120万回)行わないといけない。
しかもしっかりINDEXがついてます。
普通に半年以上かかると思う・・・
oracle9iをoo4oで操作してますがどうやったらテーブル変更しないで
二日以内に全件終了できますか？
聞くまでもなさそうだけどorz
0488NAME IS NULL
04/12/29 20:07:37ID:???UPDATEするときだけINDEXを削除して、UPDATE完了したらINDEX張りなおし。
塚主キー関係ない希ガス
0489NAME IS NULL
05/01/26 23:47:07ID:???Excelファイルを繋げといわれた・・・
データが重複してるのは、重複してる数だけ必要だからで、
主キーはつけずに上のデータから消しこみしたいとか。
Excel的にはありなのかもしれんが、レコードの「上から順に」って
斬新な発想だなと。嫌がられても無理矢理に主キー設定したが。
0490NAME IS NULL
05/01/27 09:41:28ID:???そんな斬新でもないだろ。
昔のシステムいじった事ない人なのかな？
0491NAME IS NULL
05/01/28 04:41:31ID:???「斬新」てのは皮肉でそ。
0492NAME IS NULL
2005/03/28(月) 16:25:37ID:FaNfWzuJ0493NAME IS NULL
2005/03/29(火) 21:31:41ID:rB3ZIFyp「～を～してWEB上で管理するシステムを作成せよ
新規登録・検索・一覧表示・更新・削除の各機能が必要
ただし各データに固有番号を付与する事は禁止とする」
みたいな問題をやたらと出されてた
DBに詳しい奴も 主キーさえ使えたら…と頭を抱えてた
0494NAME IS NULL
2005/03/29(火) 23:34:59ID:???すごい複合キーになったらいやだね。
0495NAME IS NULL
2005/03/30(水) 01:54:56ID:???実務でも、ユニークにするだけのために関係ないキー使ったら（パフォーマンスの都合とかは別）、
ダサイ実装なんて言われるぞ。
0496NAME IS NULL
2005/03/30(水) 22:55:36ID:???0497NAME IS NULL
2005/03/30(水) 23:50:40ID:???0498NAME IS NULL
2005/03/31(木) 03:00:16ID:???意味としての主キーと識別子としての主キーを同列に考えるやつ
複合主キーつかいまくった挙句、仕変でデスマってたバカがいたなあ…
0499NAME IS NULL
皇紀2665/04/01(金) 01:27:32ID:???解らなくなって、デスマる確率が高いな。
intで入れた順番にシーケンスなんてやってたら、後からデータだけ見ても意味解らなくなる。
一応金融系や産業系で長いことやってるが、Oracleプラチナみたいな奴が
設計してるような大きなシステムで、識別のためだけにキーを設定してデータ
突っ込んでるシステムは見たことがない。
読み出すソフトが無くても、データだけ見て業務の流れが解るように作るのがプロだろ。
小規模のとりあえず動けばみたいなシステムでは、腐るほど見たことはあるけど。
0500NAME IS NULL
皇紀2665/04/01(金) 02:18:09ID:???自然キーが主キーとして用を成さないくらいの複合キーになってしまうのは、コード化が
必要なデータがコード付けがなされてないために起きることが多い。本来従属した属性
であるはずの登録日や入力場所などが主キーに含まれてしまっているケースなどがそれ。
これだと主キーに仕様変更が発生しやすい。
本来ならば適切なコード付けを行ってそれが自然キーになるような設計にするのが
ベストだが、>>493の講習のように適切にコード付けされていないレコードを押し付けられる
ことがほとんど。次善の策で代理キーを使うことになる。
データベースの設計者にコンピュータだけではなく業務全体に対してよほどの能力と権限
がなければ適切なコード化は難しい。理論だけの人か恵まれた現場にいる人でなければ代理
キーやむなしという考え方をしてもおかしくないと思うよ。
0501NAME IS NULL
皇紀2665/04/01(金) 07:56:29ID:???0502NAME IS NULL
皇紀2665/04/01(金) 09:32:45ID:???データベースシステムの都合とビジネスの都合でうまく調整がつけばいいのだが、
力関係は技術屋＜＜＜＜実務屋だからしゃーないよ。
0503NAME IS NULL
皇紀2665/04/01(金) 10:11:16ID:???「業務の流れ」てのは変わるものだから
0504NAME IS NULL
皇紀2665/04/01(金) 11:54:49ID:???シーケンスとか使ったっていい。
かつ、業務上意味のあるコードを、ユニーク制約やNOT NULL制約などを
要件に従ってつけておく。
これなら業務要件もDB設計から把握しやすいし
突如コードの洗替なんてとんでもな依頼が来ても対処はらくちん。
両方いいとこどりでいいじゃん。
原理主義的宗教論争に陥る前に、現実解を優先するべき。
ただ、見出し-明細とかの親子関連の場合、子に独自IDつけると
参照関連にしか見えなくて、そこが悩ましい。
な訳で、俺は注文-顧客みたいな参照関連の場合は上記の方法、
注文見出し-明細みたいな親子の場合は、
子は親ID+連番の複合キーにしてます。
0505NAME IS NULL
皇紀2665/04/01(金) 17:30:37ID:???金融だとコード系が業界標準で決まってたりするから499のような考え方でいいのかもしれないね。
Oracleプラチナみたいな痛い例を引き合いに出さず立場や環境の違い認め合おうではないか。
0506NAME IS NULL
皇紀2665/04/01(金) 21:19:23ID:soTwNKQ0「能書きは良いから動かしてくれ！」
0507NAME IS NULL
皇紀2665/04/01(金) 22:44:03ID:???データモデリングとはあまり関係なかったような。
最近のはよく知らんのでなんとも言えないが。
0508NAME IS NULL
皇紀2665/04/02(土) 00:41:33ID:???立場や環境と言うよりも、技術力の差のような気がするが…
プラチナな奴が作れば、小規模システムだって素晴らしくできるわけで
0509NAME IS NULL
2005/04/02(土) 15:06:05ID:a2Szs17Qうちの案件でプラチナな奴を使ったら人件費だけで予算オーバー
0510NAME IS NULL
2005/04/02(土) 16:36:24ID:DclvoDbo0511NAME IS NULL
2005/04/02(土) 23:47:58ID:???0512NAME IS NULL
2005/04/03(日) 06:52:39ID:???0513NAME IS NULL
2005/04/03(日) 11:55:21ID:???0514NAME IS NULL
2005/04/03(日) 16:56:58ID:???単に私が知らなかったのか、それともVersion6くらいから入ったのか。
という意味。
0515NAME IS NULL
2005/04/03(日) 18:48:43ID:???unique + not null でやってた記憶が。
0516NAME IS NULL
2005/04/03(日) 18:51:29ID:???0517NAME IS NULL
2005/04/03(日) 19:34:59ID:???実装されないとほとんど意味のないもの。
純粋に使い勝手の問題。
0518NAME IS NULL
2005/04/03(日) 19:55:51ID:???例えば口座番号とかで主キーを昔から作ってるって事でしょ
0519NAME IS NULL
2005/04/03(日) 22:14:39ID:???移植が多かったからどうしても複合キーになりがちだった。
さらに上の世代の人たちから、初期の汎用機のDB2でメーカーのSEから索引は
使ったらいけないといわれたと証言を得ているが同時は何か事情があったの
だろうか。
0520NAME IS NULL
2005/04/04(月) 09:32:53ID:???索引はない方がよかった。insert したが、索引は更新されず、
Tableには存在するが、ある条件だと照会できない、ということが
現実にORACLEでは起きていた。ワークスペースの設定の問題とか
エラー時のエラーコードが正しく返ってきていたかとか、Btreeの
管理にバグがあったりとか原因は色々考えられるが、それこそ20年近く
前だとこういうことは度々起こったから、索引はできるだけつけない
ようにというのはマニュアルの類にさえ書かれていた。
0521NAME IS NULL
2005/04/04(月) 09:49:25ID:???この業界、去年はベストだった解が今年にゃタブーになってるなんてよくある話ですから。
で、過去のベストを脳みそに刻んでいる上の人間がそれを頑なに守っているという。
現物さわってる現場の下っ端の発言なんか聞きもしないし権限も無い、と。
0522NAME IS NULL
2005/04/04(月) 10:19:39ID:???設定を変えるチャンスがない。だから、自由度という点からすれば、
主キー設定なんてない方がいいんだろうけど、パフォーマンスもあるし・・。
0523NAME IS NULL
2005/04/04(月) 14:27:22ID:???ANSI-SQLのデータ定義言語(DDL)にCREATE INDEX命令は含まれてなくて
各メーカーの独自実装扱いだった。いまのANSI規格でもそうなのだろうか。
0524NAME IS NULL
2005/04/04(月) 19:46:08ID:???パフォーマンスより、データが二重になってしまう方が怖い
無理矢理キーでも、同じデータが入ってしまう可能性もあるし
なにかユニークな自然キーが欲しいよ、やっぱり
業務上で、口座番号とか伝票番号とかあれば、確かに楽なんだけどね…
0525NAME IS NULL
2005/04/05(火) 09:45:58ID:???0526NAME IS NULL
2005/04/06(水) 12:34:13ID:???するには、テーブルをロックする以外に方法はないのですか。
もちろんマルチユーザのデータベースですが。
0527NAME IS NULL
2005/04/06(水) 12:38:23ID:bsFmYDLm検査だけだったら、検索してヒットすれば制約違反で良いのでは？
この結果を踏まえて追加や更新を行う場合は、もうちょっと複雑な処理がいるだろうがな。
0528NAME IS NULL
2005/04/06(水) 13:02:01ID:???0529NAME IS NULL
2005/04/06(水) 13:19:15ID:???0530NAME IS NULL
2005/04/06(水) 19:43:48ID:E+G6fNQP作れるよ。
0531NAME IS NULL
2005/04/07(木) 16:33:36ID:???主キーはひとつだけだが候補キーはいくつも作れる。
どちらも非NULLでUNIQUEだから実質いくつも作れるという認識でもいいと思う。
このスレで話題になっている代理キーは主キーのほかに候補キーを持つという話で、
キーがないレコードに適当な主キーをつけるという話ではない。
0532NAME IS NULL
2005/04/10(日) 01:18:54ID:???RDBも捨てたものではないな。
0533NAME IS NULL
2005/04/15(金) 21:07:09ID:???実用上の理由からCODASYLから借りてきたもの。
0534NAME IS NULL
2005/04/22(金) 15:14:42ID:Ep3EiPSoデータベースは関係の集まりであるとするRDBにおいては、
一意識別はより切実であって、借り物云々は当たらないと思う。
0535NAME IS NULL
2005/04/22(金) 15:48:42ID:???そんなこともしらないの
0536NAME IS NULL
2005/04/22(金) 21:14:39ID:???0537NAME IS NULL
2005/04/26(火) 02:31:40ID:9zw9nuFPprimary key
alternate key
surrogate key
0538NAME IS NULL
2005/04/26(火) 20:03:58ID:???0539NAME IS NULL
2005/04/29(金) 23:58:25ID:???履歴を取る必要があって、条件を考えていたら主キーにするために項目が多くなってしまうし
シーケンスも考えたんですけどね
0540NAME IS NULL
2005/05/02(月) 13:13:08ID:???そんなこと考えてられない。
0541NAME IS NULL
2005/05/02(月) 13:48:23ID:???0542NAME IS NULL
2005/05/02(月) 14:00:04ID:???結構ある。こういう場合、主キーも何もないね。
0543NAME IS NULL
2005/05/02(月) 22:48:18ID:???>結構ある。
すげぇな
0544NAME IS NULL
2005/05/03(火) 00:33:41ID:???一時表じゃダメなのか・・・？
0545NAME IS NULL
2005/05/03(火) 06:44:00ID:???と思ったらそのMDBから鯖にリンクテーブル張られててワケワカメ
0546NAME IS NULL
2005/05/03(火) 06:51:26ID:???「データこそすべて」的身上でプログラミングしていると、どんどんtableを
作らなくてはならなくなる。たとえば、勤務表でAさんとBさんは不仲で同一
時間帯の勤務は不可と言う場合、不仲テーブルをつくり
A,Bの一レコードだけ書いておくことになる。前向き推論のようなロジックでは
データベースの煙詰めみたいなこともやる。プログラムロジックの大半を
データベースが担うとなるとほとんどのテーブルは極めて小さなもので
そんな場合、一々、主キーのことなんか考えないでしょ、というのが真意です。
0547NAME IS NULL
2005/05/03(火) 16:44:54ID:???0548NAME IS NULL
2005/05/03(火) 21:47:13ID:???女が多い職場の管理職は大変だよってことさ
0549NAME IS NULL
2005/05/04(水) 00:26:35ID:???SELECT COUNT(*) FROM 不仲 GROUP BY 不仲名;
A,B | 500
A,C | 145
B,C | 1.67E16
0550NAME IS NULL
2005/05/04(水) 04:26:33ID:???0551NAME IS NULL
2005/05/05(木) 02:04:59ID:???0552NAME IS NULL
2005/05/05(木) 03:53:22ID:???0553NAME IS NULL
2005/05/08(日) 14:02:00ID:???名前,不仲な人
山田,田中
山田,佐藤
佐藤,鈴木
鈴木,田中
田中,山田
ってやって、シフト更新するときになめればいいだろ。
0554NAME IS NULL
2005/05/10(火) 19:01:56ID:???外部キーは心底テーブルのメンテナンスをしようとすると邪魔になる。
0555NAME IS NULL
2005/05/10(火) 23:59:05ID:???0556NAME IS NULL
2005/05/11(水) 01:25:20ID:???詳しく。
0557NAME IS NULL
2005/05/11(水) 01:31:47ID:???リファレンス先のキーが複数のテーブルで使われてる場合は、
設計上外部キーであっても実装では制約にはしないことが多い。
リファレンス先に索引が必要なのは当然として、外部キー側にも索引が
必要なケースがほとんどであるがデフォルトでは索引は生成されない。
逆方向の索引なしでリファレンス先のキーを変更や削除した場合、
外部キー側にテーブルスキャンが発生することに注意しよう。
ただこういうレベルで外部キーを嫌がられても困るのだが。
「外部キー付けるとデータを入れにくくない？」
0558NAME IS NULL
2005/05/11(水) 02:03:54ID:???0559NAME IS NULL
2005/05/11(水) 07:45:15ID:+lelbHvj0560NAME IS NULL
2005/05/11(水) 09:46:37ID:???0561NAME IS NULL
2005/05/12(木) 09:10:56ID:???0562NAME IS NULL
2005/05/12(木) 09:27:22ID:???0563NAME IS NULL
2005/05/12(木) 10:27:25ID:???U
0564NAME IS NULL
2005/05/12(木) 12:48:28ID:???0565NAME IS NULL
2005/05/13(金) 12:46:49ID:???多分今だと改善されてるのも多いだろうと言う前提で、かつて設計担当した漏れの考え。
DBMSが勝手に名前付けちゃうと、使用するインデックスを明示して検索するのが面倒。
条件が限定されるが、参照する際の「該当無し」レコード用等でNULLを用いる事が出来ない。
インデックスを比較的頻繁に変更する事が想定される場合、主キーのみ手続きが別になる。
以上より、確かにフル活用する計画だと主キーは張らないかもしれない。
0566NAME IS NULL
2005/05/13(金) 13:06:27ID:???付けちゃわないと思うけど
0567NAME IS NULL
2005/05/13(金) 17:05:25ID:???0568NAME IS NULL
2005/05/13(金) 18:13:59ID:???Oracleの場合はﾃｰﾌﾞﾙ作成時にPK制約を付けると自動で名前が付くわな。
0569NAME IS NULL
2005/05/13(金) 18:39:25ID:???使ってる処理系では制約名がそのまま索引名になってました。
CONSTRAINT name PRIMARY KEY (col1, col2)
後からの追加はこんな感じでできる。
ALTER TABLE ADD CONSTRAINT name PRIMARY KEY (col1, col2)
0570NAME IS NULL
2005/05/13(金) 19:01:17ID:???索引を明示的に指定するのはAccessをISAM風に使うとき以外に
使ったことはないのですが、ヒントとかで指定するのでしょうか？
0571NAME IS NULL
2005/05/13(金) 22:57:42ID:???Oracleでも自動で振られた名前を変更できるんでしょ?
だったら主キーが邪魔になる事など殆ど無いと思うのだが。
0572NAME IS NULL
2005/05/14(土) 21:31:51ID:???俺が最後に見たときで983いってたから時間の問題だったと思われ
誰か次スレ立てよろ
0573NAME IS NULL
2005/05/15(日) 03:57:48ID:???立てました。よろしくお願いします。
頼むから正規化しろよ 第二正規形
http://pc8.2ch.net/test/read.cgi/db/1116097001/
0574NAME IS NULL
2005/05/15(日) 22:33:00ID:p5AU4cZrユーザデータを管理するテーブルを
CREATE TableUser
(
ID int,
Value Text
);
みたいに定義して
あるユーザ番号のユーザのデータを取り出すには
IDが10から20のデータを取り出すみたいなことやってた奴がいた。
一部上場の某企業。
0575NAME IS NULL
2005/05/15(日) 23:17:24ID:???情報が足りないから、その上司がおかしいのかそうじゃないのか判断がつかんな。
人のこと言うのはそういうところキチッと説明できるようになってからにするがよろし。
0576NAME IS NULL
2005/05/15(日) 23:42:32ID:???一人のユーザーの情報を取得するのにID10～20とか取るって
奴なんじゃないの？
森羅万象テーブルって奴ですか。
古い人はいまだに結構やるみたいですね。
0577NAME IS NULL
2005/05/16(月) 00:26:16ID:???それだったらまだマシ(w
名前
住所
電話
の項目をそれぞれ1レコードに格納して、
上のようにカラムが3つだと、ユーザ1の
データはID1からID3を取得するってやってた。
0578NAME IS NULL
2005/05/16(月) 00:50:33ID:???>>577
同じことを言っているような気がするが‥
問題は、ユーザー番号、データ種類のそれぞれとTableUser
レコードとの関係をどう表現しているかだ。
0579NAME IS NULL
2005/05/16(月) 00:58:12ID:???ユーザ1とID1・ID2は、どうやって結び付けてるの？
それを管理するﾃｰﾌﾞﾙが別途用意されてるの？
0580NAME IS NULL
2005/05/16(月) 02:08:22ID:???0581NAME IS NULL
2005/05/16(月) 11:09:12ID:???すんません、言葉足らずで。同じ事言ってました。
森羅万象テーブルっていうそうなんです。
まだこの場合、ユーザー情報限定だけど、
・ID
・データ種別
・値
で、データ種別で区別して色んな情報を値につっこむなんてのが
本当にあるんだって！こわー。
リソースが貧弱だった頃の苦肉の策なんでしょうかね。
0582NAME IS NULL
2005/05/16(月) 12:27:52ID:???システム的にどーでもいいデータならいいんじゃない？
データ種別が TEL代表、TEL裏口、FAX、携帯、とか。
0583NAME IS NULL
2005/05/16(月) 12:31:41ID:???継承使ったことないけど
0584NAME IS NULL
2005/05/16(月) 13:20:13ID:???元のは実際には使わないpureクラスということで・・
0585NAME IS NULL
2005/05/16(月) 13:21:35ID:???それ森羅万象じゃなくて電話番号じゃないですか
0586NAME IS NULL
2005/05/16(月) 14:31:55ID:???これか
http://www.amazon.co.jp/exec/obidos/ASIN/4534034733/
こっちか
http://www.amazon.co.jp/exec/obidos/ASIN/4534032501/
に出てた言葉だな。
業務に関わる所じゃ絶対にやらないけど
システム全体で使う定数の内、
後で変更される可能性がある場合なんかは
ソースで定数書かないでDBに持っておいたけど
森羅万象っちゃ森羅万象ぽかったな、あれは。
0587NAME IS NULL
2005/05/16(月) 17:58:28ID:???10レコード取り出してconcatしてからsubstrするとか。
現在でも、長い項目を持つ組を作っておいて、substr()で分割する
viewを定義するテクニックは生きてますよね。
0588574
2005/05/16(月) 18:02:02ID:d95wnL3s1
山田タロウ
111-1111
2
田中ハナコ
222-2222
3
梅田とゑ子
333-3333
これで合計9レコード。２番目のユーザのデータ取得はIDが
４から６までって感じで。
遠まわしに上司に進言しても、彼にまかせているからで終わり。
DBバックアップすると自動的にソートがされるDBもあると思うけど、
どうなったのだろうか。
0589NAME IS NULL
2005/05/16(月) 19:25:35ID:???最悪だな・・・・
例えば、苗字に"梅田"が付く人の電話番号を取得するにはどうしたら良いんだ？
0590NAME IS NULL
2005/05/16(月) 19:40:17ID:???0592NAME IS NULL
2005/05/16(月) 22:26:11ID:???なら最初からテーブル作れってのは、無しよこの際。
0593NAME IS NULL
2005/05/18(水) 00:09:30ID:Tq87rojfすいません、教えてください。
区分やコード化されている全ての項目はユーザーが画面で管理できるようにメンテ画面を用意し
名称等は適用年月日を見て取得するルールだった場合、項目の種類毎にテーブルを作るのですか？
たとえ数が100以上あろうと。
0594NAME IS NULL
2005/05/18(水) 03:28:45ID:???パラメータテーブルつまりパラメータ名をキーにパラメータ値というのはありだと思う。
ユーザ毎に固有のパラメータをもつ場合にユーザー＋パラメータ名でキーとういのは許容範囲。
ここの例のようにデータの並び順に依存するようなものは許容外。
許容内でもRDB的にはパラメータとその値としてしか識別できないのでそのパラメータの
意味や関連はアプリケーション側で管理する必要がある。
0595NAME IS NULL
2005/05/18(水) 10:37:06ID:???パラメータテーブルって
>586が言ってる定数をハードコーディングしないで
DB側で持つ、ってのと同じ？
ならよくやりますね。
>593のはよく汲み取れないんだけど、適用年月日ってなんだろう。
0596NAME IS NULL
2005/05/18(水) 11:23:45ID:???最終的には私ならどんどん項目の種類ごとにテーブルを
作っちゃうな。
0597NAME IS NULL
2005/05/19(木) 13:28:25ID:???個人テーブル
個人ID, 名前, 更新日, その他検索等に使う項目....
個人その他項目テーブル
個人ID, 項目ID, 値
項目テーブル
項目ID, 種別名
って感じ？
0598NAME IS NULL
2005/05/19(木) 14:51:03ID:???まったく別の意味を持ったデータなのが問題なんだって
0599NAME IS NULL
2005/05/24(火) 18:35:25ID:???それがあらかじめわかってればレコードに埋め込んじゃうかなあ。
0600NAME IS NULL
2005/05/24(火) 19:09:38ID:???0601NAME IS NULL
2005/05/24(火) 22:30:44ID:???つまり、それだけ非道い設計って事だよね。
0602NAME IS NULL
2005/05/24(火) 22:51:39ID:???そんな設計など思いもよらないマトモな思考の持ち主か、
そんな設計に全く疑問を抱かない狂人かのどちらかに違いない。
0603NAME IS NULL
2005/05/25(水) 07:51:54ID:???フィールドの内容と同時に意味もデータとして管理する手法でISAM的には間違いではないが、
関連や結合や集合演算などリレーショナルデータベースの特徴的な機能が使えなくなる。
他と関連があるデータ項目には使うべきではない。必要がある場合は自己責任で使うこと。
>>588 は順次編成ファイルでまれに見られる手法で、ISAMから見てもセオリーから外れる。
>>599 は住所のキーとして郵便番号が不適切だという話であまり関係なさそうだ。
0604NAME IS NULL
2005/10/29(土) 02:04:15ID:???0605NAME IS NULL
2005/10/31(月) 10:11:59ID:???0606NAME IS NULL
2005/10/31(月) 12:20:25ID:???必然的に自然キーなので変更されてビュー側まで含めた大改修になることがしばしばあるよなぁ
0607NAME IS NULL
2005/11/03(木) 17:48:35ID:???主キーが入ってたり入ってなかったりしてたがね。
抜けてるんだけどって聞いたら、まだ入れてないって返答が。
どーすりゃいいのかと。しかもマスターデータは他社にあるので
こっちで入力した分は他社に返すという。ｱｯﾋｬｯﾋｬ!ヽ(ﾟ∀ﾟ)ﾉｱｯﾋｬｯﾋｬ!
この案件は案の定潰れたがね。( ﾟДﾟ)y─┛~~
0608NAME IS NULL
2005/11/18(金) 11:22:54ID:???主キーの列を丸々切り捨てられたテーブルの方が恐怖だと思うが････
エクセルしか知らない社長さんが、
自社の顧客管理システムのDBでやらかしたって話を聞いたことがある
0609NAME IS NULL
2005/11/18(金) 11:39:55ID:???そもそのキーっているのかな。
0610NAME IS NULL
2005/11/18(金) 11:41:31ID:???0611NAME IS NULL
2005/11/18(金) 12:39:02ID:???0612NAME IS NULL
2005/11/20(日) 18:54:02ID:???0613NAME IS NULL
2005/11/21(月) 00:11:04ID:???0614NAME IS NULL
2005/12/08(木) 18:08:58ID:???* 主キーが必要なテーブルなのに付いてなくて冷や汗出てる場合。
* 主キーが不要なのに、無いテーブルを見つけて騒いでる痛い場合。
があるように見える。
業務自体をうまくビジネスロジックに分析して、主キーの有無やどれを主キーにするかって設計が必要な感じだな。
ところで業務の都合上で項目追加に成った場合は、主キーも再検討が必要ってこと？
業務の内容が変わって行くとビジネスロジックも変更が必要で、いかに汎用性の有るビジネスロジックと主キー設計が出来るかって設計者の腕の見せ所だけど、やっぱり失敗を繰り返して苦労して経験として養って行くしか無い？
伝票でも帳簿でもログ処理でも通用するような、有る程度汎用性を考慮したレシピ的な理論が欲しいかも。
0615NAME IS NULL
2006/01/13(金) 12:24:45ID:???>ところで業務の都合上で項目追加に成った場合は、主キーも再検討が必要ってこと？
つうより、そのテーブルに追加管理したい項目をどこのテーブルに追加するべきかを検討するんでしょ。
無いなら新規テーブルじゃない？
>伝票でも帳簿でもログ処理でも通用するような、有る程度汎用性を考慮したレシピ的な理論が欲しいかも。
くれくれくんかよｗ。そんななら自分で決めて他人に強制すればいい。
0616白馬の玉子 ◆PqSzNbkqDo
2006/04/12(水) 12:23:39ID:???DBがOraだったけど、もろオフコン。
主キーなくて、フィールド4つ以上でやっと複合キーになるし、
同じ内容なのに、テーブル3つに分かれてるし・・・。
それなりの設計思想なんだろうけど、
時代を感じたな。
それでｘｘ億円くらいとってたらしいけど・・・。
高速化のため！とか主張してたが、
見た感じ、遅くなる要素、満載だった・・・・・・・・。
ほとんどの更新系が、VBで Select - While not EOF - Select Case - Update - Loop のレコード総当りで書かれてて、
うわぁぁぁぁ！！！って感じ・・・・・。
それで高速化！とか威張られても、ねぇ・・・大手のN社さん！
Oraの機能、まったく活用してねージャン。
0617NAME IS NULL
2006/04/17(月) 14:15:09ID:???論理ファイル (ビューとインデックスのセットみたいなもん) が200ぐらいある。
そして、画面とロジックと使用テーブル宣言のセットで1プログラム。
再利用とか保守性とかの概念が生まれてなかったらしい・・・
0618NAME IS NULL
2006/04/18(火) 01:19:28ID:/VTC9Lb+ストレートにAS/400と書けｗ
しかし、ホントに再利用とか保守性とか考えねーよな。
なぜ楽をするための努力を惜しむのかと。
いくらでも楽できる機能があるのに、だれもつかいやしねぇ。
0619617
2006/04/18(火) 10:08:48ID:???0620NAME IS NULL
2006/04/18(火) 21:07:36ID:???うちもその口(AS400)だったけど
保守性の概念がない⇒
いくらでも残業代が出る
＆毎日徹夜してシステムを守るのがシステム部門の美徳みたいな風習があった
＆独身で家庭がない人が担当者
再利用の概念がない⇒
ステップ数で開発費が決まる
＆担当システムの規模が大きい方が会社は俺が背負ってるんだみたいな気になれる
＆独身で家庭がない人が担当者
大抵こんな所に原因がある気がしたyo
0621NAME IS NULL
2006/04/19(水) 09:49:17ID:???特にSQLを理解できない、しようとしないPMと言われている人に、その傾向が強い。
ERwinが社内標準なのにEXCELでファイル設計するよ(T-T)
↓
漏れが、ERwinで打ち直す。
↓
2重管理＆正規化 大混乱。
↓
どうやら漏れが悪い事になってるらしい
↓
管理方法等を相談
↓
PM精神論にﾊｼﾙ or 丸投げ↓
＿
.＿
（ ゜ A ゜；）
こんな毎日ですが、ﾜﾀｼﾊｹﾞﾝｷﾃﾞｽ。
0622NAME IS NULL
2006/04/19(水) 11:12:42ID:???0623NAME IS NULL
2006/04/19(水) 12:06:42ID:???何が言いたいのか分からん。
言葉が足りないのでは？
0624白馬の玉子 ◆PqSzNbkqDo
2006/04/19(水) 12:53:02ID:???VisualStudio＋SQLServerで組んでるっつーのに、
「作業工数管理したいから、ステップ数出して！」
だって・・・・。
その瞬間３秒ほど、回答詰まって体が固まったYO・・・・。
クラス数とか、オブジェクト構成とか、そういった要望なら理解できるけど、
「ステップ数」！！！
だよ！？
あとでうわさ聞いたら、頭の中がCOBOLな人らしい。
前世紀の遺物だな、あーいう管理職は・・・・。
プロジェクト進行の邪魔だから、馬鹿な管理職はさっさと進でください！
0625NAME IS NULL
2006/04/19(水) 13:32:39ID:???プログラムのソースならともかく、DBの場合はどう出すつもりなんだろう。
0626NAME IS NULL
2006/04/19(水) 15:46:10ID:???言われたとおりステップ数もだせばいいじゃん。
0627白馬の玉子 ◆PqSzNbkqDo
2006/04/19(水) 17:18:44ID:???オブジェクト構成の詳細は図式数値ともに、あえて出さなかったよ。
出しても、誰も読めないらしくって、以前設計時にUML3パターンほど出したら、
なにこれ、こんなもん必要ない！ってつっぱねられたのさ。
それより、操作説明書出せ！だってさ・・・
設計時に操作説明書出せって、その要求、なによ・・・・。
しまいには、客先の年間業務スケジュールまで分析させられて、
いわく、「部署内の誰も、完全な年間のスケジュール、わからないんだよねぇ～」だと。
っつーか、それが管理職であるおまえの仕事だろう！とつっこみたかった。。。。
で、とりあえず、PGのステップ数は提出したけど、
業務効率悪いねぇ～～～だってさ。
UIデザインにどれほど時間がかかって、
背後でどれほどのストアドが記述されてると思ってんだ、このばかちんがぁ！
ちなみにこの大学の旧システムの学生テーブルの主キーは、
5桁「学生番号」なんですが、
この学生番号の年度を表現する桁が1桁しかなくて、
10年ごとに過去の学生を別のOBテーブルに変換格納しないとOBが消滅するしくみに
なってました。すばらすぃ・・・・。
それは「主キー」とは言わないのでは？？
こんな馬鹿システム作った某社、最高っす！
おかげで、俺は、学生の管理のために、複合キー地獄です・・・。
高速化なんて、できやしねーってよ。
おまけに、過去のゴミデータがいて、絶対的にキーになる複合キーフィールド群において、
重複データが存在する始末・・・。
もういやです、ほんと、文教系の仕事って・・・。
アカデミズムからは程遠いですよ、ほんとに。
学校の職員教員って、馬鹿ばっか・・・・・。
（っていうか、「自分で責任取れない君」、ばっかり・・・。）
あぁ・・・・仕事しよっと・・・。
0628元COBOL使い
2006/04/19(水) 17:32:27ID:???無駄と思っている事を、無理強いすると、いい加減な仕事ふえるよ。
目的って重要です。
0629NAME IS NULL
2006/04/20(木) 21:15:32ID:ds1Y0fKR簡単でいいじゃん。上がそれで納得するならｗ
自分が欲するものを作るんじゃなくて、相手が欲しいものを作るのが
PGやSEの仕事なんだし。客だけじゃなくて上司でも同じだと思う。
まあ、社内改革するのなら徹底的に闘ってくれｗ
0630NAME IS NULL
2006/04/20(木) 21:19:29ID:ds1Y0fKR大学事務員と、教授～講師をいっしょにしないように。
事務員はプログラムなんて知らない。
ふつうの会社の事務と同じ。
0631白馬の玉子 ◆PqSzNbkqDo
2006/04/20(木) 22:08:55ID:???「上がそれで納得するならｗ」
↑
この時点で、俺と仕事への姿勢が違うもんね。
理解できなくて当然っすよ。
なんか、スレの主旨とあわなくなっちゃったので、ごめんなさい＞＞みなさん。
このネタはしゅーりょーしときます。
0632NAME IS NULL
2006/04/20(木) 22:27:43ID:ds1Y0fKR>>627を読んでも、どこかで勘違いしている臭いがプンプンするけどね。
ま、ひとりよがりで突っ走ってくれｗ
0633元COBOL使い
2006/04/20(木) 22:57:17ID:???>自分が欲するものを作るんじゃなくて、相手が欲しいものを作るのが
客が本当に欲っしているのは、正確な見積もりとその根拠だと思うが。
>まあ、社内改革するのなら徹底的に闘ってくれｗ
無 馬犬...(ﾟ∀ﾟ)ｱﾋｬﾋｬﾋｬﾋｬ
0634NAME IS NULL
2006/04/21(金) 10:01:25ID:CX6yg83T＞客が本当に欲っしているのは、正確な見積もりとその根拠だと思うが。
何？このずれた会話は。
マ板でよく見るがCOBOL使いの設計は最悪らしいが、>>633のレスで確信した。
0635元ＣＯＢＯＬ使い
2006/04/21(金) 19:12:24ID:???まぁ、ｵﾏｲさんの受け身な姿勢とﾚﾍﾞﾙは分かったよ。
ｽﾚ違いｽﾏｿ
0636NAME IS NULL
2006/04/21(金) 21:04:01ID:HfZIsICFわかっているなら最初から来るな、ヴォケ。
0637元ＣＯＢＯＬ使い
2006/04/21(金) 22:23:26ID:???0638NAME IS NULL
2006/04/22(土) 00:08:01ID:???現実には存在しない代用キーを多用されるほうが嫌だな
0639NAME IS NULL
2006/04/22(土) 01:12:48ID:???たとえUUIDでも無いより100万倍マシ
0640NAME IS NULL
2006/04/22(土) 01:38:52ID:???30過ぎて2chやっててはずかしくないのかな？？
俺が同じ立場なら2chなんかやらん。
それに2chやってるところ見ると未婚者っぽさそうだけど、システムをしっかり設計できるなら、
システムよりも自分の人生をしっかり設計したほうがいいぞ。
0641NAME IS NULL
2006/04/22(土) 01:41:39ID:???30過ぎたおじさんが、年下っぽさそうな相手に必死だなとか言ってる方が
俺は必死に見える。
0642NAME IS NULL
2006/04/22(土) 01:42:18ID:???0643NAME IS NULL
2006/04/22(土) 08:46:27ID:???＞俺が同じ立場なら2chなんかやらん。
こういうことを言っている奴ほど、
将来、２ちゃんでなくても似たようなことは絶対やっていると思う。
未来のことに対して言い切る奴って、だいたい無責任だし。
0644NAME IS NULL
2006/04/22(土) 09:22:12ID:???0645NAME IS NULL
2006/04/22(土) 10:20:17ID:???しらじらしい切り口から始まり
次の行で、さっそく矛盾
最後の行は、棚上げで締める
ヘタな政治家の人みたいで、おもしろいとおもいました。
又、ここへ来た30代以上を、全てを敵にまわす発言も、
すごい勇気だとおもいました。
えーと、主キーの話だっけ？
あれは、いいよねぇ～
0646NAME IS NULL
2006/04/22(土) 14:20:26ID:+UsjqiTMCSVの代わりにセキュリティ高くなるからと勘違いしてDBに移行したケースじゃねえか？
CSVで作るシステムにわざわざPK設定しねえし
CSVの代用ならそれでもいいけど
どっちにしろPKつけた方が楽になるけどね
0647NAME IS NULL
2006/04/22(土) 14:58:51ID:???0648NAME IS NULL
2006/04/23(日) 01:42:55ID:???0649NAME IS NULL
2006/04/23(日) 01:48:32ID:???あんまいい人生送ってないっていうか、人生設計した方がいい人たちばっかって普通は思うよ。
それとも、おまえらは特殊すぎて、普通の友達とかいないから、普通の考えわからんかな。
0650NAME IS NULL
2006/04/23(日) 05:58:01ID:6VARQ0Cr0652NAME IS NULL
2006/04/23(日) 10:45:24ID:???その座布団は>>640に渡すべきだな。
0653NAME IS NULL
2006/04/23(日) 12:39:43ID:???わしゃ、後もう少しで30代の仲間入りさ～。
まぁ、2chは混沌としているが、過信しなければ、
いい情報源だよ？ と、正当化してみるﾃｽﾄ。
0654NAME IS NULL
2006/04/23(日) 15:14:42ID:???実は、その辺の年齢層が一番多く
かつ、ﾁｮｳﾄﾞ気になり始めている頃と考えられる。
確かにｽｺﾞｲ勇気だ
_、_
（ ._ノ` )y━・~~~
0655NAME IS NULL
2006/04/24(月) 03:06:21ID:???他の人は答えるの避けて、他の俺に対する発言してんのかな？？
やっぱ、避けてんでしょ？？
>>654
君の言葉を借りると、俺の発言に反応してる人は君も含めて、30代前半であたってるから、
反応してるってことでＯＫ？
0656NAME IS NULL
2006/04/24(月) 12:37:03ID:???0657NAME IS NULL
2006/04/24(月) 15:08:05ID:???元COBOL使いですがﾅﾆｶ？
0658NAME IS NULL
2006/04/24(月) 19:37:36ID:???俺はお前が誰なのかが疑問だ
0659NAME IS NULL
2006/04/24(月) 23:30:24ID:z7GeGS14ORACLEで主キーを指定できるようになったのは何時頃から
だろう。バージョンは? 私は詳しく知らないが、たぶん
1990年頃、version6.0くらいからだろう。つまり、Excelが
流行し始めた頃でそんなむかしのことではない。それまでは
主キーの概念は理解していたが、実装となると単にindexファイルを
作成するだけだった。
ということは、1980年代に作成されたORACLEのシステムだと、
主キーなんてなくて当たり前のことなのだ!!
0660NAME IS NULL
2006/04/25(火) 03:12:41ID:???0661NAME IS NULL
2006/04/25(火) 23:58:52ID:???オラ、悟空
0662NAME IS NULL
2006/04/26(水) 20:13:48ID:???>たとえUUIDでも無いより100万倍マシ
実はちょっと前からこれが気になっているんだが、
冷静に考えてみて、これって悪いのかな、と。
どっかでこれの是非とか読んだような気もするんだが、
思い出せん。
(なんかMSのASP.NETのProfileとかがUUIDなんだとかも聞いた気がする)
0663NAME IS NULL
2006/04/26(水) 20:24:38ID:???0664NAME IS NULL
2006/04/26(水) 21:36:27ID:???0665NAME IS NULL
2006/04/27(木) 11:02:09ID:???結合無しでデータ見る場合連番より分かりにくくなるけど
0666NAME IS NULL
2006/05/10(水) 01:08:44ID:???0667NAME IS NULL
2006/05/11(木) 15:59:02ID:???その結果を見て違うと言う人がルールを知ってるのでしょう。。
0668NAME IS NULL
2006/05/23(火) 02:08:54ID:???いたのね。「データのエクスポート」で取るとき、設定次第でどうなのか
知らないけどそいつの環境の設定は、MDB側に主キーの情報が反映
されてなかったのよ。それでそいつ、知らずに何度もおなじMDBに
エクスポートしてて、同じ主キー値のレコードが複数出来ちゃって
困ってた。
もうちっと仕事覚えてくれよ・・・
0669NAME IS NULL
2006/05/23(火) 20:37:32ID:???0670NAME IS NULL
2006/06/04(日) 17:08:59ID:???データ型が変わるから、気をつけろー。（長井風 古いか。。
ってか、開発時のデータならまだしも、本番データをMDBに
バックアップって、問題ないの？
0671NAME IS NULL
2006/10/28(土) 18:48:42ID:GOZLHMAZoracle+VBで、ヘルプで参加した際、まずPKないなんて普通。
カラム名は日本語で300カラム以上。（備考1、備考2・・・みたいに）
SQL書くだけでも、もううんざりした上に、納品後、カラム名が可変とか言い出した。
もう死ね！！氏ねじゃなくて死ね！！エクセルでも使ってろ！！
0672NAME IS NULL
2006/11/04(土) 10:09:33ID:ww13bNDfと言ってると思う。
0673NAME IS NULL
2006/11/04(土) 18:31:05ID:???key1 key2 data1 data2 data3 とカラムがあるテーブルで、data1、data2、data3をキーとしてkey1、key2に対してアップデートをかける。
「これおかしいお！」とリーダーに言ったら、「本当はこのテーブルはdata1、data2、data3が（業務的には）キーなんだよね」だって。
業務的にキーならそっちをキーにしろよと・・・。
0674NAME IS NULL
2006/11/05(日) 07:22:44ID:AbI7e55r0675NAME IS NULL
2006/11/05(日) 22:09:34ID:???……もっぺん勉強せにゃorz
0676NAME IS NULL
2006/11/05(日) 23:16:22ID:???ﾜﾛﾀwｗ
リレーション概念ないんだな、それｗｗｗ
0677NAME IS NULL
2006/11/28(火) 00:42:42ID:2uKzX2xWプロジェクトで使うテーブルは作成完了していたんですが、
キーとしているのが製品名で、製品名をキーにもつ関連テーブルが全部で１３０個くらいあります。
製品名を変更したりする場合は「製品名保持テーブル一覧テーブル」を使って
ループしながら１３０個のテーブルの製品名をアップデートしたりしています。世の中のプロジェクトでは
こういうテーブル設計は一般的なんでしょうか？
製品名テールを作って、内部的にはユニークな番号を使って管理すれば製品名変更は
テーブルひとつ書き換えるだけですむのでは？という話をしたところ「HDDを余計に食いつぶすし、
番号使ったら直感的に分からなくなるしクソ設計だ」といわれてしまいました。
0678NAME IS NULL
2006/11/28(火) 01:38:39ID:???0679NAME IS NULL
2006/11/28(火) 02:10:56ID:???0680NAME IS NULL
2006/11/28(火) 02:30:35ID:???なぜか取引毎にテーブルがあって数だけは多いとか。
0681NAME IS NULL
2006/11/28(火) 09:27:00ID:???0682NAME IS NULL
2006/11/28(火) 21:39:20ID:???悪いものだという事が分かりました。ありがとうございます。
0683NAME IS NULL
2006/11/28(火) 22:00:56ID:???伝票の場合は過去の製品名で表示したいとかあるので
名称も項目として持つことがありますな
0684NAME IS NULL
2006/11/29(水) 00:31:20ID:???tgkさん？
0685NAME IS NULL
2006/11/29(水) 03:43:07ID:???製品名の履歴として管理すればいいだけでは・・・
0686NAME IS NULL
2006/11/29(水) 06:16:04ID:???数百万レコード超となることが多いので
重いJOIN減らすため埋め込むのれす
0687NAME IS NULL
2006/11/29(水) 08:18:21ID:???スナップショットをとっておく事が多かったな。
最近販売管理関係やってないなあ。
0688NAME IS NULL
2006/11/29(水) 09:37:35ID:???>>680 の場合は
>キーとしているのが製品名で、製品名をキーにもつ関連テーブルが全部で１３０個くらい
うへぇ or2=3
0689NAME IS NULL
2006/11/29(水) 10:52:00ID:???糞重たくなると思うのだが？
0690NAME IS NULL
2006/11/29(水) 16:50:32ID:???インデックスのカラムで検索させれば検索速度あがるんだよね？状況によっては遅くなるらしいけど。
んで、主キーは何に使うの？同じく、検索速度あがるの？
0691NAME IS NULL
2006/11/29(水) 17:09:23ID:???0692NAME IS NULL
2006/11/29(水) 19:44:04ID:???このスレを眺めて自分なりの結論を出せ。（ｗ
【恐怖】主キーがないテーブルみたことありますか？
http://pc8.2ch.net/test/read.cgi/db/1069324950/
0693NAME IS NULL
2006/11/29(水) 20:12:58ID:???＞【恐怖】主キーがないテーブルみたことありますか？
このスレがこれなので無限ループに陥りそうだ
>>690
主キーは行を一意に識別するもので、
ユニークで非NULLであるという制約を持つ。これが主キー制約。
主キー制約を実現するためにＲＤＢでは索引を使用している。
CREATE INDEX命令はANSI SQLには含まれていないよね確か？
0694NAME IS NULL
2006/12/02(土) 01:48:42ID:???0695NAME IS NULL
2006/12/04(月) 14:58:02ID:???ユニークではなかった。
仕様策定者のせりふが忘れられない、
「えぇ。では、○○もKeyという事にしましょう。」
世の中、「では」なんて軽い言葉では済まされない事もあるんだよ・・・
0696NAME IS NULL
2006/12/04(月) 17:18:05ID:???0697NAME IS NULL
2006/12/04(月) 18:44:00ID:???お客さんにとってはそんなもんだよなあ。
しかたないと思うよ、その策定者のセリフは。
0698NAME IS NULL
2006/12/04(月) 19:22:52ID:???ユニークと聞いていたのに、対向システムでいつの間にか崩れていたことがあったな。
ダブったデータはどうすればいいかとお客さん経由で問い合わせたら、
「適当に処理しといて」という返事寄越しやがって、お客さんも怒ってた。(w
0699NAME IS NULL
2006/12/05(火) 12:41:25ID:???ﾊﾞﾛｽ
0700NAME IS NULL
2006/12/06(水) 00:22:38ID:???0701NAME IS NULL
2006/12/06(水) 12:00:47ID:???0702NAME IS NULL
2006/12/06(水) 13:11:45ID:???0703NAME IS NULL
2006/12/06(水) 13:55:48ID:???って超定番でもう誰もいわない。
0704NAME IS NULL
2006/12/06(水) 14:59:50ID:l9nu+9X3こうやって誤魔化しながらいってるやつってのは、ほんとうはそれを言いたいわけだ。
１行目が本音で２行目が照れ隠し。
0705NAME IS NULL
2006/12/06(水) 15:24:47ID:???でもほんとは>>330で既出なの。
俺じゃないけど。
0706NAME IS NULL
2006/12/06(水) 15:43:38ID:???>>330 = >>703
親父ギャグは笑うまで繰り返すの法則。
0707703=705
2006/12/06(水) 15:53:12ID:???でもがんばって繰り返すよ
0708NAME IS NULL
2006/12/06(水) 16:57:49ID:???0709703=705
2006/12/06(水) 17:46:14ID:???0710NAME IS NULL
2006/12/06(水) 21:22:52ID:???0711ISNULL(NAME, NULL)
2006/12/16(土) 14:24:46ID:???主キー はその表に入るデータ(行)を一意に識別することができる1列以上の列の組み合わせの
うち、もっとも重要な列(の組み合わせ)に対して与える称号。
インデックス は、よく検索される列を検索しやすいようにあらかじめ作っておく索引。本の索引と
同じようなもの。インデックスは項目が一意になるユニークインデックスと項目が重複してよい
(普通の)インデックスがある。
主キー制約 をつけると、「その表に入る行を一意に識別することができる1列以上の列の
組み合わせ」という制約を実現するために勝手にユニークインデックスがつく。
主キー はモデルを作るときに「その表に入る行を一意に識別することができる1列以上の列の
組み合わせのうち、もっとも重要な列」をあらわすしるしで、それを実装で実現する手段が
ユニークインデックス なのだ。
0712NAME IS NULL
2006/12/17(日) 23:38:44ID:c8T56vdc0713NAME IS NULL
2006/12/18(月) 21:30:35ID:???0714NAME IS NULL
2006/12/19(火) 01:01:11ID:???どうやったらそんな気色悪いテーブルが作れるのだろう？
１列＝１バイト？？？
0715NAME IS NULL
2006/12/19(火) 01:28:30ID:???まあ代理キー＋ユニークも綺麗とは思わんから構わん。
0716NAME IS NULL
2006/12/23(土) 00:14:16ID:fExmKA+s使わなくなったフィールドは無視するだけなんで基本的に減ることはないんですが、仕様が追加されたらそれにともなって
フィールドをどんどん追加していくそうで。
フィールド数の変化するテーブルに関しては、フィールド名テーブルを別に作って管理するらしーんですが、
フィールドが増えてくっていうのに慣れなくて、、、
いろんな設計があるんだなぁ、と思う今日この頃です。
0717NAME IS NULL
2006/12/23(土) 10:24:23ID:???まあ、最初からそれを想定しているならそれもアリだろうけど
使わなくなったフィールドを無視するのは単に頭が悪いと言うか
正規化の概念がないだけだとｵﾓ。
あと、多くのRDBはフィールド情報を保持したテーブルを
システムで自動的に管理しているので、
「フィールド名テーブルを別に作って管理」と言うのは
正直なところ、アホの子と思わなくもない。
0718NAME IS NULL
2006/12/23(土) 12:34:29ID:???「これを参考にして作れ」っていわれたのがそういう奴だったんで、
「はぁ、そうですか」というわけで。
作ってる最中から「これでいいのか｝」とは思ってたけど、どうせ俺の知ったこっちゃ
ねーし。
0719NAME IS NULL
2006/12/24(日) 15:06:06ID:???0720NAME IS NULL
2006/12/24(日) 20:38:04ID:???その場合でも後から処理順とかを追えるように、
シーケンス使って連番振らない？
まぁほんとのワークテーブルならそれも不要ってことかな？
手間と整合性のトレードオフですか。
0721NAME IS NULL
2006/12/26(火) 00:45:46ID:???俺の場合、そういうデータは外からスクリプトでゴニョゴニョするので、
データ特定のためのシーケンスは必ずつけるようにしている。
0722NAME IS NULL
2006/12/26(火) 01:50:54ID:???10万件取り込んで数回SELECTして終わり、とかだと
PK無しにすることによるパフォーマンス面でのメリットが大きかったり
0723NAME IS NULL
2006/12/26(火) 21:53:08ID:???＞パフォーマンス面でのメリット
ってそれほどのもの？
0724NAME IS NULL
2006/12/26(火) 23:32:32ID:0tnnv+Jgその辺決めた奴、COBOLERじゃね？
後ろにフィラーをあらかじめ多めにとっておいて、必要になったら取り崩していく。
レイアウトはdata-division(だっけ？)に台帳からコピーして修正。
0725NAME IS NULL
2006/12/27(水) 22:55:55ID:???0726NAME IS NULL
2006/12/27(水) 23:16:42ID:???0727NAME IS NULL
2006/12/27(水) 23:18:20ID:???0728NAME IS NULL
2006/12/28(木) 01:52:59ID:???0729NAME IS NULL
2006/12/28(木) 09:49:13ID:???0730NAME IS NULL
2006/12/28(木) 10:11:18ID:???あれはRowVersionだから、主キーが勝手に書き換わってまずいんじゃない。
出来たかどうかは知らんが。
0731NAME IS NULL
2006/12/28(木) 17:24:41ID:???0732NAME IS NULL
2006/12/28(木) 22:24:25ID:???いや、ここはCOBOL.NETに挑戦してもらいたいw
0733NAME IS NULL
2006/12/29(金) 02:04:45ID:???腐 っ て い る
0734NAME IS NULL
2006/12/29(金) 23:52:06ID:???.NETを付けなくても(ry
0735NAME IS NULL
2006/12/31(日) 07:32:16ID:???ｺﾎﾞﾗｰは腐ってると言えるけど。
0736NAME IS NULL
2007/01/02(火) 18:06:22ID:???コボラーって揶揄されるのはそういう人だよね。
COBOLやってた人で凄い人はやっぱ凄いよ。
0737NAME IS NULL
2007/01/02(火) 21:00:46ID:???COBOL上がりの人が圧倒的にDQN率が高いだけだろう。
漏れが現場で合う連中だと、とりあえず100%くらいDQNだなぁ。
0738NAME IS NULL
2007/01/03(水) 18:37:48ID:???DQNってよりもCOBOLの固定概念がありすぎて、
話が噛み合わないってほうが多いなぁ。
0739NAME IS NULL
2007/01/04(木) 10:59:14ID:???COBOLやっていた人がいかに凄くても､RDBの概念を理解して動作させている人は非常に少ない｡
0740NAME IS NULL
2007/01/04(木) 11:31:50ID:???プログラムかかせても1行ずつフェッチするとかホントにやりやがる奴いるしな
0741NAME IS NULL
2007/01/06(土) 14:00:23ID:???あげくにDB遅いなとか。遅くしてるのはおまいらだって(w
0742NAME IS NULL
2007/01/06(土) 16:07:12ID:???必ずFILLERがあるとかｗ
まあ単に勉強不足なだけなんだよね
しかし無知であるのは仕方ないとしても勉強する気がないのは最悪
仕事なんだからさー
主キーのないテーブル云々ってのも結局そこに起因するのが殆どな気がする
0743NAME IS NULL
2007/01/06(土) 18:26:52ID:???必要な属性が複合キーとしてズルズル並んでるイメージ。
それをそのままＲＤＢに持ち込もうとするとおかしくなる。
逆にＲＤＢしかやってないのにCOBOL的なバッチ処理を書かせると、
OLTP処理が変更トランザクションの数だけ動くように書いてしまう。
0744NAME IS NULL
2007/01/06(土) 19:58:51ID:???もうすぐアホジャヴァー役たたねえといわれ日がくるな
0745NAME IS NULL
2007/01/06(土) 20:08:50ID:???0746NAME IS NULL
2007/01/06(土) 20:31:16ID:???裏で動いてるRDBがもったいない。
0747NAME IS NULL
2007/01/06(土) 21:56:13ID:???0748NAME IS NULL
2007/01/06(土) 22:17:15ID:???漏れはどっちも使えるけど、速度が気になるならSQLのストアドとかで
事足りているのでJavaが遅い云々はそれほど致命的でもない感がある。
つかJavaで遅いとか言っている人はCでも遅いと思うけど。
0749NAME IS NULL
2007/01/07(日) 21:29:42ID:???0750NAME IS NULL
2007/01/07(日) 21:39:30ID:???適用しようとするマヌケSEだろｗ
0751NAME IS NULL
2007/01/07(日) 23:05:34ID:???ただ最近の開発は全てドカタなので、デスマの原因やらトロいってグチを言語に
なすりつける時点で相当にDQNなSE&PGだって事を自覚した方がいいな。
0752NAME IS NULL
2007/01/08(月) 02:52:25ID:???0753NAME IS NULL
2007/01/08(月) 03:22:14ID:???0754NAME IS NULL
2007/01/08(月) 08:39:22ID:???さてoracleがJavaのストアドが書けたり、MSSQL2005で.NETのストアドが書けたりするけど、
どのくらい使われてるのだろう？一回目の起動に時間がかかっていや～んな感じなのだが。
0755sage
2007/01/14(日) 00:56:15ID:jZSYQ9d5パフォーマンスとかどんな感じなの？
別に変わんない？
0756NAME IS NULL
2007/01/16(火) 05:00:31ID:???鯖いっぱい用意して物量で対応できないと氏ねる。
そういう大規模トランザクションでJavaがあってないのは認めるけど、他にまともで安価なミドルウェアがほぼ無いのも事実。
Javaのミドルウェアを他に移植して無料で公開してくれ(w
0757NAME IS NULL
2007/01/16(火) 23:38:44ID:???つ「言い出しっぺの法則」
ってのは冗談として「他」って具体的に何だ? これ、と指定があればやってやろか、ってな猛者も
いなくもないかもしれないかも(ry
# ちなみに俺は凡人の中の凡人なのでJava VMのメモリマネジメント性能をぶっちぎるプログラム書くのは諦めたorz
0758NAME IS NULL
2007/01/17(水) 09:02:18ID:???0759NAME IS NULL
2007/01/17(水) 09:06:52ID:???ttp://www.wince.ne.jp/snap/ceSnapView.asp?PID=874
0760NAME IS NULL
2007/01/17(水) 09:58:03ID:???Ajax とか Flash とか Curl とか組み合わせなくても
Java でバックエンドもフロントエンド ( UI ) も作れて便利そうなのに。
0761NAME IS NULL
2007/01/18(木) 00:35:43ID:???これこそがJREだけを入れて実現できる
現時点で最も簡単に環境構築できるリッチクライアントなんですが。
多分、動作環境がインスコ済みという意味では一番なのに
開発言語自体も一大勢力を築き上げてるのに
0762NAME IS NULL
2007/01/19(金) 22:20:54ID:???王道中の王道の部分しか使えないよな。
0763NAME IS NULL
2007/01/19(金) 22:29:51ID:???MSのActiveXやノータッチデプロイメントも同じ穴の狢。
0764NAME IS NULL
2007/01/19(金) 22:30:26ID:???0765NAME IS NULL
2007/01/20(土) 11:28:20ID:???そうだったりして。
3.0で、邪道を取り込んで
なんとか生き延びたって感じですか。
0766NAME IS NULL
2007/01/20(土) 11:44:04ID:???敷居が高かったし、漏れの扱う案件ではあそこまでの機能は
いらんかったのでスルーしていたし、今後もスルーだろうなぁ。
JSF辺りでいーや、って思うし。(これもEJB一部なのか？)
消えつつある感のある技術と言うか言語といえばperlじゃねーの。
PHPがでてきているし。
0767NAME IS NULL
2007/01/20(土) 14:39:31ID:???perlはUNIX方面の一発スクリプト廚の道具で、PHPはperlのCGIに手を出せなかった低レベルウェブデザの言語ってイメージ。
これからはrubyかなあと思いつつ、まだまだ採用できるレベルにはほど遠い。
0768NAME IS NULL
2007/01/20(土) 15:21:13ID:???EJBとJSFではドメインが違いすぎる
理解してないキーワードをよく知りもせず並べ立てても
鼻で笑われるだけだぞ
0769NAME IS NULL
2007/01/20(土) 15:50:56ID:???別にドメインがどーこーとか思うモノか？
EJB+JSP+JSF+strutsのアプリも作れる。別の意味で感動できたが。
なんか使ったことのない人間が語っても鼻で笑われるだけだぞ。
0770NAME IS NULL
2007/01/20(土) 16:39:27ID:???死ねるアプリだな。（ｗ
0771NAME IS NULL
2007/01/20(土) 22:18:55ID:???0772NAME IS NULL
2007/01/22(月) 00:30:03ID:???何でそんなの作ることになったの？
キーワード語って仕事取ってきた営業の陰謀か？
0773NAME IS NULL
2007/01/22(月) 01:03:25ID:???別に複雑な事情があったワケでもなく、
servlet+JSP+EJBで動いていたアプリと
strutsで動いていたアプリがあって、
まとめる事になった。
漏れがJSF派の人なので、JSFメインで
組んでいったが、JSFでは手の届かないトコロが
あったりするワケで、JSFとstrutsが共存できるのは
ワリと知れ渡っていて、ついでにJSPも共存できるのは
知っていたから、「できるかなー」って思って、
やってみたら出来た。というだけ。
営業から言われたのは「工数節約」くらいなので、
節約してみますた。（w
現行バージョンのWebSphereがJ2EE1.4止まりなんで、
WebSphereがJ2EE5以降をマトモに実装するようになって、
ついでにDBのテーブル設計と現行の文字コードがEBCDICなので
これをUTF-8に移行してスッキリしたら、JSFでリプレースしようと
思っています。
0774NAME IS NULL
2007/01/22(月) 18:01:29ID:???AS400かい?
0775NAME IS NULL
2007/01/22(月) 21:53:34ID:???i5ですｗ
0776NAME IS NULL
2007/01/24(水) 00:27:07ID:???うごくものをリリースしてくれるので、そのままか新しくするか決めるだけ。
その腕前なら、AS400をJavaとかのオープン系にしたくて困っていた元居た会社に紹介して上げたい(w
そう言う案件ってあんまり出来るところ少ないと思う。
つーかやらされそうになったので逃げた漏れ。orz
最初はPHPとか移植したら楽で良いなあと、妄想してた時期も有りました(w
0777NAME IS NULL
2007/01/24(水) 01:12:57ID:???そこら辺を理解しないと死ねるだけだと思う。
主なデメリットはドキュメントはないわ、Internetも情報がメチャ少ないし、
マニュアルであるiSeriesのWebSphereのｲﾝﾌｫﾒｰｼｮﾝｾﾝﾀｰは英語版しかないし。ｗ
AIX版を参考にしてOS/400に置き換える脳は必要かな。
IBMのソフト自体は重いが出来はいいのでRPG&CLからJava&SQLに移行すれば
劇的に生産性は上がるしAS400の安定性と堅牢さが利用できるので、
漏れは積極的にオープン系の技術は取り込むようにしている。
あと、IBMは面倒というか相談には乗ってくれるがJSF辺りだと日本の普及率がｲﾏｲﾁな
性か漏れが人柱状態な気もしなくもない。
結局IBMの人にRedbooks（英語版)のヒントを貰ってなんとか解決するってノリだしなぁ。
まあ、某日立とかに比べればIBMは面倒みてくれるのは確かだな。ｗ
0778NAME IS NULL
2007/01/25(木) 01:30:35ID:???まあAS400なんて手間の割に実入りが少ないからねえ。ミニコンよりも汎用機やった方が儲かる。
0779NAME IS NULL
2007/01/25(木) 07:35:16ID:???ﾋﾞﾐｮｰなんだよなぁ。
知ってる汎用機チームだと一部の人は週休0.5日制になってるし
と思えば、定時上がりのﾔﾂもいるしな・・・。
0780NAME IS NULL
2007/01/28(日) 02:22:13ID:???0781NAME IS NULL
2007/01/28(日) 04:20:17ID:???0782NAME IS NULL
2007/01/28(日) 10:40:28ID:???でも、ER図やテーブル定義書に
「受注と受注明細は"0...*"の関係にある」
「受注.確定フラグは、0:未確定、1:仮受注、2:確定の意」
って書くなら、foreign-key制約つけてcheck制約つけてほしい。
「だってテストデータ作るときに面倒じゃないですか」とか
言われるんだけど、設計はしたけど実装しないってのは
手抜き工事みたいなもんだ。
0783NAME IS NULL
2007/01/28(日) 15:15:55ID:???0784NAME IS NULL
2007/01/28(日) 15:46:26ID:???漏れはNOT NULLは積極的につける派だけど、
FKは時と場合で、フレームワークとかの比較的最新の技術で
組む時はFKだけど、COBOLとかの古代言語系の時は
つけない。と言うかCOBOLerが理解できないだろうし、
更新系で速度命の場合は、つけないけど。
ただ速度云々に関しては制約つけた方が安全性が高まるから
少しばかし遅くなっても制約つけるべきだとｵﾓ。
オペレータが２重にJOB起動させたけど制約で例外が発生して
助かった例もあるしな。
0785NAME IS NULL
2007/01/28(日) 16:03:11ID:???0786NAME IS NULL
2007/01/28(日) 22:00:55ID:???0787NAME IS NULL
2007/01/29(月) 10:03:31ID:???0788NAME IS NULL
2007/01/29(月) 20:50:17ID:???主キー制約、ユニーク制約：索引と密接にかかわるのでもちろん使う
NOT NULL制約：もちろん使う
CHECK制約：アプリ任せでほとんど使わない
参照整合性制約：
親子レコードのケースでは基本的に使う
複数の箇所で使うようなコードには基本的に使わない
0789NAME IS NULL
2007/02/01(木) 21:52:15ID:???最後にパフォーマンスが微妙に足りないときに削るかどうか考えるw
結合テスト段階で制約違反出した奴はペナルティww
0790NAME IS NULL
2007/02/02(金) 22:26:15ID:???0791NAME IS NULL
2007/02/04(日) 04:05:45ID:???参照整合性制約はたとえば
注文と注文詳細では使うが
店舗と都道府県では使わない（都道府県コードを複数箇所で使う）
ってことですか？
0792NAME IS NULL
2007/02/06(火) 01:02:22ID:???インポート時に制約を無効にすればいいじゃない
0793NAME IS NULL
2007/02/20(火) 13:18:33ID:???認可DBを作っていてDBは
T01[認可相手の名前・住所等のDB]
T02[認可期間、認可した日付、申請日、認可合計料金]
T03[認可した場所別連番ID、単価、数量、計算金額]
という感じでT01-T02-T03という感じのリレーションをしている。（Access2003です）
データ件数はT01で700件前後、データ全体で1.5MB程度
キーとして
T01:認可番号
T02:認可番号＋認可期間年月日（自）＋（至）
T03:認可番号＋（自）＋（至）＋連番ID
としているんだけど、俺ってそんなにアホな子かな？
本職なかたの指摘プリーズ！
0794793
2007/02/20(火) 13:22:58ID:???○T02にT03集計値の金額が入っていることについて
旧システムの金額を移行したためデータ化している。
というのも、旧システムの金額が単純な計算では導き出せない数値もあったので
○T03に計算結果である金額が入っている件
同上
○単価について
単価はコード化しているが、その単価自体は毎年変わるので
実際に使用した単価をデータで持っている
0795NAME IS NULL
2007/02/20(火) 13:35:04ID:???1. テーブルそれぞれの目的がいまいち不明確
2. 各テーブルの関係が不明確 T1:T2 は 1:1？ T1:T3 は 1:n？
3. T3 の(自)(至)って何？
0796793
2007/02/20(火) 14:13:01ID:???1．T1が認可先の名前・住所・Tel、認可場所など、T2が認可１件単位の履歴、T3が1認可当たりの内訳
2．T1－－－T2－－－T3
1対n 1対n の関係
3．略してスマソ。期間年月日（自）、期間年月日（至）です
0797NAME IS NULL
2007/02/20(火) 14:28:19ID:???認可1履歴（T2）ごとに、複数の認可期間を持つ内訳（T3）があるの？
認可期間は内訳（T3）ごとに異なるの？
0798793
2007/02/20(火) 14:36:50ID:???そうです。
認可物件が継続の場合もありますが、それでも単価が異なってきますし
認可の内容自体がガラリと変わるケースもあるので
0799NAME IS NULL
2007/02/20(火) 15:58:55ID:???とりあえず、認可期間は属性だな。もちろん索引はあってもいいが主キーではない。
T01:認可番号
T02:認可番号＋履歴番号 属性として、認可期間年月日（自）＋（至）
T03:認可番号＋履歴番号＋明細番号
COBOLなんかだとこれでＯＫなのだがRDB的には３つ以上の複合キーはできるだけ避けたほうがいいので
履歴番号をユニークなものにする。
T01:認可番号
T02:履歴番号 属性として認可番号（外部キー）と認可期間年月日（自）＋（至）
T03:履歴番号＋明細番号
ＯＲマッピングなど使う場合は複合キーは使わないようにするので明細番号をユニークな番号として
T03:明細番号 属性として履歴番号（外部キー）
0800793
2007/02/20(火) 20:27:12ID:???教えてくれてありがとう！
やっぱりテーブル設計っていろいろとむずかしいな
アホな子ということがわかったので、もっと勉強しないといかんわ
0801NAME IS NULL
2007/02/22(木) 18:23:54ID:8aAyMxNpN対Nのデータが毎月届くのだよ
主キーも無く…
そんなの差分更新出来ないし、おまけに年変わりで
旧年度データがもう来なくなるんだよ
全件入れ替えも厳しい…
おまけに年が変わった後の前年度更新もある…
そんなのデータ渡すから更新しろと言われても…
直近三ヶ月のデータをもらって、置き換え
前年度が変われば、前年度の最新全件置き換え
ってするしか思いつかん…
なんか他にあるか？
0802NAME IS NULL
2007/02/22(木) 22:16:30ID:???ちょっと待て
0803NAME IS NULL
2007/02/22(木) 23:46:39ID:???どうアクセスするのかわからなきゃ答えようがなかろう。
それを度外視していいなら「来ただけ全件入れとけ」って言うぞ。
0804８０１
2007/02/23(金) 00:36:58ID:pvcSq1o7住所が変わっただけでは、その郵便番号は複数あるからどれを置き換えればいいかわからない
つまり全件入れ替えしかないわけだが
年をまたぐと来ないデータがあるから、全消しー全件置き換えも出来ないだろ
うーん。
謎。。。
なんか、うまいやり方ねーかなー(ｗ
0805NAME IS NULL
2007/02/23(金) 00:42:12ID:???0806NAME IS NULL
2007/02/23(金) 00:47:04ID:???801の話を信じると、そんなデータはそもそもSELECTで照会も
マトモに動いていない事になるしな。
本気で困っているならテーブルの詳細とキーとインデックスと
中身のデータを晒せ。
話はそれからだ。
0807NAME IS NULL
2007/02/23(金) 02:00:50ID:???どうも見てると、お前さんの扱うデータというのは、
「表の形にはなるが、行を特定する術がない」
かのように思えるんだが。
ってことは、どの行を取っても、別の行と「等しい」と判定できないんじゃないか?
だったら毎回全件追加でいいんじゃないのか。
そうやってため込んだデータをどう使うのかは神のみぞ知るだけど。
0808NAME IS NULL
2007/02/23(金) 09:46:29ID:???DB関係ねーな
0809NAME IS NULL
2007/02/23(金) 11:25:22ID:???0810NAME IS NULL
2007/02/28(水) 12:01:00ID:???0811NAME IS NULL
2007/03/06(火) 00:57:19ID:???0812NAME IS NULL
2007/03/09(金) 13:36:18ID:VlRmkENp自主開発のRelationalDBのデータをAccessに移そうとしたんですが、主キーの意味が分からず、ただの連番データが増えてるだけなんですが…
0813NAME IS NULL
2007/03/09(金) 16:45:33ID:f5uYvLc40814NAME IS NULL
2007/03/09(金) 17:08:23ID:???DBを逆移行してるから、Keyも劣化していいんじゃね？(w
0815NAME IS NULL
2007/03/09(金) 18:52:20ID:???0816NAME IS NULL
2007/03/09(金) 23:11:14ID:???DBエンジンを自主開発できるお方に私ごときは意見できませぬｗ
0817NAME IS NULL
2007/03/10(土) 17:45:28ID:???0818NAME IS NULL
2007/03/10(土) 21:01:54ID:???DBとDBMSを混同するのは初心者によくみられる間違いだね。
0819NAME IS NULL
2007/03/11(日) 10:12:18ID:???くれるRDBMS側のサービスに利用されるだけですね。RDBの場合、理論的には
集合だから重複データはあり得ないので、こういう概念が強調されますね。
0820NAME IS NULL
2007/03/20(火) 06:57:17ID:???当然主キーもGUID。"{xxxx-xxx....xxx}"みたいな文字列で。
0821NAME IS NULL
2007/03/20(火) 10:03:25ID:???0822NAME IS NULL
2007/03/20(火) 14:08:50ID:???0823NAME IS NULL
2007/03/20(火) 14:53:07ID:???0824NAME IS NULL
2007/03/20(火) 16:00:59ID:???0825NAME IS NULL
2007/03/20(火) 20:59:21ID:???普通にINTかBIGINTでナンバリングしてけばいいと思うんだが。
なんかINSERTとか遅そうだし。
0826NAME IS NULL
2007/03/20(火) 21:38:40ID:???0827NAME IS NULL
2007/03/20(火) 21:45:29ID:???容量なんじゃねーのか？
0828NAME IS NULL
2007/03/20(火) 22:17:25ID:???0829NAME IS NULL
2007/03/21(水) 00:28:57ID:???GUIDって16進で32桁だから16BYTEじゃねーの？
0830NAME IS NULL
2007/03/25(日) 13:41:22ID:???auto incrementを使わずに、
ユニークな値をinsertしたいとかなら、
実はそれなりにいい解だったりしない？>GUID
0831NAME IS NULL
2007/03/25(日) 13:50:48ID:???取り回しが面倒やね
んでもGUIDは生成が重そうだな
どんぐらい性能に差が出るんだろう
0832NAME IS NULL
2007/10/27(土) 22:18:25ID:???って、マジにきかれました。
0833NAME IS NULL
2007/10/27(土) 22:21:50ID:???むかし、４Dの売り込みに来ていたおっさんが言っていた記憶がある
0834NAME IS NULL
2007/10/29(月) 00:47:58ID:???違いは何？
0835NAME IS NULL
2007/10/29(月) 19:56:03ID:???データによっては排他的な項目によるユニーク性を求められる場合もあるので
その場合はユニークインデックスが(複数)必要となる。
極限まで正規化すれば主キーは一つになるのかもしれないが、ジャーナルとかだと全く無意味になる場合もある。
0836NAME IS NULL
2007/10/29(月) 22:04:33ID:???主キーは、Nullを認めない
ユニークインデックスは、Nullを認める
主キーは、一つのテーブル一つ
ユニークインデックスは、複数可能
0837NAME IS NULL
2007/10/29(月) 22:08:52ID:???認めないRDBMSもあると思ったが。
0838NAME IS NULL
2007/10/30(火) 00:40:35ID:???0839NAME IS NULL
2007/10/30(火) 09:09:48ID:???それを実現するための仕掛けがNOT NULLのユニーク索引。
主キー制約といったりする。
0840NAME IS NULL
2007/10/30(火) 10:21:25ID:???主キーは、一つのテーブル一つ
ユニークインデックスは、複数可能
あとは839のいうように
考え方の問題。
0841NAME IS NULL
2007/10/30(火) 22:53:22ID:???SQLServerはたしかnullを1つしか許さなかったと思うけど、
uniqueが強制not nullになるDBMSってのは聞いたことがないなぁ。
0842NAME IS NULL
2007/10/30(火) 22:56:37ID:???NOT NULL
UNIQUE
INDEX
これらは主キーの必要条件だけど
十分条件じゃない。
ってことでいいんじゃない？
違いうんぬんて話だとどうも違和感が。
0843NAME IS NULL
2007/10/30(火) 23:26:47ID:???DB2って・・・
0844NAME IS NULL
2007/10/30(火) 23:32:23ID:???Null一つにしても、OracleとSQL Serverでは、
>>841 の言うように必ずしも同じ扱いではない
主キーは、”制約”で
ユニークインデックスは、索引
一意制約とユニークインデックスの違いは？
各製品によって実装が変わってくる。
作成するときのSQL文が異なるだけで、一意制約を作っても、
バックでユニークインデックスを作成している場合がほとんど
結局は、同じ動きをしたりする。
0845NAME IS NULL
2007/11/05(月) 01:08:44ID:???普通も何も、リレーショナルモデル上で主キーは一組だけだ。
（候補キーは複数ある場合があるけど）
リレーショナルモデルを実装したRDBで、複数組の主キーを定義できる
製品なんてあるのか？
0846NAME IS NULL
2007/11/05(月) 20:31:59ID:???0847NAME IS NULL
2007/11/05(月) 21:18:52ID:???一体今までどういう話してたと思ってんだよ。
振り出しに戻っちゃうじゃん。
0848NAME IS NULL
2007/11/05(月) 22:33:51ID:???最後の１行くらい読んでくれ。
全てを完全正規化テーブルなんてやってらんない現場も有るんよ。
0849NAME IS NULL
2007/11/05(月) 22:47:17ID:???＞製品なんてあるのか？
IBMのDB2とO/Rﾏｯﾊﾟｰ(SDO)はそこらに対応していたな。
あとコレは漏れがIBMに染まっているだけかもしれんが、
主キーもUNIQUEも同じ「制約」だったと思うが。
OracleやSQLServerは違ったのか？
0850NAME IS NULL
2007/11/06(火) 04:12:28ID:???索引としての一意な索引と
制約としての一意制約がある
どうも、この二つが混同していると思われ
主キー制約は、一意制約の内の一つ
一意制約の内の特別なものと考えたら良い
DB2でも、主キー制約は、一つのテーブルに一つしか定義できない
0851NAME IS NULL
2007/11/06(火) 06:56:31ID:???＞DB2でも、主キー制約は、一つのテーブルに一つしか定義できない
DB2/400は複数定義できた。
つーか、PRIMARY KEYと言う指定がない。w
UNIQUEを指定汁！って事らすぃ。
0852NAME IS NULL
2007/11/06(火) 07:58:30ID:???・1列で行を一意に特定できる列 「キー」
・2列以上を組み合わせて行を一意に特定できる列の組 「複合キー」
→表内の「キー」または「複合キー」の中でも、それらを代表する
キーに対する呼称「主キー」
「主キー」と宣言すると、たいていの DBMS はキーとして備えるべき「UNIQUE」「NOT NULL」
を自動的につけてくれる。
その他の「キー」を「キー」としてDBMSに認識させたいのであれば、「UNIQUE」「NOT NULL」
をつけておけばよい。すると、その列がキーとして成り立つよう重複する値を排除したり、
外部キーを使うときにその列または列の組を一側の列の候補として自動的に処理してくれる。
そう考えればどうだろう。
0853NAME IS NULL
2007/11/06(火) 12:57:02ID:???その場合は、
DB2では主キーを定義できない
というのが正しくないですか？
0854NAME IS NULL
2007/11/06(火) 16:23:16ID:???>たしか、４Dって、主キーがなかったような
>むかし、４Dの売り込みに来ていたおっさんが言っていた記憶がある
あんなRDBとはとても言えない不良品を引き合いに出さないでください｡
0855NAME IS NULL
2007/11/06(火) 21:54:19ID:???それは、>>853 の言うとおり、主キーを定義できない（Primary Key制約を作成できない）。
Primary Key制約が実装されていなくて
ユニークインデックスで代用する製品も >>854 のように 稀に存在している。
Not Null ＋ Unique Index で代用することは可能
0856851
2007/11/06(火) 22:40:05ID:???＞DB2では主キーを定義できない
＞というのが正しくないですか？
言葉遊びの領域にあると思うが、古参のAS/400のエンジニアに
「このテーブルの主キーってなんですか？」と質問しても
答えられない人が多いと思う。
比較的マトモ(?)な教育を受けた新人は「このPFに指定されている
UNIQUEキーが主キーです」と答えるとｵﾓ
昔のAS/400のDBは基本的に全てのカラムがNOT NULLでした。
OS/400上で稼動するRDBMSはOSﾈｲﾃｨﾌﾞ駆動と
SQL定義に合わせたOS上で稼動ｴﾝｼﾞﾝと両方使えるので、
主キー（相当）が二つあったり切り替えたりする動作は気にしないなぁ。
どうせ内部的には同じ動作するワケだし。
0857NAME IS NULL
2007/11/06(火) 23:32:56ID:???古くからあるRDBの当時のバージョンにはPRIMARY KEYがなかったり、
別のキーワードがその意味だったりしていた。
その当時でも主キー・候補キーや正規化などの概念はあったから、
それを実現するためにユニークキーを付けるとかやってたと思う。
NULLがデフォルトでNOT NULL制約ができたのもSQL89からで、
以前はNOT NULLが標準のものが多かったように記憶している。
ちなみにCREATE INDEX文はANSI SQLでまだ規格化されてないキーワード。
（すくなくともSQL92時点ではまだだったと思う。）
0858NAME IS NULL
2007/11/08(木) 04:31:41ID:???実際にDBMS上でのPRIMARY KEY定義の話を分けた方がいいかも
テーブル設計で主キーを決めないことってないよね。
ログファイルとかジャーナルみたいに、垂れ流して貯めておくだけのテーブルは別にして。
実際にDBMSでは、製品によっては、PRIMARY KEY制約をサポートしていないものもある。
製品がPRIMARY KEY制約をサポートしていなくても、UNIQUE INDEX＋NOT NULLで代用しているはず。
0859uDVmhUDTEly
2007/11/20(火) 21:47:20ID:???0860fWSqFRnSJkpHZv
2007/11/23(金) 00:24:28ID:???0861uFvlxkBszTpua
2007/11/23(金) 10:58:24ID:???0862zMuZbosNrA
2007/11/23(金) 21:15:22ID:???http://kgnsye.cn/california-dept-of-corporation-htm.html California dept of corporation htm
http://kgnsye.cn/single-family-homes-carlsbad-california.html Single family homes carlsbad california
http://kgnsye.cn/archangel-tattoo-design.html Archangel tattoo design
http://kgnsye.cn/blue-book-pricings-for-atv.html Blue book pricings for atv
0863izuqmUah
2007/11/24(土) 08:14:04ID:???0864lugEIFgFnNtIXdB
2007/11/24(土) 21:54:08ID:???0865NAME IS NULL
2007/12/01(土) 00:47:58ID:???主 キ ー の 張 ら れ て い な い 状 態 ！！！
いや、だからどうしたという事もなく淡々と仕事してますけどね、ﾊﾊﾊ
0866NAME IS NULL
2007/12/01(土) 10:05:36ID:???さらっと「なんで主キーとかインデックスとかないんですかね」って聞いてみて報告よろ～
議論したり啓蒙したりはしなくていいから
0867NAME IS NULL
2007/12/01(土) 13:56:48ID:???既に説明受けている。
最初の設計・構築が素人さんだったそうだ。
運用してから１０年以上で何がどうなっているか社内にも判る人が居ない。
だから、「これ主キーじゃね？」と思ってもどんなデータが入るか予測が付かないから
主キーを張る事すら出来ない。
インデックスというか帳票・画面用のソートキーは付いている程度。
今回俺は金さえ貰えれば良いから議論も啓蒙もしていないｗ
0868NAME IS NULL
2007/12/03(月) 00:11:09ID:FZGtjY5kいや、主キーが必要ないテーブルなら張る必要ないだろ
0869NAME IS NULL
2007/12/03(月) 00:41:38ID:???「主キーが必要ないテーブル」が100個用意されるって
どこの業界のどんな業務が頭に浮かんでんだよｗ
>>867
依頼主が改修に費用が出してんのが不思議だな。金あるなら作り直ししそうなもんだろ。
料金取りっぱぐれないうちに手ぇ引いとけw
0870NAME IS NULL
2007/12/03(月) 21:40:52ID:???何処も受けきれずに断ったらしい。
俺はあと数ヶ月で勤務先変わるから関係ない。
貰う予定期間で予定のモノ貰えばさっさと㌧ずら!!!
0871NAME IS NULL
2007/12/29(土) 01:37:35ID:???もうそういうファイル要らない設計に出来るんだから頭使えよな！ってことだよね
0872NAME IS NULL
2008/02/23(土) 03:31:02ID:???優越付けがたいので主キー設定してません。ｗ
全く問題なし。
0873NAME IS NULL
2008/02/23(土) 21:11:49ID:???優柔不断・・・
0874NAME IS NULL
2008/03/06(木) 02:54:33ID:???総じて全員優秀だと思う。いやマジで。
誰かうちの会社に来てくれないかな・・・。
ちなみにうちの会社、主キーどころか
ExcelとDBの理解していない人が何人もいる。
正規化って食べ物？って言いかねないくらい
レベルが低い。indexは無いし全部可変文字列なんて
当たり前。
言い訳が得意なら、努力しない豚でも生きて
いけるのだなと感じる今日この頃。
0875NAME IS NULL
2008/04/16(水) 14:29:02ID:???あなたのレスどこかで見たなｗ
0876NAME IS NULL
2008/05/06(火) 18:09:19ID:???でもところどころUNIQUEとかNOTNULLが設定されてる（規則性なし）
かんべんしてくれ
0877NAME IS NULL
2008/05/08(木) 22:05:45ID:???日時の主キーはあるぞ
0878NAME IS NULL
2008/05/11(日) 08:31:48ID:???0879NAME IS NULL
2008/08/21(木) 02:59:39ID:???進研模試の偏差値でいうと２ちゃんねるのニュース速報がおよそ45、民放地上波の報道ステーションが約40、
ニュース速報＋は35程度の読者を想定しています。
0880NAME IS NULL
2008/08/23(土) 23:35:13ID:???0881NAME IS NULL
2008/08/26(火) 17:41:50ID:???個人的には内部にIDを別に作るほうがいいと思うんだけど…。
名称が欲しいだけなのに3つも4つもWHERE句に書かないと取れないのがめんどくせえ。
＃今検索したらそういうのは「サロゲートキー」というんだな。
＃初めて知ったｗ
0882NAME IS NULL
2008/08/26(火) 21:10:13ID:???0883NAME IS NULL
2008/08/26(火) 21:55:12ID:???国の人間も同じ事を考えてるよ。
名前？ 生年月日？ 住所？ 性別？ ざけんな！
こちとら年金督促状を送りたいだけなんだよ！
生まれたらすぐに一意タグでも埋めろよ！
ってな（´・ω・`）
0884NAME IS NULL
2008/08/26(火) 22:33:07ID:???２ちゃんねらーが潔癖症なくらい身元がばれるのを恐れてるようなもん。
0885NAME IS NULL
2008/08/27(水) 21:17:28ID:???国がいやがるのよ。国を支えていると言い張る馬鹿な奴らが。
自分たちと取り巻きの素行がばれるのをめっちゃ嫌がっている。
0886NAME IS NULL
2008/08/28(木) 11:47:20ID:???0887NAME IS NULL
2008/09/05(金) 21:14:06ID:Aklfn9i/0888NAME IS NULL
2008/09/05(金) 21:18:35ID:+fyrMg5zｼｭｯｼｭｯしながら
0889NAME IS NULL
2008/09/05(金) 22:38:09ID:???辞めたいです。
0890NAME IS NULL
2008/09/05(金) 23:38:15ID:???俺もたまに見る
特定のDBの特定のバージョンまでに限って
GROUP BY使った方が速かった、らしいが……
(というか、そのDBのdistinct使った時の実行計画がアフォすぐるシロモノだったようだ)
何のDBだったかは忘れた
0891NAME IS NULL
2008/09/05(金) 23:51:51ID:???でも、一意性制約をユニークインデックスの上乗せして作るより、
ユニークインデックスが一つあれば良いかな。
運用側の意見としては。
あ、もちろんユニークインデックスが無いテーブルを作れとゆう話は、
打ち合わせの時点で私は却下しますけどね。
0892NAME IS NULL
2008/09/06(土) 06:40:03ID:???distinct なんて単なるシンタックスシュガー
group by を知っていれば distinct は不要だが逆は言えん
0893NAME IS NULL
2008/09/06(土) 07:01:36ID:???同意。
0894NAME IS NULL
2008/09/06(土) 07:14:47ID:???「主」キーってのは観念的なものだからな。技術的にはキーであればいいわけだ。
0895NAME IS NULL
2008/09/23(火) 22:24:55ID:???あえてPRIMARY KEY作らない場合もあるよ。と言ってみるテスト
0896NAME IS NULL
2008/09/23(火) 22:39:19ID:???0897NAME IS NULL
2008/09/23(火) 23:00:27ID:???やってくれると思うがな。
できないDBMSってどれ？
0898NAME IS NULL
2008/09/24(水) 00:57:33ID:???キーだのインデックスがあると無条件に使っちゃうって、どんだけバカなのよw
0899NAME IS NULL
2008/09/24(水) 20:08:04ID:???4th Dimension
0900NAME IS NULL
2008/10/10(金) 21:47:18ID:???……いま面倒見てる人事システムがそうなんだが。
最初見たときは結構ビックリしたが、そのうち慣れてしまった。
あ、さすがに主キーはちゃんとあったよ。
0901NAME IS NULL
2008/10/11(土) 00:12:41ID:???よう俺
てゆーか外部キー使ってるとこってほとんど見たことない
多分俺はろくな現場を回ってこなかったのだろうなorz
# そこ、現場よりお前が(ry)って突っ込みはやめてくれろ
0902NAME IS NULL
2008/10/11(土) 10:15:15ID:???見たことあるって言うか自分が設計したものを除いて外部キーがあるテーブルを
ほとんどどころか全く見たことがない。
…というオレも外部キーの有用性が分かったのは数年前なんだけどね。
0903NAME IS NULL
2008/10/11(土) 15:47:35ID:???0904NAME IS NULL
2008/10/12(日) 08:44:01ID:???だからつけた方がいいといえばいい。
0905NAME IS NULL
2008/10/12(日) 11:33:23ID:???テーブルの削除のパフォーマンスから索引の要否は判断できると思うが。
そのオーバーヘッドすらも許容できなくて、あえて制約を付加しない設計も
ありはするね。
0906NAME IS NULL
2008/11/06(木) 23:40:53ID:oi3DlEtx0907NAME IS NULL
2008/11/15(土) 00:19:02ID:???いわば保険みたいなもん
0908NAME IS NULL
2009/02/06(金) 21:14:13ID:CAltmj0N0909NAME IS NULL
2009/02/06(金) 22:50:32ID:???0910NAME IS NULL
2009/02/07(土) 06:28:53ID:???0911NAME IS NULL
2009/02/07(土) 07:45:28ID:???0912NAME IS NULL
2009/02/07(土) 07:57:33ID:???0913NAME IS NULL
2009/02/24(火) 11:42:57ID:???余儀なくされるのはどんな場合でしょうか？
0914NAME IS NULL
2009/02/24(火) 23:25:31ID:???運用中との話だから仕様追加ではないかと。
0915NAME IS NULL
2009/02/25(水) 05:44:09ID:???事業部制の導入などでは、大量発生する？
0916NAME IS NULL
2009/07/02(木) 21:52:04ID:???0917NAME IS NULL
2009/12/06(日) 16:18:54ID:???主キーを必ず設定しなければならない決まりはないからね。
0918NAME IS NULL
2009/12/07(月) 15:37:06ID:???重複排除以外に積極的(RDBとして本質的?)な意味はないからね。
0919NAME IS NULL
2009/12/08(火) 22:58:44ID:???0920NAME IS NULL
2010/02/15(月) 03:22:15ID:???0921NAME IS NULL
2010/02/19(金) 23:24:01ID:???は七年ぶりに反省するべき
0922NAME IS NULL
2010/06/08(火) 05:32:35ID:???0923NAME IS NULL
2011/03/24(木) 07:39:09.09ID:GoXeNBk+どうでもよいことなのだ。
0924NAME IS NULL
2011/03/26(土) 12:33:57.03ID:ndRK6ZD00925NAME IS NULL
2011/04/09(土) 19:34:48.52ID:GHq/rX2P>924
アクセスは適当に付与してくれるじゃないか。
0926NAME IS NULL
2011/04/14(木) 21:28:13.19ID:F/sxykTL0927NAME IS NULL
2011/04/23(土) 21:29:11.66ID:???定義されているものは、ユニークの保証がない。
テーブル定義はカオス、、、(-_-;)
そんなシステムのメンテをしたことがあるな。
0928NAME IS NULL
2011/04/25(月) 22:57:53.14ID:???0929NAME IS NULL
2011/04/27(水) 14:43:22.06ID:???あまりにもひどい既設テーブルだらけだったので､知らんぷりして悉く自動採番つきの主キーを定義したフィールドを仕込んだことがあるw
0930NAME IS NULL
2011/04/27(水) 20:25:50.41ID:???0931NAME IS NULL
2011/04/28(木) 13:18:56.16ID:???OracleはROWIDがあるのでその心配はないのだが｡
0932NAME IS NULL
2011/04/28(木) 17:53:55.38ID:???Primary Key 指定が規格に入ったのは、
89年からだと思うが、それ以後の製品？
0933NAME IS NULL
2011/05/14(土) 11:02:39.85ID:???確かそんな話をDBmagaginで読んだような記憶があるな。
基本主キーなりuniqueなキーは必要だと思うけど
よそから貰ってくるマスターデータなどは、
キャッシュされてfullscanだから無くても支障は無かったな。
主キーに従属するindexのコストを考えると
一意の値が保障されている通貨換算レートなどは不要だと思っている。
0934NAME IS NULL
2011/07/21(木) 23:28:46.62ID:uYI4xppD只今勉強中です。
0935NAME IS NULL
2011/07/30(土) 13:02:19.71ID:???一般的には付けたほうがいい。
HACKしたわけではないけど列指向データベースとかは余り有益ではないかも。
0936NAME IS NULL
2011/08/21(日) 14:12:10.62ID:???今、改修してるシステムのDBは9割以上のテーブルに主キーが設定されていません。
その代わり、全てのテーブルにインデックスは設定されています。
これは主キーを設定してもしなくても同じなのでしょうか。
0937NAME IS NULL
2011/08/21(日) 18:05:16.45ID:???0938NAME IS NULL
2011/08/21(日) 20:42:39.03ID:22rNpbGh同じではないけど、問題ないなら主キーの設定はしなくてもいい。
そもそも、主キーの設定は必須ではないからね。
0939NAME IS NULL
2011/08/21(日) 21:35:44.80ID:???ほとんどのDBMS実装では、主キー=Not NULL制約+ユニークインデックスだと思っていいかと
ユニークでないインデックスなら、そのテーブルは行を特定できない可能性がある
それで問題ないなら主キーなくてもいいんじゃね
0940NAME IS NULL
2011/09/08(木) 18:24:23.93ID:???全カラムでユニークであることは維持しないと。
完全に重複してるデータがどんどん入ってしまうと、さすがに後の処理が厄介だね。
データ設計段階で冗長なカラムを付加してでも主キーを設定してデータベースシステムに任せるか、
すべてプログラム側で一意性を維持させるかということかな。
0941NAME IS NULL
2011/09/13(火) 16:34:44.58ID:YBAEI4zg単なるインデックス+UNIQUE+NOT NULL制約のためだけに使ってる感じ
そういうのって、どうなんだろう
0942NAME IS NULL
2011/09/13(火) 19:04:50.73ID:???0943NAME IS NULL
2011/09/14(水) 00:01:37.44ID:???汎用的なスキーマにするにはそうせざるを得ないな。
ERPとかそうなってるだろ。
無論論理設計段階で要件がかちっと決められる場合はそうではないけど、
ソーシャルとかで大量のクエリを捌かないとならないばあいはあえて参照整合性は付けないかな。遅いから。
0944NAME IS NULL
2011/09/14(水) 01:12:47.01ID:???結合すると、ON句を指定しないでもその参照制約を用いての自然な外部結合結果を
返してくれる、みたいなメリットがあったら、もっとみんな使うんじゃないのかなぁ、とか
妄想することがあるんだが、そういう実装ってあるのかな?
0945NAME IS NULL
2011/09/14(水) 01:36:56.36ID:???0946NAME IS NULL
2011/09/15(木) 13:20:39.23ID:???0947NAME IS NULL
2011/09/21(水) 14:54:55.64ID:???見たことがある人は手をあげて
0948NAME IS NULL
2011/09/21(水) 15:30:00.08ID:???インデックス名をPK_<TABLENAME>_1とかしたら
一瞬頭をひねるだろう。
フハハハ
0949NAME IS NULL
2011/09/21(水) 17:09:25.64ID:???Oracleでは設定できんのだが、できる実装があるのか?
0950NAME IS NULL
2011/10/12(水) 19:56:15.22ID:???CONSTRAINT <TABLE名> PRIMARY KEY (<KEY1>,<KEY2>,...) USING INDEX
0951NAME IS NULL
2011/10/12(水) 19:58:18.98ID:???×<TABLE名>
0952NAME IS NULL
2011/10/12(水) 21:19:50.02ID:???0953NAME IS NULL
2011/10/12(水) 22:00:40.10ID:???PKとは唯一無二のカラム（例えば顧客マスタの「顧客コード」）で、
所謂複数列によるPKとやらはユニークキーという認識で合っているのか？
0954NAME IS NULL
2011/10/12(水) 22:32:47.19ID:???RDBに限っていうと、列が単一でも、複数でもキー候補となりうる。
列またはその集合(複数の列)を指定するとテーブルの中の組を
一意に識別できるならばその列またはその集合はキー候補です。
キー候補のうちで、任意のものをプライマリーキーに指定できます。
任意のものだから、どれでもよい。
プライマリーキーは多くの場合、テーブル生成時に指定することが
許されているので特別な何かと思いがちですが、データベースシステムが
常にプライマリーキーの存在に注意して動作してくれるという点を除けば
論理的には他のキー候補と何等差はありません。
0955NAME IS NULL
2011/10/13(木) 06:54:27.19ID:???教科書的な答えなら、このスレの >>1 - >>150 くらいの中で出尽くしてる
のではないか。プライマリーキーに関する議論としては、ウェブやブログでは
ほとんど見つけることのできない情報源になっていると思う。
0956NAME IS NULL
2011/10/14(金) 20:40:04.71ID:???キャシエ
0957NAME IS NULL
2011/11/23(水) 01:47:14.60ID:???レコード数が１年で１万行程度だったら主キーとかインデックスとかつけないな。
理由は考えるのがめんどくせーから。
シンプルに、よりシンプルに！がモットーです。
0958NAME IS NULL
2011/11/23(水) 12:55:37.48ID:???0959NAME IS NULL
2011/11/23(水) 15:20:08.35ID:???全く同じ行が複数ヒットするんだが、別々の注文なのか、１つの注文が不具合で２行になったのか。
インサート日は時間まで無くて困る。
0960NAME IS NULL
2011/11/23(水) 23:34:14.47ID:???0961NAME IS NULL
2011/11/23(水) 23:35:18.86ID:???0962NAME IS NULL
2011/11/24(木) 08:00:38.45ID:???数千年・・・
0963NAME IS NULL
2011/11/25(金) 04:36:40.14ID:???0964NAME IS NULL
2011/12/02(金) 21:45:52.90ID:kohrfEHAつけとかないと困る
0965NAME IS NULL
2011/12/03(土) 06:32:22.42ID:???必要のない **ID といった項目が無闇と多くなる。
0966NAME IS NULL
2011/12/03(土) 07:02:20.99ID:???0967NAME IS NULL
2011/12/04(日) 17:32:35.30ID:???0968NAME IS NULL
2011/12/04(日) 19:03:07.68ID:???0969NAME IS NULL
2011/12/05(月) 07:52:19.83ID:???0970NAME IS NULL
2011/12/05(月) 19:21:50.51ID:???っていんたいんだろう
0971NAME IS NULL
2011/12/05(月) 22:39:00.10ID:???設計中に全フィールド足しても主キーにならないテーブルなんてものが出てきてしまったら普通は
設計あるいはモデリングの失敗だから、そこで立ち返って検討しなおすべきであって、勝手なキーを
くっつけて「主キーができたから大丈夫」なんて済ませるべきじゃないってことだろう。
例えば>>959の例で、このテーブルに何かユニークなキーを追加したところでほとんど何の
解決にもならんし。
0972NAME IS NULL
2011/12/07(水) 22:00:19.82ID:???（サロゲートキーのどの行でもいいけど、とにかくそのデータから1行だけ消したいって場合もある）
0973NAME IS NULL
2011/12/07(水) 23:14:12.91ID:???0974NAME IS NULL
2011/12/07(水) 23:16:15.62ID:???そういうのは明示的に件数を持とうよ。
0975NAME IS NULL
2011/12/07(水) 23:27:45.89ID:???DB設計をしっかりやればおｋ
それを適当にやってたらクズ
0976NAME IS NULL
2011/12/07(水) 23:55:18.93ID:???俺DWHの開発してたことあるけどネティーザって主キー設定しても
実際には主キーが効かないっていうイミフな仕組みだったな
データ突っ込むときに自分で気をつけろってマヌアルに書いてあった
あれは二度とやりたくない
0977NAME IS NULL
2011/12/12(月) 23:26:01.17ID:???リーダーに主キーを消されたことあったな。
そのどうデータが入るかわからないテーブルで
バグ出したら、こっちの責任になるんだが。。
0978NAME IS NULL
2011/12/13(火) 05:11:19.30ID:???0979NAME IS NULL
2011/12/13(火) 06:03:07.92ID:???最初に集合ありき。それを見つめて制約がでてくる。
そういう帰納論理的な考え方も魅力はあるよ。
0980NAME IS NULL
2011/12/13(火) 22:10:14.24ID:???0981NAME IS NULL
2011/12/16(金) 02:18:31.93ID:???0982NAME IS NULL
2011/12/16(金) 07:59:53.30ID:???彼女はいつもきちんとしていて，忘れ物などあろうはずもない．
ただ微かな残り香だけがのこっていた．
朝食の用意をしよう．
一人分だからといきなりの手抜きは，なんだかあのひとに申し訳ないように思えた．
いつものメニューでいこう．
ふと食卓の紙片に目がいった．小ぶりの花瓶に隠れるように置いてある紙片を
取り上げたとたんに抑えていた涙がこぼれる．
一言「すき」とだけ書いたあのひとは一体，どんな思いでこれを書いたのだろう．
紙片を握りしめ，もういちど視線をもどすとそこにはいつものテーブル．
もうそこに「すき」と書いた紙片はない．「すき」はもうテーブルにないのだ．
シュキーのないテーブルとはまさにこのことだ．デービーってほんとに素晴らしいものですね．
0983NAME IS NULL
2011/12/16(金) 09:59:34.65ID:???0984NAME IS NULL
2011/12/16(金) 15:34:03.97ID:???レス数が950を超えています。1000を超えると書き込みができなくなります。