頼むから正規化しろよ
レス数が950を超えています。1000を超えると書き込みができなくなります。
0001パフォチュー
03/08/12 21:13ID:uJybnGokまるっきりDBが正規化されてねーじゃんか！
｢冗長化したほうがパフォーマンスがいい｣だと？
ハッシュ・ジョインくらい勉強しろ！
論理設計からやり直せ！その前に自腹でベンダーの講習受けて来い！
だからPJに途中参加するのは嫌なんだよ(鬱
0002名無しさん＠お腹いっぱい。
03/08/12 21:22ID:uJybnGok0003禿道
03/08/12 21:40ID:ClWPxTztよくわからんが取り敢えず同意
0004名無しさん＠お腹いっぱい。
03/08/12 21:59ID:???システムの中枢部分をな〜んでいい加減に設計するの？
プログラマは苦労する罠
0005禿道
03/08/12 22:25ID:ClWPxTzt嘘じゃ無い。
否定できないお前もDQN。
更新の頻度にもよるが書き込み時間を気にしないなら、データの冗長化は
データアクセス時間を短縮することができる。
冗長データが手入力じゃ無いなら、許せ。
俺は手入力を相手に毎日格闘している。
0006名無しさん＠お腹いっぱい。
03/08/12 22:52ID:uJybnGokはぁ？冗長化なんか今時、推奨するところなんてあるの？
PGは複雑になるし、保守性悪いわ、柔軟性はないわ、
テーブルは無駄に巨大化してくわ。。。メリットなんざ思いつかんね。
だいたい何の為のハッシュ・ジョインなんだよ。
つーか、まず正規化してから冗長化など検討すべきだろ。
ロクでもない設計して言い訳的に
｢冗長化したほうがパフォーマンスがいい｣
なんて言われたら、そりゃキレるよ。
0007名無しさん＠お腹いっぱい。
03/08/12 23:09ID:FNgPW25+かなり複雑怪奇なSQL発行しまくり。
副照会か6階層くらいあってたり、仮想領域を3つくらい使ってたり、
もうめちゃくちゃでわけわからん。
作った本人の漏れでさえ、何やってるかわかんなくなる。
まじこんなDB腐ってる。
0008名無しさん＠お腹いっぱい。
03/08/12 23:23ID:???0009名無しさん＠お腹いっぱい。
03/08/12 23:36ID:???しかもHINTも使えないからチューニングのしようがない。
んで、制御部隊（設計者）にパフォーマンス悪いと報告すると
逆ギレされる。
一度CREATE VIEWのDDLを拝見したいもんだ。
0010名無しさん＠お腹いっぱい。
03/08/13 00:05ID:???チューニングの基本はSQLの見直しだとは思いますけど、
やはり正規化してないと整合性がとれなくなったりして
思わぬバグを誘発する恐れもありますし。
以前、｢正規化できないんだよ。このシステムは｣なんて平然と
言ってのけるSEがいました。
それでよくBIG ITとかよく宣伝してるなぁと感心しました。
0011名無しさん＠お腹いっぱい。
03/08/13 00:10ID:???でっかくって非定形処理の多いデータウェアハウス→冗長化
どっちにしても、色々チューニングして一番ｳﾏｰな状態に
するのはめんどうなのれすよ。
0012あぼーん
NGNG0013クラッシャー堺
03/08/13 15:00ID:JkUi5yos0014名無しさん＠お腹いっぱい。
03/08/13 18:34ID:F+w598Ig0015あぼーん
NGNG0016名無しさん＠お腹いっぱい。
03/08/13 19:46ID:???冗長化もまだ許せる。
だけど、だけど・・・
横 に 長 い テ ー ブ ル を 作 る の だ け は 勘 弁 を・・・
数量1,2,3・・・10ってなんだよ・・・
0017名無しさん＠お腹いっぱい。
03/08/14 02:01ID:???さらに結合いっぱい、書き込みいっぱい、I/Oもメモリもいっぱいいっぱい。
帰りたかった。
0018名無しさん＠お腹いっぱい。
03/08/14 09:05ID:???その系統で数量128とか見て眩暈を起こしました。
数量じゃないけどさ・・・。
0019山崎 渉
03/08/15 21:58ID:???│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
0020山崎 渉
03/08/15 22:49ID:???│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
0021名無しさん＠お腹いっぱい。
03/08/16 03:15ID:Nt2klYxEそれを知らずに堂々とコンサルタントするF通の馬鹿さ加減には
うんざ〜り。
一生、SQLは外だしして、クライアント・カーソルを用いて
DBサーバーを苦労させてね！
0022名無しさん＠お腹いっぱい。
03/08/16 03:43ID:???日本のベンダーは開発（設計）能力無いねぇ。
ちっとは頑張って画期的なDBMSでも作ってね（無理でも）
ゲイツより茂雄が好きな日本人より。
0023名無しさん＠お腹いっぱい。
03/08/16 03:50ID:???>ゲイツより茂雄が好きな日本人より。
それ、わかりづらい！
0024あぼーん
NGNG0025名無しさん＠お腹いっぱい。
03/08/16 13:17ID:t/5MsxPF正規化できない場合があるよ。
客が主キー制約をどうしても認めない場合。
あと、テーブル数で料金が決まってる場合とか。
客はいろんな可能性を後へ残しておきたいんだろうけどな。
技術的にも論理削除がやりやすいとか言う、逃げもある。
元々の設計が悪いとか、レビューが悪いとかいうのもあるだろうけど、
俺が思うには、経験を持った人間がポリシーを持って対処するしかない。
そうして初めて正規化のメリットがデメリットを上回る。
この損益分岐点は実は結構高いところにあるのだ。
0026名無しさん＠お腹いっぱい。
03/08/16 13:20ID:???あと、下手なＤＢにしといたほうが、メンテとか仕様変更で金を取れるというのも
あるかもしれんな。 人月で金払ってるんだからこうなるわけだ。
0027名無しさん＠お腹いっぱい。
03/08/16 17:33ID:???select * from viewをexplainで見てみたらいいよ。
DQNな実行プランが出てくるんじゃねぇか？
0028名無しさん＠お腹いっぱい。
03/08/17 20:45ID:+oqRYfoP実行計画採取のGRANTさえ無いユーザじゃない？
うちはそうだよ。
0029名無しさん＠お腹いっぱい。
03/08/23 01:36ID:???・大量で変化しにくいデータの検索の高速性が求められる
・ビジネスルールを正確に立てられない
場合は冗長化もアリかと。
0030名無しさん＠お腹いっぱい。
03/08/23 02:24ID:1yygtNzF。。。。すまん
0031名無しさん＠お腹いっぱい。
03/08/23 17:00ID:???もっとすごいの見たことがあるぞ。
３次元配列になっているテーブルをメンテしたことがある。
といってもDB側が３次元になっているわけではなく、COBOLのCOPY句が
３次元展開してあってそこで処理するという罠。（一応、DBの項目とCOPY句の項目
定義の並び順は一致していたけど、数えるのが大変）
何のためのRDBなんだか・・・・。
あと、別のところではもっとすごいことやってて、キーと4096桁のでっかい固定長がいくつか
あるテーブルを見たことがある。
これもCOBOLのCOPY句で分解するというもの。（要はDB上では項目は連結していて、
プログラム上で初めて分解される。）
INIT VALUE に X'40404040F0F0F0F0F0F0F040404040・・・・'なんてのがつづいて
いたのを見た時には、正直絶句。はやく撤退してよかった。
ちなみに、両方ともメーカー主導のデスマーチプロジェクトだったがな。
0032名無しさん＠お腹いっぱい。
03/08/24 12:17ID:???わざわざCOBOLでOracle使ってマッチング処理をCOBOLで書いたそうだ。
正規化以前にSELECTを身に付けろと小(ry
0033名無しさん＠お腹いっぱい。
03/08/24 16:38ID:???スレの流れで何を冗長化してるのかは分かったけど。
003431
03/08/24 20:30ID:???ホスト系でCOBOLで処理してまーす、てなところはそういう所多いね。
あと多いのが自前でアクセスルーチン作ってるとこ。
昔はDBの性能が悪かったのと、リバインドに結構時間がかかっていたからだと
おもうんだけど、直にSQL発行できないんですごいいらつく。
どちらも遥か昔のSQLのアクセスプランがメタクソだったころの名残だろう。
パフォーマンス稼ぎに主表にカーソル作ってループさせ、主表のfetchのところで
さらに副表のカーソル作ってカーソルENDになるまでループさせたことはあるよ。
（当時JOINはむちゃくちゃ遅かった。）
と は い っ て も １ ０ 年 く ら い 前 の 話 だ け ど な 。
そういや、今でも汎用機のRDBってバインドとかするの？
>>33
たぶん一般用語だとおもう。漏れは使ったことがない。
（漏れは説明資料とかでは項目の二重持ちとか書いたな）
普通は非正規化とか非正規形かいってかっこつける。
ほ ん と は か こ わ る い け ど な。
0035名無しさん＠お腹いっぱい。
03/08/24 22:08ID:netEchZjあっ！それ知ってるかも。SQLをまったく知らないCOBOLer集団が
Pro*COBOLで作ったデイリーバッチが４日かかったとか。
○○証券の勘定系ですけど。。
0036名無しさん＠お腹いっぱい。
03/08/24 22:27ID:???カヴァリングインデックスと、それが適用されるカヴァードクエリがある。
普通、売上データには商品名を入れずに商品コードだけを格納するでしょ？
商品コードだけでなく、商品名も格納してしまえば、商品マスタを
参照しなくて済むようになる。まぁ、これは誰でも分かるね。
さらに、この商品名にインデックスを張るとパフォーマンスが良くなる。
抽出条件として使用しない商品名にインデックス張って意味があるのかって？
あるんですよ。インデックスを貼っているとその内容はインデックス領域に
格納されるから、実データノードを参照せずに値が取り出せるようになる。
つまり、テーブル定義の冗長化とあわせて、インデックス作成でも
抽出条件だけでなく参照頻度の高い項目にもインデックス張ると
パフォーマンスが上がります。たとえば、売上データをもとに
商品コード、商品名の一覧を表示して、選択した商品の詳細な履歴を
表示するような場合、最初の一覧表示は売上データの
インデックス領域だけで処理を完了できるようになるわけね。
抽出条件だけにこだわらず、高頻度参照項目にもインデックスを張る。
これがカヴァリングインデックス。Select句の項目すべてにインデックスが
張ってありインデックス領域だけで処理完了できるクエリを
カヴァードクエリと言う。基幹系システムに情報系システムを追加するような
案件も増えてきているし、正規化ばかりにこだわってちゃだめだよ。
基幹系ならともかく、情報系のパフォーマンスを維持するためには
冗長化なんて常識ですね。
0037名無しさん＠お腹いっぱい。
03/08/24 22:42ID:???独り言はこちらへどうぞ。
http://life.2ch.net/yume/
003831
03/08/24 22:43ID:???それって冗長化っていうのか？ただのパフォチューだとおもうんだが。
あと、SQLServerはくわしくないけど、パッと見、商品コードの検索のパフォーマンスと
更新系のパフォーマンスが落ちないないかい？（あっ、インデックスは別々にとるのか）
おちなきゃたいしたもんだな。いや、知らないんで聞いているだけなんだけど。
それと、SQLServer限定でかまわないんで、非正規化してパフォーマンスあがるってどんなの？
実はつぎの仕事でこいつ使うんだが、いままでつかってたイビム様のDBと結構勝手が違うんで
困っています。
0039名無しさん＠お腹いっぱい。
03/08/25 01:20ID:???言わんとしてる事は分かるけど、>35以前で出てる例をそれと同列に語るのはどうかと。
0040名無しさん＠お腹いっぱい。
03/08/25 02:56ID:a7wMPlxrインデックス厨
0041名無しさん＠お腹いっぱい。
03/08/25 19:47ID:cO3nWzqK0042
03/08/25 20:24ID:bIGup91dすげぇ。
俺もその発想にはいたらなかった。
0043名無しさん＠お腹いっぱい。
03/08/25 22:42ID:cW9F7TKX>あがるってどんなの?
【メリット】
どのRDBでもそうだが、一般的に結合する必要が無いからその分の
オーバヘッドがかからない。
でも個人的に一昔前ならいざ知らず、最近ではハードスペックも
ずいぶん上がっているし、OLTPではそれほど大差無いっすよ。
【以下デメリット】
ましてや保守性まで捨ててまで冗長化設計する必要はないと思う。
冗長化するとOLTPでは小さなメリットはあるかもしれんけど、
重複データを多数保持するから、整合性を保つ為にアプリケーションで
コントロールするには限界あるからTRIGGERで泣く泣く対応したり。
結局バッチなどでSQL-LoaderやらOSQLやらに頼って、
24時間サービスも出来なくなるし、バッチに時間がかかりすぎて、
サーバーメンテナンスなど時間が制限されたり。
最近はイテレート型開発などがメジャーだし、
正規化しとかないと後で項目追加とかになったらそれのコストも
かかるよね。
（まだまだ思いつく。。。。）
とりあえず第三正規化ぐらいまでやってみて、
｢どうしても｣となったとき冗長化を検討してみては？
0044名無しさん＠お腹いっぱい。
03/08/26 00:03ID:JjcaBwgp0045ヶ ◆/iQf.Br2tM
03/08/26 00:34ID:/cqp0IvRデータ自体正規化されていない場合余計な労力を使って
正規化しようとしても無理。
データが云々じゃなくてデータの入力出力他取り扱いに正規化の概念が
そもそもない場合どうしようもない。
ＳＥがどうこうじゃなくってこういうのを納得させるのが不可能な場合も
かなりあるんだよね。
0046名無しさん＠お腹いっぱい。
03/08/26 02:24ID:???そういうことを「メリット」って言うようでは
もまいは、ハッキリいってレベル低い。
それはメリットでも何でもない。
単にあきらめているだけだろう。
0047名無しさん＠お腹いっぱい。
03/08/26 07:17ID:YHYrBqtjなんでもかんでも正規化すればいいってもんじゃないってのは
わかりきってるわけだが、メリットというまとめ方をするとこれまた
なんか実情に合わない気がするわけだ。
0048名無しさん＠お腹いっぱい。
03/08/26 07:36ID:???確定させることが必要な
（マスタデータ変更で、過去の確定データも変更されたらマズイ場合に）
トランザクション系のテーブルに対して正規化崩しを使う。
それ以外は、もちろん正規化が基本。
パフォーマンスというが、開発、保守（リカバリ）、拡張を含めた
トータル的な視点からは、きちんと正規化されたモデルの方が低コストである。
0049名無しさん＠お腹いっぱい。
03/08/26 08:00ID:???そりは非正規化じゃなくて、まっとうな設計だとおもう。
マスタと実績はそもそも意味が違うからね。
0050名無しさん＠お腹いっぱい。
03/08/26 10:00ID:YHYrBqtjすべからく正解。
0051名無しさん＠お腹いっぱい。
03/08/26 11:23ID:n0gKu5D6そうね、実行時の速さだけでなく、>>48で言っているように、
開発、保守、拡張時のパフォーマンスも考慮にいれないとイケナイ。
00521
03/08/26 23:05ID:pJNYwhmR人の意見に反論するのは結構ですが、同時に持論も書いてくれると
ありがたい。
0053名無しさん＠お腹いっぱい。
03/08/27 00:12ID:???たとえば担当者コード 10番の山田さんが りんごを販売した売上データに
担当者コード 10 だけでなく、担当者名も格納するということだよね。
あとで、担当者マスタの 10番を 佐藤さんにされちゃった場合、
佐藤さんが りんごを販売したことになっちゃうから。
上記のことが問題になるようなシステムでは、販売時のスナップショットを
とるのが必要要件なのだから、(事後参照保証がない)担当者名を格納するのは
あたりまえで、それを格納したとしても正規化を崩しているとは言わない。
(「そのときの情報を落としておきたい」というのが要件なんだからさ。)
0054あぼーん
NGNG0055名無しさん＠お腹いっぱい。
03/08/27 01:44ID:???そういう要件の情報がなく、いきなりDBモデルを
みたら正規化崩しに見えるんじゃない？
逆にいうと、そういう要件（確定データ保存）
でもないのに上記と同じモデルを設計すると、
正規化崩しとなってしまうわけかな？
煽りじゃないよ。
0056ヶ ◆/iQf.Br2tM
03/08/27 18:03ID:jm41G9Nmなんというか，既にデータが沢山あって正規化されていないシステムで
運用されていた場合には
・正規化のためにデータを解析して整理する
・運用側の教育（とりわけデータの入出力について）
がきわめて困難であり運用の停止期間・更新期間内に完了できない
ことも多々ありますです。
こういうケースで無理に正規化を推進すると結局のところデータ処理担当者
がデータ入力の『やり易さ』が低下するので『使いにくい』システムになってしまう
のです。
いくつか実例があるのですが 一番簡単な一例として某社の
給与計算システムの社員テーブル。
社員番号,氏名,郵便番号,市町村コード,住所,社宅区分…
社宅区分＝１：社宅居住者なので給与から家賃を差し引く
社宅区分＝０：社宅居住者ではない
さて完全に正規化するとすれば 住所で社宅区分は一意になるので
(特定の住所が社宅である＝社宅区分は住所で一意になる)住所マスタ
か何か作ればそれは達成できる。
社員マスタ
社員番号,氏名,住所コード…
住所マスタ
住所コード 郵便番号,市町村コード,住所,社宅区分…
とまあそうすることは可能だが面倒なためそこまではしないことが多い。
さらに夫婦両方とも社員で社宅に住んでいる場合どちらか片方からだけ
家賃を引くようにしないといけないので旦那の方を 社宅区分１
奥さんを０に設定。などデータだけでは予測がつかない処理もあるので
注意だ。
005746
03/08/27 19:58ID:???あのな、「無理」とか「どうしようもない」なんていうのが「メリット」か？
普通「非正規化のメリット」を書くなら「非正規化をすると、こういう良いことがある」ってなことを
書くもんじゃないのか？>>45はメリットでも何でもなく、努力の放棄っていうわけだ。
だから「レベルが低い」って書いたんだよ。俺のカキコは反論でも何でもない。
言葉の誤用を指摘しているだけだ。メリットって言葉の定義域から考え直せ。
ついでにお望みのようだから俺の持論も書いてやる。
・徹底的に正規化しろ！
・わざわざ非正規形に戻さなければならないような後戻り工程を作るな！
・ハードが貧弱だったときの常識を今更持ち出すな！
だ。10年以上DOAやってるがこれで困ったことは一度もない。
むしろ非正規形にしてしまった結果、数年後に足を引っ張る方が多い。
レコード件数も数100万件は普通だ。億単位も何度もやってる。
ありがたがってくれ。
ついでにな、「使いやすいデータアクセス」と「正規化されたデータ構造」は両立できるぞ。
正規化されていないコード体系をどう扱うのかなんてのは、普通に出てくる話だ。
ちゃんと正規化できるよ。ユーザインターフェースとしてのデータ構造をそのまま
DBに入れようとするから駄目なんだ。
＞ 社宅区分＝１：社宅居住者なので給与から家賃を差し引く
・社宅居住者である
・給与から家賃を差し引く
既にふたつの内容が混ざっているわけだが？
しかも、「社宅居住者である」はドメインの定義域に入るかどうかというデータ構造の
話だが、「給与から家賃を差し引く」は、ビジネスルールであって、既に変動要因だし
アプリケーションの仕様だぞ。
こういう混同をしているから、「メリット」と「あきらめ」を混ぜてしまうんだ。
もっと、がんがれ！
0058ヶ ◆/iQf.Br2tM
03/08/28 12:05ID:Q75JHJjhまあただ実際のところ1から全て自分で設計できるような恵まれた条件でないことも
ありますから。
数十年前のアプリケーションの更新をする。アプリケーションの仕様書と
実際に動いている状態がなんだか違う。どうやら使い勝手がよいように改造
をしてあるらしい。
そういうときは実際に動いているデータを観察して運用担当者に改造個所を
聞き出しながら作っていく。ただちょこちょこと改造を加えた結果聞き取り調査
の際には出てこなかった改造がテスト時のエラーで見つかることもある。
まあなんというか教科書通りでないということも多々あるわけであって
こういうときどうするかといえば，ソレは仕様にないから金輪際対応しませんとか
仕様変更だから納期を延ばせとかそういう風に突っぱねるわけにもいかないわけで
納期と作業の両を勘案して妥協しないとならないということもあるということを
一応考慮に入れておいてください。
005931
03/08/28 21:42ID:???57はまっとうな正論を言っていると思うよ。
漏れもずいぶんひどい設計のシステム見てきたんで、同一項目
があちらこちらにあったり、繰り返し項目がDBの中にはいって
いて泣きを見たのは１度だけじゃない。
ただ、すべての案件がDBを１から設計するものばかりじゃないし、
期間と工数が限られてて、後から考えると変な設計したなぁ、という
こともあったのも事実。まぁ、漏れの腕が悪いといえば悪いのだけど、
状況と開発期間によっては>>58の状況もいたしかないと思うけどね。
で、>>56の命題だけど、社宅<->世帯主社員と社宅<->社宅居住社員
の関連表でなんとかならないか？
0060名無しさん＠お腹いっぱい。
03/08/29 00:32ID:???0061名無しさん＠お腹いっぱい。
03/08/29 21:42ID:???0062名無しさん＠お腹いっぱい。
03/08/29 22:49ID:wuV7R3neトータルコストに視点を置いてしまえばその場の環境もあり、
単純な正論は無いと思いますけどね。
でもデータベース設計では正規化をまず念頭に置いて間違えでは
ないと思いますが。
0063名無しさん＠お腹いっぱい。
03/08/30 01:44ID:???求める結果を得るために遠回りな処理をしなければならないような作り、じゃないかなぁ。
上でも出ていた横に長いテーブルなんかその典型例かも。
例えば入金伝票を扱うとする。
ちゃんと正規化されて、伝票の1明細につき1レコードを持つようなテーブル構造になって
いればSQL一発で合計金額が取得できる。
だが、金額1、金額2・・・なんつー持ち方をされたらそう簡単にはいかない、と。
0064名無しさん＠お腹いっぱい。
03/08/30 02:04ID:???0065名無しさん＠お腹いっぱい。
03/08/31 00:04ID:O2kVRfN3あげる設計なんだけど、やっぱダサい組み方なのかなあ。
ちなみに在庫データ20億件（過去分含む）、商品データ10万件くらい。
（実際には他のデータもある）
きちんと設計すればSQLだけでも対応できるのかな。
これだけ大規模なのは初めてなので教えて君でスマン。
0066名無しさん＠お腹いっぱい。
03/08/31 00:11ID:2xEdmdQcインデックス作るのもアナライズするのもえれぇ時間かかりそう。。
0067名無しさん＠お腹いっぱい。
03/08/31 00:17ID:???それって夜バッチで20億件のデータを作ってるの？
OS/DBMSを教えて。
0068名無しさん＠お腹いっぱい。
03/08/31 01:14ID:O2kVRfN3Solaris＋某社のマイナーDB。
ちなみに20億は過去分含んでる。1週分は2000万件くらい。
これをもとに「この店/この営業地区ではこの商品がこう推移してる」とかを見るわけ。
夜間は毎日8hくらいかけていろんな切り口のデータを事前作成してる。
さすがにこれだけあると事前にデータ作らないと厳しいかな？
他にこのくらいの規模で仕事した人の体験談きぼん。
（大手スーパーとかコンビニはどうしてるんだろう）
0069名無しさん＠お腹いっぱい。
03/08/31 01:35ID:???0070名無しさん＠お腹いっぱい。
03/09/01 23:56ID:OWqCRzNGその元データ20億件のテーブル構造は？
そんだけデカイとCBOだと思うがANALYZE5%でも
3時間以上かかりそう。
20億件のDWHで8時間ならコストに優れていると思ったりした。
0071名無しさん＠お腹いっぱい。
03/09/02 00:04ID:Rwx77e/Jもしかして
Symfoware？？？？
不治痛とかそういう設計しそう・・・・。
ていうかやってるんだけどね。
漏れのところも。
0072名無しさん＠お腹いっぱい。
03/09/02 00:30ID:???あ、SybaseIQならﾏｼﾞマイナーだな。
0073名無しさん＠お腹いっぱい。
03/09/02 00:30ID:GPdlZK1U当然ながらお得意の騎上位での腰振りもやってくれてますのでファン必見です!!その他有名女優が
セーラー服であんな恥ずかしことを．．．！
http://66.40.59.77/index.html
0074名無しさん＠お腹いっぱい。
03/09/03 01:49ID:???徹底的に正規化されたため劇遅くなったシステムを多く見てきました
（設計が悪いと言われればそれまでですが）。
いま僕が開発してるシステムは速度優先なので、
正規化しなかった部分が多いです（データの整合性を取らなくてもいい部分が多かった性でもありますが）。
結局ケースバイケースだし、重要なのは正規化することではなく開発者のセンスだし、
正規化バカにはなりたくないものです。
0075雑言スマソ
03/09/03 07:01ID:???センスと言い換えてしまうのもちょっと抵抗があるなぁ。
技術だったり、工学だったりするのをマジックに戻してしまう。
単純に速度だけの問題ならば、とりあえず最初にダミーデータ
つくって負荷かければ損益分岐点が客観的にでる気がするし。
それで正規化の度合いと折り合いつけるのもよいし、
マシンおねだりするのもよいし。
0076名無しさん＠お腹いっぱい。
03/09/03 16:16ID:???言いたい事はわかるけど、ケースバイケースや開発者のセンスに任せた結果
酷い事になってるDBが多いような気がするなぁ。
あくまでも正規化を基本とするのは間違いじゃないと思うけど。
ちなみに私は、正規化されたが為に遅くなったシステムってのは見た事ない。
どんな場合にそうなるの？
0077名無しさん＠お腹いっぱい。
03/09/03 16:45ID:???CREATE TABLE users (
serial_id serial NOT NULL,
sex integer,
age integer,
nickname character varying(32)
)
CREATE TABLE bbs (
bbs_id serial NOT NULL,
subject character varying(256),
body character varying(1024)
)
だとして、掲示板に書いた人の性別、年齢、ニックネームを表示させたいときとか。
これが百万のオーダーになると、
CREATE TABLE bbs (
bbs_id serial NOT NULL,
sex integer,
age integer,
nickname character varying(32)
subject character varying(256),
body character varying(1024)
)
とした方が早いと思うんです。が。
0078名無しさん＠お腹いっぱい。
03/09/03 16:51ID:???0079名無しさん＠お腹いっぱい。
03/09/03 22:53ID:Pl2K2BADだとしてなんでbbsテーブルにusersのserial_idの列がないの？
0080名無しさん＠お腹いっぱい。
03/09/04 00:33ID:???0081名無しさん＠お腹いっぱい。
03/09/04 01:07ID:???単純すぎるよ。
DBを単なるレコードストレージとして使っているようなものだからね。
ただ、誤解しているようなので言っておくが、いまはJOINはそんなに
パフォーマンスは悪くない。
逆に１：Nのリレーションで全件引っ張って１つの表(VIEW)にする場合、
DBのチューニングがうまくいっていれば
１のほうはディスクアクセスは最初の１回だけで２回目以降は
キャッシュメモリから持ってくるのでパフォーマンスがあがる。
>>77の例でも件数によるが、たいていの場合ユーザー情報はユーザー数
分しか読み出されないので、結局正規化したほうがパフォーマンスがよく
なる。
0082名無しさん＠お腹いっぱい。
03/09/04 01:15ID:???たとえ会員制でも。
例えがよくなかったね
0083名無しさん＠お腹いっぱい。
03/09/04 14:54ID:???もう１個 前提に無理がある
１００万のオーダーに対して全件抽出の
可能性はきわめて低いはず。
最新のN件とかになると、明らかに正規化されていた方が早いはず。
0084名無しさん＠お腹いっぱい。
03/09/04 16:27ID:???>>81 現状は1Gのメモリをキャッシュで食い尽くしてスワッピングしまくりなんですね。
今はx86ベースなので、次はSPARCかAMD64かってのも考えてます。
>>82 そうですね、僕の開発してる分野では正規化の恩恵はあんまり受けないかも知れないけど、
物流とか金融の開発のことを想像したら、正規かも必要だって思いました。
>>83 いや、管理側で集計取るので全抽出は頻繁にあるのです。
0085名無しさん＠お腹いっぱい。
03/09/04 22:29ID:???DBシステムでスラッシング発生させるなんて言語道断。
しょっちゅう発生してるなら、共有ヒープやソート領域のサイズを小さくしろ。
それから、AMD64はともかく、SPARCなんてIA32と比べてそんなに速いもん
じゃないよ。特にひゃくまんにひゃくまんくらいの安いクラスは勝負にならない。
それ以前に、CPUにボトルネックがあるってのをちゃんと検証したのかな？って
疑問もあるが。よっぽど速いディスクなのか遅いCPUなのか...
＃あぁ、なぜかPostgresはOracleと比べてCPUの負荷が高くなりがちだったな。
0086名無しさん＠お腹いっぱい。
03/09/04 23:35ID:???使って開放してないみたいなんです。
現状足引っ張ってるのはHDDなので、メモリたくさん積みたいな。って。
なのでSPARCかAMD64。久しぶりに Solaris いじってみたいな。
0087名無しさん＠お腹いっぱい。
03/09/05 00:15ID:???置き換えて解決しようというパターンだな。
0088名無しさん＠お腹いっぱい。
03/09/05 00:20ID:???0089名無しさん＠お腹いっぱい。
03/09/05 01:47ID:???0090名無しさん＠お腹いっぱい。
03/09/05 21:50ID:fFJD8s2pマスタ(A_TABLE)にコード(PrimaryKey)と名称を保有。
トランザクション系のテーブルにA_TABLEの名称を保有。
．．．．何？この設計。
0091名無しさん＠お腹いっぱい。
03/09/05 22:02ID:???0092名無しさん＠お腹いっぱい。
03/09/07 02:40ID:???全然関係ないが「超マシン誕生」の一節を思い出した
「アナライザは1万ドルもする。それにくらべて連中の超過勤務手当てはタダだ」
0093名無しさん＠お腹いっぱい。
03/09/07 20:08ID:qGFLzh9Q何かの履歴テーブル?
0094名無しさん＠お腹いっぱい。
03/09/08 12:06ID:???使ってるRDBのアーキテクチャをちゃんと理解していない奴にSQLを書かせているから性能が出てないだけちゃうんかと。
性能が出ていないのは本当に正規形が理由なのか？
データの整合性が不要ならそもそもDBなんていらんのでは？
ケースバイケースの指針が明解になってない状態では開発者のセンスとか言われても当てにならんだろう。
正規化バカというがこういうことを書く奴に限って、レコード少なくて項目の少ないシステムだと、こんな単純なシステムなら正規化を
する必要もないですよ、とかいうんだろうな。
ものは試しに、きっちりと正規化を行うべきケースとやらをちゃんと書いてみて欲しいものだ。
それを明示できないやつのセンスなど信じてシステムの重大要素であるDB設計など任せる方が怖いよ。
>>82
書き込んだ時点でsexがコロコロ変わるか？それってネカマ管理か（ｗ
ageはbirthdayの導出じゃないのか？age列がドメインとして全く正規化されていないことに気付け。
bbsなら全文検索をしたいとかいうニーズを考える方が先だろう。そうすると、余計な列がないほうがIO上有利に決まっている。
あと管理側で云々というが、それだったらbodyは別テーブルに分けるほうが普通だろ？
管理の為に必要な情報ってのがどういうものかわからんが、user別発言回数なんてのを
countしたいなら、本文は不要だからな。アクセスパターンの分析もせずに物理設計
するなよ。論理設計で手抜きしてるんだからせめてそれくらいはちゃんとやれ。
もまいは正規化やりすぎを語る前に、正規化そのものを勉強しる！精進が足らんだけだ。もっともっとがんがれ！
0095名無しさん＠お腹いっぱい。
03/09/08 13:03ID:???実際にシステム組んだ時に思った事書いただけだ
0097名無しさん＠お腹いっぱい。
03/09/09 08:17ID:RHS5R/v2あなたの言いたい事は理解出来るが、煽り口調ですな。
もうちょっと紳士的にお願いします。
確かに｢整合性を無視した設計｣は論外ですがね。
0098名無しさん＠お腹いっぱい。
03/09/10 20:02ID:YlwmCvt9現在あるシステムのカスタマイズを行っているんですけど、
現行のＤＢ設計者はいないし、テーブルの制約が多すぎて
にっちもさっちもいきません。
ディクショナリをいろいろ調べてＥＲ図興して。。。
あぁ。。制約を設定しすぎるのも後々ツラかったりしませんか？
0099名無しさん＠お腹いっぱい。
03/09/10 21:57ID:tGVyPlm+っちゃうよ。
0100名無しさん＠お腹いっぱい。
03/09/11 00:13ID:o1HVsw0dもしかしたら、それ漏れのプロジェクト？
某クレジットのシステム？
ＪＯＩＮ禁止ってのになんか見覚えが・・・。
0101名無しさん＠お腹いっぱい。
03/09/17 21:17ID:tJ3tjEnR不治痛にて...
JOIN禁止
SELECTは*で
SQLは外出
...あっほーーー
0102名無しさん＠お腹いっぱい。
03/09/17 22:43ID:sZz9Ze2C0103名無しさん＠お腹いっぱい。
03/09/18 22:10ID:LMoUfHJC0104名無しさん＠お腹いっぱい。
03/09/19 08:51ID:???0105名無しさん＠お腹いっぱい。
03/09/24 14:27ID:HDcPR1MU単体テストなどで、テストデータ作るのがめんどいよ。
列が１００以上あってさ、１０レコードぐらい作るのにも
ホネだよ。
以上２年目のプログラマの愚痴でした。
0106あぼーん
NGNG0107名無しさん＠お腹いっぱい。
03/09/24 23:28ID:kgwakjbUあ〜わかるそれ！俺OracleでSQL*PlusしかDBﾂｰﾙ知らんからね。
INSERT INTO HOGE VALUES('111',222,'333',444,'555',,,,,,,,,,,,
あ〜あ。。めんどくせ。
0108名無しさん＠お腹いっぱい。
03/09/27 02:38ID:???shでもPerlでもいいから何かしらそういう系の
スクリプト言語を覚えることをお勧めする。
捏造データ作るためのSQL文生成なんぞ容易い。
0109名無しさん＠お腹いっぱい。
03/09/29 00:04ID:ULtVDCM9ホストからRDBに移行するための条件が、
「テーブル定義はホストを同じで」
何のためにRDBにするの？
金の無駄。だから赤になるんだな。
0110名無しさん＠お腹いっぱい。
03/09/29 22:47ID:/Lm4/xCeやはり「テーブル定義は前と同じで」
糞みたいなＤＢ設計をそのまま継承するとは。。。
0111名無しさん＠お腹いっぱい。
03/09/29 22:54ID:???突っ込みどころのある課題がないとダメか。。
0112名無しさん＠お腹いっぱい。
03/09/29 22:55ID:???DB設計がそのままなら、せめて最適化に命をかけてください。
0113名無しさん＠お腹いっぱい。
03/09/29 23:13ID:???だからDBを一度構築した後でDB構造を変更するのは、極力避けなければなりません。
そのため、まず紙と鉛筆の世界で正規化手法に従ってDB設計をキッチリ行ってから、
構築作業をはじめたものです。
最近は、ACCESS/ORACLE/SQL鯖等、パソコン系のRDBが発達し、DB構築に
データ構造の変更が容易になったせいか、正規化手法を理解していない
若いSEが増えてきたように思えます。
プログラム開発中にデータ構造を変更すると、プログラムの変更を
余儀なくされ、結果、余計なコストもかかります。
XPなど新しい開発手法がもてはやされている現在でも、
DB設計などはウォータフォール的なやり方も必要だと考えます。
以上、おっさんの愚痴でした。
0114名無しさん＠お腹いっぱい。
03/09/30 00:01ID:???「リレーションにする」とか「テーブルを分ける」とか、そういう言葉で表現してます。
SQLも自力ではかけなくて、AccessにSQLを生成させて、それをコピペしてます。
今度の仕事はMSDEでやりましょう。と提案すると、少し動揺したような顔をしたの
で、Accessからも接続できますよと説明すると、上機嫌になりました。
ハッカージャパンのような厨房雑誌ばっかり読んでないで、普通のDBの入門書
でも読めばいいのにと思うのですが。
(ハッカージャパンにしても、よくPerlのスクリプトとか載ってるようだけど、
上司はPerlもCも使えないようだし、なにを読んでるのだろうかと思う)
0115名無しさん＠お腹いっぱい。
03/09/30 00:54ID:???危険だな。
Accessからリンクはって全てを解決した（つもり)のプロジェクトになりそう。
0116名無しさん＠お腹いっぱい。
03/10/01 16:25ID:1gbbeq+m例) TABLE_A:TABLE_B = 1:n
TABLE_A(PrimaryKey:a,b,c,d,e)
a,b,c,d,e,fffff
TABLE_B(PrimaryKey:a,b,c,d,e,g)
a,b,c,d,e,g,hhhhh
上記のTABLE_Aは500万件程度、TABLE_Bはおそらく5000万件程度の大規模な
DBになると思われます。
で、上記のような構成だとINDEX領域にかなりの無駄があると思います。
ほかにうまく関連付け出来る方法はありますか？
0117名無しさん＠お腹いっぱい。
03/10/01 21:06ID:???TABLE_B(a_id, g, hhhhh, PK(a_id,g))
0118名無しさん＠お腹いっぱい。
03/10/01 22:26ID:R3mBVKRLイメージですか？
0119名無しさん＠お腹いっぱい。
03/10/01 22:34ID:???その上司はSE?PM?
データベースの論理設計をやったことない人なら正規化という言葉を
知らなくても無理ないかもね。
ちなみに業務要件は知りませんが、MSDEはやめたほうがいいと
思ったりしてみました。
0120名無しさん＠お腹いっぱい。
03/10/01 22:38ID:???イメージ的には多分そうでしょう。
でも採番はDBEにやらせたほうがいいと思いますよ。
OracleならSEQUENCE
SQLServerならIDENTITY
その他のDBMSでも同様の機能はあるでしょう。
0121名無しさん＠お腹いっぱい。
03/10/01 23:37ID:???not null 忘れないようにな。
0122名無しさん＠お腹いっぱい。
03/10/03 23:38ID:ZPfMotMTだってDBAではある程度｢正規化｣ってのは当たり前だしょ。
アプリ開発部隊が｢これエラーになっちゃうんですけど？｣
っていわれると、だいたいＳＱＬの書き方が悪い。
0123名無しさん＠お腹いっぱい。
03/10/04 14:55ID:???> アプリ開発部隊が｢これエラーになっちゃう(ry
それはDB設計の話とは関係ないだろ。
0124名無しさん＠お腹いっぱい。
03/10/04 16:07ID:???スマソ。表現間違った。
例えば、不必要にサブクエリを大量に発行していたり、
わざわざテーブルスキャンするようなSQLだったりね。
0125名無しさん＠お腹いっぱい。
03/10/06 23:09ID:8DA89W7mサブクエリはストアドにしますか？そのまま書きますか？
どうしてもな場合、ストアドにして提供したら？
0126名無しさん＠お腹いっぱい。
03/10/08 20:36ID:???正規化なんか「第一正規化」「第二正規化」「第三正規化」の順にやりなさい
とか、（第一正規系はこうなって・・・というのを書く欄がある）処理時間見積り
を仕様書に書くようになっているし（マシンが変わったらどうするつもりだ？）
そのくせ、項目一覧にキー（PKとか外部キーとか）を識別する欄がない。
ER図も書かなくていいらしい。
＃別に処理見積もりをするなとか、正規化するなとか行っているんじゃなくて
＃んなもん、仕様書に書くなということをいいたかった。
なんか、去年くらいからやったプロジェクトの成果だとか自慢してたけど
どうもシスアドとってすぐに配属されたような人間ばっかがやったようなもの
としか思えなかった。
0127名無しさん＠お腹いっぱい。
03/10/08 23:13ID:???プログラマにそれをやらせるのか・・・
香ばしいというより・・・
0128名無しさん＠お腹いっぱい。
03/10/09 00:15ID:???合理的思考をちょいと体系的な知恵にしたようなもんだし、
特に意識しなくても第三くらいまでは普通に出来てしまうもの。
なんでわざわざ第一からやらせるんだろうか・・・
試験勉強の弊害か？
通した上の人間もかなりヤバいと思う。
0129名無しさん＠お腹いっぱい。
03/10/09 00:42ID:???世の中には常軌を逸した人がいるからだよ。
0130名無しさん＠お腹いっぱい。
03/10/10 20:54ID:GiDrGrOC昔、UNI○YSでそんなDB設計書見たことある。
結局そんなドキュメントはWrite Only。
開発者は項目定義とER図さえあれば、事足りると思うんですがね。
0131名無しさん＠お腹いっぱい。
03/10/10 21:25ID:???冗長化されたテーブルを無条件でSELECT *してた。
（しかもクライアント・カーソルで）
キャッシュヒット率30%だって。
もう今週でPRJ外れるから関係ねぇけど、使いモンになんねぇよな。
0132130
03/10/10 21:48ID:???0134名無しさん＠お腹いっぱい。
03/10/13 10:18ID:???絶対に100にはならんだろ
せめて99%って書こうよ
0135NAME IS NULL
03/10/13 12:27ID:???>>133ではないが100%に絶対ならないの？
例えば、データブロックサイズ１個がSGAより小さくて、PrimaryKeyで
SELECTしたら、100にならない？
0136NAME IS NULL
03/10/13 23:01ID:???たぶんそれでも100は無いと思います。
インデックスやディクショナリを読みにいきますから。
（嘘かもしれんけどね）
0137NAME IS NULL
03/10/14 17:14ID:Ji699eh5区分ってあるじゃない。性別区分とか処理区分とか売上区分とかいろいろいろ…
そういう「区分」ってアプリケーション内部で
if(sex == 1){ printdata = 男 } elseif(sex == 2) { printdata = 女}
みたいに処理してしまうんだけど、本来は区分毎に一つのテーブルもたせるべきなのかな?
0138NAME IS NULL
03/10/14 17:27ID:???男テーブルとか女テーブルとか作るってこと?
0139NAME IS NULL
03/10/14 18:06ID:???性別は2種類って決まってるから、いっその事"男"、"女"で入れてしまうとか。。
0140NAME IS NULL
03/10/14 18:10ID:???ﾌﾗｸﾞ的な意味しか持ってないと別ﾃｰﾌﾞﾙにしようが無いような。
DBには数値で入れといて、ﾌﾟﾛｸﾞﾗﾑ側で定数に置き換えてｺｰﾃﾞｨﾝｸﾞ
する人間が分かりやすい形にして終了かと。
0141NAME IS NULL
03/10/14 18:24ID:???属性を結びつける理屈はDB内には存在しない。
そうするとプログラム内にルールを作らなければならないけど、
ルールがプログラム全体に正しく周知されているかどうか
チェックするのは非常にめんどい。
何かしらの都合でルール変更があったりしたら更に大変。
だから、個人的には>>137みたいな実装はお勧めしたくないなぁ。
また、別の話題として、性別にyes/no型（boolean型）を使うかどうかも
本来ちゃんと検討しなくちゃならない。
「性別は2種類」は現実としてはその通りだとしても、DBでの取り扱い上
本当に2値しか取らないのか？ということ。
たとえば、性別不明でも登録可能な設計にする可能性があれば、
やはり2値はまずいだろう。nullで逃げるのも好ましくない。
0142137
03/10/14 20:56ID:hj6tt/FH2値にとらわれないでください。
で、思いついたのがこんな↓テーブル
<T_KUBUN>
NAME, ID, VALUE
"性別", 1, "男"
"性別", 2, "女"
"売上", 1, "売上"
"売上", 2, "返品"
"関係会社", 1, "得意先"
"関係会社", 2, "仕入先"
"関係会社", 3, "その他"
とまあこんな感じでシステムで使用する区分をひとまとめにした
テーブル(区分マスタ)を用意したら便利なのかどうなのか??
select t_syain.simei, t_kubun.value
from t_syain join t_kubun on t_syain.sex = t_kubun.id
and t_kubun.name = '性別'
こんな風につかうです。やっぱヘン?
0143NAME IS NULL
03/10/14 22:08ID:???それはちょっと・・・
完璧に正規化から外れるし、使いやすいとも思えない。
0144137
03/10/14 23:02ID:hj6tt/FHでも「SQL書いて貼り付ければ画面も帳票もできちゃうよ」ってフレームワーク
使ってたりすると、SQLレベルで全ての項目が揃うのが便利なのだよね。
よくOracleなんかでDECODEだらけになってるSQL見てて、なんとかならないのかと
思ったけど。結局アプリに使う言語レベルで纏めるのが一番いいのかな。
ところで。
全くこれ以上増えも減りもしないよ。という区分でも、値が20こくらいあったら
きっと多くの人はアプリに埋め込まずにテーブルにすると思う。
区分のテーブル化とアプリに埋め込む判断基準は何で線引きするべきなんだろう?
徹底的に正規化すべし!! と言うのに乗っ取ると、区分の値がいくつであれ区分毎に
「なんちゃら区分マスタ」を作るのが正しいのかな?
0145NAME IS NULL
03/10/14 23:05ID:???僕は一桁(9個まで)位でわけてますね。
0146NAME IS NULL
03/10/15 00:46ID:???独自の方をユーザ定義できるならそれを使う、と。
0147NAME IS NULL
03/10/15 11:29ID:MmiJnUGSてかさ、何で男/女を1/2とかにマッピングするの？性別テーブルとか性別配列とかがあって、マッピング値と実値との関連がはっきりしているならまだしも、そんなもん無いんでしょ？どうせやるならM/Fの方がまともだと思うがなあ。
0148NAME IS NULL
03/10/15 11:56ID:???0149NAME IS NULL
03/10/15 14:58ID:???0150NAME IS NULL
03/10/15 16:11ID:???どこがＤＢなのかと問い詰めたい。
0151NAME IS NULL
03/10/15 16:30ID:???たとえば、DECODE(SEX,1,'男','女')みたいなものは
Viewで提供しちゃうとか。
まぁそれも管理し辛くなるかも。
0152NAME IS NULL
03/10/15 16:33ID:???if ( db.fileds("SEX") == 1 ) {
printf("男");
} else `
printf("女");
}
とかね。
0153NAME IS NULL
03/10/15 16:39ID:???1 男
2 男(タマ無しサオ有り)
3 男(タマ有りサオ無し)
4 男(両方無いが遺伝子はXY)
くらいは視野に入れておかないとね。
0154NAME IS NULL
03/10/16 11:18ID:???そうすると残された選択肢は何？
0155NAME IS NULL
03/10/17 00:02ID:???それなら逆も考えないと
あ、タマは無いよな(w
0156NAME IS NULL
03/10/17 04:24ID:???私は普段、iniファイルとかに定数として書いてますよ。
0157NAME IS NULL
03/10/21 03:15ID:???0158NAME IS NULL
03/10/21 17:55ID:???そのココロは？
0159NAME IS NULL
03/10/21 18:55ID:RC3MFIe1なんか有る時にSQL使いたいから。
0160NAME IS NULL
03/10/23 17:46ID:fNG7AZNH１）全てをマスタデータとしてDBに定義し、
そのデータをアプリケーション側でキャッシュする。
男女の区分など変わらないものはキャッシュ期間を無期限にする。
２）コードと人間の見た目の対応を、
外部のプロパティーファイルとして定義する。
前者はマスタとして
<SEX>
1: 男
2: 女
が定義され、このオブジェクト構造をアプリケーションが保持する。
多くの場合アプリケーション起動時に一度DBに問い合わせるだけになる。
変更はテーブルにアップデートをかける。
後者は
<SEX>
1: MAN
2: FEMALE
を固定的に定義し、プロパティファイルとして
MAN=>"男"
FEMALE=>"女"
とか
MAN=>"殿"
FEMALE=>"姫"
を配付する。
この手の変わらないと思われるコードは、国際化仕様を考えると
合理的な解法が見えてくる場合もあるかと。
0161NAME IS NULL
03/10/24 09:16ID:???なんでMAN,FEMALE？
MALE,FEMALEだろ？
DBの勉強する前にEnglish勉強して下さい．．．
0162NAME IS NULL
03/10/25 15:26ID:???0163NAME IS NULL
03/10/29 06:05ID:???男、女、その他で、実態とずれてきたら増やせばいいだろ。
0164NAME IS NULL
03/10/31 01:26ID:???ユーザの都道府県情報なんかも、
都道府県マスタみたいのつくって、正規化するべきなんでしょうか？
0165NAME IS NULL
03/10/31 02:32ID:???するかどうかはデータにもよると思うけど〜
県コードはJISとかから持ってくよろし
0166NAME IS NULL
03/10/31 20:53ID:3MZ7Eppjそれは第３正規化のカテゴリーですな。
0167NAME IS NULL
03/11/01 01:06ID:hqmy3kq3何でも数字で打ちたいキーボードの鬼向けの入力支援のために
わざわざソースや演算経路を複雑にする行為であって、
別の必要な情報で間接的に得られるので正規化というわけでもあるまい。
0168NAME IS NULL
03/11/01 01:11ID:???> わざわざソースや演算経路を複雑にする行為であって、
そりゃ偏見入りすぎ。
見た目はともかく、内部的に日本語の文字列を
識別子として扱うこと自体に少なからずリスクがあろうに。
0169NAME IS NULL
03/11/01 04:40ID:???0170NAME IS NULL
03/11/02 04:16ID:???0171NAME IS NULL
03/11/05 23:30ID:Lx8TiKNF種別 | 内容
------+------
言語 | COBOL
....以上
0172NAME IS NULL
03/11/06 11:37ID:???それって第一正規化とゆーんだっけ？
0173NAME IS NULL
03/11/06 12:03ID:???種別 | 種別| 種別 |
------+--------- ----+------ ------+---------------
言語 | F-BASIC OS | MVS 資格 | 情報処理2種
言語 | ASM OS | Win 資格 | Oracle8i Plutinum
言語 | PL/I OS | Linux 資格 | 普通自動車免許
言語 | COBOL OS | Solaris DBMS | IMS
言語 | C DBMS | DB2
言語 | VB DBMS | SQLServer
言語 | C++ DBMS | Oracle
言語 | Java
言語 | C#
0174NAME IS NULL
03/11/06 17:24ID:???右詰になってよくわかりまへん。
言語：F-BASIC?/ASM/PLi/COBOL/C/VB/C++/Java/C#
0175NAME IS NULL
03/11/06 22:09ID:???>174
左詰に見えるんだが......
0176NAME IS NULL
03/11/06 22:12ID:???少なくともこんな表を書いているうちはデータベースの設計は任せたくないな。
0177NAME IS NULL
03/11/06 23:00ID:???それで１０００フィールドぐらいあって、
同じ意味のものの位置が行によってどんどんずれるという設計。
ああいうのと連携する仕事が来たらどうしよう。
0178NAME IS NULL
03/11/07 01:47ID:???そういうのがきたら、パーサー書いて
スクリプトとして処理するしかないな。
0179NAME IS NULL
03/11/07 18:07ID:/RTzaVIzモーニング娘。 | LOVEレボリューション
モーニング娘。 | Peace!
みたいな感じにテーブルを作りたくて、
こうしたら
select * from table where artist='モーニング娘。'
とかで検索できるけど
select * from table where artist='モー娘。'
みたいに別名でも検索できるようにしたいっていう場合って
テーブルはどんな風に設計すれば良いの？
0180NAME IS NULL
03/11/07 19:28ID:???＃>>1じゃないですが（ｗ
artist_table(primarykey:art_id)
art_id|artist |nickname
1 | モーニング娘。 |モー娘。
music_table(primarykey:art_id,music_no)
art_id|music_no|title
1 | 1 | LOVEレボリューション
1 | 2 | Peace!
とか、別名複数あるなら別テーブルにするかな。
0181NAME IS NULL
03/11/07 19:43ID:???別名ぐらいは極力明細にせず、上限１０個とかで入れちゃった方がいいと思う。
やり過ぎるとシステムが重くなる。
artist
id | name | nickname1 | nickname2
1 | モーニング娘。 | モー娘。 |
2 | つんく | |
music
id | name
1 | LOVEレボリューション
2 | Peace!
artist_music
artist_id | music_id
1 | 1
1 | 2
2 | 1
2 | 2
0182NAME IS NULL
03/11/08 00:32ID:9gnAoqkRこのテーブル構成で
artist=松浦あや/music=桃色の片思い
を挿入するとき効率がいいSQLってどんなかんじ？
0183NAME IS NULL
03/11/08 01:16ID:???痛いぞ
0184NAME IS NULL
03/11/08 01:21ID:???artistあややある？(select)
ある＞あややのartist.id(σ･∀･)σｹﾞｯﾂ
ない＞あやや登録(insert)
music桃色の片思いある？(select)
ある＞桃色の片思いmusic.id(σ･∀･)σｹﾞｯﾂ
ない＞桃色の片思い登録(insert)
artist_musicあややの桃色の片思い登録されてる？(select)
ある＞がいしゅつ
ない＞artist.id/music.id登録(insert)
SQLてゆうかロジックだ（ｗ
最後だけいきなりinsertするのもありかな？（僕はしないけど
0185NAME IS NULL
03/11/08 01:45ID:6qfeikX1林檎殺人事件を郷ひろみでも樹木希林でもヒットさせたい時どうするの？
林檎殺人事件を２重登録するの？林檎殺人事件に関するもっと多くの付随情報があったら？
0186180=184
03/11/08 02:16ID:???artist
id | name | nickname1 | nickname2
1 | モーニング娘。 | モー娘。 |
2 | つんく | |
3 | 松浦あや | あやや |
4 | 郷ひろみ | |
5 | 樹木希林 | |
music
id | name
1 | LOVEレボリューション
2 | Peace!
3 | 桃色の片思い
4 | 林檎殺人事件
artist_music
artist_id | music_id
1 | 1
1 | 2
2 | 1
2 | 2
3 | 3
4 | 4
5 | 4
これじゃだめ？
＞林檎殺人事件に関するもっと多くの付随情報があったら？
当初の話(>>179)に入ってないから入れてないだけじゃ・・・。
0188180=184
03/11/08 03:04ID:???＞もっといい方法があるのかと思った。
データはこんなもんでいかに登録・検索しやすいPGを書くか。だと思う。。。
0189NAME IS NULL
03/11/08 04:01ID:6qfeikX1>>181はＳＥの癖で、要件自体に見落としがある可能性を示唆するためのものだったので。
テーブルが駄目だとＰＧで工夫しても駄目システムになってしまうので。
項目（フィールド）については客も気付きやすし後から追加しやすいんだけど、
構造については客は気付かないことが多いし後から変更しにくいので。
0190NAME IS NULL
03/11/08 12:05ID:???それってMAX６回SQLコールするんでしょ？なんか効率悪いんじゃ。
ロジック組まなくてもINSERT FROM SELECT〜みたいな
SQLで一発でいかないかい？
今、テスト環境が無いんで検証は出来ませんが。
0191NAME IS NULL
03/11/08 16:37ID:6qfeikX1>>184じゃないけど、
全部まとめて１個のストアドにすればいいんじゃん？
つーか書き込みアクセスでそれほど効率を気にする必要はないと思うが。
ｍｄｂだかどうか忘れたけど、クエリに書き込める場合もあるよね。そのことかな。
だけど構造によっては拒否されたり誤動作する場合もあるし、
ＳＱＬＳｅｒｖｅｒとかＯｒａｃｌｅとかだともともと無理だったような。
ＯＤＢＣを介するとできる場合があるんだっけ？
でも怪しいので、素直な直書きロジックで、速度が気になるならストアドっていうのでいいと思う。
0192180=184
03/11/08 17:07ID:???検証は大事だよねー。
>>190
え、どんなのか知りたい。。。
>>191
ま、DBが特定されればそうだろうねー。
むしろ、質問者179さんが「何を作ろう」としているのか分からないので
これ以上の話が出来ないんだとおもうんだよなー。
自分用の所有リスト作りたいだけなのか、
何かしらのシステムなのかも分からんのじゃ。。。
0193NAME IS NULL
03/11/08 20:01ID:???1発でUPDATE/INSERTというのは基本だと思います。
ですから、複数のテーブルにINSERTする場合にSQL１発で行かないとき
などは、僕はストアド推奨派ですね。
1発で書いておけば、フォワードリカバリとかする場合にも問題が
少ないしスマートです。
もちろんシステム全体のトレードオフが最優先検討事項ですが。
0194NAME IS NULL
03/11/08 20:52ID:???＞別名ぐらいは極力明細にせず、上限１０個とかで入れちゃった方がいいと思う。
頼むから正規化しろよ
0195NAME IS NULL
03/11/08 21:52ID:???トランザクション切ってやってる限り一発にこだわらんでええっしょ。
何のためのトランザクション？
それと、今例に挙がってるくらいのものならともかく、もっと複雑な条件を
要するジョブを大量に発行するときのことを考えると、闇雲に
長いSQL文で実現するのはお勧めできない。
というのも、文自体が長くなってくると、perserやoptimizerの負担が
馬鹿にならなくなってくるからだ。
SELECT部自体の実行時間もどんどん長くなる。
SQL文一発っつーのは、見た目は美しいけどDBにとってはたまったもんじゃない
というのもままあること。
ま、データ規模や要件によって事情は変わってくるけどね。
0196NAME IS NULL
03/11/08 23:48ID:???自民党が政権握ったら、俺ら弱小ソフトウェアハウスの
未来は更なる悲惨な運命を辿るだろうな。
0197NAME IS NULL
03/11/09 00:10ID:???政権取るなら取るで本格的に長期のビジョンがなきゃならんけど、
どうも民主党上層部はその辺甘い。ワイドショー政治に満足している。
なんにせよ、この板から首吊りが出ないことを祈るよ。
0198NAME IS NULL
03/11/09 00:21ID:???今、日本のソフトウェア産業は９割以上、俺ら弱小ソフトウェアハウスが
担ってる事実を政治家の先生方は認識しているのか？
0199NAME IS NULL
03/11/09 03:17ID:???0200NAME IS NULL
03/11/09 09:57ID:???0201NAME IS NULL
03/11/10 01:09ID:???RDBつーよりは全文検索とかの世界じゃやないかなー。
0202NAME IS NULL
03/11/10 01:15ID:???Namazuですか
0203NAME IS NULL
03/11/10 05:06ID:???それだと検索が遅いだけでなく区切り文字、引用符の処理でかえって複雑化するし、
同名アーティストへの対応もできないし、入力の手間も増え、入力ミスにも対応できない。
また、様々な集計等への再利用もできない。
0204NAME IS NULL
03/11/11 13:16ID:OlXELN3R設計は×でしょうか?
例えば
<受注情報テーブル>
受注ID, 受注年月, … 顧客区分, 顧客ID
というテーブルがあるとして
顧客区分が1の場合は顧客IDは<個人情報テーブル>の個人ID
顧客区分が2の場合は顧客IDは<法人情報テーブル>の法人ID
という場合、正規化にのっとって正しく設計した場合はどのようになるのでしょうか?
(そもそも個人と法人をわけたまま扱うことが云々…というところは無視して下さい)
0205NAME IS NULL
03/11/11 18:09ID:rgxeXVwaケースバイケースですね。重くなるとか、他の再利用の仕方にとって簡単かどうかとか。
例えば、受注情報テーブルの顧客IDをやめて個人IDと法人IDの２フィールドにした方が
DBサーバにとっては負担が軽いですかね。やってみないと分からないですけど。
それぞれ普通に１本線のリレーションになるので。
それで、同じ列に表示したい帳票があればISNULL(個人ID,法人ID) AS 顧客IDとか。
この場合だと顧客区分は個人IDと法人IDのどっちがヌルかで計算値として出せますね。
でも処理速度に影響があるなら顧客区分をあえて冗長性保存した方がいい場合もあるだろうし。
0206NAME IS NULL
03/11/11 22:11ID:???俺なら、顧客IDマスターを置いておいて、3テーブルともその
マスターを参照するようにするかな。
0207NAME IS NULL
03/11/11 23:35ID:rcetuSKt顧客マスタ:顧客区分+顧客ID+その他属性情報
受注テーブル:受注ID+受注年月+顧客区分+顧客ID+その他受注情報
結局、顧客区分+顧客IDでユニークになるわけですよね？
顧客IDの頭1バイトを顧客区分として保有させるよりは
いいと思いますよ。
受注情報のDWHを意識するなら受注情報テーブルの顧客区分+顧客IDに
インデックスを張りましょう。
0208204
03/11/12 09:05ID:ExumycNy特に正規化の手法から逸脱しているというわけではないのですね。
パフォーマンスはおいといて、設計の美しさのみを求めた場合、>>204に挙げた
三つのテーブルはどのように設計し直すべきでしょうか?
やはり>>206さんがいわれるように、間に一つテーブルをかませて抽象化(?)する
のが理想的でしょうか?
0209NAME IS NULL
03/11/12 23:17ID:e45CXKa/とりあえず整合性を保とうとするのはやめてくれ・・・
今なら間に合う。ちゃんと設計しようぜ。
つうか、俺にやらせてくれ頼むから。
0210NAME IS NULL
03/11/12 23:36ID:Q3Q0AoRxとりあえずでもなんでもいいから、実例ｷﾎﾞﾝ
0211NAME IS NULL
03/11/14 18:40ID:GDfRaqTR作品テーブル
作品ID｜作品名
-------------------
00001｜林檎殺人事件
-------------------
00002｜夏色の片思い
-------------------
00003｜ダンディライオン
アーティストテーブル
アーティストID｜アーティスト名｜種別ID
--------------------------------
00000000001｜郷ひろみ ｜000001
--------------------------------
00000000002｜樹木希林 ｜000001
--------------------------------
00000000003｜松浦あや ｜000001
--------------------------------
00000000004｜松任屋由美 ｜000001
0212NAME IS NULL
03/11/14 18:41ID:GDfRaqTRニックネームテーブル(ネームIDはいらないと思う)
アーティストID｜ネームID｜別名
--------------------------------
00000000001｜0000001｜ひろみ
--------------------------------
00000000001｜0000002｜Go
--------------------------------
00000000002｜0000001｜きききりん
--------------------------------
00000000003｜0000001｜あやや
--------------------------------
00000000003｜0000002｜ayayaya
--------------------------------
00000000003｜0000003｜ぱぱや
--------------------------------
00000000003｜0000004｜ままや
--------------------------------
00000000004｜0000001｜荒井由美
--------------------------------
アーティスト種別テーブル
種別ID｜種別名称
---------------------------------
0000１｜ボーカル
---------------------------------
00002｜作詞
---------------------------------
00003｜作曲
---------------------------------
00004｜ギター
---------------------------------
00005｜ボーカル
0213NAME IS NULL
03/11/14 18:43ID:GDfRaqTR作品参加アーティストテーブル
作品ID｜アーティストID
---------------------------------
000001｜00000000001
---------------------------------
000001｜00000000002
---------------------------------
000002｜00000000003
---------------------------------
000003｜00000000004
0214NAME IS NULL
03/11/14 18:45ID:GDfRaqTR面白いから、貶せ。
0215NAME IS NULL
03/11/15 02:51ID:???0216NAME IS NULL
03/11/15 03:25ID:WX6Q4llT種別ＩＤは”正しくは”アーティストテーブルじゃなかんべ。
「その曲への関わり方」だから。
しかし、場合によってはその違いを別人として扱いたいという
要望もあるので、なんとも言えん。
あと、検索支援でしかない別名のためにリレーション負荷かけて
レコード数数倍にして返させる意味はあまりない。
0217NAME IS NULL
03/11/15 21:38ID:???どんなライオンだろう…。
0218NAME IS NULL
03/11/17 05:57ID:???0219NAME IS NULL
03/11/17 10:37ID:???0221NAME IS NULL
03/11/17 14:48ID:???0222NAME IS NULL
03/11/23 01:43ID:???0223NAME IS NULL
03/11/23 02:28ID:???0224NAME IS NULL
03/11/23 18:27ID:EdE78rfq辞めてくれよ。ただでさえ正規化されてないのに、
AccessでOracleにAttachしてデータ書き換えまくり。
もうなにがなんだか。やっぱ正規化と外部キー設定は必須だよね。
今ごろ気付いても遅いけど。
0225NAME IS NULL
03/11/23 19:36ID:???DBA権限を別に作って、そいつがやったことをトランザクションログで突きつけてやれ
0226NAME IS NULL
03/11/23 21:23ID:23LWUWCu0227NAME IS NULL
03/11/23 22:50ID:???正規化とか設計以前にセキュリティの問題だろ。
0228NAME IS NULL
03/11/23 22:57ID:oOMkgLbE0229NAME IS NULL
03/11/23 23:08ID:+jlhXyEp複数のテーブルにデータが重複しまくり。
俺は下っ端だからなんも言わないけど、ひどい設計だったよ…
0230NAME IS NULL
03/11/23 23:16ID:???最近は高速で大容量のHDが安価で手に入るから、
設計がショボーンでも、ユーザサイドからの視点では
それほど不満も無く動くのです。
苦労するのは、それを基に設計開発するSE/PGなのです。
ましてや、2次3次開発と、カスタマイズするに従い
見るも無残なDBに。他社にアウトソーシングも出来なくなり
無駄な月額費用だけ浪費していき、運用する期間が延びれば
それだけ赤字になる。。
0231NAME IS NULL
03/11/24 01:32ID:???DOAでもOOでも何でもいいから、とにかく一度は勉強しろと。
0232NAME IS NULL
03/11/24 04:52ID:???お客さん方には、間違いなく全部の伝票や、全部の例外を見せて欲しい。
「これで全部ですか？例外はありませんか？」
「全部です」って全然全部じゃないんだよな。査察じゃないんで家宅捜索するわけにいかんし。
「あ、この場合はこうなんです」のたった一言で根本の設計が変わる場合があるからね。
残念だけど根本からやり直す予算はないので無理矢理押し込むけど。
0233NAME IS NULL
03/11/24 07:53ID:???0234NAME IS NULL
03/11/24 11:32ID:???客のいう「全部」を鵜呑みにする時点で藻舞は人が良すぎる。
全部であるわけがないと想定しておくのが要件分析の第一歩。
0235NAME IS NULL
03/11/24 12:39ID:???まぁね。ただ馬鹿高い金を払ってセミナーとか行くより、
自分で書籍を買って勉強したほうがいいと思う。
ただDOAとかERDなどの開発方法論は、個人ではなかなか導入
出来ないでしょう。結局PMとかが勉強して開発プロジェクトに
導入してくれなきゃね。
どちらにせよ、机上の空論にならないようにしましょう。
0236NAME IS NULL
03/11/24 15:26ID:???しかし、何度も嘘付かれたら信じるよ。
さんざん資料作って何度も確認した結果、全体的にはMRPだった。
それに対し例外ケースを組み込むような設計になった。
しかし後で出た一言で、本当は製番管理システムから例外を作った方が早いことが分かった。
その一言は、既に何度もそれはないと確認してきたことだ。
こちらも当然あらゆるケースを想定して確認を取ってる。
それでもこっちのせいだと言うなら家宅捜索するしかない。
0237NAME IS NULL
03/11/24 15:31ID:???SQLもRDBも知らないしあんまり正規化と縁がない。
でも考え方はRDBも階層型もNetwork型も一緒なのかな？
0238236
03/11/24 15:35ID:???素人が説明するぐらいなら、こっちで実際の伝票見た方が早い。
だから全帳票出してくれと言ったら素直に全部出してくれ。
0239NAME IS NULL
03/11/24 16:14ID:2Ilkee+yどんなインタビューしてたんだ？
お前「全的にはMRPでしょうか？」
客 「はいそうです。」
そんなインタビューしてなかったか？
0240236
03/11/24 17:39ID:???どうしても馬鹿にしたいみたいだね。意味不明な人だな。
「MRP」なんて言って分かる客ならそもそも問題も起きないよ。
どういう形態で受注し、どういう形態で在庫管理し、
最後にどういう形態で売上げるか、その形態がケースによって違うので、
こんなケースはないか、あんなケースはないか、具体的に１つ１つ確認したよ。
いっとくけど>>189は俺だよ。必ず先読みして具体例を見せて質問する。
最初の要求説明では抜け落ちがあり得ることを示唆したのは、ここではなぜか俺だけだよ。
その上で、自分で全部説明しないで今までの業務で使った伝票・帳票を全部見せろと言ってる。
そのことに何か問題が？
0241NAME IS NULL
03/11/24 18:17ID:F6eXBuoi普通なら「見せろ」とは言わない。
こころのどこかに「見せろ」という気持があれば、
良好なコミュニケーションが取れなくなる。
人間って不思議。
0242236
03/11/24 18:34ID:???実際にそんな言い方するわけないでしょう。
承認印欄は作ってあるけど、実際には押すように要求しないし。
でも誠意ある資料と説明で、相手は承認印を押したかのような
気持ちになってくれる。そういうやり方してるよ。
もちろん、やっかいな客がいることを知ってて疑いを持ってるからそうするんだけど。
でも情報がないのに勝手に馬鹿にできる可能性を探ったりするほど歪んでないよ。
0243NAME IS NULL
03/11/24 18:52ID:F6eXBuoi君が良い人で、仕事熱心なのも優秀なのもわかった。
(嫌みじゃないよ)
まだ、30代まえ？
雑談から業務を引きだせる、インタビューテクニックを
手にしたら人生楽になると思う。あと、承認印はもらうように。
承認印は自分とお客様双方を守るために押印していただくものだ。
0244NAME IS NULL
03/11/24 21:11ID:???俺は本業じゃないけど、知り合いの人にDB設計を頼まれて
先週やっと立ち上げた所だけど、一番苦労したのは情報収集だった。
最大文字数が20文字と聞いて、30文字まで打てるようにしてても
さらにその上を行ったからなぁ。
「この情報を集めといて下さい」と言っても
「イヤです」とハッキリ言われた事もあるし。
どうしろと？
って感じだった。
みなさんの言うコミュニケーションが絶対的に不足してたのが原因だろうけど。
0245NAME IS NULL
03/11/24 23:08ID:???執り、ユーザに承認印を捺印してもらう。
どこでもそうだと思うがユーザさんは基本的にわがままでしょ？
後でああだこうだ言われたら議事録を提示し、お互いの落しどころを
模索する。どうしてもここは変えたいと言われればそれは仕様変更として
もちろん別途お金は請求する。
やっぱユーザとの打ち合わせは営業＋ＳＥで臨んだほうが合理的だと思う。
0246NAME IS NULL
03/11/25 00:30ID:???技術的なこととは全然異なるスキルが
必要だということに気付けば自ずとグチの
方向も変わるよ。過程がどうであれ出来上がりに
自分で不満を感じる時点で、それは負けなんだ。
その負けを認めて次にどう生かすかという事が
大切だ。>>236はもっともっとがんがれ。応援するぞ。
0247NAME IS NULL
03/11/25 01:17ID:???すぐに作って部内とお客さんの両方に回覧する。
ってそれが普通かもしれないけど。
言った言わないの争いってあまりに不毛だからねぇ。
仕様として固まったらちゃんと線引いて、こっから先は
仕変ですよお金と時間下さいねって念を押すのも大事
・・・と先輩に言われた。
0248NAME IS NULL
03/11/25 01:21ID:???自分が与えられた情報の中で最大限効率的に動いてるという
自負があればあるほど、大元の情報を狂わせる事態は
嫌で嫌で仕方ないと感じると思う。
でもそれに腹を立てても仕方ないんだよね。
自分の情報収集法を見直す方がずっと建設的。
なかなか難しいことだけど。
0249NAME IS NULL
03/11/25 17:21ID:vK4PmOEtみたいなものを論じているようなので書き込みます。
分かりやすい項目名といったものはどう標準化していけばいいのでしょう?
計算条件テーブル内の
「商品を返品した(された)場合の請求合計金額の端数処理方法の区分」
なる項目の名前が
henpingoukeihasuukbn
などと付けられてしまって「う〜〜ん」という状態です…
他にも henpinmeisaihasuukbn 等があってSQLに書き起こすと長いわ
読みづらいわで何がなにやらといった状態です。
こういう場合、みなさんならどういう項目名にしますか?
0250NAME IS NULL
03/11/25 17:53ID:???h_ghasukbn
h_mhasukbn
返品関連のものをh_にして、後はgoukeiをg、meisaiをm
くらいかな。
他に紛らわしいのあったらその時考える。
0251NAME IS NULL
03/11/25 18:51ID:MwVO9JgK塩梅が結構難しいんだよね
アナログ的な要素が凄く多いから嫌。
これで正解とかいうんじゃなくて、このくらいが正解みたいなところが嫌
自意識過剰な奴とか独りよがりな奴が幅を利かせられる（幾らでも他人を批判できる）分野でもある。
とにかく嫌い。
0252NAME IS NULL
03/11/25 21:07ID:???はは。ありますね。そーゆーケース。
まぁでも日本語の項目名自体が長いからある程度は仕方ないような気もします。
0253NAME IS NULL
03/11/25 21:48ID:???塩梅とは？
正規化と性能のバランスのことを指していますか？
以下ORACLE限定のはなしですが、
テーブルを結合するにあたり、きちんと正規化されたデータベースであれば、
インデックスがお互いに張られているわけですから、ハッシュ結合どころか
ネステッドループ結合でも充分な性能が得られると思います。
仮にインデックスが張られていなくても駆動表・比駆動表でその他の抽出条件を
指定し、データの絞り混みを行うことにより満足いく性能が得られると思います。
以上は他のDBでも基本的な考え方は同じだと思います。
最近｢性能｣を盾に正規化をしない（出来ない）設計者が多いですよね。
0254NAME IS NULL
03/11/25 22:29ID:6ScGRtXl条件テーブルなら俺はどんなに長くなってもそうする。無駄だけど
条件名って言う項目を作って日本語名を入力する場合すらある。
0255NAME IS NULL
03/11/27 01:34ID:???と言ったところで、結局工数に上乗せされるだけなんだけどね。
素直に全部全てすりっと出せばその分安く上がるのに。
0256NAME IS NULL
03/11/27 21:07ID:???0257NAME IS NULL
03/11/29 01:18ID:PxZlqEGC受信したメールなどの履歴を保存するのに１ユーザー１テーブルとするのか、
それとも １つのテーブルにユーザーIDと一緒に保存して検索して取り出すべきな
のか・・・
データ件数が増えてきたときのことを考えると１ユーザー１テーブルの方が良さそ
うな気がしますが一つのＤＢで１０００とか１００００ものテーブルがあった場合、
著しくパフォーマンスの低下などするのでしょうか？
また、１テーブルにすべて保存する場合でもユーザーIDにインデックスつけれてや
れば１ユーザー１テーブルと変わらない気もするし・・・
今までたかだか１００テーブルぐらいのシステムしか作ったことがないのでわかり
ません。ご意見お願いします。
0258NAME IS NULL
03/11/29 11:29ID:???以上
0259NAME IS NULL
03/11/29 13:39ID:???はげどう
どう考えたら「1ユーザー1テーブル」なんていう仕様を思いつくのか。
0260NAME IS NULL
03/11/29 15:45ID:???0261NAME IS NULL
03/11/29 16:47ID:???1つのスキーマにテーブルが1000とか10000て。。
テーブル名を考えるのもめんどう。
テーブル構造が変わったらメンテも大変そう。
HotMailとかのテーブル構造とかが参考になりそうですけど、
私はしりません。
0262NAME IS NULL
03/11/29 17:33ID:???1ユーザ1DBホストにすればよろし
0263NAME IS NULL
03/11/29 23:41ID:???10件10万テーブルと10万件10テーブルなら後者の方が遥かに
DBMSにとって「楽な仕事」。
0264NAME IS NULL
03/11/30 01:00ID:???正規化したと言い張る奴の設計を見たら、同一のコードで参照できるテーブルが18あって
これが全て一対一でリンクできるという唖然としたシロモノだったりする。
んで、出来ちゃったから構造変更不可なんだそうな。
一つの情報系のプロジェクトでテーブル数140ってのは多すぎるだろ！
カラム数2ってのが45もあるし。。。。キー以外はデータの重複は無いけど。
マスターメンテはマジで死にます。
定時前だけど見て直ぐ帰りたくなったよ（ｗ
0265NAME IS NULL
03/11/30 01:57ID:PbWn2vje決めています。（30で、マスター・運用・ME・売上・は構築可能です。（ダイタイ））
マスター＝テーブルと考えているお客様もいますもので困り者です。）
無茶を言うお客様は、テーブル上のフラグで対応可能とご説明します。
[テーブルと・実行体は違うので、テクニックしだいでどうにでも・・・]
テーブルが少ないほど実行体も簡略化出来、サービス残業が減ってよいです。
「くされクライアント４ネ・・・・・・・・」
0266NAME IS NULL
03/11/30 01:59ID:???いちいちテーブル定義とか拡張とかマイグレートとかしてられなくなったので
CREATE TABLE xxxxx
(
id INTEGER,
key VARCHAR(16),
val INTEGER, (DATETIME とか TEXT もあり)
PRIMARY KEY(id,key)
)
のよーなテーブルを作って済ませたいと思うようになったんだが、甘いか?
# id で CLUSTERED INDEX 作るので許せ(w
0267NAME IS NULL
03/11/30 08:14ID:???MSSQLのシステムテーブルにはそんなのが大量にあります。
が、やるとやった本人が死ぬと思います。
0268NAME IS NULL
03/11/30 13:57ID:???ってことは逆にゆーと仕様がまったく決まらんってことですか？
危険な匂いがしますな。
0269266
03/11/30 14:42ID:???危険なまま2年間放置されたシステムだけんのう。
0270NAME IS NULL
03/11/30 17:26ID:???>正規化したと言い張る奴の設計を見たら、同一のコードで参照できるテーブルが18あって
拡張性、汎用性、仕様変更に対する柔軟性を考えたシステムはそうなるんじゃない？
>んで、出来ちゃったから構造変更不可なんだそうな。
このへんの発言から考えるとただの腐った設計かもしれないけど
0271NAME IS NULL
03/11/30 22:34ID:???仮に、拡張性・汎用性・仕様変更に対する柔軟性を考えてシステムを組んだとすれば
「敢えて正規化していない」
と、言うと思う。
0272NAME IS NULL
03/12/01 03:53ID:???たとえるとこんな感じかな。
従業員マスタが有ったとして、従業員コードと氏名だけでテーブルを作り、
従業員コードとフリガナだけでテーブル、従業員コードと住所だけでテーブル
従業員コードと電話番号だけでテーブル、従業員コードと部署コードだけでテーブル
とまぁこんな状況。しかもどのテーブルもレコード数は一致する。
しかも、検索パターンに合わせて設計するとテーブルは5つもあれば十分（変更される要素が薄い）
今、その関連の打ち合わせから帰ってきた（ｗ
会議が始まったのは昨日の午後一時だよ。。。。。
0273NAME IS NULL
03/12/01 04:00ID:???そんなとこだろうと思ったよｗ
0274NAME IS NULL
03/12/01 04:06ID:???それをunionすると>>266の希望のものになるのかな。
何聞いても「分からない」ばっかりで、
「フリガナはもちろん1つですよね」って何の気なしに聞いたら
「分からない。分からない。全部後から変更できるようにして」
と言われてブチ切れたとか。
0275NAME IS NULL
03/12/01 10:16ID:???フリガナ〜聞いてもわからない〜
にゃんにゃんにゃにゃ〜んにゃんにゃんにゃにゃ〜ん
も〜んくばかりいうお客さん〜
犬の〜SEさん困ってしまって、
・・・の続きを歌ってください
0276NAME IS NULL
03/12/01 11:07ID:oXx8656X無理って言え。もしくはまっさらのDBとコンパイラーを納品して。
後から好きなように変えれます。
といって逃げろ（ｗ
0277NAME IS NULL
03/12/01 17:09ID:???「分からない・・・
0278NAME IS NULL
03/12/01 19:57ID:???↑
コレ使えるｗ
0279NAME IS NULL
03/12/01 21:27ID:???なんかオブジェクト指向？みたいな感じでテーブルをそれぞれ分けて、
VIEWでバーチャルなテーブルとして提供してあげるみたいなのが有効な
気がしてきますた。
ダメかな？
0280NAME IS NULL
03/12/01 21:56ID:???第３正規化までされている下記テーブルがあったとします。
受注No|商品CD|単価|数量
------+------+----+----
AAAAAA|BBBBBB| 50|100
上記の状態で合計金額(単価＊数量）を求めるとき、
1. SQLで求めるのが普通ですか？
SELECT 単価*数量 AS 合計 FROM HOGE WHERE〜
2. それともアプリケーションで単価列と数量列を取得して
計算しますか？
SELECT 単価,数量 FROM HOGE WHERE〜
合計 = xxx.Fields("単価") * xxx.Fields("単価")
どちらがいいか？理由も教えて下さるとありがたいです。
その他にやり方もあれば、ご意見願います。
0281NAME IS NULL
03/12/02 02:31ID:???帳票なら1。ただしストアド。速度が全く違うから。
入力画面なら読込時でなく変更イベントで2。
ちなみに単価が端数になることはよくあるので、
金額を保存しない基幹業務はまず考えられない。
逆に単価を保存せず、そっちを計算値で表示するということはある。
0282NAME IS NULL
03/12/02 03:05ID:MlG23vfJ受注ﾅﾝﾊﾞｰ＝受付日＆（店舗番号）＆整理番号
単価＝顧客コード（商品区分SELECT料率区分S＊料率）（特定区分は言い値）
＜商品区分：０〜99＞：１００ありゃ十分。＞
TRANSACTION⇒SQL（SYBASE）
請求系⇒実行体⇒SYBASE：ではいかが？
（請求系はマスター総なめなので、1.5億円ぐらいなら（実例）２時間）
（TRANSACTION系なら問いあわせ（実例）10秒）
＜＜クライアントSUN：ULTRA ENTERPRRISE450：ｸﾗｲｱﾝﾄ：ULTRA5：5〜6＞＞
顧客マスターにより：売上地区：営業マンID：DE URIAGE＿RANK系の（日報＆月報が可能）
0283NAME IS NULL
03/12/02 17:59ID:???従業員コードと部署コードのような関係と、
従業員コードと(担当する)取引先コードのような関係を、どのようにして分別
をつけるかってのは意外と難しい問題になることがあるのかもね。
何を持って一対多の関係を考慮するべきなのか。
あんまり想像力豊かなのも困るしねぇ。
0284NAME IS NULL
03/12/02 21:58ID:8caVKpbN一昔前のC/Sなら負荷分散を考慮してクライアント側（アプリケーション）で
やったかもしれない。
WebならDBサーバにやらせる（SQLでやっちゃう）
0285NAME IS NULL
03/12/02 22:32ID:6WLRo4dXそれならWebの場合DBの付加分散のためにアプリケーションサーバで
処理するってアイディアにはならない？
DBよりアプリサバの方が負荷分散簡単だし。
0286284
03/12/02 23:04ID:8caVKpbNうん。。。？
一概にはいえんけど、サーバ性能やネットワークトラフィックなど
インフラまで考慮するとアプリケーションサーバでやるかもしれん。
でもそこまで考えてプログラム設計するPGもいないんじゃない？
結局テーブルのジョインとかはDBサーバでやるでしょ？
サーバカーソルのほうが断然早いし。
ならSQLで対応出来るところはDBサーバでやりましょう的なノリになると思う。
（あくまで通例の場合ですよ）
逆にアプリケーションサーバで処理するときのメリットがあれば教えてほしいです。
0288285
03/12/02 23:45ID:???スレ違い風味なのでsage。
SQLで対応できるならDBサバでってのは全く同意なんだけど、
負荷が気になる場合はアプリサバをブレードとかにしたら楽かなと
ちょっと思ったので。あんまし深い意味はないです。
＊強いて＊アプリサバで処理するべきだと主張するなら、
よりオブジェクティブで単機能のAPIを整備可能な設計になるってことかな。
DBへはデータを取りにいくだけってことにしちゃえば、
機能(合計金額を求めるとか)は基本APIとして作った方が使い回しが効く。
# >>280 の例示にあるように、受注取り出しに常に合計金額の算出が
# 付随するような場合は分ける必要はないけど。
0289NAME IS NULL
03/12/03 00:46ID:???まったくどーでもいいことだが
× 合計 = xxx.Fields("単価") * xxx.Fields("単価")
○ 合計 = xxx.Fields("単価") * xxx.Fields("数量")
ですね。
02901
03/12/06 01:21ID:pWhb2iV/こんなにレスが伸びてるとは思わなかった（本音）
正規化・データモデリング・パフォチュー・リカバリ・・・
データベース管理者で喰っていく限り常時悩まさせるテーマかも
しれませんね。
0291NAME IS NULL
03/12/07 02:03ID:???体系立てられた勉強もせずに2000秋からPostgresで運用始め
かれこれエセDB屋3年。今はSybaseメイン。
教科書通りのセオリーが通用しない場面なんて腐るほど出てくるし
どんなに用心して設計してもある夜突然テーブル切り直してマイグレーション大会。
それでも教科書の知識は役に立つ。
ちうわけでROMに戻りまつが時々カキコしまっす。
0292NAME IS NULL
03/12/23 14:52ID:xxg1g8Ixテーブル設計の基礎の基礎である正規化すらできていないテーブル設計をして
いっぱしの技術者のつもりかよ。
第一正規型すら満たさずに何が冗長性だ。
0293NAME IS NULL
03/12/23 17:54ID:dkEzvndk人事系の業務だと部署と社員はN:Nだと思うべし。
N:Nを前提に、如何に関連表を作るかが勝負。
0294NAME IS NULL
03/12/23 21:30ID:???だったら「部署」と「社員」の間に「所属」を入れろ。
そうすれば1:Nになる。
基本も知らずに何が勝負だ。
ER図くらいかけトーシロが。
0295NAME IS NULL
03/12/23 22:41ID:???じゃあER図見せろと言うとそんなものは無いといわれる。
せめてテーブル定義見せろと言うとなんかExcelで作った
ﾃｷﾄｰな表が出てくる。
コード体系表は無いのかと言うとやはり無いといわれる。
どーせいっちゅーねん
0296NAME IS NULL
03/12/23 22:57ID:???0297NAME IS NULL
03/12/23 23:21ID:???すみません、とーしろ何ですが、間に「所属」を入れると
なんで1:Nになるんですか？
0298NAME IS NULL
03/12/24 03:35ID:1bK7NfoFだから、所属だけで済む場合も有るし、ERPレベルになると
顧客と社員が繋がったり、関連表（所属も含む）から勝負だと
言ってる。馬鹿。
0299294
03/12/24 12:14ID:9pkx9jnx馬鹿って言ったか、この馬鹿。
カーディナリティの話をしてるんだろうが、この馬鹿。
お前は恥ずかしげもなくN:Nが前提だとか偉そうに語ったろうが、この馬鹿。
お前は基礎すら身につけていないことがバレバレなんだよ、この馬鹿。
自分の無知に気づきもせずいっぱしの仕事をしているつもりか？、この馬鹿。
「顧客と社員が繋がったり、関連表（所属も含む）から勝負」だと？、この馬鹿。
そんなのは外部スキーマの話だ、この馬鹿。
実のない言い訳をする時間があるなら入門書でも買ってこい、この馬鹿。
0300294
03/12/24 12:19ID:???一人の社員は複数の部署に所属する。
ひとつの部署は複数の社員が所属する。
ひとつの所属は１人の社員と１つの部署を関連付ける。
よって、社員：所属：部署は1:N:1になる。
表に落とすとこんな感じ↓
”所属”の主キーは｛社員コード、部署コード｝になるから、
異なる部署コードをもてば、重複して同じ社員コードを持つことが許される。
↓
ひとつの社員タプルは複数の所属タプルから参照される。
ひとつの所属タプルはひとつの社員タプルを参照する。
だから”社員”:”所属”は1:N
”部署”と”所属”も同じ。
0301NAME IS NULL
03/12/24 13:18ID:???言ってるから、そこには当然>>294の言う「所属」を含めてのことだと取れる。
なんかさ、>>293を無知扱いして偉そうなこと言いたいだけでしょ?
物知りを誇示したがるのは、知識や技術はあるけれど、技術者としての経験や自信のない
人間がする振るまいの典型だよね。頭でっかち。
0302294
03/12/24 20:54ID:???初歩的なことを言ったつもりなんだが、物知りに見えますか。
おれに知識や技術があると言ってくれるのか。
頭でっかちは本物の技術者への第一歩だ。
おれを責めてるんだと思うが、しかし同時に褒めてるぞ。
0303NAME IS NULL
03/12/25 00:03ID:???0304NAME IS NULL
03/12/25 00:05ID:???社員テーブル(PK:社員CD) 部署テーブル(PK:部署CD)
=======+======== =======+========
社員CD | 社員名 部署CD | 部署名
=======+======== =======+========
1001 | 佐藤 1001 | 総務
1002 | 鈴木 1002 | 経理
1003 | 田中 =======+========
1004 | 木村
=======+========
(A) 社員部署テーブル(PK:社員CD,部署CD)
=======+========
社員CD | 部署CD
========+========
1001 | 1001
1002 | 1001
1003 | 1002
1004 | 1002
: | :
1001 | 1002
1003 | 1001
=======+======== ※社員:部署はN:N
(B) 所属テーブル(PK:社員CD,部署CD)
=======+========+========
社員CD | 部署CD | 所属ID
=======+========+========
1001 | 1001 | 01
1002 | 1001 | 01
1003 | 1002 | 01
1004 | 1002 | 01
: | : | :
1001 | 1002 | 02
1003 | 1001 | 02
=======+========+======== ※社員:部署:所属は1:N:1
「所属」は受注とかで登場する枝番やラインナンバと同じ???
部署や社員にそれぞれ顧客がつくとなると、めちゃ複雑ですね。
私は複雑になるなら単純にN:Nの状態(A)で管理した方がいいと思うのだけど、
やっぱ豆四郎だからかなぁ。
0305NAME IS NULL
03/12/25 00:25ID:???んで、社員テーブルと部署テーブルが別にあって、
(A)の形の所属テーブルをつくるわけ。
0306NAME IS NULL
03/12/25 00:29ID:Y2e8eXh4俺も(A)でいいと思うけどな。
『社員部署テーブル』を主キーの要素だけにしてるってことは
第４正規化まで出来てると思うし。
0307NAME IS NULL
03/12/25 00:32ID:???そもそも『所属』ってどこから出てきたんだっけ？
社員CD+部署CDの複合KEYでユニークになるなら
所属なんていらねーじゃん。
0308294
03/12/25 00:59ID:???>>304
なんか変なこといってるな。
(A)でいいんだよ、(A)の社員部署テーブルがおれの言う所属テーブル。
ER図を書くとこうなる。
社員→所属←部署
(B)はどっから出てきたんだ？
>>305はわかってくれてるようだ。
0309304
03/12/25 01:16ID:???> (B)はどっから出てきたんだ？
所属を無理矢理理解しようと思ったらああなりました。
でも、勘違いしてたみたい。
てか難しと思ってたからちょっと変に考えすぎてたかも。
やっと話がわかったっす。
0310294
03/12/25 01:21ID:???社員：所属：部署はN:1:Mじゃないよ。
社員：所属と所属：部署を別にして書いたほうがよかったな。
１：Nと、M：１ね。
じゃ、あとはよろしく。
0311NAME IS NULL
03/12/25 03:21ID:S9tI5Cer症状と原因とを分けて分析する訓練してるか？
0312NAME IS NULL
03/12/25 17:27ID:???0313NAME IS NULL
03/12/26 00:22ID:5ul9Dsx2氏ねボケ
0314NAME IS NULL
03/12/26 01:32ID:???馬鹿はシカトしませう。
0315NAME IS NULL
03/12/26 07:59ID:???0316NAME IS NULL
03/12/26 15:26ID:nQsH/ozH0317NAME IS NULL
03/12/26 23:20ID:???釣りか
0318NAME IS NULL
03/12/26 23:45ID:???0319NAME IS NULL
03/12/27 00:30ID:???で、とりあえず稼動させて２次３次案件と発注される。
そんな時ＤＢがキッチリ正規化されていると開発コストが
かなり抑えられる。
0320NAME IS NULL
03/12/28 00:53ID:???0321NAME IS NULL
04/01/09 17:53ID:???・・・つーか泣けた
0322教えて下さい
04/01/24 18:23ID:7mE+Fkrm１．テーブルの数を減らせる
２．データベースの冗長性と矛盾を避けることができる。
３．データベースの検索性能をより向上させることができる。
４．データベースのセキュリティを高めることができる。
５．テーブルの列をまとめることができる。
どれが正しいのか教えて下さい。。
0323NAME IS NULL
04/01/24 20:15ID:UtaNFL+t１->むしろ増える
２->その通り
３->更新速度は上がるが検索性能はあがらない
４->セキュリティと関係無し
５->なにそれ
0324教えて下さい
04/01/24 21:16ID:7mE+Fkrmついでによければ、「現代社会における理想的なデータベースとはどのようなものか」
教えていただけませんか・・
0325NAME IS NULL
04/01/24 21:52ID:???0326NAME IS NULL
04/01/24 22:20ID:???人並みの仕事をしているつもりか？マヌケな野郎だ。
そうやって無駄に複雑なSQLでしかデータを取り出せない冗長性だらけで
現実のモデルとかけ離れたテーブル作って
周りに迷惑かけてろや。
どうせお前は現場でオラクルの使い方をかじっただけでデータベースの設計ができると
勘違いしちゃったクチだろ？
金槌の使い方を覚えただけで自分が建築技術者だと
言ってるようなものだ、恥ずかしい奴だな。
お前のような見込みのないシロートに業界に居座られると迷惑だ。
どうせソフ開すらもてないような奴なんだろ？資格は必要ないとかいってな。
そんな調子だからいつまでたっても自分の無知に気づかないんだよ。
0327孫悟羽愚 ◆9B5ELldDBw
04/01/25 16:31ID:a+lnz2Fb0328NAME IS NULL
04/01/25 17:23ID:???いくらでもある。まず本屋へいけ。
0329NAME IS NULL
04/01/26 11:50ID:???ﾋｷｺﾓﾘには家から出ることから教えないとダメだぞ
0330NAME IS NULL
04/01/26 21:50ID:???Amazonとかで手当たり次第買えば、外に出なくてもいいぞ。
0331NAME IS NULL
04/01/27 03:26ID:???（画像がほしけりゃイメージ検索つかえ）
0332NAME IS NULL
04/01/29 10:24ID:29eGoArDハッシュジョインとスタークエリーについて、実際のＳＱＬが書いてある
わかりやすいおすすめサイトがあったら、教えてください。
0333NAME IS NULL
04/01/29 10:47ID:???ここらへんなんか、いいかも
ttp://www.pursue.ne.jp/jouhousyo/sysad/sysad012.htm
ttp://www.pursue.ne.jp/jouhousyo/sysadSeikika/sysadSeikika_A.htm
ttp://www.wakhok.ac.jp/DB/chapter2.7.html
0334NAME IS NULL
04/01/29 11:47ID:???> ttp://www.wakhok.ac.jp/DB/chapter2.7.html
これの問7がなぜウになるのかわからない
表A:商品コード 商品名 単価 仕入先コード
表B:仕入先コード 仕入先名 仕入先住所
の二つのテーブルじゃダメなんだろう?
誰か解説きぼんぬ
0335NAME IS NULL
04/01/30 09:10ID:BMBTFGtDhttp://www.pursue.ne.jp/jouhousyo/sysadSeikika/sysadSeikika_A.htm
http://www.wakhok.ac.jp/DB/chapter2.7.html
0336NAME IS NULL
04/01/30 10:00ID:???直リンかよｗ
0337NAME IS NULL
04/01/30 10:13ID:6RXzcdIN表Aの主キーは｛商品コード、仕入先コード｝だ。
それはわかるな？
で、非キー項目である｛商品名、単価｝は商品コードに
関数従属している項目だから、主キーに部分関数従属することになる。
つまり、表Aは第１正規形なので正規化が不十分だ。
0338334
04/01/30 10:47ID:???ttp://www.pursue.ne.jp/jouhousyo/sysadSeikika/sysadSeikika_Q.htm#問07
↑正しくはこっち。
>>337
もう一回質問を整理します。
商品コード 商品名 単価 仕入先コード 仕入先名 仕入先住所
を正規化すると
表A:商品コード 商品名 単価 仕入先コード
表B:仕入先コード 仕入先名 仕入先住所
ではなくて
表A:商品コード 商品名 単価
表B:仕入先コード 仕入先名 仕入先住所
表C:商品コード 仕入先コード
となぜ表Cが必要なのかが分かりません。
一つの商品が複数の仕入先から購入されるのなら話は分かるのですが
問いには「一つの仕入先から複数の商品を仕入れている。」としか
書かれていません。
0339暇人
04/01/30 11:40ID:???明示されてないからな。
主キーについては｛商品コード、仕入先コード｝が主キーだと明示されている。
だから、普通に｛商品コード、仕入先コード｝を主キーとした正規化をするのが確実だよ。
0340334
04/01/30 11:57ID:???あ、わかりました。
そうか、商品コードと仕入先コードで一意に決まるとなると
{商品コード 仕入先コード} 商品名 単価
では商品名と単価が繰り返し項目になってしまうのですね。
そうかそうか。
ありがとうございました。
0341暇人
04/01/30 12:35ID:6RXzcdIN0342NAME IS NULL
04/01/30 13:06ID:???0343NAME IS NULL
04/01/30 15:27ID:???表A:商品コード 仕入先コード 単価
表B:商品コード 商品名
表C:仕入先コード 仕入先名 仕入先住所
ダメだな、漏れ（ｗ
0344NAME IS NULL
04/02/02 11:24ID:4Ms/z/8yダメじゃないよ。商品が仕入先ごとに単価が異なりえる
だろうと考えたのはいい着眼点。
もともとの問題で、正規化以前のテーブルが
商品コード 商品名 販売単価 仕入単価 仕入先コード 仕入先名 仕入先住所
となっていたのなら、求められる答えは
表A:商品コード 仕入先コード 仕入単価
表B:商品コード 商品名 販売単価
表C:仕入先コード 仕入先名 仕入先住所
になるだろう。ところが、問題の単価はたんに「単価」
とだけなっているから、表Ａに置いたとしても間違いとは
いえないな。まあどっちにしても、この問題は選択肢から
選ぶようになっているから、答えはウになるわけだけど。
もし選択肢がなければ、漏れも343のように考えただろうな。
0345NAME IS NULL
04/02/02 23:54ID:???時制DBじゃないと使い物にならん。
0346NAME IS NULL
04/02/02 23:56ID:???・・・そういう事を勉強するのﾏﾝﾄﾞｸｾ
0347NAME IS NULL
04/02/04 11:18ID:???>>343はそこまで考えてないだろう(w
0348343
04/02/05 02:56ID:???考えてるよ（ｗ
というより、345の考え方に近い。
マスタに単価を入れる事自体が間違い。
途中で単価が変わった場合、金額計算は出来なくなるし
運用で逃げる（調整項目を設ける）では、実態を表した帳簿とは言えないから
間違い無くシステム監査に引っかかる（帳簿の体裁をなしていない）
それに、そんな処理を入れて、かえって複雑にする必要は無いだろう。
と、考えた次第。
このような帳簿の場合、会計基準に乗っ取って作らなければ
単に補助簿が出来るだけになるんだけどね。
0349NAME IS NULL
04/02/10 10:10ID:???NDB>>>>>>>RDB
ということなんだね
0350NAME IS NULL
04/02/25 19:03ID:???テーブルひとつで済ましました方がかえって楽？
データの入力は顧客自身がするので、マスタの入力はめんどくさがりそうで・・・。
商品番号、メーカー 、商品名 、型番、 定価 、売価 、在庫数 、
入荷予定日 、商品解説 、商品写真 、登録日、 更新日
0351NAME IS NULL
04/02/25 21:45ID:???プログラムでそこから取得した列名を使ってSQLを生成しようとしています。
例えば、select A B C from T というSQLを、
select A C D from T というSQLに変更したいとき、
列名を管理するテーブルに
A,B,C と登録されているのを
A,C,D と変更することにより行いたいのです。
(BをdeleteしてDをinsert）
こんなふうに、列名を管理するやり方を見たことありますか？
何か問題があればご指摘ください。
0352NAME IS NULL
04/02/25 23:00ID:???わしならちゃんとテーブルを正規化してしまって
メンテ画面を使いやすいようにつくる。
テーブル構造をそのままむきだしでメンテ画面に
するからおかしくなる。
>>351
好きにすればよかろう。何か問題を感じているのか？
0354NAME IS NULL
04/02/26 01:36ID:???見たことあるっていえばあるけど。
参考までに何でそんなことしたいのか教えてくれるかな。
0355NAME IS NULL
04/02/26 09:10ID:???メリットが無いとはいえないけど、自前でやろうとするとそれなりに時間もかかるし効率が良いとは思えない。
DBをリバースエンジニアリングしてクラスにマッピングしてくれるようなツールを使う方が吉かと。
0356351
04/02/27 02:07ID:???特に問題は感じていません。何となく気になっただけです。
理由も無く聞いてすみません。
>>354
あるテーブルのデータのうち、使いたいもの（列）の組み合わせが
提供したいサービスの種類によって数パターンあって、
例えば、サービス１の処理をしたいときは列A,B,Cのデータを、
サービス２の処理をしたいときは列B,D,Eのデータを操作したいのですが、
その組み合わせ時々変わる可能性があるので（サービス２でB,D,Zを使うようになる、など）
できるだけプログラムを変えずに対応できるようにしたいのです。
そこで、サービスｎと列ｘとの対応を管理するテーブルを作ろうということになりました。
>>355
管理したいテーブルは１つなので（500くらい列がありますが）、
今回は自前でやることになると思いますが、
何か便利なツールをご存知でしたら教えて下さい。
それから、質問スレッドと間違えてこっちに書いてしまいました。
失礼しました。
回答下さった方、ありがとうございました。
0357354
04/02/27 22:22ID:???そんな理由ならまあいいか。
自分だったらテーブルにするより定義ファイル作っておしまいにしちゃいそうだけど。
そのほうが楽だし。
聞いた話だけど、同じようなことを業務システムの全テーブルについて行ったものがあったそうです。
詳細はよくわかりませんが、関係者曰く「二度と関わりたくない」ものだったそうです。
0358NAME IS NULL
04/02/28 11:03ID:???>あるテーブルのデータのうち、使いたいもの（列）の組み合わせが
>提供したいサービスの種類によって数パターンあって、
ビューを使うのじゃダメなの？
それがダメなら、3階層C/S的にそのサービスとDBの間にもう1段噛ますべきでしょう。
0359NAME IS NULL
04/02/28 11:33ID:QTIAAY4r0360NAME IS NULL
04/04/21 23:37ID:???DBMSは異常なほど知ってはいたが、正規化？はにゃ〜ん？
っていう人は結構見た
開発やっててもレコードセットやデータ構造程度にしか
見てない人ばかりだったね。
あっはは。
0361NAME IS NULL
04/04/28 00:11ID:yGaCVK3lある意味ベンダーの研修に洗脳されている人種かもしれん。
データベースの物理設計のカテゴリがいかに重要だとゆーことを
SIerは再認識すべき課題かとも思う。
0362NAME IS NULL
04/04/29 01:51ID:???0363NAME IS NULL
04/04/29 23:52ID:Cd2p5FCFおら！オラ！オラクルっつー本を読んだら
インデックスの更新はさほどコストがかからなくて、
インデックスがデフラグ状態になったときに
インデックス検索よりフルスキャンの方が速くなるということが
書いてあった。
実際インデックスのせいで更新系が遅くなったこと
ある人いますか？
0364224
04/04/30 00:00ID:EQyECvc4すいません。オレの周りにそういうことをよく言う奴がいた、
っちゅうことです。
0365NAME IS NULL
04/04/30 00:52ID:T27hzrmoインデックスにしている列を更新すれば遅くはなるでしょうね。
データとインデックスの双方更新するわけですから。
ビットマップインデックスに対する更新は特に遅いと風の噂で
聞いたことがあります。
0366NAME IS NULL
04/04/30 02:11ID:???ただ、更新の為に更新する行を探し出す必要があるわけだから、
インデックスがあった方が(それが有効に働く場合)速いわな。
単純に新規挿入されるのならインデックスなしの方が速いだろうけど。
インデックスの更新にさほどコストがかからないということは、その分
手を抜いた更新になっているわけで、デフラグ状態陥りやすい。
インデックスを基にした統計情報も逐次更新されるわけではないので、
的便お掃除&整頓しなきゃ、ダメっすね。
で、これって更新系だけじゃなくて、SELECTやDELETEもWHERE句が
あれば遅くなってしまうのだが。
と、PostgreSQLのインデックス更新の話をちょこっと聞いただけなので、
詳しくは知らんし、Oracleならもうちょっとマシな更新をしてそうだけど、
さほど変わらんのかな?
0367NAME IS NULL
04/04/30 11:09ID:Z9jvLrWB0368366
04/04/30 12:37ID:???フラグメンテーションを直すのがデフラグだから全然意味が違うな。
0369224
04/04/30 23:02ID:vP3ucElkそう。フラグメント状態です。ボケてました。つっこみありがと！
インデックスの更新という余計な手間をかける場合
なにもしないより遅くなるのは当たり前ですが、
それが体感できるくらい遅くなるものなのか？という疑問なわけです。
ってわかってくれていると思うけど。
ビットマップインデックスの更新が遅いという話は、なるほどと思いました。
0370NAME IS NULL
04/05/01 01:51ID:???テーブルの全レコード数に対して検索の結果行数がある割合を
超える場合はインデックススキャンよりシーケンシャルスキャンの
方がコストが低いというのはわかるな？
インデックス順に対してレコードが多くのデータブロックに分散
している状態ではその閾値が低くなるということだ。
0371NAME IS NULL
04/05/02 23:44ID:wRvFO8Blアホな質問だが
シーケンシャルスキャンて初めて聞いた単語だけど、
テーブルのフルスキャンをORDER BYを指定して検索すること？
0372NAME IS NULL
04/05/05 17:09ID:???第4正規化、第5正規化
とかいうやつをやった人っていらっひゃいます?
0373NAME IS NULL
04/05/06 01:48ID:???第４正規化までやるとしたら、それはリソースとパフォーマンスなどを
トレードオフした結果論でしょうね。
ある意味ここまでエンドユーザに提示してあとは査定して下さい（ｗ
みたいな。
私が最近面白いと思うのは結果論（ある意味極論）を提示したとき
素直なお客さんはお金払い良いけどね。
0374NAME IS NULL
04/05/07 16:48ID:???0375NAME IS NULL
04/05/22 18:27ID:???DBの技術的な話を理解してくれるお客さんあったことがない。
うらやましぃ
0376NAME IS NULL
04/05/24 00:43ID:79+dFvzWもうダメポ・・・
0377NAME IS NULL
04/05/24 15:55ID:wmDKM+ij東京の地下鉄路線図よりからまりまくりのスパゲティ状態よ。
ER 図を見やすく再配置するのに 1 日かかったよ。
で、これも正規化ですかね？
このへんってパフォーマンスとの兼ね合い、
フロントエンドの負担もあるんだよなー
0379NAME IS NULL
04/05/28 16:44ID:???テーブル開くだけで、2, 3分固まりますが、何か? :-P
はっきり言って、無能すぎ（ｗ
やはり、プログラミングできねー香具師には仕様云々は（略
というより、どんな作業してもヴァカなことをやるんでしょうねぇ :)
0380379
04/05/28 16:50ID:???1〜10になってるのが4つ → 4 * 10 = 40フィールド
1〜10の中にさらに1〜10と入れ子になってるのが1列。→ 1 * 10 * 10 = 100フィールド
12 + 40 + 100 = 152フィールド。
そりゃ、Pen4でも2, 3分固まるっつーの。
0381NAME IS NULL
04/05/28 19:11ID:Zb+elczzどうもRDBMSの概念を理解している香具師がおらん。
最大値を拾って、webページのカウンタやってみたり、
同じデータが入った項目が多数存在したり・・・
これを見て採用辞退したといって通るモノだろうか？
0382NAME IS NULL
04/05/28 19:59ID:???ちみが流れを変えるしかないでしょう。
しかし、その程度の技術しか持たない香具師らに対して啓蒙と教育活動を
していくのに対して異常に神経を使い、自分が磨り減ってしまうのもまた事実。
0383NAME IS NULL
04/05/29 02:35ID:Eu/3LWqK12ヶ月*20項目=240+αのカラム数って・・・。
全部横持ちすんなよな。
insert文がえらいことになってしまった。
こんなSEの下で働きたくねーよ。
0384NAME IS NULL
04/05/29 10:37ID:and4JLX3その会社の営業力は正直すごいな。技術が無くても仕事がとれる。
ある意味よい会社ではないか？
そこに 381 の技術力が加わればオニカナ かもね。
0385NAME IS NULL
04/05/29 11:15ID:EYTKUjAs今眺めている本にはこう書いてあります。
「ボイスコッド正規形とは、表内の行を一意に決定できるのは
候補キーだけの状態。」
納得できないなぁ…
だって、表内の行を一意に決定できる属性の集合
（のうち、余分な属性を持たないもの）が候補キーでしょ？
0386NAME IS NULL
04/05/29 11:19ID:EYTKUjAs「ボイスコッド正規形とは、すべての属性が
主キーにのみ完全関数従属する表」
です。
0387381
04/05/31 17:55ID:???DBM云々かんぬん以前の問題。
今時オープン系鯖にtelnetかよ。よく今の今まで動かしていたなと関心させられた。
0388NAME IS NULL
04/06/01 01:21ID:???0389NAME IS NULL
04/06/01 16:09ID:???0390NAME IS NULL
04/06/01 16:24ID:???やっぱ適度な正規化崩しが必要だな。
0391NAME IS NULL
04/06/01 18:27ID:???ていうか、なんで首が飛ぶ？
0392NAME IS NULL
04/06/03 03:50ID:???冗長性の排除。
おまえは更新異常起こす原因だから、
消えてなくなれ、とか。
0393NAME IS NULL
04/06/03 22:24ID:???今時、それぐらいの酷さはふつうだと覚悟した方がいいかもしれない。
5年ぐらい(自称)DBAとしていろいろなプロジェクトの後始末をしているが、
年々DBの設計がひどくなっていく傾向にあると感じる。
あなたのようなよくわかっている人は後始末係として重宝される。
客からすれば、将来を見越した実装や、データは興味の対象じゃないからねぇ。
今この瞬間動けさえすれば問題なしぐらいの意識だよ。
0394NAME IS NULL
04/06/04 23:06ID:???>年々DBの設計がひどくなっていく傾向にあると感じる。
これ、もう少し詳しく知りたい。なんで年々ひどくなるんだろ。
覚えることが多すぎてＤＢの比重が相対的に減ってんのかな。
0395NAME IS NULL
04/06/04 23:35ID:???が、技術の流行を追いかけるばかりできちんとした設計理論を知らないﾔｼが増えた。
低予算で短納期なプロジェクトも増えてきた。
そんな中集められたのは
理論は知っててもオープン系での実践ができない汎用系出身者と
実践ばかりで理論をしらないWin登場以降の若手技術者。
0396NAME IS NULL
04/06/05 00:35ID:???それと文句だけ言って動かない奴。
0397NAME IS NULL
04/06/05 14:09ID:???家族を食わせていこうと思ったら、もうマネージャになるしかない。
0398NAME IS NULL
04/06/08 22:41ID:???クライアントになるという手もある。
0399NAME IS NULL
04/06/08 23:23ID:kyMCR0Grそれいいよなぁ。俺もエンドユーザに憧れるよ。
一度でいいからプレゼンされる側になってみたい。
0400NAME IS NULL
04/06/09 08:54ID:???うちの会社にもいたな。
クライアントが外資系の有名企業で、
そこにヘッドハンティングされたらやっぱ行くよな。
0401NAME IS NULL
04/06/11 00:44ID:???> クライアントになるという手もある。
技術や上がりのエンドユーザか、いい加減なことがいえなくなるけど、
きちんと説明すればわかってくれるいいお客さんになるな。
0402NAME IS NULL
04/06/11 09:44ID:???全部外注にやらせてて、そのサブシステム作るよう言われたんだけど、
フィールド名のローマ字表記の形式は統一されていないし、正規化は
されていない部分が多い。
受注〜だけでJUCHU〜,JUTYU〜,JYUCYU〜の種類がありやがる… orz
0403NAME IS NULL
04/06/12 00:18ID:???きちんと説明できるほどまともな仕事してるか？
うちは全然駄目だ。
まともな客ほどごまかしが効かなくてボロボロになってる。
0404NAME IS NULL
04/06/12 01:00ID:???そんな現場にCORBAをお奨めします。
0405NAME IS NULL
04/06/12 05:44ID:Sn0QQyxZ（（ ）） ））
）） ）） （（ ,.-､,.-､_,.-､_
）） （（ （（ .,.-､,.-､_,.-､ ´_ゝ`）ヽ
（（ ）） ,.-､,.-､_,.-､ ´_ゝ`）ヽ:.:.:.:..:.::.）
,.-､,.-､_,.-､ ´_ゝ`）ヽ:.:.:.:..:.::.）￣￣
,.-､,.-､_,.-､ ´_ゝ`）ヽ:.:.:.:..:.::.）￣￣
／ （ ´_ゝ`）ヽ:.:.:.:..:.::.）￣￣
（ .:.:.:..:. : .:.:.:..:.::.）￣
0406NAME IS NULL
04/06/12 06:14ID:???うちWindowsベースなんだけど。
DCOMじゃダメなのか？
0407NAME IS NULL
04/06/12 10:38ID:YoJrTPLB最近DCOMに粘着したワームウイルスがはやってるからねぇ。
0408NAME IS NULL
04/06/13 13:45ID:rgRT/Ze1マスターを変える場合、それ以前のデータは全て確定にしたい。
たとえば年間の集計や月間の集計をとる場合、その途中でマスターが変更されている
正規化されている場合はどうするのかなー。
１）マスターの変更履歴を保存
２）抽出した日時をチェックして更新を反映する。
みたいなことをするのか？
それともマスターは追加だけで削除や変更はさせないようにするのか？
それとも確定データはマスター更新前にマスターもろとも全部保存？
ん？、これだと集計なんかできねーな。
0409NAME IS NULL
04/06/13 19:00ID:RUWtE+Jrデータのほうに集計に必要なマスタの項目はすべてコピーして
持たせるのが一般的かなあ。集計処理も簡単になるしね。
個人的に一番きれいな方法は（1）の変更履歴保存だと思う。
0410kk ◆r0p/Rg8RZU
04/06/13 19:35ID:dw0IFS930411NAME IS NULL
04/06/13 21:55ID:???んだね。マスタに変更が発生したらトリガーで
トランザクションにログを書き出すってのでどーでしょ？
0412NAME IS NULL
04/06/14 14:52ID:Z5RHMZcy＞データのほうに集計に必要なマスタの項目はすべてコピーして
それだと正規化にならんでしょう？ 実は、やり方がわからなくて、
そういうやり方でやっちまったのだが。
＞４１１
>んだね。マスタに変更が発生したらトリガーで
>トランザクションにログを書き出すってのでどーでしょ？
そこんとこ詳しくおせえて。
トランザクションてのは、一連の処理を保障するため途中でエラー
した場合それまでやった処理をキャンセルする機構でしょ。
集計は更新時に一回だけじゃないよ。
ちょっと違うようなきがする。
0413NAME IS NULL
04/06/14 20:55ID:???> それだと正規化にならんでしょう？
馬鹿正直に正規化するなら、マスターの項目のうち、
マスターの主キーのほかに日時にも従属する項目は
（マスターの主キー＋日時）を主キーとする別テーブルに分けるべきだ。
あまりお勧めしないが。
0414NAME IS NULL
04/06/14 21:33ID:???マスタと同じ項目を持っていたらどんな場合でも非正規化になるわけじゃないよ。
例えば、製品マスタの単価はあくまで現在の単価だけど、売上テーブルの単価は
製品を売ったときの単価。同じ単価でも意味が違えばそれは違う項目。
0415NAME IS NULL
04/06/15 13:00ID:JP7MgTZ9なんとなくわかるような。価格の場合そうだろうね。
顧客ID 名称 住所
の場合に住所が変わるケースはたまにあるよね。
住所を全部埋め込むのは勿体ないきがするし。
こんな場合は住所はこのマスターからは分けるべきか？
ここでいうトランザクションとは、いわゆる
RDBMS機構のトランザクションのことではなく
「一連のやりとりを日時・セッション別に記録したログ」
のことと思われ。けっこうあちこちの現場で聞くので方言ではないだろう。
マスタ以外にログ作っとくと、なにかと便利よ。
0417411
04/06/17 13:44ID:T4SLT8iK遅レスすまん。あと、言葉が足りひんかった。
業務仕様はよく分からんけど、
マスターのテーブルにINSERT/UPDATE(DELETE)のデータベーストリガーを
作っておいて、データベーストリガーではトランザクションテーブルに
INSERTしていくってな仕組みを作る。
そうすればDWH的に何でも対応できそうな気がした。
0418NAME IS NULL
04/06/17 23:27ID:???名前、種族、職業、年齢、経験値（レベル）、お金、状態（死とか灰とか）
腕力、知力、精神力、すばやさ、体力、運
アイテム ８こまで。（アイテムの状態＝不明・装備・のろい）
0419NAME IS NULL
04/06/17 23:49ID:???-----------+-----+-----+----+-------+-----+-----+------+--------+-----+---+-------
キャラクタCD | 名前 | 年齢 | お金 | 経験値 | 腕力 | 知力 | 精神力 | すばやさ | 体力 | 運 | 職業CD
状態Tbl
-------+-----
状態CD | 状態名
キャラクタ状態Tbl
-----------+--------
キャラクタCD | 状態CD
アイテムTbl
----------+-----------
アイテムCD | アイテム名
アイテム状態Tbl
--------------+-------------
アイテム状態CD | アイテム状態
アイテム-アイテム状態Tbl
----------+---------------
アイテムCD | アイテム状態CD
キャラクタアイテムTbl
-----------+-----------------------+-----------
キャラクタCD | アイテムスロット番号(<=8) | アイテムCD
0420NAME IS NULL
04/06/18 00:43ID:???それだと同じアイテムは全部同じ状態になるけどそういうものなの？
ウィザードリィをよく知らないんだけど。
0421WIZ大好き
04/06/18 22:17ID:Fot6gVKU職業マスタ
-----------------------------------------------------------------
職業CD｜職業名｜転職可能能力（腕力|知力|精神力|すばやさ|体力|運）
アイテムCDマスタ
-----------------------------------------------------------------
アイテムCD｜アイテム名｜価格|装備可能部位｜装備可能職業
｜特性値（攻撃力など）｜特殊効果CD
0422NAME IS NULL
04/06/18 22:34ID:???ぱっとみて思いついたこと。穴がありそう。
（１）１つのアイテムに特殊効果は１つしか持てないけどいいのか？
（２）１つのアイテムに装備可能職業は１つでいいのか？
（３）例えば攻撃できないアイテムの攻撃力はNull？
（４）装備できないアイテムの立場は？
（５）職業に特徴はないのか？
ともあれマスタ２つだけでは何とも評価できない。
全部書き出してほしい。
0423419
04/06/18 22:39ID:???；TДT)ｱﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞほんとだ。じゃこれでどうだ
アイテムTbl
----------+-----------
アイテムCD | アイテム名
アイテム基本状態Tbl
----------+----------------
アイテムCD | アイテム状態CD
アイテムインスタンスTbl
--------------------+------------
アイテムインスタンスCD | アイテムCD
アイテムインスタンス-状態Tbl
--------------------+---------------
アイテムインスタンスCD | アイテム状態CD
キャラクタアイテムTbl
-----------+-----------------------+--------------------
キャラクタCD | アイテムスロット番号(<=8) | アイテムインスタンスCD
アイテムインスタンスは敵からもらうとか宝箱を開けるとかのイベントで
生成されて、アイテム使用などで破棄される。アイテムインスタンスは
アイテム基本状態Tblから"装備部位"などの基本状態を受け継いで、
追加の属性があれば何らかの規則にしたがって追加される。
同種のアイテムはまとめてもてる仕様だったらスマソ。これじゃ対応できんねぇ。
0424NAME IS NULL
04/06/19 07:50ID:OHujBfWT1. キャラクタマスタ
(ID・名前・種族CD・職業CD・年齢・経験値・金・状態・腕力・知力・精神力・すばやさ・体力・運)
2.種族マスタ
(種族CD・種族名)
3.職業マスタ
(職業CD・職業名)
4.アイテムマスタ
(アイテムCD・アイテム名)
5.状態マスタ
(状態CD・状態名)
6.アイテムテーブル
(ID・アイテムCD・状態CD）
0425NAME IS NULL
04/06/20 16:03ID:po3I7fVkIDとCDって区別してるかい？
0426NAME IS NULL
04/06/20 19:45ID:???同じアイテムを２個以上持てないのが気になる。
0427NAME IS NULL
04/06/22 09:22ID:???アイテムCDとは別にIDをふって、そっちを主キーにしてるってことなんだろ。
アイテムテーブル
----------------
ID アイテムCD
1 100
2 100
0428NAME IS NULL
04/06/22 19:26ID:???IDってキャラクタマスタの主キーになってるフィールドだとおもう。
でないと、キャラクタとアイテムを関連づけるテーブルがないことになる。
0429NAME IS NULL
04/06/23 14:29ID:???あ、本当だ。キャラクタマスタにも「ID」がある。
てっきりキャラクタマスタの主キーに「キャラCD」でもあるのかと思ってたよ。
とすると、確かにCDとIDの使い分けが謎だな。
0430NAME IS NULL
04/06/24 01:03ID:???正規化しないテーブルの方がましかもしれない。
格納できない情報が出るようではどうしようもない。
0431NAME IS NULL
04/06/24 06:26ID:???キャラ名, 年齢, お金, 経験値, 所持アイテム, ...
もょもと, 20, 500, 16777216, 001040080, ...
アイテムテーブル：
アイテムID, アイテム名
001, やくそう
002, たいまつ
040, どくけしそう
080, はかいのつるぎ
120, くさりかたびら
このもょもとは、いま「やくそう」と「どくけしそう」と「はかいのつるぎ」を持っています。
キャラクタテーブルの所持アイテムの桁数を 所持限界アイテム数 * 3 、
例えば8個までなら24桁にすればOK。所持限界数を増やしたいときは
桁数を増やすだけで済むから拡張性もバッチリです。
0432NAME IS NULL
04/06/24 08:25ID:???すごい!!
目から鱗って感じ。
まともなSQL書くとやってられなくなるだろう、きっと。
ﾈﾀにﾏｼﾞﾚｽ（ ・∀・ ）ｶｺﾜﾙｲ(´・ω・`)
0434431
04/06/24 18:57ID:???DAO の Recordset でキャラテーブルを開いて所持アイテムの列を 3文字ごとに切り出し、
アイテムテーブルを seek メソッドで検索すれば非常に高速に所持アイテムを一覧できます。
0435NAME IS NULL
04/06/24 19:52ID:???そんなまねするくらいなら3桁の項目を8つ持った方がまし。
0436424
04/06/24 22:05ID:2XzNgdAE個数を保有するなら６（アイテムテーブル）でしょう。
ほら、第３正規化までやっとくと、後から項目追加になっても
楽になるでしょう。
ちなみにIDはキャラクタIDのこと。
（すまん、CDとIDの使い分けは特に意味なし）
0437NAME IS NULL
04/06/24 22:14ID:???同じアイテムは1つしか持てないって前提は普通しないと思ったんだな。
でもそれは正規化以前の問題だから、ここでは関係ないやね。了解。
それはそうと、アイテムテーブルに個数ってフィールドを足すんだね。
そうすると同じアイテムを２個もってるときに、1個だけ装備できないよ。
0438424
04/06/24 22:34ID:2XzNgdAEただ、437さんの『同じアイテムを２個もってるときに、1個だけ装備できない』て
ことは無いでしょう。
例えば、
状態マスタ
(状態CD・個数）
01・装備
で、
アイテムテーブル
(ID・アイテムCD・状態CD・個数）
001・002・01・2
にすれば、
アイテムCDが002であるアイテムを２個装備していることになりますね。
0439NAME IS NULL
04/06/24 22:43ID:???アイテムCD 002を2個持ってるときに、1個装備して1個装備しないってのができないかと思った。
（ID・アイテムCD）が主キーだと思ってたけど、もしかして（ID・アイテムCD・状態CD）が主キー？
それならできるね。
でも主キーがそれだとするとアイテムが複数の状態を持てないね（呪われたアイテムを装備とか）。
仰せの通り、要件定義をはっきりしろってところに落ち着くけど。
0440424
04/06/24 22:57ID:???『主キーがそれだとするとアイテムが複数の状態を持てない』
であれば、状態マスタに装備を持たずにアイテムテーブルに装備のOFF/ONの列を
追加すれば対応できますね。
状態マスタ
(状態CD・個数）
00・正常
01・呪い
02・故障
アイテムテーブル
(ID・アイテムCD・状態CD・個数・装備）
001・002・00・1・1
001・002・01・1・1
（装備の列は1:装備中 0:未装備）
てなかんじですかね。勿論装備品以外のアイテムは0
まぁでも正規化すれば後からどんどん仕様変更（追加）が発生しても
ある程度は柔軟に対応できますよね。
0441NAME IS NULL
04/06/24 23:22ID:???それはダメだと思う。
主キーに変更がないとすると、同じ状態のアイテムを2個持ってるときに、
片方だけ装備ってのができない。主キーの値が重複するから。
だからって主キーを(ID・アイテムCD・状態CD・装備)にするか？というとどうなんだろう。
仕様変更にはある程度柔軟に対応できると思うけど、そのＤＢを使う既存のアプリケーション込みで考えると、
主キーを変更するような変更には弱いと思う。
あと、状態ってのがよく分からない。状態マスタに格納する値の例がもう少しほしいな。
>>440の例だと、状態マスタに格納するのはアイテム単体で成立する状態みたいだけど、
装備ってのはキャラクタとアイテムがそろって初めて成立する状態だから、
装備を状態テーブルから分けるのは正しそうだけど。
0442NAME IS NULL
04/06/25 00:45ID:???実際ドラクエとかＦＦってC++とかで作られてるんだよね？
まさかあのソフトの中に簡易的なＤＢエンジンも含まれてるのかね？
でも保有情報のアクセスで並列処理は無いだろーからＤＢエンジンは
必要ないか。。
てことはHashTableやVectorを上手く使いまわしてるのかなぁ？
0443NAME IS NULL
04/06/25 09:52ID:???アドレス データ
--------------
00 10 ← HP
01 08 ← MP
：
20 01 ← アイテムコード1
21 01 ← アイテムコード2
22 03 ← アイテムコード3
：
36 40 ← アイテムコード15
37 00 ← アイテムコード16
38 00 ← アイテムコード17
：
大まかに言えば、こんな感じでデータがメモリに格納されてるはず。
0444NAME IS NULL
04/06/26 14:15ID:???>>431
0445NAME IS NULL
04/06/27 17:16ID:???インストールされていた。
数年前、さすがのPC98ノートも液晶の寿命で引退を余儀なくされ、
その際、ナイル上で作った数々のデータをインポートする為に
解析する仕事が私の元に飛び込んできた。
データベースを空けてびっくり、どのテーブルも正規化なんてされて
ませんw
でも、正規化を知らなかった前任者のおかげで
テーブルの解析はとっても楽でした。
0446NAME IS NULL
04/06/28 00:16ID:???悪・中立・善
性格によって装備できないアイテムとかあったり
対立する性格の場合、パーティが組めなかったりするよ
0447NAME IS NULL
04/06/29 00:05ID:pMfaeGQyそれはアイテムテーブルとキャラクタテーブルに属性を保有する
>>対立する性格の場合、パーティが組めなかったりするよ
それはデータベースに保有する必要はない。
アプリケーションでパーティを組むときに判断するべき。
0448NAME IS NULL
04/06/29 00:11ID:???この流れでいけば、パーティテーブルがあるんだろう。
0449NAME IS NULL
04/06/29 00:26ID:???それは流れ重視？
最近なんでもDBサーバにやらせようとする風潮に
ウンザリしてるからさ。
0450NAME IS NULL
04/06/29 09:41ID:???0451NAME IS NULL
04/07/01 16:04ID:???0452NAME IS NULL
04/07/02 00:13ID:???selectも出来んくせによく言うよ。
0453NAME IS NULL
04/07/03 08:48ID:t1hRtxZ6悪(善)のキャラを善(悪)のパーティで回収すりゃ、
善悪混成パーティになるだろうが。
0454NAME IS NULL
04/07/04 02:02ID:???そんなビジネスロジックの話じゃなくて、エンティティとリレーションの話だから。
0455NAME IS NULL
04/07/10 14:12ID:???果物 オレンジ<>ミカン<>リンゴ
飲料 コーヒー<>紅茶<>ココア
こんな風に区切り文字を入れて、複数の内容を突っ込むのは間違ってます？
項目の部分を検索するだけなら、早くなるかなとか思ったんですけど。
0456NAME IS NULL
04/07/10 15:44ID:???という仕様変更に対する作業工数を考えてみたらどうかな。
0457NAME IS NULL
04/07/10 16:39ID:???なるほど、あまり変則的なやり方はするものではないですね。
ありがとうございます。
ttp://www.stackasterisk.jp/tech/dataBase/postgresTuning03_02.jsp;jsessionid=aaZXoAg1vq1h
上記のような記事を読んで、
あまりテーブルを分けたりしない方向でいった方が良いのかなと考えてました。
こう言うのを考えるのはきちんと正規化出来てからですね。
0458NAME IS NULL
04/07/11 01:14ID:???んだ。
検索を高速に行いたいというなら、実データとは別に検索専用のテーブル
かなんかを作るほうがいいんでないかな。
0459NAME IS NULL
04/07/13 00:19ID:???「リレーショナルデータベースでは、基本的には第３正規化と呼ばれる重複した値を
最小限になるようデータをグループ化して表を設計します。
しかし、検索がメインのDSSシステムでは、正規化したままだとパフォーマンスが出せない事があり、
冗長化と呼ばれる正規化したものを崩す設計をします」
と書かれている。
ちなみに作者はあのカリスマインストラクタ、マダム代田佳子タンです。
0460NAME IS NULL
04/07/13 00:35ID:???0461NAME IS NULL
04/07/13 11:43ID:???この正規化と正規化を崩すバランス感覚を持っているとは限らないのが
資格の問題点やね。理論で分かっていても実践で役立たない Oracle マスタ多すぎ。
0462NAME IS NULL
04/07/13 15:31ID:???0463NAME IS NULL
04/07/13 20:00ID:3unH/A06主キー以外全NULLがOKなマスタに主キーがないマスタがちらほらという
糞DBの開発なんてできるかよ・・・orz
案の定重複カラムだらけ・・・・・・・・・・・・
たぶん人生の中で一番ひどいやつだな
誰か助けてくれ、まじで
0464NAME IS NULL
04/07/13 20:54ID:???TRUNCATE TABLE ますた;
0465NAME IS NULL
04/07/13 23:28ID:???お前は二番目に不幸な奴だ。
主キーがあったことを感謝すること。
0466NAME IS NULL
04/07/14 00:12ID:???俺なんかな、主キーは一応あるけどリレーションシップなんか当然なくて、
しかも結合に使うフィールドのデータ型が２つのテーブルで違ってるんだぞ。
普通に結合するだけなのに型変換。時々異常データがあって変換に失敗したりとか。
もういやん。
0467NAME IS NULL
04/07/14 06:58ID:???漏れなんか、主キー・リレーションシップほとんど無しは当然として、
参照元の列 w(bool) が True なら列 x(int)&y(text) を、False なら x&z(int) を
参照先の主キー(相当)の列 a(text) に代入するというファンタスティックなブツを見たことがある。
アプリケーション側で a の値を分離して、w の値によって結合(?)する列を決定するのだ。
((((ﾟДﾟ；))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
いちおう y と z の桁数が違ったので重複は無いようだけど、y は 00123 みたいな
0付き数値が入ってるからz の桁数が y に追いついたらトンでもないことに
なるだろうなと思った。
＃塚これ、表示で 00000123 とか見せたいところは全て TEXT 型で律儀に 0 入れてるよ…
0468NAME IS NULL
04/07/14 23:08ID:???…あ、いいのか。ゴメン
0469NAME IS NULL
04/07/19 21:36ID:???create table 売上 (
年 number(4) primary key,
売上_01月 number,
売上_02月 number,
...
売上_11月 number,
売上_12月 number
);
本によって書いてあることが違うんで困ってます。
0470NAME IS NULL
04/07/19 22:36ID:???どう違うことが書いてあるのか詳細に知りたいな。
とりあえず[売上]が繰り返し項目になっているから非正規形だろう。
CREATE TABLE 売上(
年月 datetime,
売上 long,
CONSTRAINT pkey PRIMARY KEY (年月)
);
こうすれば主キー属性[年月]に全ての属性が従属する第3正規形になるかと。
0471NAME IS NULL
04/07/19 22:42ID:???形式的には第五正規形。
でもそんな使い勝手最悪なテーブルは設計しない。
>>470
[売上]は繰り返しじゃない。
たとえば[売上_01月]と[売上_02月]は交換不可能。
繰り返し項目なら交換しても問題ないはず。
0472470
04/07/20 00:09ID:???Σ(ﾟДﾟ；ﾊｯ確ｶﾆ!!
∧||∧
（ ⌒ ヽ >469
∪ ﾉ ｽﾏﾝｶｯﾀ
∪∪
0473470
04/07/20 23:47ID:???お手元の資料(TEDB3週間)でちょいと調べてみたけど、第5世紀系は結合従属性
〜「正規化して分割された3つ以上の表(仮に x,y,z)を結合するとき、全ての表を
結合しないと元の表(a)には無かったタプルが現れる状態」〜
に分割した3つ以上の表のことの様だから、第5正規形ではない様な?
といふことで >469 の表は「主キー項目(年)に全ての属性が完全関数従属する」第3正規形
が正しいのではないだらうか。
0474NAME IS NULL
04/07/22 00:07ID:???0475NAME IS NULL
04/07/23 22:08ID:???んなあほな。
じゃあ第三正規形ってのは第二正規形から分割された２つの表の事？
「分割した3つ以上の表のこと」というのがどこから出てきたのか気になる。
引用ではなさそうに見えるが。
0476470
04/07/27 00:02ID:???∧||∧
（ ⌒ ヽ 例となる表を用意しようとしたら、再結合したら影像だらけになる表になってしまった…。
∪ ﾉ
∪∪
「分割した3つ以上の表のこと」は、『ある関係 R を分割してできる関係 R1,R2,R3... の間に
結合従属性が成立するとき,この R1,R2,R3... を第五正規形と言う』見たいなことが
3週間本に書いてあったはず。
ｊ３、明日3週間本をもう一回熟読して出直して参る。
0477470
04/07/27 00:04ID:???見つからなくて難儀する。文書ベースだけでなく例となる表も載ってると尚良いのだけれど…。
0478NAME IS NULL
04/07/30 00:24ID:???「第二正規形は第三正規形に分割する途中経過なので、あまり重要ではありません」
と言う旨の解説が…それでいいのか。
0479NAME IS NULL
04/07/30 22:19ID:???0480NAME IS NULL
04/07/31 16:35ID:wijBGoROその参考書で勉強したヤシは秋のシスアド試験受けるんか？
合格したらその論理は正しいかもな（ｗ
0481478
04/08/09 21:58ID:???うちの同僚誰も初級死すアドすら取ってないよ。みんな1-2度ほど落ちてるし。所詮運用屋は
その程度のものか…。一番死すアド向きなポジションだと思うのだがね。ちなみに今回は
見送るらしい。多分このまま取らないつもりだろう。
0482NAME IS NULL
04/08/17 13:15ID:???と言ってあげなさい。
0483NAME IS NULL
04/08/26 19:39ID:???0484NAME IS NULL
04/08/26 22:26ID:???取締役の最適化だけで済むとは恵まれた環境ですな。
0485NAME IS NULL
04/08/27 14:16ID:fXaaZ0ALとりあえずDBのオブジェクトを調べていたらViewの多さに唖然。。
Table30くらいなのにViewが100くらいある。。
しかもViewの中でViewを参照してるわ、集合関数とか
バリバリ使っていて。
TableのER図を興してみたらとりあえず第３正規化までは
されているようだが。
SQLの見直しがチューニングの基本だとは思うけど、
こんだけViewを使いまわすと人間も混乱するし
オプティマイザも混乱するだろーな（ｗ
0486NAME IS NULL
04/08/27 16:04ID:???規模にもよるだろうが、アプリケーション組むときに作られるSQLは
100や200じゃないだろう?
Viewとしてアプリケーション外にSQLを出しているだけの話で、唖然と
するようなことでもないと思われ。
いくらViewがViewを参照してようが、DBMSの方に格納してあるのだから
依存関係の把握もたやすいだろ。
0487NAME IS NULL
04/08/27 21:25ID:???あんたDBのパフォチューやったことないでしょ。
viewの階層が深くなるほど保守性は悪くなることは
容易に想像つかない？
0488NAME IS NULL
04/08/27 21:58ID:???VIEWやストアドでDB側にロジックを置くのもひとつの手法だし、
>>485だけの説明では一概になんともいえん。
もちろんVIEWを利用するとその分遅くなるけど、
VIEWを使わずに複雑怪奇なSQL(もちろんその場面で最適化された結果)
がコードに散乱するのはもっとイヤ。
0489NAME IS NULL
04/08/27 22:51ID:???保守性を意識しないViewの設計をするといたずらに階層が深くなることはあっても
Viewの階層の深さと保守性の悪さが比例するわけではない。
むしろ保守性を意識するなら積極的にView(もしくはストアド)を使っていくべき。
性能面から見ても、DBMSの実装やアプリケーションの仕様によっては、Prepareの
必要のないViewを積極的に使った方が性能が出せる場合も多々ある。
大体、想像でパフォーマンスチューニングするような奴に噛みつかれるのは甚だ
不本意きわまりない。寝言は寝てから言え。
0490NAME IS NULL
04/08/28 20:44ID:???今ごろviewを推進する人がいるとは。。
保守性を意識するなら積極的に導入すべき？嘘でしょ。
セキュリティを意識してViewを導入するならまだしも
複雑なSQLを別ファイルに置いとくだけの目的なら私は消極派ですね。
prepareの必要が無いと仰るがその動的SQL分Viewを作成するの？
管理が煩雑になるだけ。大体ヒント文も使えないことが多いし。
それで性能が出せることが多々ある？嘘としか思えない。
#誤解の無いように書くけどストアドは必要であれば導入することには
#賛同できますね。
0491NAME IS NULL
04/08/28 23:10ID:???もしOLTPでストアドを使うならそれはDB設計かアプリケーションが
ショボーンかのどちらかが多数だと思います。
大量の件数をこなす時（バッチ処理とか）くらいじゃない？
ストアドなんて。
0492NAME IS NULL
04/08/29 07:03ID:???>PL/SQLは、SQLと違って一文ずつではなく、ブロック単位でサーバに送信
>できるので、ネットワークを通る通信量（トラフィック）を少なくすることができます。
>ネットワークへの通信量を少なくできるということは、パフォーマンスの向上にも
>つながりますし、そのほかにもさまざまなメリットがあります。
0493NAME IS NULL
04/08/29 11:54ID:???> prepareの必要が無いと仰るがその動的SQL分Viewを作成するの？
( ﾟДﾟ)ﾎﾟｶｰﾝ
釣りだよね?
0494NAME IS NULL
04/08/29 13:05ID:???積極的にVIEWを使うことは保守性を高めることに繋がるというのは間違ってないと思う
> prepareの必要が無いと仰るがその動的SQL分Viewを作成するの？
動的SQL内でVIEWを使用するとVIEW内部までPrepare対象になるDBMSなんてあるの?
動的SQLの中にあり、他のSQLでも共有することの出来る静的な部分をVIEWにするから
保守性があがるのであって、常識で考えて全てのSQLをVIEWにするなんてありえないよ
VIEWだと管理が煩雑になる、プログラムソースなら管理できるなんてことがあるのかなあ
多人数が好き勝手にVIEWを作ったら作りっぱなしでロクにドキュメント管理か出来ていない
組織なだけなのでは?
0495NAME IS NULL
04/08/30 11:39ID:???0496NAME IS NULL
04/08/30 21:26ID:???それだとユーザがカンマ打ったときにバグるのでタブ区切りにしてください。
0497NAME IS NULL
04/08/30 21:28ID:???0498NAME IS NULL
04/09/01 08:09ID:nSVJnFyR0499NAME IS NULL
04/09/07 19:58ID:???それ正しいな。
いくら保守性などを上げたとしても、まともに動かなきゃ本末転倒だし。
数千件ぐらいならいいだろうけど、数十万以上の規模になると
体感で分かるぐらい差が出る。
0500NAME IS NULL
04/09/08 11:14ID:???このまえメールアドレスの個数をひとつ増やせって言われて
mail,mail2 という感じでひとつ増やしたんですけど
これっていやな予感とか感じる前に
メールだけテーブル分けた方がいいんですかね
0501NAME IS NULL
04/09/08 13:16ID:???設計の視点からのみの正論ならば、分割して保持すべき。
実務との総合判断になると、現状ソースに対する影響・将来的な拡張可能性を考えて・・・。
0502NAME IS NULL
04/09/11 19:57:42ID:???1個人(法人)につきメールアドレスを複数保持するなんて
当たり前。であればテーブルを分割することが第２正規化では？
0503NAME IS NULL
04/09/12 06:38:20ID:???お前は、メールアドレス記入欄がひとつしかないときに「ふたつ書けない！」と
文句を付けるのか？ 大抵はだまって主要なメールアドレスひとつを記入するだろ？
システムにもよるが、電話番号やメールアドレスなどの連絡項目のようなものは
高々1つか 2つと制限しても問題ないことが多い。2つや 3つであれば正規化せずに
別の列として持たせたほうが取り扱いが楽なこともある。
入力原票の記入欄だって大抵、ひとつかふたつなんだから割り切りも大事。
なんでもかんでも拡張性を意識しすぎると、かえって分かりづらくなる。
0504NAME IS NULL
04/09/17 22:15:22ID:???お前とは何ですか？お前とは。
だいたいあんたが主張していることなんか当たり前すぎる話だろ。
それを力んで何を偉そうに語ってんだか。。
0505NAME IS NULL
04/09/18 16:52:53ID:???0506NAME IS NULL
04/09/19 00:21:36ID:???繰り返し項目を別テーブルとして分割すべきかどうかすら
自力で決定できない奴が何言ってるんだか・・・
0507NAME IS NULL
04/09/19 12:47:51ID:???0508502
04/09/19 22:47:42ID:???結構あるんだよ。責任者メアド・連絡先メアド・携帯メアド・対外非通知メアド
とかその他もろもろ。
なんでもかんでも正規化しろとは言わないけど、俺の現場では顧客マスタからは
分離してるよ。まぁ扱ってる業種によるってことだわな。
0509NAME IS NULL
04/09/20 01:19:35ID:???顧客の業務見てる奴にしかわかんないよ。
0510NAME IS NULL
04/09/21 09:54:48ID:k44kR/kHおまえは502で業務も考えず正規化するのは当たり前といってる訳でとってもDQNなんだな
いまさら自分の業務ではとかいってもね
0511NAME IS NULL
04/09/21 12:24:35ID:???ずいぶんねじ曲げたな。
どこにも「業務も考えず正規化するのが当たり前」等とは書いてないが
馬鹿にしか見えない文字で書いてあるのか?
>>502は
「個人に複数のメアドが存在するのが当たり前」
であれば
「正規化理論的には分割することが正しいといえるのではないか」
と言ってるだけだろ。何も間違っていない。
0512NAME IS NULL
04/09/21 23:11:25ID:???過疎板なんだからさー
ﾏﾀｰﾘしようよー
0513NAME IS NULL
04/09/24 14:50:28ID:???何か嫌なコトでもあったのかな？
俺はあったぞ！！
12月まで契約延長だぁ！？あんなデスマプロジェクトに
あと3ヶ月も骨身を削ると思うとノイローゼになるぜ！！
あ〜ヤダヤダ。。。。
0514NAME IS NULL
04/09/30 02:32:59ID:hg1v0eRR例えば内職でやった仕事と報酬を記録してくような場合簡単なものを仮定して
記録テーブル：作業者,作業日,仕事ID
仕事テーブル：仕事ID,仕事内容,報酬
な感じでテーブル作成し記録テーブルにどんどん記録して行くわけですね。
そして、最終的に作業者の報酬を
select sum(報酬) from 記録,仕事 where 記録.仕事ID=仕事.仕事ID and 作業者=誰某
なんて出すわけです。
しかし此処で仕事テーブルの報酬が会社の状況により上がったり下がったりする事が有るとなると上記の奴じゃ不味い。
さてそこで取るべきのはどちらか。
記録テーブル：作業者,作業日,仕事ID,報酬
仕事テーブル：仕事ID,仕事内容,報酬
として記録テーブルにデータを突っ込む際にその時の報酬も書き込むパターン。
非正規化だが報酬を計算するのは物凄く楽チン。
記録テーブル：作業者,作業日,仕事ID
仕事テーブル：仕事ID,仕事内容,報酬,報酬設定日
と報酬を変えた日時を記録し作業日と報酬設定日時を比較しその時の報酬を弾き出すパターン。
正規化だがSQLが長くなるしコストも掛かる。
どっちが良いと思います？
それとももっと別の良い方法を使うならその方法を。
0515NAME IS NULL
04/09/30 02:54:03ID:???仕事記録テーブル：作業者,作業日,仕事内容ID
仕事内容テーブル：仕事内容ID,仕事内容
報酬テーブル：仕事内容ID,報酬,適用開始日,適用終了日
0516NAME IS NULL
04/09/30 03:04:44ID:???あ、そうか、報酬テーブルに分けるべきでした。
でもそれでも同じように計算コスト掛かりますね。
0517NAME IS NULL
04/09/30 03:14:51ID:???掛かるね。
仕事記録テーブルに書き込んだ後で報酬が変動しないなら、
一つのテーブルにまとめてもいいと思う。
0518NAME IS NULL
04/09/30 09:49:13ID:???非正規化だが〜の例だけど、そういうのを非正規化とは言わない。
仕事.報酬 → 現在の報酬
記録.報酬 → 作業者が仕事をした時点での報酬
論理的に双方に設定されてなければいけないフィールドだからね。
0519NAME IS NULL
04/09/30 09:57:58ID:???必要があると思う。
例えば、作業者が納品した製品に不良・欠陥・ノルマ未達成があった
場合でも一律の報酬を支払うのかどうか? とか…
おそらく例だからだろうけど、内職で日給?普通は実績*単価じゃないかな?
というのもちょっと疑問に思った。
0520514
04/10/01 01:28:13ID:???記録テーブル：作業者,作業日,仕事ID
仕事テーブル：仕事ID,仕事内容,報酬
仕事グループテーブル：グループID,仕事ID
これで報酬が変わった場合、新たに仕事テーブルに別の仕事IDで報酬が違うデータを突っ込む。
さらに仕事グループテーブルに報酬が変わる前の仕事IDと同じグループに設定しておく。
そして今後はそちらを記録テーブルへ記録して行くと。
これなら報酬を取得するのも速いし、ある仕事に関しての総報酬額もグループでselect出来るので速いでしょ。
どうでしょうか。
>>519
はい、例ですのであまり細かな突っ込みはご勘弁を。
内職なんてやった事無いので想像で書きました。
0521514
04/10/01 01:33:29ID:???うーん、例が悪かったか。
0522NAME IS NULL
04/10/01 23:28:00ID:???記録テーブルに実績として実際に受け取った報酬を記録すればいいの。
そして、それは非正規化とは言わないの。わかった？
0523NAME IS NULL
04/10/02 01:52:20ID:???センスないね。
0524NAME IS NULL
04/10/02 11:22:19ID:???身の回りでもそうだけど
たいして技術も無かったり、単に情報武装してるだけのオタクほど他人の
無知を嘲笑うような物言いで指摘するよな。
0525NAME IS NULL
04/10/02 15:28:44ID:???0526＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
04/10/02 15:43:23ID:???＿＿＿ ＿
／ ＿＿＿＿ヽ ／ ￣ ￣ ＼
| | /, −､, -､ｌ /､ ヽ 君の半笑い、ものすごく気持ち悪いよ。
| _| -|○ | ○|| |･ |―-､ |
, ―-､ (6 ＿ｰ っ-´､} ｑ -´ 二 ヽ |
| -⊂) ＼ ヽ_ ￣￣ﾉﾉ ﾉ＿ ー | |
|￣￣|／ （_ ∪￣ / ､ ＼ ＼.￣｀ | /
ヽ ｀ ,.| ￣ | | O＝＝＝＝＝ |
｀− ´ | | ＿| / |
| （t ） / / |
0527NAME IS NULL
04/10/03 01:03:11ID:???0528NAME IS NULL
04/10/04 11:10:18ID:nlQQ7qe60529NAME IS NULL
04/10/05 21:51:08ID:???いま、設計しているテーブルの項目数が１００を超えているのですが。
やはり、テーブルを分けたほうがよいのでしょうか？
初心者なもので初歩的なことを聞いてスミマセンがよろしくお願いします。
0530NAME IS NULL
04/10/05 22:00:39ID:???テーブルを分割する基準は『項目数』ではないと思いますよ。
今設計されているテーブルが業務的にどのような使い方を
されるのでしょう？
マスタ系？トランザクション系？
ただ項目数が100を超えているのは正規化の余地はありそうですね。
0531NAME IS NULL
04/10/06 22:50:55ID:zhL3f+vY第3正規化までやってみてそこからですな。
0532NAME IS NULL
04/10/07 02:40:29ID:???お願いします。
0533NAME IS NULL
04/10/07 02:48:35ID:???データベース一から組めっていわれたら組めます
正規化は理論じゃなくて実測値なんです
スピードとプログラムからの扱いやすさのバランスです
資格だけじゃそこまでわからないでしょうね
0534NAME IS NULL
04/10/07 03:55:10ID:???って人がいたなあ。
0535NAME IS NULL
04/10/07 08:44:08ID:???> 正規化は理論じゃなくて実測値なんです
DBMSが変わるたびに実測取り直して設計し直すのか?
馬鹿だなあお前は。
こういう事言ってる奴に任せると、各種制約を完全無視した頭の悪い
データベースが出来上がるんだろうなあ…
0536NAME IS NULL
04/10/07 16:03:18ID:???535 は公務員
職人は難しい事は分からないが自分の理論で唯一無二の物をつくる
公務員は決められた仕事を手順に従って行う
性能が必要なら職人に、保守が重要なら公務員に
0537NAME IS NULL
04/10/07 16:12:33ID:???それは「正規化」ではなく「最適化」
「正規化」はきちんと定義された用語なの。
0538NAME IS NULL
04/10/07 16:55:21ID:???基礎のなってない自称職人ほど始末が悪い物はない。
オタクと職人は違う。
真の職人は基礎をきちんと身につけた上で独自のやり方を確立する(守破離)
その為の徒弟制度であり暖簾分け制度。昔から何も変わらない。
0539NAME IS NULL
04/10/07 17:38:35ID:???あくまで普遍的な正規化の手法に従って設計しつつパフォーマンスが
問題になる個所で職人的能力を発揮してくれるならいいのだが。
パフォーマンスとのバランスだという点については間違いではないが、
最初からカンと経験だけでDB設計するのはどうかと思うよ。
つーか正規化程度の事を「難しい」とか言うﾔｼは職人とは呼べない。
資格は不要とか不毛な事言わずに、一度体系的に勉強するべき。
0540ただのオタク
04/10/07 17:45:27ID:???資格だってもってます。
その上でデータベースの動作原理も理解すれば正規化の本当の
目的がわかります。
そしてどんな場合でも最適な正規化をすることができます。
0541NAME IS NULL
04/10/07 17:52:17ID:???0542ただのオタク
04/10/07 17:54:07ID:???0543NAME IS NULL
04/10/07 17:55:41ID:???0544NAME IS NULL
04/10/07 18:04:43ID:???させたりする事がないようにする為です。
0545NAME IS NULL
04/10/07 18:07:36ID:???0546NAME IS NULL
04/10/07 18:24:01ID:???知識があって資格持ってる奴が
> 正規化は理論じゃなくて実測値なんです
> スピードとプログラムからの扱いやすさのバランスです
こんな素人臭いことを言うわけがない。
正規化の目的はデータの保守性と整合性を高めること。
「実測値」などと言う単語の入る余地はない。
0547NAME IS NULL
04/10/07 18:40:02ID:???免許を持ってればブレーキ、アクセルなんて用語はわかるでしょうね
でもどうやって使うかわからない
保守性と整合性を高めることによって結果的に何が得られるか
まで考えたことありますか？
0548NAME IS NULL
04/10/07 18:53:04ID:???0549NAME IS NULL
04/10/07 18:57:22ID:???自分に自身があるなら妙な例え話や後出しじゃんけん狙いのレスはいいから
とっとと自分の意見を書いてみろ
0550NAME IS NULL
04/10/07 19:13:04ID:???自分がよく目にする腐った設計をあげて見ますね
プログラム的に３行で処理できるものを項目数のジョチョウによって何十行にもしてくれてる
メンテしやすいとかいって分類名をそのままテーブルに格納しまくってる
呼び出し頻度の高いテーブルのキーに文字を使っている
同じコード体系のテーブルを何個も用意して分けている
バックアップテーブルなのになぜか項目が違う
0551NAME IS NULL
04/10/07 19:27:03ID:???その、「プログラムがわからない」という前提はどっから出てきたんだ？
おまいさんの職場ではプログラムがわからない奴が設計してるのか？
>550
1番目と4番目なんか、それこそ正しく正規化が行われていない為に発生してる問題だろ？
0552NAME IS NULL
04/10/07 19:32:24ID:???へ?
お前の挙げた例と正規化が何の関係があるわけ?
何で唐突に「腐った設計の例」が出てくるんだ?
何が言いたいのかさっぱりわからん。誰か通訳してくれ。
( ジョチョウ(なぜか変換できない)はネタなんだろうか、マジなんだろうか…
0553NAME IS NULL
04/10/07 19:32:58ID:???資格持ってても正規化できない人が多いってこと言ってるのです。
ＡＣＣＥＳＳでざっとテーブル見て意味不明でもオブジェクト指向
なんかで内包しちゃえばプログラム的には扱いやすいし、手間も少ない
資格だけで偉そうにしてる人はそこまで考えずに自己満足してるだけだって
言ってるだけです。
設計する人がオブジェクト指向を熟知してる場面には出くわしたことないです。
自分自身で設計からやったことはありますけどね
0554NAME IS NULL
04/10/07 19:39:23ID:???設計と実装を分けて考える事が出来ない事もわかった。
とりあえず話の大筋くらい読めるようになってからまた来い。
次ドゾー
0555NAME IS NULL
04/10/07 19:43:16ID:???0556NAME IS NULL
04/10/07 19:46:47ID:???0557NAME IS NULL
04/10/07 19:54:50ID:jKpaIrzTOOで包むからテーブルは意味不明でもいいってかｗ
Accessの名前が出てくるあたり1人で全部やる小規模案件しか経験ねえんだろうなｗ
晒しage
0558NAME IS NULL
04/10/07 19:57:06ID:???ＯＤＢＣでつないだらOracleのテーブルだって丸見えなんだよ
作り逃げしてるやつはそんなことも知らないのかｗ
0559NAME IS NULL
04/10/07 20:11:06ID:???つぅかそんなくだらない所じゃなくて
>OOで包むからテーブルは意味不明でもいいってかｗ
に対して反論するのが普通だろうが
0560NAME IS NULL
04/10/07 20:14:02ID:???ＡＣＥＳＳで内容見る時に自分がわかりやすいからって
記号やら分類名やら入れるのは間違ってるっていってるんだよ
意味不明っていうのはテーブル設計書を見てない人間にとっては意味不明という意味
開発する人間は設計者より頭がいいので、日本語ばっかりのテーブル内容じゃなくて大丈夫ですよｗ
0561NAME IS NULL
04/10/07 20:23:58ID:???の反論が
>記号やら分類名やら入れるのは間違ってるっていってるんだよ
テーブル設計書を見てない人間にとっては意味不明
なのか？
頼むから日本語を話してくれ。
それに、一体それが正規化と何の関係があるんだ？
お前が>550を書き込む前にそんな低レベルな話をしている人間は一人もいないのだが。
0562NAME IS NULL
04/10/07 20:27:14ID:jKpaIrzT嵐 に 反 応 す る 奴 も 嵐
0563NAME IS NULL
04/10/07 20:59:35ID:???私はこういう時文字の全角/半角でどちらが概ね正しいのかを判断しています&herats;
0564NAME IS NULL
04/10/07 21:20:12ID:???0565NAME IS NULL
04/10/07 21:41:40ID:m2OWTAKCそれは醜さと紙一重の優美さよ。
分かるか？
俺はつい最近その境地に至った。
0566NAME IS NULL
04/10/07 22:49:03ID:???0567NAME IS NULL
04/10/07 22:51:00ID:???0568NAME IS NULL
04/10/08 09:55:40ID:???システム開発一式 xx万円(珠に3桁、4桁って必要？)
0569NAME IS NULL
04/10/08 10:27:15ID:???そういう所あるよな・・・
某大手もそれだった。
0570NAME IS NULL
04/10/08 11:06:58ID:???まともにオブジェクト指向ができる人間なら、正規化する事のメリットも同時に分かるはずなんだがな。
オブジェクトに分割するって、正規化とやってることはあまり変わらんぞ。
（というか、正規化って構造化と同じという気がするがね）
>550
ツッコミどころ満載だな。
>プログラム的に３行で処理できるものを項目数のジョチョウによって何十行にもしてくれてる
本質的に正しく正規化できてるなら、項目数が増えてようが基本的にはプログラムでどうこう、
ってのはないはずだがね。SQL が複雑にはなるけど。
>メンテしやすいとかいって分類名をそのままテーブルに格納しまくってる
分類名がそれほど変化せず、付け替えなどをしないという「実務的な理由」があるなら、
それでも全然問題なし。
分類名マスタを作るのは確かに正規化だが、必要がないならその正規化を崩すのは
おかしなことじゃない。正規化「しない、できない」と、正規化「した後で崩す」では天地ほど
違う。
>呼び出し頻度の高いテーブルのキーに文字を使っている
検索条件が文字で、テーブルのキーなら全然普通だろ。
文字列をキーに使ってようがインデックスと条件さえ真っ当なら関係ないし。
>同じコード体系のテーブルを何個も用意して分けている
正規化してないのか崩したのかで違うが、これはそれこそ実運用での話になるからな。
確かにそういう腐った設計も多いが。
>バックアップテーブルなのになぜか項目が違う
あえて項目を変えてるバックアップってこともある。
状況によって違うのでこれだけでは腐ってるかどうか判別不可。
0571NAME IS NULL
04/10/08 13:02:20ID:???知 障 は 放 置 で 。
嵐 に 反 応 す る 奴 も 嵐
0572NAME IS NULL
04/10/08 15:45:15ID:???>>正規化を崩すのは おかしなことじゃない。
ハァ？
0573ただのオタク
04/10/08 15:57:13ID:???ただ＋α的な考えも必要です。
正規化の段階ですでに間違ってるものが多いですがね
0574NAME IS NULL
04/10/08 16:02:06ID:???うちの会社のシステムはほとんど自分ひとりで作っていたのだが、さすがに
手が足りなくなってきたのでいくつかのシステムを外注することにした。
出来上がってきたシステムというのが、コレが…また…なんていうか…
・宛名マスタなどの共有可能なマスタを そ れ ぞ れ に 持っている。
・さらにその宛名マスタにシステム固有の情報が 追 加 されている。
・バグを１つ直させたらバグが 増 え た。
・請求金額や売上金額に小数点以下があっても 無 視。
などなど、おまえらそれでもプロか！！というような内容。
自分で作ったほうがましだったかも…orz
0575NAME IS NULL
04/10/08 16:32:59ID:???IT技術者の2人に1人は“プロ未満”
「2万人調査」から人材像とスキル実態が判明
ttp://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20041006/150921/
0576576
04/10/08 16:44:16ID:???どっからどう手をつけたらよいもんだか…('A`)ﾏﾝﾄﾞｸｾ
0577NAME IS NULL
04/10/08 16:47:03ID:???0578574=576
04/10/08 16:50:05ID:???0580NAME IS NULL
04/10/08 17:04:47ID:???DB設計まで丸投げしたの？
つか、どんな仕様書書いて依頼したの？
0581574
04/10/08 17:59:51ID:???> DB設計まで丸投げしたの？
> つか、どんな仕様書書いて依頼したの？
それを言われるとつらい。はい、○投げしました。
まぁそれでも処理の流れや必要と思われるファイル定義なんかは
ある程度作って説明したんだけどね。
まぁ、こっちの依頼の仕方も悪かったのであまり強いことはいえないのだが
さすがにデバックもろくにしてないシステムを納品されたら相手の能力を疑うよ。
0582ただのオタク
04/10/08 18:09:55ID:???0583NAME IS NULL
04/10/08 18:44:50ID:PPCgsGSWいや別に>>581の肩を持つわけでもないが結構そーゆーところ多いんじゃないかな。
うちは今ユーザから○投げされている状態。
今回初めて契約したユーザさんなので、過去に実績があるわけでもない。
確かにユーザレビューなるものはあるのだが、こちらがレビュー対象の
ドキュメントに基づきシステムの内容を説明しても全く理解していない
（とゆーか理解しようとしない）。
単に使う側だからシステムの中身には全く興味が無いのでしょう。
そのかわりユーザーマニュアルとか画面デザインとかは逐一ツッコミが
入るけどね。
0584574
04/10/08 18:47:11ID:???それでも、実務に入っての動作をすべて再現できるわけでもないし。
ましてやDBの中身までは見れなかったんだよね。忙しくて。
ウチは零細でシステム組めるの俺だけだし、その俺も独学だからプロから見れば
何もわかっとらんといわれても仕方ない。
言い訳だとは自分でもわかってるが、外注先も正規化ぐらいしろよと。
まぁ単なる愚痴にしか過ぎないけどね。
0585NAME IS NULL
04/10/08 18:53:07ID:???進捗の読みはしんちょく
0586NAME IS NULL
04/10/08 18:56:22ID:???ﾜﾛﾀ
0587NAME IS NULL
04/10/08 18:56:57ID:???0589550
04/10/08 19:08:56ID:???あるねそういうの
システム会社でもないのにシステム案件に手だして○投げして利益だけもってこうとするとこ
がーーーって感じになる
0590NAME IS NULL
04/10/08 19:19:31ID:???そーだよなぁ。
見た目と使い方重視。バックグラウンド処理なんてさっぱり興味なし。
0591NAME IS NULL
04/10/08 19:22:44ID:???0592550
04/10/08 19:23:49ID:???それならそれで普通だし、納品終わってから文句いいだすのが普通
0593NAME IS NULL
04/10/08 19:24:07ID:???0594NAME IS NULL
04/10/08 23:10:55ID:???バックグラウンド処理まで細かく指摘できるような相手なら、自社のシステム部門に
設計/製造させると思われ。
0595NAME IS NULL
04/10/09 13:33:20ID:???いやいや自社のシステム部門に設計/製造は出来ないから外注に○投げするわけで。
自社の人間だけで30人月以上のシステムを開発するユーザなんて皆無でしょう。
そんなに大量の人間を常時所属させておく会社なんてトータルリスク管理に
無関心なユーザだね。
0596NAME IS NULL
04/10/09 17:22:07ID:???なんでそこでリスク管理が出てくるんだ?
「30人月のシステム開発 = 大量の人間を常時所属」と言うのもわけがわからん。
ひょっとしてこの人は、30人月のシステムというのは1人で30ヶ月、2人で15ヶ月
30人でかかれば1ヶ月で完成する物だと本気で思ってるのだろうか?
0597NAME IS NULL
04/10/09 18:16:25ID:???>>595さんの関連会社はいつまでたってもノウハウが蓄積されないのか
設計製造できないなら仕事とんなって
外注が直接とったほうが安上がりだし効率がいいんだよ
さっさと消えてくれ中間搾取企業は
0598NAME IS NULL
04/10/10 01:15:40ID:???今度は設計と製造を分離できない会社の登場か・・・
0599NAME IS NULL
04/10/10 10:53:41ID:???> ひょっとしてこの人は、30人月のシステムというのは1人で30ヶ月、2人で15ヶ月
> 30人でかかれば1ヶ月で完成する物だと本気で思ってるのだろうか?
まさに人月の神話だな。
0600NAME IS NULL
04/10/10 11:19:00ID:???何が言いたいのかサッパリわからん…
誰か通訳してくれ
0601NAME IS NULL
04/10/10 13:07:59ID:???一言で訳すと、
「丸投げ(・A ・)ｲｸﾅｲ!」
0602NAME IS NULL
04/10/11 07:53:23ID:???0603NAME IS NULL
04/10/12 13:16:04ID:???0604NAME IS NULL
04/10/12 15:49:49ID:???0605NAME IS NULL
04/10/14 17:37:09ID:???あるテーブルにcol_1〜col_20なんて項目を見つけた
瞬間、やる気なくなりました。
0606NAME IS NULL
04/10/14 23:05:32ID:NUSts3Hdr0001_uriage （ uriage_no , tokuisaki_code , sales_code , syouhin_code , suryou , tanka )
てな感じで作るか
r0001 ( r0001_01 , r0001_02 , r0001_03 , r0001_04 , r0001_05 , r0001_06 )
これとどっちがいいと思います？
設計というか命名規則ですが
下のやり方だと
１ r0001のr0001_01とr0002_05をjoinとかする事になってSQL見たときどう結合してるのかよくわからん
２ select分書くときもｶﾗﾑ対応の資料みながらでないと作成できない
３ その代わりSQL分はすっきるする？
４ でも全部のクエリが slect r0001.r0001_01, r0002.r0002_04 , r0003_r0003_05 from ......となって
ぱっと見ただけでは何してるか理解不能
うーんやっぱり駄目駄目そうですね、すいません
0607NAME IS NULL
04/10/14 23:14:23ID:???0608NAME IS NULL
04/10/14 23:27:16ID:???ＪＯＩＮの数が減るとかなら別だが。
0609NAME IS NULL
04/10/14 23:32:35ID:XV6ljV5x型のプリフィックスを付けた方が良いと思う。
【例】
number型 num〜 「num_uriage_no」
varchar型 var〜 「var_tokuisaki_code」
あとなるべくカラム名を短くする。
tokuisaki_code → tokuisaki_cd
0610NAME IS NULL
04/10/14 23:33:12ID:???r0001_売上 （ 売上番号 , 得意先コード , 販売コード , 商品コード , 数量 , 単価 )
にしたら分かりやすいだろ。と得意げに言い出す。。。
確かに定義は可能だが、どっかで日本語がらみの不具合出たらあんた責任取るのかと問いたい、問い詰めたい。
0611NAME IS NULL
04/10/14 23:50:56ID:???「なんで日本語なん？」って聞いたら「わかりやすいやん。」だって。
0612NAME IS NULL
04/10/15 00:20:47ID:???横方向に配列一撃処理したいとき便利
日付 何時から出勤 職員ID
10/15 10:00 6
10/15 11:00 9
10/15 11:00 3
10/15 12:00 5
10/15 12:00 7
な感じでたまってるデータを
10:00〜 11:00〜 12:00〜 13:00〜
10/15 山田 佐藤 田中 太田
鈴木 渡辺 中村
10/16 。。。。。。。
な感じで表示したい、とか
0613NAME IS NULL
04/10/15 02:33:29ID:Q1bgJl9bというのは一般的なやり方なのでしょうか？
どうせ、2038年には自分は現場にいないハズなので指摘されなきゃ大丈夫かと思うのですが・・・
0614NAME IS NULL
04/10/15 02:45:18ID:???インデックス含めたメタデータの分も考えると節約になるとは思えない。
それに扱う全データに対する日付分の割合はどれくらいなの？
0615NAME IS NULL
04/10/15 02:49:43ID:???カラム名は8文字におさえろよ。
0616NAME IS NULL
04/10/15 03:09:26ID:???なんかいいことあるん？
0617NAME IS NULL
04/10/15 03:15:54ID:???0618NAME IS NULL
04/10/15 03:16:16ID:???0619NAME IS NULL
04/10/15 03:42:47ID:???つーか、COBOLに移植って・・・何w
0620NAME IS NULL
04/10/15 03:46:54ID:???そのほうが、別DBへの移植も容易にできる、メンテも楽、西暦問題とも無縁
0621NAME IS NULL
04/10/15 04:57:38ID:???っつうか、変にリレーションとか使ったら、ファイルに移植できんやろうが。
0622NAME IS NULL
04/10/15 08:16:31ID:???0623NAME IS NULL
04/10/15 08:27:47ID:???リレーションは論理概念。
物理的にどう格納するかはあなたの自由。
0624NAME IS NULL
04/10/15 09:06:08ID:???0625NAME IS NULL
04/10/15 09:27:05ID:???0626NAME IS NULL
04/10/15 09:58:41ID:???最近ではハンガリアン記法は推奨しないというのが大勢。
カラムの型が変わった時の手間を考えてもやるべきじゃない。
>>611
当然DBMSとその周辺で日本語カラム名での動作確認が取れている上での
事だろうから無問題。
個人的にはタイプが面倒になるから嫌。
>>613
日付は日付型で扱うべき。
大抵のDBMSは日付型用に豊富な関数群を用意している。
(単純な日付計算から月初や週初めを求める関数まで)
それらを全部捨ててまで日付を数値型や文字列型で格納するメリットが
あるとは到底思えない。
0627NAME IS NULL
04/10/15 11:04:05ID:???> 最近ではハンガリアン記法は推奨しないというのが大勢。
> カラムの型が変わった時の手間を考えてもやるべきじゃない。
型が変わったときのプログラム修正ミスを防げるので意味有ると思う、
全部手間掛けて修正するのは大変だけど逆にもう一度チェックする機会になる。
> >>611
> 当然DBMSとその周辺で日本語カラム名での動作確認が取れている上での
> 事だろうから無問題。
> 個人的にはタイプが面倒になるから嫌。
おれも日本語名は有効だと思う、
タイプミスや項目名を間違える様なアホなプログラマを沢山使ってると
日本語カラム名はミスが出にくいし発見するのも容易、
上記のハンガリアンもアホプログラマのミスを見つけるのが容易になる。
一度やってみれば分かる。
0628NAME IS NULL
04/10/15 11:13:23ID:???時間をロスするし、マルチOS環境などを考えると日本語はあまりソース中に
入れるべきじゃない、コメントは化けても問題ないから日本語でいい
フィールドの形を表記に含めるのではなく、３種類程度に限定する
移植するさいに支障のないものにするほうがいい
型が限定されていればフィールド名のニュアンスでたいていの場合は
型を特定できる
0629NAME IS NULL
04/10/15 11:31:33ID:???日本語は送りがながあるからな。
売上なのか売り上げなのか売上げなのか…
> タイプミスや項目名を間違える様なアホなプログラマを沢山使ってると
> 日本語カラム名はミスが出にくいし発見するのも容易、
これは意味が分からない…
ミスが出にくいも何も、項目名が間違っていたらSQLも通らないだろ?
0630NAME IS NULL
04/10/15 11:37:25ID:???0631NAME IS NULL
04/10/15 12:17:25ID:???> 売上なのか売り上げなのか売上げなのか…
あと、「雰囲気」というカラム名がふいんきで変換できないとか
「売り上げデ−タ」なんつーのも曲者だ
0632NAME IS NULL
04/10/15 12:24:50ID:???> あと、「雰囲気」というカラム名が
中身がメチャメチャ気になる…(´Д`;)
0633NAME IS NULL
04/10/15 12:35:04ID:???0634NAME IS NULL
04/10/15 13:06:39ID:???0635NAME IS NULL
04/10/15 14:50:13ID:???最上級なのだから、敬え。
0636NAME IS NULL
04/10/15 14:54:04ID:???結局、正規化はすべきだよな？
0637NAME IS NULL
04/10/15 14:55:29ID:???0638NAME IS NULL
04/10/15 15:05:18ID:???>時間をロスするし、マルチOS環境などを考えると日本語はあまりソース中に
>入れるべきじゃない、コメントは化けても問題ないから日本語でいい
日本語使用に問題有るOSならやる必要なないけど
問題ないなら使えばメリットが有るって話だ。
それにソース打つ時間なんてプロジェクト全体の中ではほんの僅かだぞ
全体の効率で考えれば後の保守性やミスが起こらない方法をとるべきだ
打つ時間なんて気にしてるのは単価の安いプログラマの戯言だろ。
0639NAME IS NULL
04/10/15 15:23:04ID:???0640NAME IS NULL
04/10/15 15:35:27ID:???0641NAME IS NULL
04/10/15 15:46:03ID:???> 全体の効率で考えれば後の保守性やミスが起こらない方法をとるべきだ
そりゃ至極もっともな話だが、日本語のカラム名を使うと保守性が上がって
ミスも起こらないとは誰も思ってないから噛みつかれるんだよ。
日本語カラム名使うメリットがあるとすれば、エンドユーザーがExcelあたりを
介して直接DBMSからデータを引っ張るような環境だけだな。
> 打つ時間なんて気にしてるのは単価の安いプログラマの戯言だろ。
余計な煽り文句を入れるな
0642NAME IS NULL
04/10/15 16:03:28ID:???>ミスも起こらないとは誰も思ってないから噛みつかれるんだよ。
じゃあ逆に聞くが日本語使用に問題ない環境で日本語のカラム名をつかわないことのメリットってなんだ？
それがパンチ時間だけなんだろ？
日本語にすれば項目名等短くなる事多いし項目名をへんな省略しなくて住む場合も多い、
そうすると見通よくなってミスが減る事もある
馬鹿なプログラマを沢山使ってれば実感出来るとおもうけどな。
実際には日本語名はお前みたいな香具師に意味なく敬遠されるので使える場合が少ないのは事実だけどね。
0643NAME IS NULL
04/10/15 16:37:17ID:???・SQLが打ちづらい
・表記法が統一しづらい
・拡張性に乏しくなる(問題がないのはあくまで現在の運用及び開発環境に限られる)
・システム拡張の際、開発を海外の外注先に投げるという選択が取れなくなる
・(ほとんどのDBMSで)パフォーマンスが悪くなる
0644NAME IS NULL
04/10/15 16:39:37ID:???計測データってあるの？
Oracleとかはベンチマーク公開禁止だっけか。
0645NAME IS NULL
04/10/15 16:58:53ID:???文字コードの変換が入るからでは?
0646NAME IS NULL
04/10/15 18:18:22ID:???これはコーディング時の一時的な物だろ
その後のメリットに相殺される
>・表記法が統一しづらい
そんな事は無い、きちんと規則を決めればアルファベットより簡単
だいたい日本語の項目名なんて現実社会に置いて既に有る程度標準化されている。
>・拡張性に乏しくなる(問題がないのはあくまで現在の運用及び開発環境に限られる)
>・システム拡張の際、開発を海外の外注先に投げるという選択が取れなくなる
前提として日本語が使える環境での日本語名だから、この項目自体意味無し！
>・(ほとんどのDBMSで)パフォーマンスが悪くなる
データは？
内部的には漢字も半角も同じ扱いだろ？
文字コードの変換が入るのはフィールドへの代入とか、表示とかじゃないか？
0647NAME IS NULL
04/10/15 18:32:07ID:???これはコーディング時の一時的な物だろ
その後のメリットに相殺される
ほんとつっこみ所満載なやつだな
＞＞そんな事は無い、きちんと規則を決めればアルファベットより簡単
＞＞だいたい日本語の項目名なんて現実社会に置いて既に有る程度標準化されている。
いつ誰が標準化したんだ、もまえか？
俺は見たこともないな、チンピラグラマが意味もわからず日本語使ってるのは見たことあるが
＞＞前提として日本語が使える環境での日本語名だから、この項目自体意味無し！
linuxでも日本語が使える環境なわけだが、ぜんぜんコード体系が違うぞ
もっと勉強しれ、どうせWindowsしかさわったことがないへっぽこだろうが
＞＞データは？
＞＞内部的には漢字も半角も同じ扱いだろ？
＞＞文字コードの変換が入るのはフィールドへの代入とか、表示とかじゃないか？
文字コード変換はなODBCドライバで発生するんだよ
漢字があろうがなかろうが変換は行われる
文字コードが最初から一致してても行われる
なにが違うかっていったら実際に変換した文字数分の処理時間なんだよ
わかったか
0648NAME IS NULL
04/10/15 19:33:48ID:???0649NAME IS NULL
04/10/15 20:40:03ID:???> ・表記法が統一しづらい
英語でも単語の省略の仕方がまちまちだったりで統一し易い訳では
ありません。省略しないと長くなってしまいますし。
> ・拡張性に乏しくなる(問題がないのはあくまで現在の運用及び開発環境に限られる)
将来的に海外で使う事が想定される様なシステムであればそういう
配慮も必要でしょうが、そんな事は考えていないシステムもたくさ
んあります。海外展開を想定している場合は最初からそういう要求
があるでしょう。
> ・(ほとんどのDBMSで)パフォーマンスが悪くなる
ここで問題になっているのはカラム名やテーブル名ですからコード
変換が発生するとしてもSQL文をパースする時だけです。扱うレコー
ド数には依存しませんからパフォーマンスに与える影響は小さいと
判断出来ます。またSQL文の構文解析し実行計画を立てる事に比べ
れば文字コード変換は負荷の小さい処理ですし、その点でもあまり
大きな影響があるとは思えません。
具体的にどの程度影響があるのかというデータはありますか。
0650NAME IS NULL
04/10/15 23:48:15ID:???そこしかつっこみどころがないからつっこんでるのか？
> ・(ほとんどのDBMSで)パフォーマンスが悪くなる
この言葉自体になんら間違いはないだろう
空気嫁
0651NAME IS NULL
04/10/15 23:49:21ID:???基本的に悪くなりません。某DBベンダで働いている私が言うのだから間違いありません。
まだベンチマークしてませんが、そういうアーキテクチャです。
もっとも他社の製品については何とも言えませんが、今時根本的な処理ならどこでもほぼ同じレベルです。
ただし、日本語名を使った場合、ミドルウェアや開発言語、ODBCドライバなどで
特定の文字だけ問題が起きるといった可能性を否定できないので絶対に使わないでくれとお客さんには言ってます。
0652NAME IS NULL
04/10/15 23:59:54ID:???Windowsでしか使わないのだから、Windowsに依存した作り方でいいじゃないか
Oracleでしか使わないのだから、Oracleに依存した作り方でいいじゃないか
と同レベル
誰がそれを保障できるの？
アルファベットだろうと日本語だろうと保守性は、それことパフォーマンスの差異
位に微々たるものだろう
だったら将来SQL Serverでの運用とかPostgreSQLでの運用とかも考慮した
やりかたを取るのが保守性が高い作り方と言えるだろう
言語的な話で環境依存ってのはありえるが、DBみたいに基盤になるものは
環境依存下に置くのは、あまり良い選択じゃない
そういうのを作りっぱなしと言う
0653NAME IS NULL
04/10/16 00:49:22ID:???将来どうなるかわからんだろ？
だったらやはり極力変化に強い設計にしておくのが無難。
0654NAME IS NULL
04/10/16 16:31:14ID:???ロ ー マ 字 表 記 最 高
0655NAME IS NULL
04/10/16 19:02:44ID:???0656NAME IS NULL
04/10/16 19:55:01ID:???0657NAME IS NULL
04/10/18 08:52:29ID:PhkblcBSプログラム内部の変数に落とすにしても、オブジェクトにマッピングするにしても
最終的にはアルファベットになるじゃないか。
プログラム内部で改めてアルファベットの項目名を定義し直すなんて馬鹿馬鹿しいし
テーブルの項目名と異なる変数名なんて分かりづらい事この上ない。
ミスが出にくくなるなんて、寝言は寝てから言って欲しい。
0658NAME IS NULL
04/10/18 09:30:29ID:???0659NAME IS NULL
04/10/18 09:38:53ID:???0660NAME IS NULL
04/10/18 10:07:27ID:???違うだろ。
項目名はアルファベット+連番。
別紙の項目名対応表と関連付ける。
古来より行われてきたこの手法こそ最強。
0661NAME IS NULL
04/10/18 12:33:49ID:???【例】
ローマ字表記：torihikisaki_ID
日本語字表記：取引先ID
となる。
日本語表記を示すメリットは、
・プログラムのコードを追う場合は、日本語字表記の方が解り易い。
・論理設計から物理設計に落とす時、そのままの表記で列名を落とせる。
かな？
日本も英語圏の言語だったら、こんな問題に陥らなくて良かったのにな・・・・
0662NAME IS NULL
04/10/18 15:59:47ID:???全角 torihikisaki
while(変換成功){
変換やり直し
}
shift + I shift + D
全角
わかりやすいってなにが？
0663NAME IS NULL
04/10/18 16:14:46ID:???馬鹿かお前は
0664NAME IS NULL
04/10/18 16:27:42ID:???× torihikisaki_ID
○ client_ID
設計の段階で日本語使う時点で間違い
0665NAME IS NULL
04/10/18 16:43:11ID:???項目名にマルチバイト文字を使うのは論外として
いちいち辞書引かないと分からない単語を使うのは非生産的だと思われ
副資材引き当て区分
こんなのどうすりゃいいのよ?
0666NAME IS NULL
04/10/18 16:54:35ID:???自分なら submat_flg
といった短い名前にする
flgという修飾子自体も他の項目名と関連性をもたせておけば意味も表現できる
material とか mat 自体は他のテーブル名や項目でたびたび出てくるので
辞書いっかいひけばすべてわかる
副資材引き当て区分
なんてのはたとえ日本語で表記されててもはじめてみる人には意味不明なので同じ
0667NAME IS NULL
04/10/18 17:04:25ID:???設計の段階であくまで備考欄に記入すべきものだろう
0668NAME IS NULL
04/10/18 17:11:37ID:???結局 660のような項目対応表は必要ってこと？
0669NAME IS NULL
04/10/18 17:12:32ID:???なんか矛盾してる気がするぞ…
言ってることが日本語カラム名派と同じじゃないのか?
0670NAME IS NULL
04/10/18 17:14:17ID:???テーブル定義書がすでに一定の命名規約によって作成されて英語項目名
をメインに置くということ
ＥＲ図もすべて英語項目名で作成する
そうすれば仕様を理解するころには対応票は頭の中に出来上がっている
0671NAME IS NULL
04/10/18 17:16:46ID:???0672NAME IS NULL
04/10/18 17:21:35ID:???英語項目名ですでに意味に直結してるといった感じかな
0673NAME IS NULL
04/10/18 20:24:27ID:???突っ込みどころ満載ですね。とりあえず「引き当て」がどこへ行っ
たのですか。
資材区分と素材区分があったらどうします？。materialに対応する
日本語だと後者の方が最初に思い付きますが。
matで始まる単語は他にもいくらでもありますしmaterialの略し方
にしても>666の様に単語の頭を使う流儀もあればmtrlの様に子音を
抜き出す流儀がありますから表記の揺れに繋がります。
日本語に対応する英語を考えるというのは思っているほど簡単な事
ではないし馬鹿にならない労力がかかるというのは経験した事のあ
る人間なら分りそうなものですけどね。
そういえば「区分」と「フラグ」を区別して使い分けているところ
もありましたね。こういう場合は>666ならどうしますか。
0674NAME IS NULL
04/10/18 20:33:50ID:qDNRF/GpSQLに関してはDBMSに依存する部分はかなりありますからね。
OracleとMS SQL serverの両方で使えるSQL文というのはかなり厳し
い制約になります。
例えば日付処理関数なんかは処理系によって違っていますが、どう
するのですか。日付型を使わずに日付は文字列で扱う事にしてクラ
イアント側で自前の日付処理ライブラリを用意するのですか。
別の例で言えば、ある条件にマッチする検索結果の内201番目から
300番目の行を取り出す場合移植性の高いSQLを書くにはどんな方法
が考えられますか。
SQLを使っている場合、他の処理系への移植性はよっぽどの事がな
い限り考えても無意味でしょう。
0675NAME IS NULL
04/10/18 20:58:09ID:???>ある条件にマッチする検索結果の内201番目から
300番目の行を取り出す場合移植性の高いSQLを書くにはどんな方法
が考えられますか。
SQL鯖の場合だとこんな感じであってます？
SELECT TOP 100 * FROM Table1 A
WHERE NOT EXISTS
(SELECT * FROM (SELECT TOP 200 * FROM Table1) AS B
WHERE A.Field1 = B.Field1)
ORDER BY A.Field1
ｵﾗｸﾙでは通らないのかな？
0676NAME IS NULL
04/10/18 21:31:47ID:???この場合matでもmtlでも実は問題ないんですよ。
ようするに識別、連想の容易なものであればいいんです。
その辺の命名規約は固定化するか仕様書にもりこむ必要がありますがね
仕様理解の段階で日本語項目名で論理的に構成していくと
後々対応票が必要になってくるんですよ
なので仕様理解の段階ですでにある種の記号と目的の関連付けをしてしまう
ということです。
そうすることで
日本語項目名ー＞動作目的 と同じように 英語項目名 ー＞動作目的
という自然の流れが作れます。
そんなに難しいことではありませんよ、日本語項目名でやったとしても結果は同じです。
>>674
私の場合は、そういったことが現実問題として多々ありましたからね
以下のことに注意しています。
共通して利用できるデータ型しか使わない。
日付は文字列として格納する
固有の関数などは使わず、自前の共通関数を用意する
スピードの制約とかシビアな場合は、ストアドに依存するのはしかたないですが、
たいていの場合は無視できるレベルです。
0677NAME IS NULL
04/10/18 22:14:55ID:???前半部分。
それは出てくる用語数が少なければ問題にはならないでしょうけど
数が多いと馬鹿にならないと思いますよ。まぁ、この辺が個人の感
覚ですが。途中で仕様変更やなんかで新しい用語が出てきた場合に
既存の命名規約にハマらなかったりする場合もよくあります。
日本語に反対する理由として拡張性を挙げられていますが、>676
の方法でも機能拡張を求められた時点に命名規約が破綻する可能性
は低くはありません。
後半部分。
日付型を使わないというのはこれはこれでよく議論になりますねぇ。
大抵は使うべきという結論になるものと認識しています。
例えば古いPostgreSQLだとunionが使えなかったり、MySQLではサブ
クエリーが使えなかったりとかあります。日本語を使えない環境を
考慮するというのならそこまで考慮する必要があるでしょうが、あ
まり現実的な話とは思えません。
ちなみに>674の2番目の例に対する解はありますか。>675の例はSQL
サーバーに依存していますし、PostgreSQLでは確かlimitとoffsetだっ
たか固有の構文があったはずです。
Oracleであればrownumを使う事になりますが古いOracleだとサブク
エリーにorder byを使えないのでこの方法が使えません。
一般的は解としては、>675の例を使うとField1が自分より少ないレ
コードの件数を数えて、それが200から301の間のものを取得すると
いう方法が考えられますが、SQLの例は面倒なのでパスします。常
識的には素直に処理系に依存した方法を使うでしょう。
0678NAME IS NULL
04/10/18 22:29:24ID:???> 一般的は解としては、>675の例を使うとField1が自分より少ないレ
> コードの件数を数えて、それが200から301の間のものを取得すると
> いう方法が考えられますが、
突っ込まれる前に書いておきますが、Field1の値に重複がある場合
にはこの方法は使えません。そういう場合で移植性が必要なら300
件fetchして200件分捨てる位しか思いつきません。
処理系に用意されている方法よりは遅くなるでしょうし、件数が増
えれば増える程問題は大きくなります。そしてこういう要求という
のは件数が多いからこそ出てくる要求です。>676でも他の人でも移
植性のある解を持っているのであれば興味はあります。
0679NAME IS NULL
04/10/19 01:41:19ID:???それは日本語項目名を使った場合も同じです。
同じ結果ならより有利な方を選択するものです。
あきらかに依存度の高い
EXISTS
TOP
*=
なんかは使いません
代用できるものは
IN
JOIN
などです。
ＳＱＬ構文が長くなりますが、移植性には勝てません。
ロジックで工夫する場合もあります。
たすかにパフォーマンスは落ちます。
それは前文でも書いた通り、必要ない場合が多いです。
0680NAME IS NULL
04/10/19 03:11:58ID:???0681NAME IS NULL
04/10/19 04:29:58ID:???0682NAME IS NULL
04/10/19 05:55:23ID:???日本語→英語→カタカナが別の言葉になることは結構あるのだけど。
0683NAME IS NULL
04/10/19 06:37:49ID:???依存せず操作できます。マジお勧め。
0684NAME IS NULL
04/10/19 07:16:13ID:???0685NAME IS NULL
04/10/19 07:18:28ID:???いや、だから、領収書を英語にすると、receiptだろ？
じゃあ、レシートはどうするんだ？と。
0686NAME IS NULL
04/10/19 07:22:54ID:???識別できればなんでもいい
0687NAME IS NULL
04/10/19 07:31:25ID:???0688NAME IS NULL
04/10/19 08:25:17ID:???> 識別できればなんでもいい
それなら>660が最強ですね。
>679
DBMSによってはSQL文の長さに制限がある場合もありますがそっち
の配慮は大丈夫ですか。
例えば現在時刻を取得するのに移植性の高い方法はどんなのがあり
ますか。DBMS依存の方法は使えないとなるとクライアント側で取得
する事になりますが、そっちはそっちで環境に依存します。また複
数のクライアントで時刻を同期する配慮も必要になります。
>683はネタで書いたのでしょうが実際、本気で移植性を追求するな
らそうなりますよ。
本当に移植性が必要ですか。
移植性を追求するならDBMSの機能はほとんど使えなくなりますし、
それならそもそもRDBMSを使う必要が本当にあるのかという話にも
なります。それでもパフォーマンスを犠牲にして移植性を追求する
システムをRDBMSで実現するメリットが顧客にあるのですか。
0689NAME IS NULL
04/10/19 08:35:36ID:???あるとしてもそんなのはDBMSの選定ミスでしょ。
移植性を考えなければならないシステムなんて、最初から移植することが
決まってるはずじゃん。そうでないシステムと同列に語るのはおかしい。
あと、日本語の項目名を使っても結局はプログラム内でアルファベットの
項目名に置き換える必要があるって話はどこ行ったの?
0690NAME IS NULL
04/10/19 10:23:48ID:???＞あるとしてもそんなのはDBMSの選定ミスでしょ。
おれもこれに同意
結局日本語NG廚や正規化必死廚や移植性重要廚は実務経験が少ない仮想SEなんじゃない？
実務経験が有れば一旦決めたシステムが移植される確率なんて非常に低い事は
わかってるし、
何年かたって他のシステム屋が更新するかもしれないけどそんな事は関係ない
現実的には今後の為の標準化に金を使うなんてことは無駄だしクライアントには歓迎されないぞ
それに移植が必要な場合はアクセス用のモジュールに包括させて固有部分が外に出ない様にするだろう
移植性を本気で考える奴がこの程度の工夫をしないはずないんで
移植性の為に日本語NGなんていってんのはそもそもつじつまが合わないだろ
0691NAME IS NULL
04/10/19 10:30:17ID:???0692NAME IS NULL
04/10/19 11:54:59ID:???どっちにしろテストは必要だからそれだけ金出して移行するメリットがあるかどうか疑問だけど。
0693NAME IS NULL
04/10/19 12:25:40ID:???問題が出るから使用は推奨されていないはず。Firebirdでは使用すら出来ない。
一体彼らは普段どのDBMSで開発しているんだろう? SQL鯖?
0694NAME IS NULL
04/10/19 12:47:34ID:???日本語とか言ってる時点で、ろくにプログラムも組めない、素人SEなんだろう
移植性にでくわす場面なんていくらでもある
別の場所で既存のコンピュータ構成を利用して同じシステムと使いたい
別の会社の作成したシステムと連携をはかりたい
別の機器のシステムと連携をはかりたい
こんなユーザの要求なんて日常的にあると思うが、それは切り分けて
ぼうだいな金かけてるのかねこういう人たちは
モジュールに包括なんてのは先でも書いてると思うが、ただのしったかか
0695NAME IS NULL
04/10/19 13:08:06ID:???言わんとしていることには同意だけど。
> 別の場所で既存のコンピュータ構成を利用して同じシステムと使いたい
> 別の会社の作成したシステムと連携をはかりたい
> 別の機器のシステムと連携をはかりたい
いずれの場合もDBMSを操作するミドルウェアは同じ物だろうし、特に日本語
カラム名を使うことで問題が発生するとも思えない。
こじつけは良くない。
素人SEだの知ったかだのという煽り文句付きでないと技術的な議論が出来ない
というのが果たしてプロなのかどうか…。
0696NAME IS NULL
04/10/19 13:10:53ID:???会社統合に伴うシステム統合だったり、
ＤＷＨを構築して連携したり。
最近、データモデリングや標準化の書籍等が
多く出回ってきたのも、今までそのような事が
がないがしろにされてきた事の弊害が多く出て
きているからだと俺は思ってるんだけど。
0697NAME IS NULL
04/10/19 14:03:53ID:???>しかしOracleでさえ日本語カラム名の動作は保証しないし
まだそうなの？
0698NAME IS NULL
04/10/19 14:15:55ID:???> 別の会社の作成したシステムと連携をはかりたい
> 別の機器のシステムと連携をはかりたい
これは日本語カラムではなく移植性のことに対するレス
その前に日本語カラムだと移植性が落ちるという前提があるけど
移植性を考慮して設計されていると、この辺の作業ってのは
フォーマット変換するにしても楽だし、うまくいけば抽出するだけですんだりする
こういったことが発生するたびに開発費と時間をついやさずにすむんだよ
> 別の会社の作成したシステムと連携をはかりたい
得にこれについては、移植性まったく無視して設計されたシステムだと
こっちまで迷惑こうむるからね
0699NAME IS NULL
04/10/19 14:20:25ID:???2002年3月時点の記事だが・・・。
http://www.oracle.co.jp/2shin/2002/ora54/15_16.html
ここにカラム名じゃなくてテーブル名だが記述してある。
やっぱ保証はしていないみたい。
0700６９９
04/10/19 14:21:20ID:???0702NAME IS NULL
04/10/19 16:42:57ID:???SQLをプログラムに書くのが悪い。
0703NAME IS NULL
04/10/19 17:17:00ID:???O/Rマッピングで泣きを見てる連中があまりに多ので信用ならん。
第一、Hibernateで縛られる方が特定DBMS依存より余程危険な気がするぞ。
0704NAME IS NULL
04/10/19 17:34:44ID:???対応しきらなければ素のSQL書くしくみもある/できるわけだし。
0705NAME IS NULL
04/10/19 19:55:13ID:???一般的な開発に関する話としては同意ですが、SQLについては移植
性というのは幻想にすぎないというのが実感ですね。Cの移植性に
ついても大外幻想だと思っていますが。
やるとしたら使う機能を極端に制限するかSQL自体を隠蔽してDBに
対する操作を抽象化するようなインターフェースを使うか。
最初から対象プラットフォームが決まっていてその範囲内で仕様を
決めていくというのなら容易ではあるでしょうが、一般的な移植性
を考慮するのであれば使う機能を相当限定するか>702の奴みたいに
徹底的に作るかしかないでしょう。それでも素のSQLを記述する仕
組みを残さざるを得ない訳ですから限界はあります。
> 別の機器のシステムと連携をはかりたい
> 別の会社の作成したシステムと連携をはかりたい
これはインターフェースに関する問題であってプロムラムの移植性
とは独立した問題です。
0706NAME IS NULL
04/10/19 19:58:48ID:???ふつー、そんなことレビューで議題にあげてたらぶっとばされますわよ。
0707NAME IS NULL
04/10/19 20:05:30ID:???0708NAME IS NULL
04/10/19 20:27:00ID:???0709NAME IS NULL
04/10/19 20:29:56ID:???￣￣￣￣-----________ ＼ | / --￣
--------------------------------- 。 >>708
_______-----------￣￣￣￣￣
∧ ∧ ／ / | ＼ イ
ハイハイ （ ） ／ ./ | ＼ ／
＿ ／ ）／ / | ／|
ぅ／ / // / | ／ ,|
ノ ,/ /' / |│ ／|
＿＿＿＿＿ ,.／ ／/ | / .─┼─ |
（＿＿＿＿＿二二二二) ﾉ （ （. | / ┼┐─┼─
^^^' ヽ, | | /. ││ .│ │
0710708
04/10/19 20:46:47ID:???0711ぜんぜん関係ないところに
04/10/19 20:56:55ID:???0712NAME IS NULL
04/10/19 21:03:13ID:???途中からちゃんと「SQLの移植性」というより一般的な話になってるんだけどね。
0713NAME IS NULL
04/10/19 21:35:26ID:???前提条件無しだから結論は絶対出ない訳だし。
0714NAME IS NULL
04/10/19 21:48:35ID:???0715714
04/10/19 21:49:28ID:???スミマセン。
0716NAME IS NULL
04/10/19 22:56:05ID:???んでそいつはJava以外のプロジェクトでも一般的に使っているの？
0717NAME IS NULL
04/10/19 23:00:58ID:oGonGEC6その他のVIEWのパフォーマンスや、そもそもVIEWを作れなくなる可能性
についてどう考えているんだ？
0718NAME IS NULL
04/10/19 23:09:40ID:???0719NAME IS NULL
04/10/19 23:30:02ID:???0720NAME IS NULL
04/10/20 00:03:03ID:???思い付きませんが…
>717,719
それは別に非正規化以外の理由でそうなっても同じ事ですね。
0721NAME IS NULL
04/10/20 00:41:48ID:???0722NAME IS NULL
04/10/20 02:12:49ID:???0723NAME IS NULL
04/10/20 02:17:35ID:???0724NAME IS NULL
04/10/20 03:28:13ID:???0725NAME IS NULL
04/10/20 08:59:19ID:???0726NAME IS NULL
04/10/20 09:02:38ID:???ネタとして。
0727NAME IS NULL
04/10/20 09:42:52ID:???…かえって分りづらい気がする。
0728NAME IS NULL
04/10/20 09:46:47ID:???0729NAME IS NULL
04/10/20 09:57:15ID:???あるのだろうか?
大抵の場合
・モデリングがおかしい
・そもそも正規化が出来ていない
(正規化を理論として押さえていない奴ほど「正規化崩し」という言葉を使う)
・アプリケーションの構造がおかしい
(全件取得して条件に合う行を処理する、一件毎の処理に毎度SELECTを投げるなど)
・ミドルウェアべったりでSQLを知らない
(JAVAグラマ、VBグラマに多そう)
のどれかだと思われ。
0730NAME IS NULL
04/10/20 10:50:44ID:???テーブルがあったんです。
何故正規化していないのか設計者に質問したら、
場合により正規化崩しする場合がある。
という答えが。
その他、保守性や整合性の問題からもいろいろ質問
しても、特に問題ない。という答えばかり。
729さんの言うとおりかも知れない。
0731NAME IS NULL
04/10/20 11:13:02ID:???日次集計・月次集計なんて正規化崩しの最たるものだと思うのだが。
0732NAME IS NULL
04/10/20 11:29:10ID:???0733NAME IS NULL
04/10/20 11:50:08ID:???0734NAME IS NULL
04/10/20 11:52:15ID:???0735NAME IS NULL
04/10/20 11:56:26ID:???保持しているデータの意味は違うし。
0736NAME IS NULL
04/10/20 12:07:56ID:???それは正規化崩しじゃない
0737NAME IS NULL
04/10/20 15:42:04ID:???正規化にのっとってると言えるよ
日次ー月次 の関係は 会社ー従業員 の関係と同じ
0738NAME IS NULL
04/10/20 17:45:17ID:???いい所あるなら教えて。
0739NAME IS NULL
04/10/20 17:59:44ID:???同期を取る必要がない場合だな
日本の業務形態はたいていこの場合なんだけどね
同期を取る必要があるのに分離したら正規化くずしになる
0740NAME IS NULL
04/10/20 18:13:21ID:???http://pc5.2ch.net/db/
0741NAME IS NULL
04/10/20 19:19:26ID:???データ粒度を荒くしているだけで、そのテーブルひとつに着目すれば正規化されているわけだからね。
ただ、データベース全体で見ると、日別の計として得られるデータを別に
保持しているので冗長データである、という言い方はできる。
正規化崩しが敬遠される原因のひとつに「データ整合性を維持するのが困難になる」
というものがあるけど、集計テーブルも同じように整合性維持問題を抱えることになる。
通常は月次更新で、過去データを変更できないようにシステムで制御する。
ほかには、推移表などのリスト出力をサポートするために、1月, 2月, 3月と列を分けて
正規化を崩したテーブルを作成することがある。データベース管理者は、この形式のテーブルを
もっとも嫌うようだけど…。アプリケーションフロントエンドで推移表を作成するのは
ものすごく計算コストがかかる。できれば月次更新で、推移表および累計データを作ってしまいたい、
というのがアプリケーション側を担当しているエンジニアの言い分。
0742NAME IS NULL
04/10/20 19:34:49ID:???契約テーブルの顧客コードっつー項目と顧客マスタの顧客コードをリレーションはって
契約テーブルの顧客コードに顧客マスタにある顧客コード以外入らないようにするっての。
俺が今まで関わったプロジェクトって全部、テーブル間のリレーションをはらないのばっかだったから
はらないのが普通なのかなと思っていたが、実際どうですか？
0743NAME IS NULL
04/10/20 19:57:18ID:???はる。
0744NAME IS NULL
04/10/20 20:06:06ID:???はる。
カスケードも本当に必要なところだけだが設定する。
0745NAME IS NULL
04/10/20 20:36:08ID:???張ってもデバッグ所要時間に違いがないから余計な手間
0746NAME IS NULL
04/10/20 20:37:54ID:???それで整合性が保たれているならたいしたもんだ。
プログラムで全部チェックしてたり？
0747NAME IS NULL
04/10/20 20:39:29ID:???プログラム的にバグが入り込むことはまずない部分
0748NAME IS NULL
04/10/20 20:48:02ID:???> ほかには、推移表などのリスト出力をサポートするために、1月, 2月, 3月と列を分けて
> 正規化を崩したテーブルを作成することがある。
自分も非正規形だと思っていたのですが、>469以下の議論ではこれは正規形で
あるという事になっているみたいですねぇ。
0749NAME IS NULL
04/10/20 21:52:57ID:???そりゃ、バグがみつかってから修正するための時間には影響しないだろ。
それよりもサポートツールが関連をひらってくれない方がめんどう。
0750742
04/10/20 22:01:18ID:???「顧客マスタに該当データが無い時はどうしましょう？」って質問すると
「無い場合は無いから考えなくても良いよ」とか言われる。
無い場合が無いんだったらリレーションはれば良いのに……。
0751NAME IS NULL
04/10/20 22:05:18ID:???0752NAME IS NULL
04/10/20 22:07:58ID:???0753NAME IS NULL
04/10/20 22:13:05ID:???0754NAME IS NULL
04/10/20 22:13:31ID:???0755NAME IS NULL
04/10/20 22:15:39ID:???0756NAME IS NULL
04/10/20 22:18:24ID:???と
リレーションシップ＝参照整合性
を混同するなよ。
0757753
04/10/20 22:19:56ID:???0758NAME IS NULL
04/10/20 22:35:29ID:???オマエは台風の中、防波堤の上に立ってろ。
0760NAME IS NULL
04/10/20 23:16:25ID:???そうか。
台風には気をつけてな。
雨戸しめてねろよ。植木鉢は家に退避しろ。
寝る前に水分取りすぎるとおねしょするぞ。
0761NAME IS NULL
04/10/20 23:28:34ID:???今から防波堤でファイヤーダンスしてきます。
全裸で。
一人で。
0763NAME IS NULL
04/10/20 23:34:59ID:???そもそも関係変数なんて言葉使わないんだが。
0764NAME IS NULL
04/10/23 01:20:15ID:88UFjYBG『トリガーって何処で流すんですか？』
その一言を水に流してください。
0765NAME IS NULL
04/10/23 02:06:40ID:???漏れの会社じゃ新人でもない奴が新規開発でイマサラRDO使って開発中だよ・・・会社に転がってたテキスト見ながら作っちゃったらしい orz
0766NAME IS NULL
04/10/23 05:19:51ID:???0767NAME IS NULL
04/10/23 07:31:17ID:???0768NAME IS NULL
04/10/23 08:13:49ID:???0769NAME IS NULL
04/10/23 14:21:36ID:???質問さえまともに出来ない人間て最近多い。
自分が今何をどうしたいのかといった質問能力については
IT関連の業務に限らず社会人として必要不可欠な能力だよね。
馬鹿な質問者の意思を汲み取って推測して回答するのは
ホント疲れるよな。
0770NAME IS NULL
04/10/23 15:14:50ID:???IT関連の業務に限らず社会人として必要不可欠な能力だよね。
ホント疲れるよな。
0771NAME IS NULL
04/10/23 15:33:35ID:???最後の一行が無ければいい感じだったのにねぇ
質問はちゃんとしようねw
0772NAME IS NULL
04/10/23 15:34:07ID:???はげどう
0773NAME IS NULL
04/10/23 17:44:35ID:???『DBサーバ』と一言ですませませう。
0774NAME IS NULL
04/10/27 12:39:17ID:???そしたら、「お湯を入れていかれますか？」って聞くから、
「はい」って答えたさ。
そしたら、カップラーメンを袋に入れず剥き出しで、
割り箸添えて笑顔で手渡されますた。
0775NAME IS NULL
04/10/27 13:32:53ID:???お湯はセルフサービスだよ。
イケメンさんにはついでやるけどな。
0776NAME IS NULL
04/10/27 14:02:12ID:???笑顔が嬉しかったの？
0777NAME IS NULL
04/10/27 14:36:37ID:???いいや、手渡しが嬉しかったんだろう。
0778NAME IS NULL
04/10/27 15:25:47ID:???0779NAME IS NULL
04/10/27 15:31:15ID:???0780NAME IS NULL
04/10/27 16:50:14ID:???・崩れたチャーシューがちょこっとしかはいっていないのに分厚いアルミのレトルト袋
・麺にまで袋
・ちっこい海苔1枚が個包装
という、なんともやるせない現状を正規化してみてください。
0781NAME IS NULL
04/10/27 17:11:16ID:???いや、そもそも774が最も期待するソリューションを提案すべきだろ。
774はラーメンが食べたかったのか、それともたまたまラーメン、
しかもカップラーメンなどという選択を好んでいたのかどうか？
先ずはそのへんから分析すべき。
0782NAME IS NULL
04/10/27 17:57:52ID:???それはカップラーメン的にかなり正規化できてるのでは？
パフォーマンスはものすごく悪いとは思うがｗ
0783NAME IS NULL
04/10/27 23:20:07ID:RspvWNu90784NAME IS NULL
04/10/27 23:21:58ID:???0785NAME IS NULL
04/10/28 00:40:54ID:???0786NAME IS NULL
04/10/28 10:54:05ID:???0787NAME IS NULL
04/10/28 12:08:35ID:???ORマッピングがあれば必要なし
0788NAME IS NULL
04/10/28 21:58:11ID:???でも行数に制限がｗ
0789NAME IS NULL
04/10/29 00:12:12ID:???そんなあなたにRAW区画
0790NAME IS NULL
04/10/29 13:42:30ID:8AWB59Zs折衷案はどこですか？
0791NAME IS NULL
04/10/29 13:44:31ID:8AWB59Zsその能力マジで欲しい
どうやって強化できますか？
0792NAME IS NULL
04/10/29 14:35:58ID:???知識レベルがあがってくると自分が初期のころにしていた発想が失われて
初心者の質問見てなんでそんな発想するんだって感じてしまう
でも大体みな同じような発想してることに気づけたらそれでわかるよ
質問者が会社の後輩とか決まった人間ならその人それぞれの知識レベル
を考慮してその立場で考えてやれば言いたいこともわかる
なんにしても質問者を否定しないことが一番大事だと思うけどね
0793NAME IS NULL
04/10/29 15:13:52ID:???売上伝票データの扱い方が正しい正しいでしょうか？
基幹業務で売上レコードを溜め込む売上テーブルがあるんですが
その売上レコードを確定（変更不可）させるために
売上確定＋日付テーブルに売上テーブルを移動させています
0794NAME IS NULL
04/10/29 19:24:12ID:???さっそく出番だ。>>793に答えてやれ。
0795NAME IS NULL
04/10/29 23:06:46ID:???単純に確定フラグって項目作って管理したほうが楽だと思うけど
正規化としてはフラグにするのが正しい
0796NAME IS NULL
04/10/30 02:19:25ID:???正規化されたレスとはこういうレスのことなのかもしれんと思った。（笑）
0797NAME IS NULL
04/10/30 03:39:05ID:???作って、毎日売上テーブルから select *,now() をinsertしてる。
0798NAME IS NULL
04/10/30 06:24:32ID:???「売上確定+日付テーブル」が「売上確定20041030」というテーブルのことなら、萎える。
0799NAME IS NULL
04/10/30 10:11:43ID:???変更可能なので、「請求済み」という項目にして請求締め処理でフラグ立ててる。
0800NAME IS NULL
04/10/30 16:05:42ID:???0801NAME IS NULL
04/10/31 15:10:59ID:???・・・マジでやってそうだな。
基幹業務とかぬかしてるし。
0802NAME IS NULL
04/11/02 16:13:18ID:???こんな感じのテーブルがある。主キーは製品IDと更新日。
各工程の所要時間/処理速度を、製品ごとに履歴をとって保存する。
（実際には、各工程の所要人数など諸々を含めて項目数が30を超える）
各工程でどのような作業を行うかは全製品で固定。
ロット数に関係なく一定の時間（所要時間）のみかかる工程と、ロット数に
正比例した時間（処理速度×ロット数）がかかる工程がある。
製品によってはいくつか工程を飛ばすものもあるが、基本的に同じ工程を
同じ順番で経て、完成品が出来上がる。
このテーブルを基に、ある日の製造ロット数から各工程に必要な時間など
を一括して求めて、そのままアプリケーションに渡す。
…こういう場合、項目が30超えてても正規化しなくていいよな？
0803NAME IS NULL
04/11/02 17:15:05ID:???・特定の工程に必要な時間だけを渡す
・ある製品の第一工程〜最終工程までの必要時間の合計を渡す
ということは、ない。
0804NAME IS NULL
04/11/02 17:15:40ID:???工程が変わったらテーブル構成もかわるの？
製品と工程が多対多で、関連テーブルに所要時間・所要人数
0805NAME IS NULL
04/11/02 18:05:21ID:???使用する場所が限定されてて、工程の変更・追加はほぼないわけよ。
あと、例は簡略化してるけど、実際には原材料が同じ複数の製品はある
工程で一緒に処理するとか、そういう煩雑なルーチンが必要となる。
ので、工程が変更・追加されたら結局アプリケーションを書き直す必要が。
ちなみに>>804の言うとおり
製品ID, 更新日, 工程番号, 所要時間, 処理速度
てな感じの設計も考えたが、このような条件の時に、可読性以外に正規化
するメリットってあるのかな、と。そこが気になるわけだ。
0806NAME IS NULL
04/11/02 18:42:41ID:???それなりのシステムだとするとね。
マッピングの方法がちょっとかわるくらいで。
SQLを手書きする必要がある部分が多ければ別だけど。
0807NAME IS NULL
04/11/02 20:17:52ID:???0808NAME IS NULL
04/11/03 03:05:28ID:???WinXPからExcel落ちることがやたら多い!!
Win2000Serverではほとんど経験無いのに!!
(勿論Win95/98は論外だが)
0809NAME IS NULL
04/11/03 03:18:46ID:???0810NAME IS NULL
04/11/03 09:19:44ID:???0811NAME IS NULL
04/11/03 11:57:53ID:???なんでそこまでして一つのテーブルに収めたいの?
よほどSQLを知らないか、妙なトラウマでもあるのか…
> あと、例は簡略化してるけど、実際には原材料が同じ複数の製品はある
> 工程で一緒に処理するとか、そういう煩雑なルーチンが必要となる。
よくある話じゃん。
いちいち工程変更でアプリケーションを書き直す必要はない。
ちゃんとモデリングすればキレイに解決出来る問題だよ。
何か一冊、業務別のデータモデリング本でも読んだ方がいい。
やろうとしてることが自分の知識の範疇を超えてると思われ。
0812NAME IS NULL
04/11/03 23:47:15ID:ZjrGkFHFあれってDML文を発行する度にマスタテーブルを見に行くから、パフォーマンスが悪いと聞いたのだがどうなんだろ？
漏れは参照整合性制約を使用していないけど、データを抽出する時には外部結合で対応してる。
0813NAME IS NULL
04/11/03 23:57:36ID:???システムとしてパフォーマンスが悪いのが問題になってはじめて、改善策のひとつとして制約やトリガを外したりする。
0814NAME IS NULL
04/11/04 20:03:17ID:???それってデータを更新する(DELETE/UPDATE/INSERT)ときは
ある程度関係あるかもしれんけど、SELECTでは
どうなんでしょ？
Oracleが手元に無いんでわからんが暇な方、実行計画を採取して
報告してくんないかな。
0815NAME IS NULL
04/11/07 00:36:23ID:???0816NAME IS NULL
04/11/09 01:26:06ID:???この帳票の為のワークテーブルの構造が
科目０１月数０１金額
科目０１月数０２金額
：
科目２０月数１２金額
と１レコードにひたすら横に項目が並んでるんだが、誰か（というか設計者）この設計の理由を教えて
くれ・・・ orz
１帳票１レコードになるから便利・・・位しか漏れには思いつかないんだが・・・
パフォーマンスを突き詰めるとこの構造の方が有利なのか？
ちなみにテーブルを設計したのはシステム構築で飯を食ってるシステム屋だ・・・・
0817NAME IS NULL
04/11/09 01:42:53ID:???0818NAME IS NULL
04/11/09 20:26:59ID:???んだんだ
0819NAME IS NULL
04/11/10 00:49:43ID:???パフォーマンスを突き詰めなくても科目+月数で
PrimaryKeyになるんでしょ？
20*12=240行
あらら。。パフォーマンスを突き詰めなくてもホーケー。
0820NAME IS NULL
04/11/10 01:22:00ID:???240行じゃなく240列？
0821NAME IS NULL
04/11/10 10:55:41ID:???レポート作成ソフトに項目を落とし込むときに便利なのでは。
パフォーマンスは関係ないよね。
ワークテーブルって事はどこかのタイミングで正規化されたテーブルから
ワークテーブルを作成してるわけだから。
0822NAME IS NULL
04/11/10 11:49:56ID:8aD21xS6ご教授ください。
例えばユーザーテーブルと本テーブルがあったとします。
ユーザーがどんな本をもっているかを表したいので、
ユーザーテーブルと本テーブルのキーをもったユーザー＆本テーブルも
あるとします。
ここでユーザーがいくつ本をもっているかを一覧で表示するとしたら、
ユーザー＆本テーブルと結合して人数を取得できると思うんですが、
もし本テーブルが１００万くらいの数だとしたら、パフォーマンスは
あまりよくない気がするんですがどうでしょうか？
ユーザーテーブルに本をいくつもっているかを表すnum_bookなどを持たせて、
関係が変わった時に、インクメント、デクリメントする方が早いと思うのですが、
どっちのほうがいいのでしょうか？
わかりにくくて申し訳ないですがよろしくお願いします。
0823NAME IS NULL
04/11/10 12:20:03ID:???あなたの前者の考えは至極普通な考えだと思います。
ユーザー＆本テーブルからネステットジョインすれば
一覧も簡単に取り出せるだろうし。
逆に後者の考えがよくわかりません。
0824821
04/11/10 13:08:57ID:8aD21xS6なぜ後者のようにユーザーテーブルにnum_bookを持たせた方がいいのかなぁ
と思ったかと言いますと、
ユーザーが1万レコード、本が１００万レコードあり、
ユーザー一覧画面でＡさんはＸ冊、ＢさんはＹ冊という風に３０件ほど
表示するのですが、本をたくさんもっている人から並べるなどの
ソートがあり、結合するよりも、order by num_bookで表示したほうが
明らかに早いと思ったからです。
結合すると一人一人何冊もっているかを確認しないといけないと思うので、
結合するより早いのかなと思ったわけです。
普通はこんなやり方はやっぱりしないですか？？
0825NAME IS NULL
04/11/10 13:28:33ID:???ほんとにそこで問題が出た場合は、そういう対策するかもしれんけど。
0826NAME IS NULL
04/11/10 22:43:10ID:???・本を何冊持っているかわからないユーザの情報（氏名とか）は追加できない。(nullは論外)
・本を追加するには複数のテーブルを更新しなければならない。（トランザクション）
・num_bookの数とユーザー＆本テーブルの整合を直接RDBMSで保証できない。
0827NAME IS NULL
04/11/10 23:33:41ID:???保守性とか考えると正規化したほうが圧倒的に便利です。
0828NAME IS NULL
04/11/11 08:35:26ID:???どこから出てくるんだろう？
揶揄してるんじゃなくて、前にこういう仕事をこういうプラットフォームでこういう言語でやってた
とか傾向があるのかな。
DATE型が嫌いとかVARCHAR2しか使わせないとかは
みかか系の人に多いとかそういうの。
0829822
04/11/11 09:00:41ID:???やはり保守や整合性を考慮すると普通に結合した方が良いのですね。
ありがとうございます。
>>828
このシステムはＷＥＢでユーザー一覧のアクセス頻度も
結構多いのでパフォーマンスを考慮した上でそう考えました。
今までにこういう数を持たせるなんてことはやったことはないですし、
何かに依存したシステムでの開発もありませんよ。
ただパフォーマンスを追及したかっただけです。
0830NAME IS NULL
04/11/11 09:04:15ID:???結構多いっ１分で100件とか集中したりするの？
0831822
04/11/11 09:19:29ID:???問題がありそうなところを先に考慮しとくのはよくないということでしょうか？
多い時だと１分で１００件以上になる可能性もあります。
0832NAME IS NULL
04/11/11 10:38:41ID:???問題にならないレベルであるはずだし、仮にそれが問題になるならメモリをどーんと増やせば
一発で解決しそう。
まっとうな方法やってりゃ、問題が出たときもまっとうな方法で解決できるから楽。
0833NAME IS NULL
04/11/11 10:55:00ID:???正規化を崩してパフォーマンスを上げても、どこかで必ず頭打ちになる。
そのうち、行き当たりばったりでなし崩し的に正規化崩しが行われるようになって
誰も保守出来ないぐちゃぐちゃなデータベースが出来る。
パフォーマンスを考慮するというのは
・単位時間当たり最大いくつのトランザクションを処理する必要があるか。
・そのためにはどれだけのマシンスペックと回線が必要か。
・処理しきれない物についてはどうするか。
↑こういうことを見積もる事であって、いきなりテーブル構造を云々するのは間違い。
正規化を崩すなんて話は、これらすべてを考慮してもなおパフォーマンスが出ない場合の
苦肉の策ぐらいに思った方がいいよ。
0834822
04/11/11 11:41:49ID:???パフォーマンスを考慮＝正規化崩しに直結するっていう考えが
まずかったんですね。そのまえに他にやることを何も考えずにいました。
まずは正規化した上でやれるだけやってみようと思います。
（個人的にどれくらいのパフォーマンスの違いがあるかみてみたいので
num_bookと比較してみたいです）
わかりやすい説明ありがとうございました。
0835NAME IS NULL
04/11/11 15:38:20ID:???> 問題がありそうなところを先に考慮しとくのはよくないということでしょうか？
デメリットがある方策を想像で考慮するのはよくない。
0836NAME IS NULL
04/11/11 20:25:44ID:???伝票テーブル (伝票番号, 売上先コード, 合計売上金額)
伝票明細テーブル (伝票番号, 行番号, 商品コード, 売上金額)
こんなふうに、伝票テーブルに(num_bookのように)合計売上金額を持たせるのってダメ？
(明細が必要になるのって伝票発行とか限られた処理だけなので) 伝票テーブルだけで
売上集計などがすばやくできるようになってるといいかなー、と思っていたんですが。
邪道？
0837NAME IS NULL
04/11/11 21:49:50ID:???それに、合計売上金額は一度確定したら変更されることはないから、デメリットもないし。
0838NAME IS NULL
04/11/11 23:30:40ID:???伝票明細テーブルに追加するたびに伝票テーブルを更新するのかぁ。。
俺なら邪道(とゆーか変)だと思う。
PrimaryKey（伝票番号, 行番号）でGROUP BY+SUMで合計売上金額出せるんだから。
0839NAME IS NULL
04/11/11 23:44:16ID:???というか持つべきではない。理由は>838。要は正規化ね。
集計が素早くなる？その為だけに正規化を崩し複雑さを増すのは愚かな気が。
逆に、値引や税、端数その他諸々の理由でその辺が一致しないケースも扱うなら、
当然伝票と明細に金額を持たなければならない。これも同じく正規化。
販売管理業務ではこっちを採用する例のほうが多いね。
全ては要件次第。
要件を元に順当に正規化して、パフォーマンスの問題が出たらその時初めて
考えれば良い事じゃねーの？なんか考慮の順序がおかしくないか？
便利だからとか早そうだからっていう理由でDB設計してるのか？
0840NAME IS NULL
04/11/11 23:45:08ID:???> まさに、num_book と同じことをやろうとしていたんだが…。
同じ事なのになぜあえて聞くのか…
このスレを>>822から読んでみたなら自ずと答えは出るだろう?
0841NAME IS NULL
04/11/12 00:06:38ID:???0842NAME IS NULL
04/11/12 00:09:53ID:???紙の伝票に「合計金額」という項目があるなら、その写像である伝票テーブルに「合計金額」があっても問題ない。
0843NAME IS NULL
04/11/12 00:22:47ID:???正規化 合計金額 で google先生にでも聞いてみろ。
0844NAME IS NULL
04/11/13 00:21:14ID:???おまいらは何で勉強しますたか？
0845NAME IS NULL
04/11/13 03:20:44ID:???この板
0846NAME IS NULL
04/11/13 05:01:32ID:???Coddって人から教わった。
0847NAME IS NULL
04/11/13 05:09:43ID:???あの人、酒くさくね？
0848NAME IS NULL
04/11/13 05:29:58ID:???死んだ人のことを悪く言うのはイクない
0849NAME IS NULL
04/11/16 21:52:49ID:vxJjNxbr買った NULL 買った NULL
なんてテーブルはやっぱりダメですか・・・
商品Aを買ったか調べる場合、SELECT 商品A from 購入テーブル WHERE 商品A
IS NOT NULL; なんてやってるのですが。正規化したいけどわかんないです。
0850NAME IS NULL
04/11/16 22:44:23ID:???0851NAME IS NULL
04/11/16 22:46:00ID:???ダメ。許さない。Access で作ったら商品254個までしか増やせない。切腹。
＞ 商品Aを買ったか調べる場合、SELECT 商品A from 購入テーブル WHERE 商品A
＞ IS NOT NULL; なんてやってるのですが。正規化したいけどわかんないです。
それじゃ買ってないかを調べてるのではないかに。
商品を商品Tbl にまとめて、新たに購入履歴Tbl を設ける。
顧客Tbl PRIMARY KEY: 顧客ID
-顧客ID
-顧客名
商品Tbl PRIMARY KEY: 商品ID
-商品ID
-商品名
購入履歴Tbl
-顧客ID
-商品ID
商品Aを買ったか調べる場合、
SELECT 顧客名 FROM 顧客tbl, 購入履歴Tbl, 商品Tbl
WHERE 顧客tbl.顧客ID=購入履歴Tbl.顧客ID AND
購入履歴Tbl.商品ID=商品Tbl.商品ID AND
商品名='商品A';
で各顧客が買ったかどうかわかる。買った数だけ名前が出る。
集計取りたきゃ GROUP BY でまとめて 顧客名 を COUNT すればいいし、
一回以上買ったかどうかを調べるなら SELECT DISTINCT に変えればいい。
まだ買ってない顧客なら IS NULL で。
0852NAME IS NULL
04/11/17 01:23:24ID:???テーブルの設計はそれから。
0853NAME IS NULL
04/11/30 19:10:06ID:???0854NAME IS NULL
04/12/05 15:37:00ID:cMDeyAad0855NAME IS NULL
04/12/05 15:50:31ID:???そしていい運用管理者といいユーザーが揃えばｶﾝﾍﾟｷﾀﾞ!!
0856NAME IS NULL
04/12/05 18:13:43ID:???ちがうぞ。
いいシステムはいい予算からだ。
0857NAME IS NULL
04/12/05 23:56:49ID:???0858NAME IS NULL
04/12/06 00:42:37ID:???0859NAME IS NULL
04/12/06 16:09:16ID:/YmiWcVS日次データと確定データとあって、売上入力を行うと日次データに
書き込まれ、日次更新処理を行うと日次データから確定データに
移動するって感じになってるんだけど、
これって邪道？
売上データにフラグをもってた方がいいのかな？
0860NAME IS NULL
04/12/06 22:04:00ID:???日次データに更新時間とかタイムスタンプ持ってるんでしょ？
ならレコード毎にフラグ持つ必要ないじゃない。
日次処理時刻とかを管理テーブルに持たせれば、
それ以前のタイムスタンプを保有する日次データは
おのずと確定データになるんじゃないの？
0861NAME IS NULL
04/12/06 22:12:06ID:???日次更新処理が途中でおちたらどうするか、とかね。
0862NAME IS NULL
04/12/06 22:14:29ID:???0863NAME IS NULL
04/12/06 22:21:14ID:???createの時not null付けるのﾒﾝﾄﾞｲから主キーだけしか付けんと言うか勝手に付く。
0864NAME IS NULL
04/12/06 22:27:37ID:???0865NAME IS NULL
04/12/06 22:33:36ID:???0866NAME IS NULL
04/12/07 00:51:53ID:???それって利点って言うよりただの仕様じゃん。
0867NAME IS NULL
04/12/07 01:09:22ID:???仕様が保証できることに利点がないとでも？
0868NAME IS NULL
04/12/07 01:32:17ID:???いや、仕様としてそれは良いんだよ。
使うべき所に使うのは当然。
でもnot nullって考え無しに全部付けとけとか言うじゃない。
必要の無いところに付ける意味が有るのかと。
0869NAME IS NULL
04/12/07 02:30:32ID:???> 考え無しに全部付けとけとか言うじゃない。
NOT NULLとは別の問題かと。
0870859
04/12/07 09:47:13ID:g+FFS1ecコボラーが作った仕様なのでよくわかりませんが、
更新時間はもってないです。
>>861
「日次更新処理を行うとそれ以前のデータが確定データになる」
ではないのでフラグでOKですかね
設計者がいうには日々200件程度の日次データがあって
そこから日報を出力することになっているのですが、
フラグよりも日次データから確定データに移動した方が
日報出力の抽出が早いとか、データが分かれてた方が
わかりやすいとか、プログラムが楽とか言ってた。
なんか納得できない。
0871NAME IS NULL
04/12/07 10:59:00ID:???俺は昔コボラーだったけど
日次、月次のファイル（DB）を別にするのは昔ながらのバッチ処理の手法だろうね
今時の考えでは無いけど、状況や運用によっては有用な場合も有ると思う
現在でもメインフレーム使ってる銀行などではこういった手法も残ってるし
その人って４０代以上の他の言語をあまりやってないコボラーなのかな。
ただRDB使って日々200件程度ならフラグとかでわけるのが現実的だわな
0872NAME IS NULL
04/12/07 12:13:31ID:???NOT NULL 制約はキチンとつけたいと思うけど、DBMSで長さゼロの文字列の
扱いが違うからvarchar型だと厄介ですね。
脱線するけどANSI SQLだとどれが正式なんでしょうね。
長さゼロ文字列＝NULL
長さゼロ文字列＜＞NULL
何も決まってないか玉虫色の表現（笑）
0873NAME IS NULL
04/12/07 12:41:34ID:???完全に日次で締めてしまえるデータなら良いけど、たいてい日次くらいだと
遡っての修正とか検索とか発生するから同じテーブルのほうがいい気がしますね。
年締め単位くらいで別テーブルに移動ってシステムなら割とありますけどね。
日報を出したいなら別にジャーナル用のテーブルを準備して変更情報を放り
込んでだほうが実用的だと思いますよ。
0874859
04/12/07 12:42:19ID:???40後半の生粋のコボラーです。
まあうちの会社のSEはほとんどが、生粋のコボラーしか
おりませんが。
日次、月次のファイル（DB）を別にするのとRDBの機能を
使いにくそうなんですけどねえ。
0875NAME IS NULL
04/12/07 13:20:03ID:???MTがくるくる回るってソートとマッチングを繰り返すCOBOLのバッチ処理は
新興のRDBやらとは歴史が違います（笑）。伝票処理などはバッチのほうが
合理的と思えるケースもあります。
データの流れを追ってゆく形の設計をするとバッチ的な処理にマッチします。
DBだとデータは流れなくて状態が遷移してゆくって設計になります。その
ため逆に流れを記録したいときには別の仕掛けが必要になってしまいます。
世の中一般の業務的な手順や制度や法制自体がCOBOL的処理と概念に基づい
て作られてるんじゃないかと疑っています（笑）。
0876NAME IS NULL
04/12/07 13:34:49ID:???>使いにくそうなんですけどねえ。
コボラーが設計してるって事は集計に本来RDBが必要なシステムなんじゃないかな？
例えば売り上げ集計や銀行業務等のシステムでは
日時データを集計＝＞日報作成＝＞日時集計ファイルへ追加
で、月次は日時集計ファイルを集計＝＞月報作成＝＞月次集計ファイルへ追加って感じで
バックエンドの処理には殆どRDB機能を使う事は無いと思う
実際問題として未だに１０年前のシステムを使ってる所なんかだと
MT（リールの磁気テープ）の架け替えで集計処理を行ってるとこも有るよ
こんな所ではシーケンシャルリードしか出来ないのでバッチ処理的な思想になる。
で現実問題として勘定系ってこれでも十分なんだよね。
0877NAME IS NULL
04/12/07 16:54:38ID:???空文字列と NULL は違う。だから ''<>NULL。
……なんだが、そもそも NULL は何と比較しても（NULL 自身とでも）一致しない。
TRUE/FALSE の二値じゃなくて、TRUE/FALSE/UNKNOWN の三値比較だからなー。
0878NAME IS NULL
04/12/07 19:13:24ID:???>>872 はOracleが空文字列とNULLを区別してないってことを言いたいんだと
思うぞ。MSSQLやDB2は区別してるらしい。どっちがANSI準拠なのかってこと
かな。俺にもわからんが、ANSI SQL準拠ってRDBはたくさんあるのにこの
不統一ぶりってなんだろうな。
0879859
04/12/07 19:55:33ID:???ジャーナル用のテーブルっていうのはまったく思いつきませんでした。
そういう手もありますね。
>>875
COBOLの時代が長かったから世の中一般の業務的な手順は
COBOL的処理中心に回ってると思いますね。
>>876
>日時データを集計＝＞日報作成＝＞日時集計ファイルへ追加
>で、月次は日時集計ファイルを集計＝＞月報作成＝＞月次集計ファイルへ追加って感じで
まさしくこういう流れです。ISAM的な考えだなあと思います。
さすがにMT使ってるシステムはありません（ｗ
0880860
04/12/09 21:52:34ID:???いや、フラグ持つとか以前に行（レコード）に挿入日とか更新日を
保有してないほうが変だと思うなぁ。
それこそ障害時にはどこまで更新されたか解らなくなりません？
データウェアハウスもまったく考慮されてないんだろうな。。
(あっでもDaily200件くらいのトランザクション的なテーブルでしたっけ？)
0881859
04/12/10 18:55:45ID:???データウェアハウス何それって？いうぐらいの勢い（ｗ
障害対応は考えてないと思います。
日付の項目も数値8桁で定義されてた・・・
0882NAME IS NULL
04/12/10 22:01:20ID:???mmddyyyy形式で保存されてたら神
0883NAME IS NULL
04/12/11 08:00:23ID:???普通にvarcharやdecimal８桁でとったりしません？
0884NAME IS NULL
04/12/11 08:08:05ID:???受付日 datetime,
受付時刻 datetime,
(後略)
ってなってるテーブルならみたことあるけど。
0885NAME IS NULL
04/12/11 19:12:42ID:N/clY0Moあまり普通ではないと思う。
でもテーブルの項目にdatetime型って使えるようになったのは
ここ10年かそこらじゃなかったかな。
だって俺Oracleで初めて知ったもん。datetime型（ｗ
0886NAME IS NULL
04/12/12 19:10:27ID:esrA43Kc狂言の挙句、自ら削除依頼を出す。
しかし削除人から怒られ、本スレで個人情報を晒される。
現在高校生の1がスレ埋め立て目論見中
0887NAME IS NULL
04/12/12 22:12:14ID:???そういえば昔IBMのメインフレームでDB2使ってたけど
datetime型って無かった気がする。
0888NAME IS NULL
04/12/13 10:37:58ID:???ansi sqlの分類だとdate, time, timestamp じゃなかったかな。
sybaseやmssqlだとtimestampの名称を別の意味で使っるからdatetimeを
日付時刻をあらわす型として使ってる。
oracleのdate型は日付と時刻の両方を格納できるからtimestamp相当。
date（日付だけ）とtime（時刻および時間）をサポートしてるのは
mysqlとpostgreぐらいじゃないかな。db2は知らないけど。
0889NAME IS NULL
04/12/13 23:00:52ID:???datetime型は無いけどdate型はあったよね。
NULLの扱いが面倒なので 0001-01-01 をNULL代わりに使ってたよ。
0890NAME IS NULL
04/12/14 10:24:43ID:???0891NAME IS NULL
04/12/14 21:24:43ID:???0892NAME IS NULL
04/12/16 22:39:23ID:MlL2k9FZVB/ACCESS系?のSEは、日付項目をCHAR(文字型)でDB設計するヤシが多い。
両者を比較した場合の利点・欠点は？
0893名無しさん＠Linuxザウルス
04/12/16 22:53:29ID:???そんなことしないよ from Access系
0894NAME IS NULL
04/12/16 23:13:13ID:MlL2k9FZ漏れの逝ってる契約先だけかな・・
0895NAME IS NULL
04/12/17 04:08:57ID:???トラぶった経験のあるヤシは文字型使う場合がある。
どういうわけかDATE型に時刻が入ることを知らないおめでたいOracle使いがいる
んだよ。それで >>892 みたいな違いが出るのではないかな。
0896NAME IS NULL
04/12/17 04:52:39ID:???0897NAME IS NULL
04/12/17 10:47:41ID:???コボラー系SEが設計するとそういう事は良く有るよね。
0898NAME IS NULL
04/12/17 11:03:23ID:???演算があったら文字列は論外。
0899NAME IS NULL
04/12/17 16:58:17ID:mRzc/gpV仕事でOracleとSQLServer使うことがおおいけど
CONVERTやらTO_DATEやら。。。。何回使っても覚えられん。
その都度マニュアル参照したり。面倒臭い。
まぁ覚えられない自分が悪いのだが。
0900NAME IS NULL
04/12/17 17:04:52ID:???0901NAME IS NULL
04/12/17 19:40:53ID:???テーブルを作ったことがある。
update,insert,deleteぐらいしか使えない私にはこれが精一杯だった。
むしゃくしゃしてやった。今では反省している。
プロジェクトの規模や工数によってプログラマーがDB設計を兼ねて開発する
といった事は結構あるのではと思いますがDBと偏に言っても奥が深く、簡単にマスター
出来る物ではありません（SQLの文法キモいし構造が基本的に2次元でしっくりこない）。
ここにいる皆さんって次のうちどれに当てはまるのでしょうか？
１，生粋のプログラマー 正規化？俺には関係ねえ
２，DB設計者 美しいDB設計は俺に任せろ
３，プログラマー兼DB設計者 俺を使うと高いぜっ
４，通りすがり
0902NAME IS NULL
04/12/17 23:29:17ID:???日付の演算なんて殆どは稼働日ベースなので組み込み関数は使えない罠。
0903NAME IS NULL
04/12/18 16:06:52ID:???昔は1つの技術に秀でた技術者（Ｔ字型技術者）が求められてたけど、
今は複数のコトがそこそこ出来る技術者（V字型技術者）の需要が
増えてるんじゃないかな。
低予算で発注されるとおのずとそうなる。
俺はいろいろやってるけど全部中途半端な技術だね。
0904NAME IS NULL
04/12/18 17:14:19ID:???0905NAME IS NULL
04/12/18 23:39:41ID:gz9/hjHmA点からB点から距離が5kmだった場合、
AとBのレコードに距離５という冗長したデータができますが、問題ないでしょうか？
先輩から言われたのはA点からB点までの距離を管理したい場合、
それぞれの点に座標値を入れて計算で求めるのがスマートらしいのですが
実際の業務ですと座標値のデータ（距離はわかってます）がなく、どうするのがいいのかよくわかりません。
アドバイスおねがいします。
0906NAME IS NULL
04/12/19 00:10:58ID:???元になる情報が無いならどうしようも無いっしょ。
0907NAME IS NULL
04/12/19 00:22:11ID:???0908NAME IS NULL
04/12/19 00:29:06ID:jkkDi30u0909NAME IS NULL
04/12/19 00:34:21ID:???稼動しないならないシステムが納品されましたとさ。
めでたしめでたし。
0910905
04/12/19 21:02:07ID:???具体的にいいますと電柱を管理してまして、現在、電柱1本1レコードで設置住所や強度、装着バンドなどを管理してます。
それに今回隣の電柱の距離も追加することになりました。
で、隣の電柱は左右だけでなく３つも４つも関連する電柱がある場合があるので、新たに５つぐらい項目追加すれば
OKなのではと思いました。
ただこの方法だと対象したレコードに追加した場合、関連柱のレコードも更新しないと整合性とれないのでこの方法は
はたしていいのかと疑問に思いました。
で、先輩のアドバイスで座標値いれて計算で距離をだぜばよいといわれたけど、座標値のデータはありません。
てな具合です。
>>908
距離テーブルは例えばAB間の場合
キー１ キー２ 距離
A B ５
みたない感じでよろしいでしょうか？
0911NAME IS NULL
04/12/19 21:11:58ID:???キー１ キー２ 距離
A B ５
だと、
B A ３
とかいう矛盾するデータを許すことになっちゃうね。
でも、CHECK 制約で キー１＜キー２ になるように、常にキー1のほうに小さなIDの電柱が
来るようにするといいかも?
0912NAME IS NULL
04/12/19 22:04:44ID:???線分テーブル（IDと距離）と点テーブル(ID)を作って、
繋がりは関連テーブル(線分IDと点ID)で表現するって事じゃないかと
0913912
04/12/19 22:23:48ID:???0914NAME IS NULL
04/12/19 23:27:31ID:???座標うんちゃらって事はGIS絡み？
>新たに５つぐらい項目追加すれば
5つより多く追加するとテーブルレイアウト変更しなきゃならん。
0915NAME IS NULL
04/12/20 01:49:36ID:???0916NAME IS NULL
04/12/20 04:40:17ID:???0917NAME IS NULL
04/12/20 07:02:18ID:???0918NAME IS NULL
04/12/20 12:22:52ID:???距離１０ｍ以上を一覧せよといった処理を頻繁に実行するようなら距離をそのまま持っ
ておくべきで、距離と座標の整合性はアプリ側で管理すべきものでしょう。
キー１＞キー２のようなルールを作れば１件ですみますけど単純に結合できなくなる
ので、頻繁に距離情報を使うなら２件のままでいいと思います。
電線に関する情報が距離以外にもいろいろあるようなら、電柱テーブル、電線テーブル、
電柱電線関連テーブルと３種類持つことになりますが、この場合も電柱電線関連テー
ブルのレコードは方向ごとに重複して持つのが一般的です。
0919NAME IS NULL
04/12/21 01:40:56ID:t+L2RHKl0920NAME IS NULL
04/12/21 08:08:40ID:???0921NAME IS NULL
04/12/21 08:17:10ID:???SELECT キー１,キー2,距離 FROM DISTANCE
UNION
SELECT キー2,キー1,距離 FROM DISTANCE
0922NAME IS NULL
04/12/21 11:09:41ID:???電柱ID,座標(null許可)
距離テーブル：
電柱1ID,電柱2ID,距離
更新時あるいは随時、電柱1ID,電柱2IDの座標をチェックし、
双方に座標があった場合に距離を計算し、
距離テーブルと大きく矛盾したら警告フラグを出す。
でよさそうな。
0923NAME IS NULL
04/12/21 11:13:06ID:???そうじゃなく、人系が入力しないと距離ってのが決まらないのであれば、もつ。
0924NAME IS NULL
04/12/21 11:16:30ID:???>
>で、先輩のアドバイスで座標値いれて計算で距離をだぜばよいといわれたけど、座標値のデータはありません。
>てな具合です。
てことだから距離よりも座標のほうが決まらないっぽいよ？
0925NAME IS NULL
04/12/21 12:59:21ID:???座標っていうか、電柱ＩＤと、それぞれのリレーション表現だけでＯＫそうですね。
距離っていうのが単純な直線距離のみなのか、それとも電線を張る上での実質距離なのかわからないけど、
計算項目じゃなく、人が入力する項目っぽいですね。
0926NAME IS NULL
04/12/21 18:08:26ID:mbUoXkUJ現状の業務で距離を入力（記録）させてるんじゃないかな。
座標ってのは経度とか緯度になるのか？
あんま詳しくないけど今のＧＰＳって精度どんぐらいなんだろうか。
誤差が大きくて実用にならねぇような気がするです。
0927NAME IS NULL
04/12/21 18:09:30ID:???0928美香 ◆RQ0Spv3q06
04/12/21 18:11:29ID:kPbEUVj40929NAME IS NULL
04/12/21 19:35:49ID:???製品にもよるけど10m以下くらいだったはず。
普通の電波状態なら道路1本外れる事はないくらいだよ。
カーナビみたいに補正がかかるともっと正確。
電柱みたいなものを管理する時は、正確な図面データを使ってれば問題無いっす。
0930NAME IS NULL
04/12/26 01:50:49ID:???0931NAME IS NULL
04/12/26 02:10:48ID:???0932NAME IS NULL
04/12/26 23:50:50ID:???0933NAME IS NULL
04/12/27 01:40:44ID:???残念！
ttp://220.111.244.199/otakara/1223idol02.jpg
0934NAME IS NULL
04/12/27 07:34:21ID:???0935NAME IS NULL
04/12/28 23:29:41ID:???0937NAME IS NULL
05/01/11 12:54:17ID:???鍛冶屋：なに？ その炭くれるのか？
中華：哈… 哈…
鍛冶屋：その炭くれるのか？
ごっくん。
0938NAME IS NULL
05/01/11 12:55:38ID:???0939NAME IS NULL
05/01/13 00:08:40ID:???なんかのネトゲかなぁ。あっちの世界もオフショア市場が広がってるもんね。
0940NAME IS NULL
05/01/13 16:14:49ID:q8L8KnWzたとえば、ある会員の曜日毎の来店回数とか
1.会員No、日、月、・・・、土
2.会員No.、曜日区分、来店回数
1.で問題なさそうだけど、あとから祝日は別に集計して
といわれたら、2.じゃないとテーブル構造変わってしまうし．．．
0941NAME IS NULL
05/01/13 16:18:40ID:???0942NAME IS NULL
05/01/13 21:00:20ID:???これでおｋ
0943NAME IS NULL
05/01/14 10:05:00ID:???ＯＲＡＣＬＥならＴＯ＿ＣＨＡＲで出せるし、他のＤＢＭＳでも大体はある。
ないなら自作しても十分だし。（基準日からの通算日数を割った余りで曜日は出せる）
0944NAME IS NULL
05/01/15 08:43:48ID:???年月日さえあれば曜日は後から計算できますが、祝日はどうするのが定石
なんでしょうか？
春分の日、秋分の日、ハッピーマンデー適用のものなど、毎年、日付が
変わるものについてですが。
過去の祝日を記録し続けるテーブルを用意するのが、良いのでしょうか。
0945NAME IS NULL
05/01/15 11:18:57ID:???俺が以前にかかわったシステムはそうだった。
過去も未来もテーブルに持ってた。
0946NAME IS NULL
05/01/15 13:35:37ID:???0948NAME IS NULL
05/01/15 21:31:23ID:???0949NAME IS NULL
05/01/16 14:11:20ID:???0950NAME IS NULL
05/01/17 09:20:23ID:???来場集計のようなサマリデータなら曜日は計算結果になるけど
マスタデータならどうします？
例えば、曜日別の担当者とか．．．
0951NAME IS NULL
05/01/17 09:33:36ID:???0952NAME IS NULL
05/02/05 00:39:53ID:???ttp://www.atmarkit.co.jp/farc/rensai/heaven03/heaven03a.html
このアットマークITの状態
上の話よりもっとヒドイ状態、
お客もCOBOLを何十年としてきた人だから
収集つかず。
Oracleなのにテーブル結合できないで
Listを使って、プログラム内で結合してます。
(#゜Д゜) ＜「定義書に書いてなくてもデフォルト値はNULLに決まってるでしょ！」
0953NAME IS NULL
05/02/07 14:26:08ID:???951はテーブル構造を
「hogeコード,日曜日担当者名,月曜日担当者名．．．．」にするか、
「hogeコード,曜日区分、担当者名」にするか聞いているのではないのか？
0954NAME IS NULL
05/02/07 20:47:32ID:???漏れ：「お兄さんはゾウさんの方が好きだよ！」
漏れ：「もちろん、股間についてるゾウさんの方がね！ (･∀･)ｹﾞﾍﾗﾍﾗ」
0955954
05/02/07 20:48:16ID:???orz
0956NAME IS NULL
05/02/16 08:43:42ID:???だれか分かりやすく解説して頂けませんでしょか？
0957NAME IS NULL
05/02/16 12:20:03ID:???0958NAME IS NULL
05/02/17 08:58:09ID:???このサイトいいね
0959NAME IS NULL
05/03/08 15:32:12ID:7EzAYhEF0960NAME IS NULL
05/03/08 16:45:23ID:???普通は実用レベルでやめちゃうけどキッチリやりたいね。
設計にもっと工数と予算を。
0961NAME IS NULL
05/03/08 23:58:07ID:???0962NAME IS NULL
05/03/09 00:46:03ID:???どっちで持つ?
0963NAME IS NULL
05/03/09 07:51:07ID:???文字だな。
理由は文字なら数字も入るが逆はできないから。
0964NAME IS NULL
05/03/09 09:43:06ID:???最終的なキーは文字列でよいと思う。
ただ、それの構成要素が 固定文字＋日付＋連番 みたいな場合は、
キーとは別にそれらのフィールドも持ってたほうが、あとの検索のつくりが楽になる場合はある。
0965NAME IS NULL
05/03/09 15:27:10ID:???利用者の目に触れるコードや直接使わせるコードは文字で、
システムの中だけで使うコードは数値を使ってる。
>>964
COBOLからそのまま移植したテーブルだとそういうのの山になってるよ。
0966NAME IS NULL
05/03/09 15:59:25ID:???別にコボルなわけじゃ無いんだが。
キーの構成要素事態もデータの属性ならば、キーとは別に当然持つべきと書いただけ。
キーにあるから端折って持たない場合、キーを分解して日とか出さないといけないから。
0967NAME IS NULL
05/03/20 21:18:17ID:???＞「定義書に書いてなくてもデフォルト値はNULLに決まってるでしょ！」
それ主キーなんですが、ということが過去に
0968NAME IS NULL
2005/03/27(日) 12:13:02ID:yy2hD2dw例えば、
伝票マスタ「出荷元、伝票番号、項目1、項目2、…」
主キー：出荷元、伝票番号
伝票データ「出荷元、伝票番号、商品、項目A、項目B、…」
主キー：出荷元、伝票番号、商品
伝票マスタ (1)-(n)伝票データ
「出荷元、伝票番号」で紐付け
と表現できるテーブルがあったときに、
伝票マスタ「CODE1、出荷元、伝票番号、項目1、項目2、…」
主キー：CODE1(システムで自動採番)
ユニーク制約：出荷元、伝票番号
伝票データ「CODE2、CODE1、商品、項目A、項目B、…」
主キー：CODE2(システムで自動採番)
ユニーク制約：CODE1、商品
伝票マスタ (1)-(n)伝票データ
「CODE1」で紐付け
というような実装にするのって普通にOKですか? JavaからHibernate使って
読み書きしようとすると、キーが複合キーだと扱いにくいので、下のように
したいのですが、このDBを別システムからも読み書きする場合に、別システム
担当者から、「なんでこんなバカなことしてんだ、ゴルァ」って思われますかね?
0969NAME IS NULL
2005/03/27(日) 14:01:59ID:???0970NAME IS NULL
2005/03/27(日) 19:12:33ID:???0971968
2005/03/27(日) 20:54:01ID:???だからとかでなく、こうするのは普通のことなんですね。
今まで関わったプロジェクトは、全部複合キーなテーブル。
今回、初めて小規模ながらDB設計から何から任されたので、
Hibernateの使用を検討していたところでした。試しに小物の
サンプルをいくつか書いてみて、複合キーよりも単独のキーの
方が扱いやすいというところまでは分かりました。多分この方針で
いいのだろうとは思ったのですが、実戦を経験している先輩方の
意見を聞けてさらに安心しました。これで安心して理論武装できます（`・ω・´)
あ、もちろん「だって２ちゃんでもこれでいいって言われたもーん」
などイタいことを言うという意味ではないです(w
0972NAME IS NULL
2005/03/27(日) 21:13:32ID:???関係ないけど「同一商品が入力できんぞ、ｺﾞﾙｧ」ってクレームがきそう。
0973NAME IS NULL
2005/03/27(日) 21:39:08ID:???いつ何時（下手すると今のシステム作ってる最中）「再注文は既存伝票番号＋枝番で〜」とか言われるか分かったもんじゃないし
0974968
2005/03/27(日) 21:49:49ID:???確かに、一覧出すときは必ず結合です。かといって、CODE1で
外部キーを張っておきながら伝票データに出荷元を持つってのも
なんか冗長だし、マスタの出荷元を変更した時に全データの出荷元を
書き換えたりってのもイヤだし、万が一CODE1で結合したマスタの
出荷元とデータの出荷元が一致しないなんて事態が発生したときの
こと考えると、この方がいいかなと考えました。
ちなみに、同一伝票内の同一商品については、必ず集約して1レコードに
するというルールなので、そこはアプリでカバーするです。
0975NAME IS NULL
皇紀2665/04/01(金) 00:29:16ID:???マッチングするロジックやカラム内にカンマ区切りの値があるとかの索引順編成ファイルでも
扱うような珍妙なテーブル構造でできてるんだ!!SQLでサーバサイドで処理できるよう
書き直してやろうにも非正規形のテーブルがちらほらあって修正出来ねぇよ!!
0976NAME IS NULL
2005/04/08(金) 18:52:20ID:???http://society3.2ch.net/test/read.cgi/police/1109699316/
0977NAME IS NULL
2005/04/17(日) 02:48:51ID:???第２正規形と第３正規形とボイスコッド正規形の違いが分かりません。
分かりやすく教えてください。
0978NAME IS NULL
2005/04/27(水) 15:11:42ID:???要するに，何にもわかっておらんのじゃないか．
http://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E6%AD%A3%E8%A6%8F%E5%8C%96
ここでも読んでから，また質問すれ．
あと，ここまであつかましい質問には，不快だから誰も普通は回答しないことも
覚えといてくれ．
0979NAME IS NULL
2005/05/10(火) 21:11:05ID:jo2i5dU5DBはAccessです。
現在、テーブルの列数が250くらいなのですが、
新商品追加に伴い、20列ほど必要なのです。
でも、mdbって列数のMAXは255でしたよね。
一番工数の少ない対応方法ってなんだろ？
0980NAME IS NULL
2005/05/10(火) 21:11:44ID:???0981NAME IS NULL
2005/05/10(火) 21:12:00ID:???0982NAME IS NULL
2005/05/10(火) 21:13:46ID:???そこに項目追加していけばいいんじゃねない？
0983979
2005/05/10(火) 21:18:14ID:???質問させて頂きました。
でも、今からそれをやると、工数がかかり過ぎる。。
やはり>>982さんの対応方法で逃げるしかないのか。
レス数が950を超えています。1000を超えると書き込みができなくなります。