DB設計を語るスレ ２
レス数が950を超えています。1000を超えると書き込みができなくなります。
0001NAME IS NULL
2008/10/08(水) 18:34:13ID:PQV+Wmyc前スレ
DB設計を語るスレ
http://pc11.2ch.net/test/read.cgi/db/1166540159/
0002NAME IS NULL
2008/10/08(水) 18:39:40ID:???0003NAME IS NULL
2008/10/08(水) 18:41:25ID:???日付を「昭和60年2月3日」のように和暦で扱うアプリの場合、カラム型は
普通に日付型を使った方がいいでしょうか？
アプリは.NETで作っていて、
元号をコンボボックス、年月日をテキストボックスで選ばせるUIなので、
元号、年、月、日を別カラムで保持すれば楽かなーと思うのですが。
どうでしょう？
0004NAME IS NULL
2008/10/08(水) 19:52:25ID:???この板の即死判定って何レス？
しかしまぁ、はっきりいって需要ないのかも。
0005NAME IS NULL
2008/10/08(水) 20:08:27ID:???0006NAME IS NULL
2008/10/08(水) 23:14:26ID:???>>3
日付型を使うべき
0007NAME IS NULL
2008/10/08(水) 23:48:08ID:???よい書籍とかあったら教えて下さい。
0008NAME IS NULL
2008/10/10(金) 14:54:01ID:???３文字くらいしか入力しないのに、
１００文字の固定長ｗ
理由をたずねたら、
ﾃﾞｰﾀﾍﾞｰｽの構造上、固定長のほうが処理が
パフォーマンスがいいんだよって
ＳＱＬみてみたら
全部のＳＱＬに毎回ＴＲＩＭかけてるしｗ
ＴＲＩＭするなら、最初から可変長にしてくれｗ
0009NAME IS NULL
2008/10/10(金) 23:11:15ID:???ERDレッスンかなあ。
業務ごとの濃い話になると別。
0010NAME IS NULL
2008/10/20(月) 14:21:28ID:???0011NAME IS NULL
2008/10/20(月) 16:38:57ID:???＞パフォーマンスがいいんだよって
COBOLerの脳内妄想かと。
固定長しか知らん人種だし。
0012NAME IS NULL
2008/10/20(月) 19:34:57ID:???0013NAME IS NULL
2008/10/20(月) 22:34:36ID:???しやすいというのはあるな。
まぁ、ほぼ3文字しか必要ないのに100文字ってのはページ使用効率が
悪くて逆にパフォーマンスを落としそうだが。
0014NAME IS NULL
2008/10/21(火) 22:22:08ID:JfHp8/7P教えていただけたら幸いです
0015NAME IS NULL
2008/10/22(水) 11:05:30ID:???>>9
0016NAME IS NULL
2008/10/24(金) 10:23:09ID:???テーブルの正規化はこうだといわれてたりするけれど、
人の作ったDB見てると、それらが必ずしも守られていなかったりしていて、
そのDBを作った人の個性があるように感じる。
誰かが作ったDBを、他の人が見ると、「これはこういう効率の悪さがある」と
設計を批判する事もあるようだが、システムとしては稼動しているし、
使用者にとっては特別致命的なものがあるわけでもなかったりする。
となると、DB設計というのは、これが正しい、これが結論だというものは
無くて、結局はその人の考え方（速度、保守性、拡張性、引継ぎ、などで
何処を重要視するか）の世界みたいなところなのかなと思う。
このスレに来てる人はどう思う？
0017NAME IS NULL
2008/10/25(土) 00:53:05ID:Hv10EAg0固定長の文字列を格納するのにchar、とvarchar2ではやっぱりcharのほうが速度的に良いの？
今まで行ったたいていの現場では「文字列は固定長・可変長関わらずvarchar2で」っていう感じでした。
理由はいろいろあったんだけど、
・「こっちは固定長だからcharで、あっちは可変長varchaｒ2で」っつーのが単純にわずらわしい
→設計効率重視意見
・「固定長をvarchaｒ2に入れてもcharに入れるのと速度的に大して変わらない。大勢に影響なし」
→性能変わらない意見
・charだと「固定長だと思っていたけど、その後に可変長になった」っていう仕様変更に弱い。
→当初より短い文字列を入れることになった→アプリ側でtrimを入れることに→うざい
→心配だから全部trimを入れた→アプリ開発当初からうざい
という感じで、固定長ならcharを使おうって積極的に押す人はいませんでした。
これまで固定長文字列をvarchar2で扱ってもcharで扱っても速度的に違いを感じたことは無いんだけど、
固定長ならやっぱりcharのほうが良いの？
最大で1万レコードくらいしか扱ったことが無いんだけど、でかいと違うのかね？
0018NAME IS NULL
2008/10/25(土) 05:51:16ID:???DBMSによる。varchar2といってるからOracleなのだろうけど。
0019NAME IS NULL
2008/10/26(日) 11:27:45ID:???制約とかINDEXとかにも関わってくるけど、DB2とかだとCHARの方が速いな。
1万レコードってそりゃExcelでも処理できなくもない処理量だから、
性能変わらないって意見も解る。
そういう現場なら設計効率重視で可変長のみでもいいと思うけど。
個人的にはそういう重要な作業を「わずらわしい」と感じるヤツに設計は
して欲しくないんだが。
0020NAME IS NULL
2008/10/27(月) 01:45:28ID:eNeS7+/+あれってほんとうに効果あるの？
0021NAME IS NULL
2008/11/02(日) 10:48:06ID:???今はハードの圧倒的進化とRACで、ほぼ限界無く欲しい処理能力得られるから可変長でも良いと思うけどね。
どうせミドルのCやJavaの時点でポインタという名の可変長メモリ管理してるから、速度気にしてもしょうがない。
可変長で処理できるほどの潤沢なメモリが無かった時代に使ってたようなコボルのようにどこまでも固定長で処理してる訳じゃないし。
業務だといろいろ小手先の要求が有るから、表記用の文字列と処理用の日付の両方で持ってる。
３２日って入力して月末処理したいだとか。orz
伝票や帳簿には末日って書いてたからシステムでも同じようにやりたいとか。orz
締めのタイミングが、後藤日＋末日だったりするし。日付型で末日とか持てりゃ苦労は無いが。
0022NAME IS NULL
2008/11/02(日) 21:39:17ID:???COBOLerがいるならある意味仕方ない感はあるんだが、
そこでCOBOLerのイカれた提案を拒否して、美しい設計を目指すべきだと思うけど。
つか月末（営業）日や五十（営業）日を算出する関数やクラスを定義するだけだろうに。
0023NAME IS NULL
2008/11/02(日) 21:49:46ID:JdZg49uN0024NAME IS NULL
2008/11/03(月) 23:29:45ID:???1年に何十回もあるわけじゃないしユーザー側で決めさせれば良い。
規則的ではない変な締めがあっても対応出来る。
0025NAME IS NULL
2008/11/07(金) 03:23:17ID:eToAOLwU具体的には
１０日から、２０日まで３００円、２１日から３０日まで１５０円 ってテーブルと
毎日の売上数の入ったテーブルをつくって
１４日から２４日までの、売上高を算出させたい！
とか思ってるんだけど
☆売価テーブル
期間開始日 期間終了日 売価
___________10______________20____300
___________21______________30____300
☆売上数テーブル
日付 売上数
____1__________5
____2__________3
____3__________2
____4_________10
____5__________8
．
．
．
___30_________7
こんなかんじ？
でも、これだとＳＱＬでデータ拾ってくるのに
日付ＪｉｏｎでＳｕｍってもってこれないから、めんどくさいよね？
かといって
☆売価テーブル
日付 売価
____1_______300
____2_______300
____3_______300
____4_______300
____5_______300
．
．
．
___29______150
___30______150
とかいう、売価テーブルつくるのも、いくら領域いるんじゃーって感じじゃない？
なんか、いいほうほうないかな？
0026NAME IS NULL
2008/11/07(金) 04:15:33ID:???SELECT
SUM(売上数 * 売価)
FROM
売上数テーブル
JOIN 売価テーブル ON 日付 BETWEEN 開始日 AND 終了日
WHERE
日付 BETWEEN 14 AND 24
価格がどの時点で確定するかというのが重要なので
売上テーブルに売価が必要なこともあるでしょう。
売ったあとに売価テーブルの内容が変わったら大変なことになってしまうし。
0027NAME IS NULL
2008/11/07(金) 22:16:08ID:???人によって好みは分かれるだろうけども、自分なら日毎に持つな。
それと、開始日/終了日の方は終了日を省略して開始日のみにした方がまし。
0028NAME IS NULL
2008/11/09(日) 23:12:05ID:IPd6NExyやっぱIE？
0029NAME IS NULL
2008/11/10(月) 00:30:01ID:???日付ごとに売値を持ってるほうが、メンテ楽そう。
売価テーブル、売価履歴テーブル、売上数テーブルを作って、
価格改定があったら売価テーブルを更新。一日の〆でその日の
売価テーブルを売価履歴テーブルにバッチでコピー。
で、
select
sum(売上数テーブル.売上数 * 売価履歴テーブル.売価)
from
売上数テーブル
left join 売価履歴テーブル on
売上数テーブル.日付 = 売価履歴テーブル.日付
where
売上数テーブル.日付 between '2008-11-14' and '2008-11-24'
みたいな。
0030NAME IS NULL
2008/11/10(月) 08:39:10ID:???>いくら領域いるんじゃーって感じじゃない？
１年でたった365レコードでしょ？
0031NAME IS NULL
2008/11/10(月) 11:00:54ID:???0032NAME IS NULL
2008/11/10(月) 20:20:30ID:1PkOr8o/一品目なら３６５レコードだけど
これが、数万品目あつかう小売チェーン店とかだったら年、数百万〜数千万レコード
これを何に使うのかによるけど、売り上げを算出するってことは前年比とか
数年分の比較に使うんだろうから、その３，４年分
って考えたら、結構な量になるんじゃね？
でも、実際売価が変更されるのは、週一回あればいいとこだろうし
ものによっては数年変えないとかあるだろうに、余計なデータ増やすのは
パフォーマンスからみるとイマイチな設計なきがするなぁ
＞日付 BETWEEN 開始日 AND 終了日
で取れるようにしたほうが、ＤＢサイズ小さくなってキャッシュ利き易くなるし、いいんじゃね？
0033NAME IS NULL
2008/11/16(日) 01:56:57ID:???0034NAME IS NULL
2008/11/16(日) 03:29:23ID:???デザパタというよりアナパタに近いよな。
0035NAME IS NULL
2008/11/16(日) 04:13:49ID:???是非、その本を教えてください
お願いします
0036NAME IS NULL
2008/11/16(日) 05:39:40ID:???生産管理のはかなりレベル高い。生産管理やった事ないけど
読み応えあって面白かった。
あとは「グラス片手に」シリーズとか。
DBマガジン連載時によく読んでて会社のバックナンバー揃えて貰ったら
とたんに書籍が出おった・・・。
もうちょっと業務から設計よりになると「楽々ERDレッスン」も面白いです。
渡辺氏とは犬猿の仲。でも実装はこっちのが現実的かと俺は思う。
あとは本じゃないけど渡辺氏の公開してる
データモデルはいやーお世話になりました。
http://homepage2.nifty.com/dbc/
0037NAME IS NULL
2008/11/16(日) 14:29:38ID:???0038NAME IS NULL
2008/11/16(日) 14:31:57ID:???結局ケースバイケースで全然逆のこと書いてあったりして、途中で
読むの放棄した。結局ケースバイケースのバランスなんだよ！
0039NAME IS NULL
2008/11/16(日) 17:22:43ID:???ばれちゃーしょうがーねーな
でも本はいい本だから読んでね
0040NAME IS NULL
2008/11/16(日) 19:33:51ID:???羽生さんは大規模システムもちゃんとやってきてる人なのかな？
ABDとか大きいレガシーシステムでどうせいっちゅーんじゃ、みたいな。
業務系は技術系と比べて情報少ないんで、
自分のやってることになかなか自信がもてない。
各社ごとではちゃんとノウハウたまってんのかね？
0041NAME IS NULL
2008/11/16(日) 22:20:46ID:???貯まってたら3Kとか最下層とか言われて無いだろｗ
0042NAME IS NULL
2008/11/17(月) 02:58:17ID:???そうですね・・・他にないってだけかw
だけっていっちゃ悪いか。
業務系、バッドノウハウは立派にたまってましたねぇ。
とくに大手製造業の子会社行った時は恐れ入った。
0043NAME IS NULL
2008/11/19(水) 00:11:57ID:???0044NAME IS NULL
2008/11/19(水) 00:23:52ID:???複合インデックスさえあれば
0045NAME IS NULL
2008/11/19(水) 00:38:37ID:???0046NAME IS NULL
2008/11/19(水) 02:49:26ID:???犬テーブルと猫テーブルとかってわける？
動物テーブルでまとめる？
004746
2008/11/19(水) 02:53:38ID:PDW1LNDk複数のテーブルで一意なIDが欲しくなった時どうする？
0048NAME IS NULL
2008/11/19(水) 03:04:51ID:???動物テーブルで分ける
ＩＤ＋種別（イヌ/ネコ/ハムスター・・）
0049NAME IS NULL
2008/11/19(水) 03:07:52ID:???動物テーブルには犬猫以外にも数十種の動物が含まれる
それぞれが専用フィールドを持っていたら？
0050NAME IS NULL
2008/11/19(水) 03:09:43ID:???データがみっちり詰まった普通サイズのテーブルが複数なのと
どっちが良いか
後者にした場合、動物全体での一意ＩＤが欲しい場合どうするか？が問題になる
0051NAME IS NULL
2008/11/19(水) 03:18:30ID:???フィールド：一意ID、犬ID、猫ID、、、、
これだと動物の種類の数だけフィールドが必要で、
新しく動物の種類が追加された時にテーブルの追加だけでなく
ここへのフィールド追加もやらなきゃいけない。
テーブル追加だけで済んだ方が良い。
0052NAME IS NULL
2008/11/19(水) 03:26:29ID:???１つの巨大テーブルにするほうが
実用上の障害が思いつかない
誰か思いつく？
0053NAME IS NULL
2008/11/19(水) 04:42:21ID:???ＩＤ＋種別（イヌ/ネコ/ハムスター・・）＋属性
0054NAME IS NULL
2008/11/19(水) 10:40:33ID:???005546
2008/11/19(水) 16:21:28ID:???それは属性テーブルを動物別に作って外部キーはるってこと？
結局>>51だと思うけど
今のところの結論としては、
動物テーブルでまとめて、動物別にビューを作るのがいいかなと
0056NAME IS NULL
2008/11/19(水) 16:22:53ID:???パフォーマンス的に不利だからね
かといってテーブル間の一意ＩＤが欲しいがために１つのテーブルにまとめるってのも
おかしいとは思うけどね
005746
2008/11/19(水) 17:43:56ID:???単に一意ＩＤを振っても、あるＩＤがどのテーブルのどのレコードなのか
を特定できなきゃいけないからリレーションテーブルは必要なんだよね
そしてパフォーマンスの不利は避けられない
やはり動物テーブル＋ビューが最適と判断した
0058NAME IS NULL
2008/11/19(水) 17:52:22ID:???例えば明日からペットショップでマンモスハナアルキの扱いを
新たにはじめるとして、そんなマイナー動物一種類のために
巨大な動物テーブルのスキーマを変更するのもどうかと。
ID+共通データの動物リレーションと動物別リレーションに分けて
ある場合、ハナアルキ類のためのリレーション一つ作成して後は
幾つかビュー定義をちょこまか修正すれば完了。
既にストアされているデータへの影響は少なくて済むはずです。
0059NAME IS NULL
2008/11/19(水) 17:53:20ID:???下らなすぎてスルーしてたけど
> やはり動物テーブル＋ビューが最適と判断した
最適かどうかは場合によるわな。
NULLだらけの横長テーブルなんて保守したくないし。
パフォーマンスの不利がどれほどのもんかとかな。
006046
2008/11/19(水) 18:13:15ID:???そういえばテーブルへのフィールド追加って登録されてるレコード数に依存して負荷上がるのか。
でも動物テーブルから動物別テーブルへのリレーションはどうやって張るの？
WEBアプリフレームワークが自動認識してくれるような形で張るには、（つまりRDBの基本仕様上で張るには）
>>51みたいに動物の種類数だけフィールドを用意しないといけないと思うんだけど。
006246
2008/11/19(水) 18:17:11ID:???動物別テーブルと動物テーブルを結合したビューを作っておけば良いのかな
その結合処理って高速に出来るのかな？
0063NAME IS NULL
2008/11/19(水) 18:17:32ID:???0065NAME IS NULL
2008/11/19(水) 18:29:09ID:???>でも動物テーブルから動物別テーブルへのリレーションはどうやって張るの？
基本的には>>62の通りで良いのではないかと。
アプリケーションフレームワーク云々は別として、Relational Database Model
に基づいて実装するなら、動物リレーションで各動物に一意な動物IDをキーと
して振って、種類別リレーションからはその動物IDを参照。
後は動物リレーションと各種類別リレーションの間に外部キー制約を定義。
種類別にIDを振っても良いけど、基本的には冗長になるので必要無いはずです。
あとこういう分割は普通に行われているので、実用的な速度で結合処理を実現
する方法についてはちゃんと解が存在しています。
インデックス等々に関して調べると良いのではないかと。
006646
2008/11/19(水) 18:32:26ID:???ありがとう。
0067NAME IS NULL
2008/11/22(土) 03:29:20ID:???あれ、もしかしてリレーションテーブルには各外部キーにインデックス張っても
意味ないの？
>>62
DB構築者がビュー作って使う利点ってあるの？
0068NAME IS NULL
2008/11/23(日) 02:48:09ID:???他の２つのテーブルを繋ぐ処理だけだろうって事。
0069NAME IS NULL
2008/11/23(日) 02:50:12ID:???ビューの利点＝プログラムでＳＱＬ書かなくて済む、なんて理解してるんだったら
そんなの定数定義しておけば良いだけだしＤＢにビューなんて機能持たせる意味ないだろ
0070NAME IS NULL
2008/11/23(日) 11:32:04ID:???ビューは実装寄りの話だ
0071NAME IS NULL
2008/11/23(日) 12:07:03ID:???リレーションテーブルって複合インデックスのほうがいいんでしょうか
0072NAME IS NULL
2008/11/23(日) 17:46:01ID:???0073NAME IS NULL
2008/11/23(日) 21:17:09ID:???ユーザーは複数の組織に所属している事がある
ユーザーが特定の部門に属しているか、特定の権限を持っている場合ににのみ
特定のテーブルと1:1の関連を持たせる
しかし、権限や部門がが重複すると、そのたびにユーザーが抽出されるので
同じユーザーのデータなのに、複数データが出来てしまう。
こういうとき、どうするのが一般的なんでしょう？
0074NAME IS NULL
2008/11/23(日) 21:48:57ID:???DISTINCT一発で解決する問題のようにも見えます。
0075NAME IS NULL
2008/11/23(日) 22:12:47ID:???１つのユーザーテーブルに組織も権限も部門も全部つっこもうとしてるんだろ？
0076NAME IS NULL
2008/11/23(日) 22:15:37ID:???元のユーザーTBLがそういう感じなんよ
そこの部分はいじれない状況ということで許してくれ
やっぱり重複排除しかないのかねぇ
0077NAME IS NULL
2008/11/23(日) 22:27:58ID:???>元のユーザーTBLがそういう感じなんよ
もうテーブルが存在するなら、質問するときはそのスキーマの概略
程度でも示さないと。でないと答える方も>>74とか>>75みたいに無駄な
推理に頭を使う事になるでしょう？
0078NAME IS NULL
2008/11/23(日) 22:37:37ID:???すまん
0079NAME IS NULL
2008/11/23(日) 22:51:55ID:???こういう糞テーブルの保守が必要なんですけど、って話すだろｗ
0080NAME IS NULL
2008/11/24(月) 01:31:03ID:???普通に再設計して既存アプリのインターフェース(元TBL型のVIEW)用意すればいんでね？
0081NAME IS NULL
2008/11/24(月) 02:03:02ID:???郵便番号マスタ、市区町村マスタ、銀行マスタ、法定休日マスタ、和暦マスタ、消費税率マスタ
みたいなマスタテーブルを作ることに疑問を覚えるのは俺だけか？
何故、日本全国共通の情報を各々のDBに持ってちまちまメンテするんだろう？
疑問に思っちゃいけないことなのか？
0082NAME IS NULL
2008/11/24(月) 02:11:33ID:???・完全参照系データでしかもそれほど動的に変わるものではないからWebAPIにする価値無し
0083NAME IS NULL
2008/11/24(月) 02:45:40ID:???0084NAME IS NULL
2008/11/24(月) 02:59:24ID:???WebAPIにしたらどこの誰が利用してるか分かる可能性がある
0085NAME IS NULL
2008/11/24(月) 09:37:58ID:???0086NAME IS NULL
2008/11/24(月) 10:21:38ID:???じゃあ、どうしろと？
0087NAME IS NULL
2008/11/24(月) 13:27:15ID:???その中でもファイルとして公開されてる物はある。
でも、提供先が国外だったりしてデータおかしかったりする物もある。
郵便番号なんかはバッチ処理でWebから落としてきて〜ってどこでもやってるでしょ。
↑をメンテ処理って言ったらそれまでだけどｗ
0088NAME IS NULL
2008/11/24(月) 15:37:55ID:???この手のマスタを毎月（或いは毎年）メンテしてるやつらって、
ホントくだらない人生送ってるな思うよ。
0089NAME IS NULL
2008/11/24(月) 15:59:02ID:???0090NAME IS NULL
2008/11/24(月) 16:09:58ID:???0091NAME IS NULL
2008/11/24(月) 16:21:56ID:???0092NAME IS NULL
2008/11/24(月) 16:22:19ID:???俺様に無断で祝日増やしやがって馬鹿政府のこんちくしょう。
将来なんちゃらクラウドの上にテータベースに乗っけて運用するよう
になると、この手のマスターデータは標準部品として提供されるように
なるのでしょうか。
0093NAME IS NULL
2008/11/24(月) 16:42:55ID:???部下ねぇw
部下のことをくだらない人生送っていると思いながら、その仕事をやらせているわけか。
それが本当なら、そりゃまともにやろうという気がうせるだろう。
0094NAME IS NULL
2008/11/24(月) 18:46:07ID:4T2xxdv4国会で法律が変わるたびに各々の自治体で
ベンダーに依頼して改修してるんだよな。
後期高齢者医療制度対応とかさ。
この国はどんだけアホなんだろう？
0095NAME IS NULL
2008/11/24(月) 22:59:03ID:???ＳＩ企業にとっちゃ、仕事が増えるからいいんじゃない。
0096NAME IS NULL
2008/11/25(火) 01:12:59ID:???世の中がまわる為に必要だから止められないんだよ
0097NAME IS NULL
2008/11/25(火) 01:28:14ID:???住所データとかは各ベンダーが持たないなら国がWebAPI提供するしかないし
今の形が妥当
0098NAME IS NULL
2008/11/25(火) 03:17:40ID:???> 後期高齢者医療制度対応とかさ。
上手に作られたシステムなら、マスターの変更だけでＯｋ。
でも、テストは必要。
結局、ベンダーに発注するしかない。
0099NAME IS NULL
2008/11/25(火) 11:32:56ID:rHJnodNO道路や建物つくる感覚で発注してるんだろうね。
0100NAME IS NULL
2008/11/25(火) 15:22:35ID:???0101NAME IS NULL
2008/11/25(火) 17:56:35ID:???商品テーブルにジュース ポテト ハンバーガーって商品があって
この3つを組み合わせでバリューセットって商品を作りたいとすると
商品テーブルのバリューセットの主キーとジュースの主キーを組み合わせるテーブル作ればOKだよね？
0102NAME IS NULL
2008/11/25(火) 18:04:20ID:???0103NAME IS NULL
2008/11/25(火) 18:08:08ID:???お前は同じテーブル内のレコードを繋げるリレーションテーブルを作ろうとしてるのか
別にそれでも実装上の問題はないのか・・・
0104NAME IS NULL
2008/11/25(火) 18:18:18ID:???この商品はこの3つの商品の組み合わせですみたいな感じで
セットの値段とバラの値段を表示したいなと思いまして。
>>103
実装上は大丈夫なんですが、もっといい方法があるかなと思って質問させて貰いました
0105NAME IS NULL
2008/11/25(火) 18:58:29ID:???三点セットなら、バリューセットのキーと主菜・副菜・ドリンクのキーの計4つの
キーを含むリレーションを作成。
セットによって副菜が2つになったりドリンク無しだったりと構成要素が大きく
異なる場合はバリューセットのキーと構成要素のキーを含むバイナリ
リレーションで表現。
0106NAME IS NULL
2008/11/25(火) 19:17:48ID:???単品テーブル（商品テーブルID＋その他属性）
セットテーブル（商品テーブルID＋その他属性）
単品セット間リレーションテーブル（単品テーブルＩＤ＋セットテーブルＩＤ）
これでセットメニューがどんな構成だろうと対応出来るぞ
バイナリも使う必要ない
0107NAME IS NULL
2008/11/25(火) 19:29:56ID:???>>106
ありがとうございます。
家帰ったらテーブル作ってみて試してみます！
0108NAME IS NULL
2008/11/25(火) 19:30:26ID:Y/2zDRqR>単品セット間リレーションテーブル（単品テーブルＩＤ＋セットテーブルＩＤ）
これがまさに、バイナリリレーション(binary relation: 二項関係)ですね。
あとこの手のスキーマ設計の場合、
・単品商品とセット商品の共通部分を商品テーブルとして切り出す
・単品テーブルとセットテーブルはそれぞれ共通属性も含めて保持
全商品の共通属性に関しては別途商品ビューを用意して参照
のどちらもアリなので、お好きな方をどうぞ。
0109NAME IS NULL
2008/11/25(火) 23:18:29ID:???0110NAME IS NULL
2008/11/26(水) 00:35:25ID:???原価とか利益をどう持つかで色々な設計のパターンが出てきそうだ
0111NAME IS NULL
2008/11/26(水) 15:15:15ID:???0112NAME IS NULL
2008/11/26(水) 15:18:27ID:???具体的な指摘をして欲しい。
俺がリレーションテーブルと言う言葉を使うのは、
マスタもテーブルもテーブルなのにおかしいと思うから。
かといってリレーションと言うだけではＦＫなども含まれてしまう。
0113NAME IS NULL
2008/11/26(水) 16:16:47ID:???>>111はなんだか意地悪な感じだね。
「リレーション」というのは「テーブル」の事を指します。
なので「リレーションテーブル」っていうと「犬ドッグ」的な感じになっちゃいます。
RDBの基となる関係代数からの用語ですが。
テーブル：リレーション
レコード：タプル
フィールド：カラム
テーブルとテーブルの関連のことは「リレーションシップ」と呼びます。
0114NAME IS NULL
2008/11/26(水) 16:18:20ID:???>マスタもテーブルもテーブルなのにおかしいと思うから。
>かといってリレーションと言うだけではＦＫなども含まれてしまう。
ってか、この２行の意味が分かんない。
0115NAME IS NULL
2008/11/26(水) 16:29:01ID:???それは文脈によらない？
DBの実装上の用語ではおかしい事は言ってないよ。
http://pgyougo.seesaa.net/article/21114655.html
マスタなのかテーブルなのかを明示したい場合、どういい分ければいいの？
リレーションとリレーションシップで言い分けるより通じる。
0116NAME IS NULL
2008/11/26(水) 16:46:11ID:???http://homepage1.nifty.com/silabel/it/master_table.html
さらに、リレーションシップという言葉がＦＫを含む例は
mysql workbenchがある。
リレーションシップという言葉はＦＫもリレーションテーブルも含んで使われている。
リレーションシップを示す”テーブル”のみを表現する言葉を俺は知らない。
ここで言うテーブルとはRDBMSに対するSQLでcreate tableで作成されるもののみを指す。
関係代数における概念は、実際のRDBMSやその関連ソフトにおいて
「不都合なく実装出来る形」にしか実装されていない。
概念的に忠実に再現されているとは限らない。
マスタ＝基幹データ
（マスタと比較される文脈で出される）テーブル（俺がリレーションテーブルと呼ぶもの）＝マスタ間のリレーションシップを示したテーブル
テーブル＝マスタとリレーションテーブルを含んだもの（SQLでcreate tableで生成するもの）
果たして、この世に存在し得るデータ一般を表現する一形式を議論する場合と
ある業務のＤＢ設計を議論する場合で
同じ用語体系が使われるべきだろうか？
0117NAME IS NULL
2008/11/26(水) 17:00:17ID:???>マスタなのかテーブルなのかを明示したい場合、どういい分ければいいの？
ディメンジョンとファクトかな、と思ったりするのはOLAP畑の自分。
(いや、厳密に対応するわけではないのでツッコミは勘弁ですｗ)
>リレーションシップを示す”テーブル”のみを表現する言葉を俺は知らない。
このようなエンティティ間の関係だけを格納するテーブルを定義する
というのはデータベーススキーマ設計におけるベストプラクティスと
いうかデザインパターンの一つで、でもそれには決まり切った名前が
ない、という不幸なんでしょうね。
昨日もバイナリリレーションと書いてやばっ、と思ったらやはり誤解が。
言葉って難しいです。
0118NAME IS NULL
2008/11/26(水) 17:01:12ID:???検索してもほとんど出てこないから通じない可能性が怖いけどね。
あとさらに言えば、リレーションがリレーションシップと同じ意味で使われる場合がかなり多い。
今検索して見つけた例
http://support.codegear.com/print/35960#5%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E9%96%93%E3%81%AE%E3%83%AA%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3
「テーブル間のリレーション」と言う言葉が使われている。
>>113によれば「ドッグ間の犬」だな。
0119NAME IS NULL
2008/11/26(水) 17:06:02ID:???意味は通じるけど111のようなツッコミが入るのは不思議じゃない。
>>112で「正しい言葉だと思うけど」と言ってたけど、正しい言葉ではないだろ。
通じるけど。
>マスタなのかテーブルなのか
これはもう通じない。なにを言ってるの？
>リレーションとリレーションシップで言い分けるより通じる。
まともに勉強している人はリレーションとリレーションシップで通じる。
0120NAME IS NULL
2008/11/26(水) 17:14:56ID:???0121NAME IS NULL
2008/11/26(水) 17:21:30ID:???誤用が広まっていても、正しいことにはならないよ。
日常会話ならともかく、開発のときは気をつけるべきだね。
そして
http://homepage1.nifty.com/silabel/it/master_table.html
は酷すぎ。信用しちゃいけない。
0122NAME IS NULL
2008/11/26(水) 17:44:34ID:???今話題になってるのは「関連テーブル」と呼ぶことが多いような気がする
T字形では「対照表」と呼ぶのかな
>>118のディテールテーブルというのは違うよね？
・単品テーブル
・セットテーブル
・単品セット関連テーブル
で言うと、単品テーブルの事をディテールテーブルと呼ぶ。
マスタ/ディテールという呼び方は、マスタ/トランザクションのマスタと用語が重複してしまうので、ヘッダ/ディテールとか親/子を使うようにしている。
>>121
>http://homepage1.nifty.com/silabel/it/master_table.html
>は酷すぎ。信用しちゃいけない。
ひどいね
0123NAME IS NULL
2008/11/26(水) 17:47:40ID:???＞自分勝手な用語は
一般的な用語しか使っていない。
リレーションテーブルと言う言葉はテーブルと言う言葉を含んでいてマスタと比較する文脈であれば問題は無いと思う。
＞これはもう通じない。なにを言ってるの？
一般的な用語であるかどうか検索して確認してから発言しろ。
>>121
酷すぎるという根拠は貴方の主観以外にあるの？
俺は検索と言う方法でそれが一般的な用語であると言う客観的な根拠を示したつもりなんだけど。
0124NAME IS NULL
2008/11/26(水) 17:55:56ID:???それは間違いだったね。
>>122の通りディテールテーブルと俺が言うマスタ文脈上のテーブルは意味が違う。
関連テーブルだと英訳すればリレーションテーブルになるけど、
もし英語で設計書かけと言われたらどう書くの？
0125NAME IS NULL
2008/11/26(水) 18:18:41ID:???http://q.hatena.ne.jp/1177173258
これのtbl_は恐らく関連テーブルを指してるだろうね。
マスタとトランが示されてるのに同列で語られるものは関連テーブルしかないからね。
本来の意味通りのテーブルならテーブル名の接頭辞にする意味ないからね。
http://72.14.235.132/search?q=cache:yznFGh5_EJ8J:questionbox.jp.msn.com/qa763441.html+http://www.leasekin.com/rodan/mag2pos/002/00046.htm&hl=ja&ct=clnk&cd=1&gl=jp
これも同じで、本当は質問者が遭遇していたのは「関連テーブルを指す”テーブル”」なんだろうけど、
回答者はテーブルという用語が文脈によって意味が変わる場合もある事に気付いてない。
本当にただのテーブルと言う意味なら質問者はマスタやトランと並べて質問しないだろうね。
0126NAME IS NULL
2008/11/26(水) 18:30:04ID:???http://blog.goo.ne.jp/xmldtp/e/a416473823c05b2b24108981b3025bad
結局、関連テーブルに対し適当な名前が付けられていない。
関連テーブル以外には名前が付けられている事があって、
単にテーブルと呼べば関連テーブルを指すと言うケースがある。
関連テーブルは英訳すればリレーションテーブルになってしまい、これも適当な用語ではない。
0127NAME IS NULL
2008/11/26(水) 18:41:31ID:???0128NAME IS NULL
2008/11/26(水) 18:43:50ID:???バリューセットの例でいえばmany-to-manyの関連なので
「association table」かなぁ。
0129NAME IS NULL
2008/11/26(水) 19:11:52ID:???> これのtbl_は恐らく関連テーブルを指してるだろうね。
質問には「普通のテーブル」って書いてあるよw
普通のテーブルって何よ！！！
ってくらいの低レベルな質問者なので、こんなの引用されてもなあ
> 本当にただのテーブルと言う意味なら質問者はマスタやトランと並べて質問しないだろうね。
質問者はそのくらいDBについて分かってないだけでしょ。
>結局、関連テーブルに対し適当な名前が付けられていない。
「関連テーブル」でいいじゃん。
>単にテーブルと呼べば関連テーブルを指すと言うケースがある。
非常に特殊な低レベルのバカの場合だけだろ。
「リレーションテーブル」は正確ではないけど意味も通じるしいいけど
「マスタテーブルとディテールテーブル」を「マスタとテーブル」と表現するのは
だめすぎだよ。
> 関連テーブルは英訳すればリレーションテーブルになってしまい、これも適当な用語ではない。
relationship tableではいかんのか？
T字形だと「対照表」と呼ぶよな。
ネットで初心者が用語を混同して質問しているのをいくら挙げられても、なんにもならないよ。
0130NAME IS NULL
2008/11/26(水) 19:17:56ID:???「マスタとテーブル」って汎用機時代のオッサン用語だったりするかも。
0131NAME IS NULL
2008/11/26(水) 20:12:46ID:???＞質問には「普通のテーブル」って書いてあるよw
その質問者が普通のテーブルが何を意味してるのかが分かってないから聞いてるんだよね？
俺が挙げたのは用語を混同している初心者の質問でなく、
用語を混同して設計されたＤＢの保守作業をする事になった初心者の質問だよ。
実際俺も保守作業において、実際のテーブル名及び設計書でそういう用語が使われていて知った。
事実、その用語を紹介しているサイトも紹介した。
マイナーだとしても認知されている用語なのは間違いないと思うが？
カタカナ化せず関連テーブルと呼ぶなら、
mst_ trn_ とつけて kanren_ってつけるの？
それとも普段からの呼び方は「関連テーブル」で設計書上では「rel_」とするの？
0132NAME IS NULL
2008/11/26(水) 20:20:22ID:???> >>121
> 酷すぎるという根拠は貴方の主観以外にあるの？
正しい事が書いてある項目を見つけるのが難しいっす
0133NAME IS NULL
2008/11/26(水) 20:27:43ID:???そのサイトに書かれている項目のうち何割が間違っていますか？
偏りが発生しない方法で２０件程度を抜き出して答えてもいいです。
それをしないうちはサイトに対する信憑性の低さを根拠には出来ないはずです。
俺の認識では、確かに誤用かもしれないが確実にこの用語で作られたシステムはかなりある。
かなりのエンジニアに通じる。
全く認知されていない「勝手な用語」であると思えてしまう人が居るのは、単に知らないだけ。
と言う認識。
0134NAME IS NULL
2008/11/26(水) 20:41:20ID:???"rel_"とか"r_"とか"kanren_"とかなんでもいいけど"tbl_"とはしないよな。
ダメ設計者が関連テーブルに"tbl_"と接頭辞をつける事例はあるんだろうけども
それは積極的に「関連テーブルはtbl_とつけよう」とした訳ではないと思う。
ほんのちょっと、ほんのちょっとだけでも論理的に考える頭を持っているならば
「関連テーブルはtbl_」なんて考えるわけがないし。
>>133
>この用語で作られたシステムはかなりある。
じゃあ俺が寡聞にして知らないだけなんだろうね。
なるべくならそんな「エンジニア」さんとは仕事したくないけど。
件のサイト、２０件とかメンドクサイです。ただこの先参照する時には
眉につばをつけてみる、本を読んだり他で調べて自分で考えてみる、
ということをお薦めします。
スクリプト言語 = 文法が簡単なプログラミング言語
シーケンシャルファイル =「1行1データ」で表されるデータ。
トランザクション・ファイル = プログラムの処理の過程で削除されてもよいファイル
オブジェクト指向 = 既にあるものを組合せ、短期間でよりよいプログラムを作ること。
0135NAME IS NULL
2008/11/26(水) 20:42:53ID:???■テーブル
マスター・データの関連データを格納したファイル
またの名を「ディテール・テーブル」
0136NAME IS NULL
2008/11/26(水) 20:43:35ID:???というか汎用機時代はそうだったのかもしらん
0137NAME IS NULL
2008/11/26(水) 23:17:28ID:???汎用機出身のオッサンはテーブルのことを「ファイル」と呼んだりするからあなどれないw
0138NAME IS NULL
2008/11/26(水) 23:19:51ID:???>スクリプト言語 = 文法が簡単なプログラミング言語
これは間違ってはいないと思う
0139NAME IS NULL
2008/11/26(水) 23:24:13ID:v/u6t0exかなり的を外していると思う。
0140NAME IS NULL
2008/11/26(水) 23:32:56ID:???>そのサイトに書かれている項目のうち何割が間違っていますか？
>偏りが発生しない方法で２０件程度を抜き出して答えてもいいです。
>それをしないうちはサイトに対する信憑性の低さを根拠には出来ないはずです。
なんという上から目線www
0141NAME IS NULL
2008/11/26(水) 23:51:18ID:???テーブルなのかビューなのかファンクションなのか接頭語で分かるように
テーブル（オブジェクトとしてテーブルに分類されるもの）には全てT_を付ける、とか
珍しくも無いと思うけど。
0142NAME IS NULL
2008/11/27(木) 00:38:24ID:???コボラはDB屋の敵だ
0143NAME IS NULL
2008/11/27(木) 01:29:46ID:???それやるとDB側だけ変更でテーブル→ビューって置き換えた時にT_XXXってビューが出来る。
0144NAME IS NULL
2008/11/27(木) 02:52:23ID:???そんなアホサイトじゃなくて書籍を買って読んでみなよ。
お母さんにお小遣いもらってさ。
0145NAME IS NULL
2008/11/27(木) 06:43:29ID:???俺ルールを押し付けるスレって雰囲気だな。
0146NAME IS NULL
2008/11/27(木) 19:36:08ID:???0147NAME IS NULL
2008/11/27(木) 20:23:03ID:???0148NAME IS NULL
2008/11/29(土) 04:44:35ID:???だからってRDBのテーブルを「ファイル」って呼ぶなよ
0149NAME IS NULL
2008/11/29(土) 11:00:42ID:???0150NAME IS NULL
2008/11/29(土) 13:37:59ID:???0151NAME IS NULL
2008/11/29(土) 14:38:32ID:???同じ事なわけねーだろw
0152NAME IS NULL
2008/11/29(土) 20:58:43ID:???ミドルウェアってえらいね
横に長いテーブルまんせー
0153NAME IS NULL
2008/11/30(日) 02:02:41ID:???0154NAME IS NULL
2008/11/30(日) 02:14:29ID:???ここ作ってるやつもコボラっぽいな
ttp://homepage1.nifty.com/silabel/computer/cobol.html
> 1999年にはＹ２Ｋ対策としてＣＯＢＯＬを修正できるスキルが一時的に見直された。
って、コボラが問題をまき散らしてただけだろ。
もしかして将来の職のためにわざとやってたのか？
0155NAME IS NULL
2008/11/30(日) 03:18:18ID:???つかないのですが・・・
かつてDB屋さんとコボル屋さんの間で血で血を洗う闘争でも
あったのでせうか（(；ﾟДﾟ)ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
0156NAME IS NULL
2008/11/30(日) 05:29:09ID:???0157NAME IS NULL
2008/11/30(日) 06:02:15ID:???メインフレームＤＢとUnix系ＲＤＢとだろ。
前者で使われている言語は主にＣＯＢＯＬ。
後者で使われている言語はかつてはＣ、現在ではスクリプト系言語などさまざま。
Unix系ＲＤＢの登場は1980年代で日本で普及しはじめたは1990年前後から。
メインフレームＤＢはもっと歴史が古くて1970年代から実用化されていた。
メインフレーム＝ＣＯＢＯＬのほうが20年以上先輩であるわけだ。
メインフレームＤＢで古くからあるものはＲＤＢ=リレーショナルデーターベースではない。
階層データーベースを使っているものが多い。ＤＢをアクセスするためにミドルウェア
が存在する。
まあ、歴史的にはこんなかな。とメインフレームを知らない俺が言ってみる。
階層データーベースにはテーブルというものがない。「ファイル」というのはそのせいか。
ものが
あって、
0158NAME IS NULL
2008/11/30(日) 11:09:41ID:???うま
0159NAME IS NULL
2008/11/30(日) 15:27:50ID:???コボルを扱う人間の設計には欠陥が多いのは事実ではあるな。
オマエラは一生２０年前のシステムのだけ見てれば文句はないのだが、
現代のRDBのシステムにクチを出してくると、ほぼプロジェクトは火を噴く結果になる。
0160NAME IS NULL
2008/11/30(日) 18:43:39ID:???先ほどの「横長のテーブル」もそういうCOBOL畑だった人が持ち込みがちな
「困った設計」なのでしょうか。
単に正規化に無頓着なのか、それともまた別の異なる設計論があるのか、
まるで異文化コミュニケーションですね。
0161NAME IS NULL
2008/11/30(日) 19:59:12ID:???メインフレームを使う金融系COBOL畑と言うのは、技術畑のエンジニアが
やった仕事ではなく、大昔のIBMのテンプレートを真似ただけの、
マニュアル仕事であって、競争とかそういうのは無い狭く閉じた世界の
物語と言う感触がある。
昔は昔なりの事情があるから全否定はしないけど、
老人から「俺は昔こんな事をしたんだぜ」と自慢げに話されても
「ふーん、大変でしたね」と言う感想しか沸いてこない。
JavaとかC#,Python,Rubyなんかは過去の反省と言うかそれなりの
理想を持って進化している言語であり、それらを選択するエンジニアは
「過去よりは少しはマシに」と言う未来に向かって試行錯誤するタイプなんだけど、
COBOL畑の人間は「俺はこう教えられた。俺は今までコレでやってきた。
これ以上俺は何も覚える気がない。俺は正しい」と人間的に
成長が止まっているタイプが圧倒的（ｗ）に多い。
さらにヤやこしいのが金融系と言う仕事が謎なステータスがあり、
そこでCOBOLがある程度ブイブイ言わせているので、COBOL畑の
人間が高給取りかつ増長している現実がある。
0162NAME IS NULL
2008/11/30(日) 20:55:35ID:???0163NAME IS NULL
2008/12/01(月) 00:48:22ID:???が自慢だけならいいが
「俺は昔こんな事をしたから、これからもこれでOK」
というおっさんが権力だけ持ってるのがうざい
0164NAME IS NULL
2008/12/01(月) 01:46:40ID:???0165NAME IS NULL
2008/12/01(月) 02:10:20ID:???そこまで力がないからでしょ。
力があって理解せられてれば自慢じゃなくて添削依頼になる。
0166NAME IS NULL
2008/12/01(月) 03:08:50ID:???簡単にウン１０年の情報化の歴史を小僧っこに否定されてみろ。
0167NAME IS NULL
2008/12/01(月) 14:17:25ID:???話にならん
0168NAME IS NULL
2008/12/01(月) 14:21:02ID:???0169NAME IS NULL
2008/12/01(月) 15:33:13ID:???普通にされてるんだが・・・自分より10以上離れた年齢の人に。
そうでもないと思ってたがずいぶんとマシな所に勤めてたようだ。
0170NAME IS NULL
2008/12/01(月) 21:25:43ID:???0171NAME IS NULL
2008/12/01(月) 23:26:52ID:???気が付いた>>169であった・・・。
0172NAME IS NULL
2008/12/02(火) 17:56:54ID:???残念だが、そういう人間はCOBOLやJava、C#にかかわらず非常に多い。
実際COBOLって方言が多くて、年代や機種によってさまざまに変化しているから
１つのシステムだけを延々やってた人以外は、毎回やり方を変えていたよ。
＃メインフレームだと新機能を使わないってルール付けしてたりもする。
システムそのものも、１００万件以上ならDBをキーをつけて並び替えて抽出するより
前件なめて、ソートして抽出したほうが早いという時代から、やっぱりちゃんと
抽出したほうが早いって切り替わる時期でもあったので、こちらでは常識でも
あちらでは非常識がまかり通っていた時代だよ。
＞さらにヤやこしいのが金融系と言う仕事が謎なステータスがあり
こんなの金融に限らずどこのシステムにもある。
JavaやC#で代替できないものはないし、そこだけJavaからCOBOLを
呼び出して実行してもいい。
どんな仕事の仕方をしてきたかで決まるのであって、どんな言語を使うかではない。
>>163
２０年前からそうだよ。そんなやつは今も昔も変わらず多い。
>>168
砂利を運ぶのに「カウンタックを作れ」と指示されて、カウンタックを作っちゃう日本と
ちゃんと目的にあったカスタマイズされたダンプを作るアメリカとの違いだよ。
0173NAME IS NULL
2008/12/02(火) 20:18:19ID:???0174NAME IS NULL
2008/12/02(火) 23:11:27ID:???でもどうだろうな、技術というものはいつも同じスピードで進歩するものでなくて
ある時期に急激に進歩してその後停滞するものであるから
ＩＴ関連の技術は、今後２０年間あまり変わらないのではないかな
0175NAME IS NULL
2008/12/03(水) 00:17:39ID:???まだまだ変わる思うよ。
次の劇的な変化は、関数型言語が実用的なレベルになるくらいにハードが進化した時に来ると思う。
0176NAME IS NULL
2008/12/03(水) 00:25:44ID:???というのがあるだろ。
COBOLerも、自分の技術は普遍的でメインストリームで、そこいらのPCのような
おもちゃとは違うと信じているし、それが時代遅れだとは露ほども考えていない
というのはおんなじだな。
0177NAME IS NULL
2008/12/03(水) 00:26:52ID:???ですが、この次に別な何かは来るのでしょうか。
0178NAME IS NULL
2008/12/03(水) 01:10:21ID:???オブジェクトデータベースというのはどうなんでしょ
0179NAME IS NULL
2008/12/03(水) 06:51:45ID:???チマチマ普及すると思うが、メインはRDBだと思われ。
0180NAME IS NULL
2008/12/03(水) 22:54:59ID:???0181NAME IS NULL
2008/12/03(水) 23:14:26ID:???0182NAME IS NULL
2008/12/03(水) 23:48:06ID:???全てのテーブルでカラム数が2です。
スキーマ設計の欠陥でもネタスキーマでもなく、カラム数は
2で固定、という仕様のDBMSなのです。
このやり方でも大抵のデータを表現できる自信はありますが、
このやり方の時代が来ることも、また無いような気がします。
(内心は、あるかも、そんなときめきもちょっと感じています)
0183NAME IS NULL
2008/12/04(木) 04:18:16ID:???0184NAME IS NULL
2008/12/04(木) 23:53:14ID:???そういう作りはちょっと考えてんだけど、実際にやってるとこあるんだなw
いまから趣味でつくろうとしてるOSSで試してみようかな・・・
0185NAME IS NULL
2008/12/05(金) 00:05:17ID:???http://monetdb.cwi.nl/
RDB/SQLやXMLDB/XQueryを実装したパッケージとして配布されて
いますが、MonetDBのコアは二項関係だけをストアする最低限の
ストレージとそれを操作するアセンブリ言語で構成されています。
Javaアプリケーションに対するJavaVMのような、DBMSを実装して
実行するためのvirtual machineのように使えるソフトです。
大抵のデータ構造は二項関係の集合に分解して表現できるので、
目的のデータ構造を二項関係の集合に分解するルールを決めて、
後は使いたいクエリ言語をアセンブリ言語に書き下すコンパイラを
実装「出来れば」どんなデータ構造もクエリ言語もどんと来い、
そんな考えのDBMSです。
研究ではRDBやXMLDB以外にもGISやRDFDB/SparQLなんかも
実装しているみたいです。
実用向けではなく実験的なDBMSですが、SDSSという天文分野の
大きなDBをこれに乗せるプロジェクトも走っているようです。
更新系は弱いですが、参照系に関しては商用DBも上回ることも
あるようです。
0186NAME IS NULL
2008/12/05(金) 03:51:53ID:???リアルタイム更新のインターネット用途は不適っぽいな。
0187NAME IS NULL
2008/12/05(金) 17:13:10ID:???作っちゃえ、というやり方ですから行単位で参照したり更新したり
というOLTPアプリでは既存のRDBMSの実装の方が優れます。
基本は参照のみ、集約値の計算等のためにフルテーブルスキャン
を多用する、しかもどんなクエリが来るか事前に読めない(クエリを
決めうちしたIndexやMaterialized viewを使うことが出来ない）用途
を意図した設計のようです。
なのでOLAPやData mining、学術用のデータ解析など向けですね。
0188NAME IS NULL
2008/12/05(金) 22:58:34ID:???性能は悪そう。
0189NAME IS NULL
2008/12/06(土) 00:27:38ID:???MonetDBのアセンブリ言語使って何かしようというのは相当変な事 orz
をしようという人だけであって、普通はSQLとかXQueryで使うはずです。
性能はDMやOLAPなどの用途に関しては相当に速いはずです。
実際のところ商用DBではSybase IQがよく似た設計を持っています。
(そもそもSybase IQは初期のMonetにインスパイアされたらしい）
なのでコラム単位のVertical fragmentationの用途と利点に関しては
次のSybase IQの記事が参考になります。
http://www.thinkit.co.jp/free/article/0707/8/1/
あとGoogle Tech Talkでの次期MonetDBの話も面白い。
http://jp.youtube.com/watch?v=yrLd-3lnZ58
0190NAME IS NULL
2008/12/06(土) 02:26:08ID:???OODBって結局一度もブームこなかったな
ポストRDB！！とか騒がれていたのに
0191NAME IS NULL
2008/12/06(土) 13:57:59ID:???実データをオブジェクト指向で扱うのって無理が有りすぎる。無限に要素を想定する事に成るし。
加工するにはオブジェクト指向で操作したほうが直感的では有るけど。
0192NAME IS NULL
2008/12/06(土) 19:51:06ID:???ORでインピーダンスミスマッチとかよく言われるけど、
SQLからクラスとマッピングコード生成するスクリプトを書けば
いいだけだしな
何もＤＢ自体がOOである必要はねーよ
0193NAME IS NULL
2008/12/06(土) 19:57:07ID:???A りんご
A 100
A 青森産
B みかん
B 150
B 愛媛産
みたいに。
「このレコードは名称、このレコードは値段」とか判断付かなくない？
0194NAME IS NULL
2008/12/06(土) 20:15:21ID:???0195NAME IS NULL
2008/12/06(土) 20:17:37ID:???判断付かなくて困るって程のことでもないし、いいのか。
0196NAME IS NULL
2008/12/06(土) 20:37:18ID:???無能は黙ってろ
0197NAME IS NULL
2008/12/06(土) 20:53:52ID:???カラム数は2で固定ですが、テーブル自体は沢山作る事ができるので、
この例だとキー:名称、キー:値段、キー:産地の三つのテーブルを作るのが
一つの解です。
各テーブルでキー->名称、キー->値段、キー->産地の関数従属性を表現
出来て、これらの三つからキー->(名称, 値段, 産地)の関数従属性を導出
出来ますから、この分解は無損失です。
0198NAME IS NULL
2008/12/06(土) 20:58:29ID:???組織
上位組織
社員マスタ
社員番号
役職
権限マスタ
権限
とあるときに、ある社員の役職が自分の所属する組織だけで通用する
権限を持たせるようにするにはどう関連を引けばいいの？
0199NAME IS NULL
2008/12/06(土) 21:12:21ID:???0201NAME IS NULL
2008/12/07(日) 11:02:15ID:???0202NAME IS NULL
2008/12/08(月) 01:00:44ID:???MonetDBもSQLを使えば普通にnカラムのリレーションを作れますよ。
JDBCやODBCもあるので、ただRDBMSとして使う分にはMySQLとか
その辺のOSSのデータベースサーバと変わりません。
なんかMonetDBがとても普通でない変態DBみたいな誤解が生じても
アレなので、念のため。
2カラム限定なのは低水準のアセンブリ言語を直接使って変な事を
する時だけです。変態なのはDBMSではなく、私。
0203NAME IS NULL
2008/12/09(火) 22:31:44ID:8rN2YWi9DBはどのように設計したらよろしいでしょうか？
こんな感じのドラゴンボールの天下一武道会みたいなトーナメント表です
優勝
|
|~~|
|~~~|~~~|
A B C
0204NAME IS NULL
2008/12/10(水) 01:06:13ID:???俺なら一試合一選手で1レコードにしてこうする
PK ID
対戦相手ID
X回戦（一回戦とか二回戦とか）
X試合（第一試合とか）
選手
勝敗フラグ
0205NAME IS NULL
2008/12/10(水) 01:11:09ID:???このやり方だとトーナメントの下から追うのはいいが上から追えないが。。。
0206NAME IS NULL
2008/12/10(水) 19:07:05ID:8RNJEsTT休日マスタのような、主キーを日付にしたいけど、時間はいらないってときに、
日付型でやる？数字か文字でやる？
日にちのみのと時間のみの型があるなら日にちのみの型でやるんだが、
日付型って時間とセットなんだよなぁ
日付型で時間入らないように制約つけるのがベスト？
0207NAME IS NULL
2008/12/10(水) 22:25:29ID:???0208NAME IS NULL
2008/12/10(水) 23:47:56ID:???0209NAME IS NULL
2008/12/11(木) 01:30:53ID:???日付関係の関数が使えるので日付でやる
変に文字列とか数値とかでやると後で型をキャストする必要がある時めんどいし。
0210NAME IS NULL
2008/12/11(木) 06:36:02ID:???そうでないRDBMSもあるんだから、そういう環境依存な話されてﾓﾅｰ
漏れは日付は日付型を使う派。
そうしておかないと、あとでCOBOLerの様な人種が「9999-99-99」とかﾄﾝﾃﾞﾓ日付を入れて
アプリでﾄﾝﾃﾞﾓ実装をやりはじめそうだし。
0211NAME IS NULL
2008/12/11(木) 19:06:44ID:???むしろその制約のために日付を無理やり文字列管理ってDBがいかに多いか…
0212206
2008/12/11(木) 20:16:12ID:???２００８はデータ型増えてるのか．．．
>>209
確かに日付関係の関数は便利だな。
自分で日数計算とかやってられんな
>>210
俺の中では、日付型は日にちと時間せっとなのがスタンダードで、
日にちだけとか時間だけとかの型があるほうが特殊だと思ってた
まあ、どっちにしろ環境依存といえばそうなんだが、
それ言いだすとまず環境を決めないと設計語れないしな
>>211
すまん、よく意味がわからん。
9999-99-99を入れたいがために、文字列で定義されているシステムが多いってことか？
まあ、やはり日付入れる項目には日付型使うほうがよさそうなんで、
やっぱりその方針でやるよう検討するわ。
0213NAME IS NULL
2008/12/11(木) 20:48:31ID:???> 9999-99-99を入れたいがために、文字列で定義されているシステムが多いってことか？
２０００年問題で有名になったYYMMDDというのがある。
0214206
2008/12/12(金) 00:19:34ID:???いや、あるのは知ってる。YYnnnとかな
ＤＢ使わない、それこそコボラーな世界では普通だった。
その世界ではそれが間違ってるとは思ないが、
ＤＢ設計としてはどうなの？って話だ
いまどきメモリの１バイトは血の一滴ってわけじゃあるまいｗ
0215NAME IS NULL
2008/12/12(金) 01:09:26ID:???リレーション社員＜社員ID, 入社日, 退職日＞に対して、
(社員1, 1/1, 4/1)
(社員2, 2/1, 6/1)
(社員3, 4/2, 8/1)
(1) self joinして、在職期間が重なる社員のペアを抽出する
(社員1, 社員2)
(社員2, 社員1)
(社員2, 社員3)
(社員3, 社員2)
(2) 日付の期間でGROUP BYして社員をcountする事で、
リレーション在職者数(人数, 日付from, 日付to)を求める
(1人, 1/1, 1/31)
(2人, 2/1, 6/1)
(1人, 6/2, 8/1)
なんてクエリは、実務ではどのように実装しているのでしょうか？
こういうTemporalな演算を標準SQLで頑張る論文を読んだことがありますが、
結論は「出来ればこういう演算はDBMSで直接サポートしてくれぇ」でしたｗ
0216NAME IS NULL
2008/12/12(金) 02:00:56ID:???(2)は普通に入社日と退職日でGROUP BYしてCOUNT取れば出来ないか？
0217NAME IS NULL
2008/12/12(金) 17:25:06ID:???ソレって主にOracleの事情だったっけ？
DB2,Postgre,MySQLは日付と時間を自由に出来たはずだが。
0218NAME IS NULL
2008/12/12(金) 22:41:18ID:???0219NAME IS NULL
2008/12/13(土) 15:20:28ID:???別に二つカラム持って、こっちは日時しか見ない、こっちは時間しか見ないでもいいと思うが。
どうせ日時の二倍データ量使うでしょ。
１バイトでも件数大量なら無視できないけどな。
オープンソースとかで安易に電網鯖構築してるとレスポンスめちゃめちゃ悪いサイトが出てくるのはそんな理由も大きい。
商品情報とか数万件じゃ済まないし。
0220NAME IS NULL
2008/12/13(土) 18:13:10ID:???ナニを言っているのかよく解らんが、Oracleは間違っていないとか
そういう類の発言のつもりか？
DB2のDATE型は'2008-12-13'と10バイト使う(Verによりやや違うが)が'0000-01-01'〜'9999-12-31'まで許す（紀元前は不可能)
MySQLのDATE型は'2008-12-13'で3バイト使うが'1000-01-01'〜9999-12-31'しか許さない（のワリに'0000-00-00'を許すんだよな、意味は解るけど）
ナニが普通なのか知らんが、>>219の偏った知識の持ち主が「レスポンス云々」を
語るのは不思議な感じなんだが。
メモリの１バイトは血の一滴ではあるまいに、は賛同するが、
RDBMSを使う要件の多くは「数万件ですまない」ケースがほとんど」だしなー。
0221NAME IS NULL
2008/12/13(土) 23:33:34ID:???(2)は日付テーブルを持っておいて、1日ごとにジョインしたあとにgroup byして…
とかで出来そうだけど死ぬほどパフォーマンス悪そう。
プロシージャとかで必要に応じてデータ作るのが現実的な気がする。
0222NAME IS NULL
2008/12/14(日) 06:39:14ID:???0223NAME IS NULL
2008/12/14(日) 07:16:32ID:???(1) は社員AとBの在職期間のoverlapを判定するには合計4パターン
(A-B-B-A, A-B-A-B, B-A-B-A, B-A-A-B)を条件として書く必要が
あって、なので単純なDATEDIFF関数では力不足なんです。
Postgresにはその名もOVERLAPSという関数がありますが、こういった
関数を持たないRDBではどうしているのかなと。
(2)については、各社員の入社日・退職日を境界として全期間を細かく
ぶつ切りにして、個々の期間について各社員の在職期間とのOverlap
を判定して・・・と、さらに面倒な処理が必要になります。
いずれにしてもSQLで書くには結構大変なクエリで、でも実務の現場
では案外良くありそうなクエリなので、どうやって実現しているのか
興味がありました。やはりストアドプロシジャでゴリゴリでしょうか。
0224206
2008/12/14(日) 07:24:05ID:???前半いわんとすることが全く理解できないんだが．．．
日付型が時間とセットでしか格納できな処理系で、時間を設定しない項目に
日付型を使うか否かというのが論点だったんだが．．．
>１バイトでも件数大量なら無視できないけどな。
これには同意
ただ、数万から数十万程度の件数でレスポンス悪化するようでは、
そもそもの設計がおかしいと思うぞ
>>220
ＲＤＢＭＳのオーバーヘッドを避けるためにＤＢをつかわないシステムを見たことがある
つまり、ＤＢつかう以上ある程度のオーバーヘッドは了承の上だと思う。
日付型が文字や数字より（ＤＢに格納する上で）ある程度のオーバーヘッドが生じるわけだが、
百万件オーダー程度ではあんまり考慮しなくていいかとおもってるんだが
>>222
それってどんなＤＢＭＳでもそうなのかね？
まあ、はじめに処理系依存な話をしだしたのは確かに俺だが、
特定のＤＢＭＳでしか通用しない話は、そのＤＢＭＳを明示してくれないか
ついでに聞くが、デフォで３２ビットってことは、変更も可能ってことかね？
0225NAME IS NULL
2008/12/14(日) 07:52:35ID:???在職期間の重なりを判定するならこれで十分だろ。
(A.入社日 < B.退社日 and B.入社日 < A.退社日)
(2)も、集計期間のリレーションが用意されているなら同じように可能。
0226211
2008/12/14(日) 08:13:55ID:???すまん、遅レス。
俺が遭遇したのでは
「値が未設定の項目はHigh Valueをセットしましょう。日付のHigh Valueは99999999です」ってのとか
「99999999にしておきゃ日付範囲の検索時に有効だろうがJK」ってのとか
いずれにしろなんだその言い訳？みたいのばっかだったよ。
特殊パタンだと
「2008-12-32」を入れておきたいとか、「26:59:00」まで一日の範囲にしたいってのもあったな。
0227NAME IS NULL
2008/12/14(日) 08:50:07ID:???>>224
＞timestampはデフォ３２ビットでおま。
DB2のTIMESTAMP型は10バイトな。
Oracleは12バイト。（Verや使い方で9-11バイト）
日時関連の型は処理系や実装は各RDBMSでけっこう違う。
DB2だと'20081204'をINSERTすると例外出すが、MySQLはOKとかな。
>>226
まあ、日付は日付以上の意味はない罠。
判定したけりゃnullかどうかで判定汁。と言うのがDB屋としての回答ではある。
DB2だとINSERTの時に不正な日付は例外だすから、そこらは安心だ。
MySQLだとINSERTをスルーするから後の結果が怖いな。
＃違っていたらﾂｯｺﾐﾖﾛ
0228206
2008/12/14(日) 17:43:40ID:???その手の話は、コボラーの時代には普通の設計だったな
まあ、未設定なら俺ならLow Value入れるがなｗ
特殊パターンは悩みどころだな
だが>>227 が言うように、
>まあ、日付は日付以上の意味はない罠。
>判定したけりゃnullかどうかで判定汁。と言うのがDB屋としての回答ではある。
というのが正しいスタンスなんだろうな
結局のところ、日付以上の意味合いを持つものを一つの項目に格納しようとするからそうなる
ＤＢ設計としてはそれはやめるべきだろうと理解した
ちなみに、たとえば、有効期限みたいな項目があったとして、
期限日が入ってる場合以外に、未設定と永久があって区別したい、とか言うと
未設定はNULLでいいとして、永久ってのは別途フラグかなんかで項目作るのが正しいＤＢ的設計？
0229NAME IS NULL
2008/12/14(日) 20:22:51ID:???0230NAME IS NULL
2008/12/14(日) 21:13:47ID:???'9999-12-31'と'9999-99-99'なんて現実的に同じ意味だし。
ただ単に9999-99-99を許すと今度は8888-88-88とか使いだすだろうし。
そんなつまらん理由の為、日付型の美味しいところを捨てるのはワリに合わんだけだし。
しかし、そういう実装はCOBOL等のバッチ屋はアタマ使わなくて済むかも知れんが、
UIを担当する部署(Webチームとか）から「ふざけんな」と言われるのがオチなので、
フラグで持つ方が親切だろうなぁ。
Web系のフレームワークと連動させるケースだと'9999-99-99'の実装は殺意しか
沸いてこない。
まあ、ここらも現代においてCOBOLerが嫌われる要因のひとつでもあるな･･･。
0231211
2008/12/14(日) 21:31:32ID:???すげえ、あたりｗｗ
後から High Value ２ って規格ができたよ。
もろ8888-88-88だった。
バッチ組の仕様でHigh Valueでも2タイプを判断しなくちゃいけなくて云々と説明されたけど、理解不能だったorz
UI側はただただ面倒臭くてたまんなかったわー。
他の項目の状態判断して、設定するHigh Value値を切り替えなきゃいけないんだから。
0232NAME IS NULL
2008/12/15(月) 00:37:50ID:???からある意味仕方ないのはあるな。NULLと言う概念は存在しないし、データには
なんでもヘッダ(01)、データ(10)、トレーラー(88,99)とかつけたがるし。
COBOLerにはＳＱＬにある3値論理が理解できんのだろう。
コレもRDBを操作するSQLの基礎だと思うが、COBOLerはRDBを操作するのにSQLを使わないケースがあるし。
とは言え、RDBMSなんだからCOBOLerがSQLやらフレームワークを考慮してくれないと困るんだが
あいつらの上司はモノを知らんくせにやたら立場と態度がデカいのがウザいったらありゃしねぇ。
0233206
2008/12/16(火) 02:13:45ID:???>データにはなんでもヘッダ(01)、データ(10)、トレーラー(88,99)とかつけたがるし。
さすがにそれはお前のとこだけだろうと思うが
>とは言え、RDBMSなんだからCOBOLerがSQLやらフレームワークを考慮してくれないと困るんだが
まあ、ＣＯＢＯＬとＲＤＢっていまいち相性悪いよな
そもそもＣＯＢＯＬ全盛のときはＤＢは実用的ではない場合がほとんどで、
ＤＢ導入するならＣＯＢＯＬもやめて作り直せば良いんだが．．．なかなかそういかない現実がある
0234NAME IS NULL
2008/12/16(火) 19:16:08ID:???品目一つに対して一列になっているため、
品目の調整がはいるたびに大変な状況です。
実績は金額、件数、率を含んでいるため
単純に列を行に移し替えることはできません。
こういった場合、実績の単位ごとにテーブルを分けて
管理するといった方法でよいでしょうか？
言い忘れてましたが、実績には対応するコードがあり
それで特定可能です。
（今はなぜか列名にそのコードが設定されていますが…）
0235NAME IS NULL
2008/12/16(火) 20:34:23ID:???COBOLerはCOBOLerで、「なんでCODASYL標準のDBMS使わないんだよ。」
と思っている希ガス。
0236NAME IS NULL
2008/12/16(火) 22:48:38ID:???品名マスタ（品名コード、品名、値段・・・）
実績テーブル（実績コード、店舗コード、品名コード、実績、・・・）
こんな感じ？
0237NAME IS NULL
2008/12/16(火) 23:02:45ID:???実績一覧テーブル（みかん金額、みかん件数、みかん率、りんご金額、りんご件数、りんご率…）
になっている、という話？
0238NAME IS NULL
2008/12/17(水) 00:52:18ID:???今の構成としては
YYYYMM、店舗コード、実績001、実績002、実績016、実績003…
といった感じです。実績列の名前末尾三桁が実績コードです。
つまり、品目を特定するキーがないのが現状です。
前任者の意図としては、web側で出力するのに
SELECT一発で出せるようにということのようです。
>>236さんの方法ですと、実績の単位の型ごとに
列を持つことになるかと思います。
実績_金額、実績_件数、実績_率のように。
この場合、１レコードに対して、必ず２つのNULL列が出ますが
設計上良いものでしょうか。
他に案も浮かばないですが…。
0239NAME IS NULL
2008/12/17(水) 08:18:50ID:???実績テーブル（実績コード、店舗コード、YYYYMM、実績）
でいいんじゃない？
これをクロス集計すれば一発だと思うけど
0240NAME IS NULL
2008/12/17(水) 18:41:13ID:???はい、単位は品目コードで一意に識別できます。
今日ちょうどリーダーに同じ案を出したのですが、
違う単位の実績を同じ列に入れることに少し難色を示されました。
（実績単位ごとの列、テーブルを設けるという案でも同じような反応でしたが）
でも、>>239の方法が一番シンプルに
まとめられるやり方ですし、また話してみようと思います。
ありがとうございました。
0241NAME IS NULL
2008/12/19(金) 10:35:49ID:???イベントとリソースの分類で定型的な手法ってありますか？
0242NAME IS NULL
2008/12/20(土) 05:53:23ID:4lEGcef7一般的にどういう順番でjoinするのが速いですか？
0243NAME IS NULL
2008/12/20(土) 06:25:23ID:???大きいテーブルを先に持ってくる。
実データの入ったＤＢで計測するのが一番。
0244NAME IS NULL
2008/12/21(日) 04:57:19ID:Qp++Fn0Mところでテーブルに画面表示用のデータ入れたカラム容易したり、
アプリ依存の使いまわし効かないようなデータ入れたりって皆さんしてます？
DBの勉強は一通りしてみましたが、実務に当たってこのあたりの良し悪しに悩んでます。age
0245NAME IS NULL
2008/12/21(日) 09:41:35ID:???結果セットに直結する形のフォームや帳票のコントロールのせいで
そういう作りにしてしまってるものを見ることがあるが、
これは、ある種のバッドノウハウの類。
オンメモリで処理しにくいものだったらローカルDBを活用したらどうだろう。
0246NAME IS NULL
2008/12/21(日) 15:34:35ID:Qp++Fn0M成る程です。
例えば、DBサーバとAPPサーバが別々に存在したとする。
APP依存、固有のデータに関してはAPPサーバ側にローカルDBを構築して活用する感じですかね。
仮に予算や客都合でローカルDBを用意できない場合は、
せめてテーブルを切り分けて管理したいと考えてます。
しかしJOINが重なるとパフォーマンスや管理の面で劣る…
なかなか難しいですね。
0247NAME IS NULL
2008/12/21(日) 18:55:34ID:???他にもSQLiteとかSQL Server Compactがそういう目的に使える。
0248NAME IS NULL
2008/12/21(日) 22:12:17ID:???使わんだろ？サーバーサイドでわざわざ複数のDBに分ける理由はない。
>>246の別テーブルでというのが普通。その上で、アプリ固有の情報といっても
変更の可能性が低くて1:1あるいは1:0リレーションシップであれば1テーブルに
まとめてしまうくらい。
0249NAME IS NULL
2008/12/21(日) 22:26:04ID:???＞アプリ依存の使いまわし効かないようなデータ入れたりって皆さんしてます？
やらないし、やらせない。
それをやりだすと、アタマの悪い後任者が「ここにこのデータがあるから、コレ使えばいいじゃん。
オレ賢い！」と勘違いして、データベースの基本の「One Fact In One Place」の
理念がパーになる。そして黒歴史が始まる。
0250NAME IS NULL
2008/12/22(月) 09:50:29ID:???0251NAME IS NULL
2008/12/22(月) 13:24:18ID:???0252NAME IS NULL
2008/12/22(月) 19:20:00ID:7uJOOUG40253NAME IS NULL
2008/12/22(月) 22:32:50ID:???まともなドキュメントが作られてない or 作られていても後任の教育ができていない場合なら
そういうのも考えられるけれども、まぁ、設計の問題というより組織の問題だな。
0254NAME IS NULL
2008/12/23(火) 08:06:38ID:???マトモなドキュメントやら教育云々なんて絵空事だよなぁ････。
そういうった組織を含めて「システム」と言うのだと思うが。
それにアタマの悪い管理者ほど「マニュアルがあれば誰でも出来るだろ」と
言い出す始末だしな。
「○○が出来ていれば」なんて絵に描いた餅なんて食べられないよ。
0255NAME IS NULL
2008/12/23(火) 10:52:22ID:???カラムのコメントは歯抜けだらけ、
アプリの仕様書もない状態。
「このアプリの仕様を踏襲した新システムを作れ」
見えないルールを予測するエスパーたち。
誰かが言った。
「DBがシステムそのものだ」と。
そんな事判ってる。
ならせめて、そのDBの利用ルールを網羅した仕様書を用意しておいてくれ。
0256NAME IS NULL
2008/12/23(火) 12:28:52ID:???＞画面表示用のデータ入れたカラム
＞アプリ依存の使いまわし効かないようなデータ
ってそれぞれ具体的にどんなの？
0257NAME IS NULL
2008/12/23(火) 12:43:34ID:???0258NAME IS NULL
2008/12/23(火) 12:45:18ID:???要・不要を語る意味が無いと思う
0259NAME IS NULL
2008/12/23(火) 14:18:21ID:???仮に同一DBを利用するアプリが増えた場合、
設けた表示順が利用できず、新たに用意する事もありえる話。
これってまさしくアプリ依存だよね。
で、この依存したデータたちをどう扱うべきかって流れかと。
0260NAME IS NULL
2008/12/23(火) 14:19:04ID:???「してまーす」でいいわけね。
他にいい方法ないもんですかねー。
0261NAME IS NULL
2008/12/23(火) 15:04:28ID:???よくわからん。
マスタとかを別とすれば基本的にテーブル自体アプリ依存とかだと思うけど。
将来有るか無いかわからない他のアプリでの再利用とかまで考えるのがおかしな話だと思う。
0262NAME IS NULL
2008/12/23(火) 19:32:27ID:???他のテーブルと結合させないで、専用のクラスや関数でラップして読み書きさせてる。
たまたま、同じデータベースに同居しているというイメージ。
パラメータ系のテーブルもこれに倣っている。
0263NAME IS NULL
2008/12/23(火) 22:58:50ID:???特定アプリだけの専用DBなら、画面プログラマがO/Rマッパで生成するDBで充分だろう。
業務システムの場合、組織・人・商品のような共通データを一元化するべきだから、
きちんとDB設計することが重要になる。
0264NAME IS NULL
2008/12/23(火) 23:05:50ID:???＞マスタとかを別とすれば
0265NAME IS NULL
2008/12/23(火) 23:37:10ID:???マスタは不変の固定情報だけにしないと、時系列のデータを扱った時に矛盾してしまう。
例えば人の場合、生年月日はマスタ上の固定データで良いとして、
配属情報なんかは日々のトランザクションの中にあるわけで、
これを例えば、社員マスタに所属部署の列なんかを作って、常に最新の配属情報で
上書きしたら、そのテーブルは今日のデータとしてしか使えないし、兼務情報も得られない。
実際、いろんなアプリで共通に使うデータの多くがトランザクション上にあるから、
やはり特定アプリの表示用データなんかをDBに置くことには危険がともなう。
0266NAME IS NULL
2008/12/23(火) 23:46:23ID:???特定のアプリ用の独立したテーブルを作るのはいいんじゃないか
0267NAME IS NULL
2008/12/23(火) 23:50:02ID:???スキーマ分けて権限で制御とかなら分かるけど
DBに置いちゃダメってのは行きすぎだと思う。
0268NAME IS NULL
2008/12/24(水) 00:32:17ID:???それこそDB上に保持する理由が解らんな。
テンポラリテーブルやＰＣのローカル上に落として好き勝手やるならともかく。
0269NAME IS NULL
2008/12/24(水) 00:35:15ID:???今議題になってる各アプリ専用のDBとして、
基幹系DBと独立させる設計はどうだろう？
今、業務で扱ってるDBが監査用の設定が入ってて、
DDLとか大量検索が走ると警告メールが部署内に飛び交うんで、
あんま基幹系DBのスキーマを弄りたくない空気があるんだよね。
0270NAME IS NULL
2008/12/24(水) 05:35:01ID:???テンポラリテーブルやローカルDBじゃセッション間、クライアント間で共有できないだろ。
もしかして、そういう共有する必要のあるデータは全部「アプリ依存」じゃないと考えているとか？
0271NAME IS NULL
2008/12/26(金) 07:15:53ID:???クライアント間で共有と言う時点でその設計が糞だと言ういい証明なワケだが。
0272NAME IS NULL
2008/12/26(金) 19:39:01ID:???そこでばっさり切り捨ててあいつ使えないなと思われるか、何か工夫してあげてあいつ神と必要な人間に評価されるかは、これからの正社員リストラで生き残れる分かれ目だったり。
組織の運営上は、きちんとマニュアル整備して、誰でもマニュアル通りに対応する体制にしてないと、監査も通らないし危機管理上もマズい。
情報やノウハウを属人化させてるから、退職だので、前任者居なく成ったとたんに困るんだよ。
0273NAME IS NULL
2008/12/26(金) 23:15:51ID:???「共有が必要だとすると設計がクソ」か。
またとんでもない決め付け厨が現れたもんだ。
0274NAME IS NULL
2008/12/26(金) 23:33:33ID:???0275NAME IS NULL
2008/12/27(土) 01:05:33ID:???具体的にどんなニーズなんだろう。
なんかエンジニアが実力不足を言い訳で乗り切ろうとしているだけにしか見えんが。
0276NAME IS NULL
2008/12/27(土) 01:09:34ID:???0277NAME IS NULL
2008/12/27(土) 03:32:10ID:???「特定のアプリ用のデータはローカルに置け」といってる人の言う「特定のアプリ」とは
「ローカルPC上からDBにアクセスして、個人的に何かをするツール」的なもののみを指してるに違いない。
それだと話が通る（というか噛み合わない理由がわかる）
そのツールだけで使うデータであり、ツールはその人以外誰も使わないのであれば
データをサーバーに置くべきでは無いわなｗ
0278NAME IS NULL
2008/12/27(土) 03:41:57ID:???これがわからなければ議論はできない
0279NAME IS NULL
2008/12/27(土) 09:14:51ID:???会社の宿題をここで解決してるのがバレるのが嫌なんだろうか。
仮に前に話題に上った「特定アプリの表示用データ」なんか、
ほとんどの場合は共有するモンでもないと思うが、
「共用データをＤＢに置くオレカッコイイ、オレ神だぜ」と言うケースは
具体的になんなんだろう？と激しく疑問だったりする。
0280NAME IS NULL
2008/12/27(土) 10:24:55ID:???0281NAME IS NULL
2008/12/27(土) 10:46:01ID:???オレはてっきり、Web/Appサーバに軽量DBMSかXMLか何かでUI層絡みの
データを置くのを、DBサーバに対して（Web/Appサーバの）ローカルと言ってると
思ってたんだが
0282NAME IS NULL
2008/12/27(土) 15:59:13ID:???逆に共用データをみんなが個別に端末に保存して
「オレカッコイイ、オレ神だぜ」って具体例を挙げてくれやｗ
0283NAME IS NULL
2008/12/28(日) 02:28:30ID:???それはローカルとはいわないと思う。
0284NAME IS NULL
2008/12/28(日) 02:53:39ID:???業務アプリならその手のデータがほとんどかもしれない。過去１０年分ぐらいのデータなんてほとんど更新される事も無いし。
後はアイテム数膨大なアプリとか。１０万アイテムぐらいならいちいちオンラインでネット上をばんばんデ−タ流すよりも、ローカルにキャッシュして差分更新で扱ったほうが快適かもしれない。
0285244
2008/12/29(月) 00:57:50ID:???ローカルというのはWebアプリ視点で物申しておりましたorz=3
つまりWebサーバー上にある軽量DBやXMLなどの事です。
一応、例を提示しておきます。
[DBサーバー]
DB : Oracle
… 顧客情報、商品情報、販売情報、生産情報などが入っている。
[Webサーバー１]
「販売管理システム」というWebアプリケーションが動いている。
ローカルDB : Postgresql
… この「販売管理システム」依存のデータを管理。
例えば、「一覧表示用の順序データ」や「検索条件」、「ログ」など。
[Webサーバー2]
「生産管理システム」というWebアプリケーションが動いている。
ローカルDB : Mysql
… この「生産管理システム」依存のデータを管理。
例えば、「一覧表示用の順序データ」や「検索条件」、「ログ」など。
[端末にインストールされているシステム１]
「商品開発支援システム」というVC++で作成されたWindowsアプリケーション。
0286NAME IS NULL
2008/12/29(月) 03:02:11ID:???いくら良い設計しても、プログラマーに伝わらなければデスマの元だよ
0287NAME IS NULL
2008/12/29(月) 03:05:44ID:???そういうことは>>256-257辺りで早く言えｗ
0288NAME IS NULL
2008/12/29(月) 17:10:41ID:???統合して全部オラクルで共用データも含めて情報持っても良さそうだが。
システム付け足すのは簡単だっただろうけど、管理大変でしょ。あちこちにデータベース有って全部違うし。
そのうち経営情報システムとかで横断的に情報欲しい時にどこにデータが有るか探すの大変で嵌まると思うｗｗｗ
0289NAME IS NULL
2008/12/29(月) 17:27:30ID:???「なんとか統合してくれ」的なプロジェクトに参加したことがあるなー。
他社のDBの情報を利用するとか止むを得ない事情でも無ければ
分けたくないところ。
0290NAME IS NULL
2008/12/29(月) 21:43:14ID:???>>288-289の言うとおりシステム統合とかで大変な感じ。
DB鯖にアプリ専用Tableが一番いいんじゃないかね。
0291NAME IS NULL
2008/12/30(火) 05:43:43ID:???0292NAME IS NULL
2008/12/31(水) 11:18:09ID:???とりあえずシステムできちゃったから面倒見ろよと。
0293NAME IS NULL
2009/01/05(月) 02:31:06ID:???理想論にかぶれて運用しにくい建付けにしたりってことかと。
でも最近のteenage sexは意味が違ってるよな確かに・・・
0294NAME IS NULL
2009/01/07(水) 19:10:01ID:???データーベースとはこのように設計するものなのか
0295NAME IS NULL
2009/01/12(月) 16:24:21ID:???例えで書籍のDBがあるとして書籍テーブルと著作者テーブルを著作者IDでつなげていたのですが
共著のものがでてきて今のままだと対処方法がわからなくなりました。
いちおう新たにテーブルを作って書籍IDと著作者IDを持たせ
本A＝著作者A、本A＝著作者Bの2レコードで表現できるようではあるのですが、
書籍テーブルとかぶって大半が無駄なように思えます。
他にうまいやりかたはあるのでしょうか。
0296NAME IS NULL
2009/01/12(月) 16:41:45ID:???0297NAME IS NULL
2009/01/12(月) 16:59:02ID:???ではこのやりかたで進めようと思います。
ありがとうございました。
0298NAME IS NULL
2009/01/12(月) 16:59:37ID:???どうしてもっていうなら、追加するテーブルは「2人目以降のみを管理する」ことにすればレコード数は減るかもしれないけど
お勧めはしない
0299NAME IS NULL
2009/01/12(月) 17:44:39ID:???新たに作るっていうかそもそも「著作者テーブル」がそれじゃないの？
0300NAME IS NULL
2009/01/12(月) 18:19:42ID:???0301NAME IS NULL
2009/01/12(月) 18:36:34ID:???言い忘れていたけど、仮に>>295の解決策をとるのであれば
書籍テーブルにあった著作者IDのカラムは削除した方が良い。
「書籍テーブルとかぶって大半が無駄なように」と書いてあった
ので一応補足します。
0302NAME IS NULL
2009/01/12(月) 21:43:44ID:???ああすまん、著作者じゃなくて295で作ったという関係テーブルのこと
>>301
それはないだろ
0303NAME IS NULL
2009/01/16(金) 00:30:44ID:aohFMQX5＞それはないだろ
いやあると思いますよ。下のようにするのが一般論だと思います。
[書籍テーブル] キー：書籍コード
書籍コード、書籍名
[著作者テーブル] キー：著作者コード
著作者コード、著作者名
[書籍・著作者リンクテーブル]キー：書籍コード、著作者コード
書籍コード、著作者コード
0304NAME IS NULL
2009/01/16(金) 23:33:46ID:???それが295だ。ちゃんと流れを読め。
0305NAME IS NULL
2009/01/17(土) 00:26:21ID:???フォローどうも
>>304
いや、301で書いたのは、単著の書籍だけの頃はきっと
[書籍テーブル(単著だけ)] キー：書籍コード
書籍コード、書籍名 、"著作者コード"
のようなスキーマだったろうから、この書籍テーブル(単著だけ)から
"著作者コード"のカラムは不要なので削除した方がよい、ということ
です。
0306NAME IS NULL
2009/01/17(土) 01:59:35ID:VBakR5WFお前がちゃんと読め
0307NAME IS NULL
2009/01/17(土) 02:01:07ID:???だめだこりゃ
0308NAME IS NULL
2009/01/17(土) 02:10:59ID:???0309NAME IS NULL
2009/01/17(土) 02:51:42ID:???T_顧客マスタに【2008年度】のデータがあることが発覚！
日付のところ2008年になってるのがちらほらある
http://mj.dip.jp/jlab-beer/s/test1232112051347.jpg
0310NAME IS NULL
2009/01/17(土) 02:52:15ID:???この設計ってどうよ。
0311NAME IS NULL
2009/01/17(土) 12:44:39ID:???どういうことなん？これ
0312NAME IS NULL
2009/01/17(土) 13:16:26ID:???登録年月日と変更年月日が同一のデータばっかりってな話？
0313NAME IS NULL
2009/01/17(土) 13:18:50ID:???「変更年月日 < 登録年月日」 のデータが存在するって話か。
例えば、「顧客コード」 が 000020 のレコード。
0314NAME IS NULL
2009/01/17(土) 13:20:04ID:???0315NAME IS NULL
2009/01/17(土) 16:43:09ID:???0316NAME IS NULL
2009/01/17(土) 23:26:13ID:???DB構築に関する基礎を学ぶのにお勧めの書籍・サイトないでしょうか。
0317NAME IS NULL
2009/01/18(日) 00:59:39ID:???DB構築はどこを指しているかによる。
0318NAME IS NULL
2009/01/18(日) 01:00:56ID:tHveqmjSいいからしゃぶれよ
0319NAME IS NULL
2009/01/19(月) 15:43:47ID:???0320NAME IS NULL
2009/01/30(金) 17:33:52ID:???全部舐めとれよ。
0321NAME IS NULL
2009/03/08(日) 18:49:29ID:???SQL質疑応答スレ 8問目
http://pc11.2ch.net/test/read.cgi/db/1236253554/46
>>46
正規形のなかで第1正規形だけは異質とされている通り、これだけは純粋に
モデリングと区別できる正規化とは言えないですね。第2正規形以上の「正規化」は
従属性を「保持」したままスキーマを操作するものであるのに対し、非正規形から
第1正規形にする操作は逆にリレーショナルモデルに落とし込む際に失われた
従属性を修復する操作であるとも言えるので。
いずれにせよ、第1正規形でないものは本来のリレーショナルモデルとは言えない
という意味において、それがモデリングの問題であることには違いはないということと、
スキーマだけ見てそれが正規形かそうでないか議論することはナンセンスであると
いう点では>>46に同意するけど。
0322NAME IS NULL
2009/03/08(日) 18:54:43ID:???0323NAME IS NULL
2009/03/08(日) 19:54:16ID:???第一正規形が異質な点はその通りだと思います。
以下雑談なのでちょっとくだけた言い方になりますが、私は恩師の指導が
珍妙とくしゅだったせいか、リレーションがあまり好みではありません。
所詮は関数を実装したり表現したりする方法の一つだよね、その程度です。
なので入れ子リレーションも多値関数や高階関数ですね、そうですか、
良いんじゃない？ぐらいの認識です。
ただ非第一正規形から第一正規形を作るにはデータ構造中に含まれている
ヘンテコ関数全てにトドメを指さないといけないので2NF以下続く正規化とは
異なりデータ構造が当然大きく変化しますし、データモデリングとも絡んで
突っ込むと実は案外面白い問題だと考えています。
ただあのスレでがっかりだったのが、ただ「勉強しろ」「正規化しろ」という
コメントが続いた事です。
ちょっとひどいと思ったので>>13と>>15のスキーマを示して「データベース
理論的にどう異なりますか」と聞いてみたら「正規化について基礎から勉強
しなおそう」と返されました。おぉ〜い、もう正規形だよｗ
他方で誰もデータ設計については言い出さなかったので、あのような流れに
なりました。
0324NAME IS NULL
2009/03/08(日) 21:21:26ID:???0325NAME IS NULL
2009/03/08(日) 22:16:22ID:???愚痴の部分は申し訳ない。
0326NAME IS NULL
2009/03/08(日) 23:05:05ID:???Javaとかのオブジェクト指向な言語で、
dogクラスはanimalクラスを継承して、って学習のネタで言われるなんだろうけど、
実務で使うケースとかフレームワークが既に決まっている場合とかだと、
それらを考慮してＤＢ設計した方がみんなが幸せになれるので、
2chでああいった質問ってほとんど意味ないとｵﾓ。
0327NAME IS NULL
2009/03/09(月) 02:17:57ID:???向こうで設計の話を延々と続けたら確かにスレ違いだが、そこでの回答が
ひどかったと言うのにスレ違いもなにもないじゃん。
言ってることはむこうの「正規化勉強しろ」ってレスと変わらんわけだし。
それにしても、この板でCOBOLerを馬鹿にする人は多いけど、こういう
話題を振っても反応がそのCOBOLerと同じなんだから笑ってしまうよな。
0328NAME IS NULL
2009/03/09(月) 22:27:26ID:???0329NAME IS NULL
2009/03/11(水) 17:55:10ID:???私には面白かったです。
2chでこんな話が読めるとは思いませんでした。
これからも時々、何か書いてくれるとうれしいです。
自分はまだよくわかってないので、勉強します。
それにしてもカリー化という言葉を、DB板で見るとは思いませんでした。
自分はHaskellとかの関数型言語で知りましたから。
関係ないけど、↓この連載は面白いです。
ベンチャー社長で技術者で
http://el.jibun.atmarkit.co.jp/g1sys/
0330NAME IS NULL
2009/03/12(木) 01:41:39ID:???>カリー化という言葉を、DB板で見るとは思いませんでした。
実際スキーマを理解する際に便利な考え方です。
上司の変な教育のたまものですね。いちいち数学の言葉に
ブレイクダウンしないと気がすまない人です。
彼にいわせると、GROUP BYは逆関数なんだそうです(笑)。
あとその連載、読んでます
DB畑の人間としては納得出来るところが多いです。
0331NAME IS NULL
2009/03/15(日) 00:44:22ID:???>あとその連載、読んでます
>DB畑の人間としては納得出来るところが多いです。
あぁ、それまだやってるんだ。
大規模システムを知らない人風だったから読むの止めてまった。
0332NAME IS NULL
2009/03/19(木) 12:40:57ID:???学生名から著者→タイトル→感想文表示
著者からタイトル→学生名→感想文表示
この２つをできるようにしたいんだけど、みなさんならどんなテーブル用意します？
１テーブルでいいのかな・・・？学生数は300人程です
0333NAME IS NULL
2009/03/19(木) 14:16:14ID:???同姓同名のケースがあるが学生名で学生の判別してかまわないか？
出来ないなら別途学生番号を振りキーとする。
タイトルと著者を独立して管理するか？
しないなら
学生のレコードの属性として保持すればよい。
するなら、
さらに著者とタイトルの関連は管理するか？
著者に対してタイトルが複数
共著の扱い
同名タイトルや同姓同名の著者の扱いは？
感想文は学生の属性としてよいか？
学生に対して感想文は１つか？学生の共同作成はないか？
こういったところは >>332でないと分からん。
0334NAME IS NULL
2009/03/19(木) 14:38:04ID:???私ならとりあえず、こんな感じかな。
テーブル
本: (本ID), タイトル
本著者: (本ID, 著者名)
学生: (学生ID), 学生名
感想文: (感想文ID), 学生ID, 本ID, 提出日, 題名, 本文
リレーションシップ
本.本ID 1-* 本著者.本ID
学生.学生ID 1-* 感想文.学生ID
本.本ID 1-* 感想文.本ID
本のタイトルや学生名が重複しても見分ける必要がないなら1テーブルでも良いけどね。
>>333 の言うとおり、要件によるよ。
0335NAME IS NULL
2009/03/19(木) 16:02:58ID:???本テーブル作って
両者の関連で本著者にしないのはなんで？
0336NAME IS NULL
2009/03/19(木) 18:01:14ID:???この辺とかノウハウ持ってる気がする。
http://pc11.2ch.net/test/read.cgi/db/1137309494/
成績管理システムを作ろう！２【社会貢献】
0337NAME IS NULL
2009/03/19(木) 18:36:40ID:???横からですが、妥当なテーブル構造だと思います。
0338NAME IS NULL
2009/03/19(木) 19:24:09ID:???興味あります。
実際に学内で何のためにどう使うのかなかなか想像が
難しい。学生名から感想文引っ張るのは何となく用途が
想像出来ますが、著者から感想文の集合を引っ張るのは
はて？と。
同じ著者の本を読んだ学生間で感想文の読み比べでも
するのかな。
0339334
2009/03/19(木) 21:26:21ID:???本のデータの入力時に著者が同一人物か同姓同名かどうかは分からない(調べないだろう)から。
>>337
ありがとうございます。
0340NAME IS NULL
2009/03/19(木) 22:24:07ID:???なんで著者に限って同姓同名を許容するの？
同名の本や同名の学生は区別してるのに。
ましてや>>332の要件で著者から検索することが挙げられてるんだから
全く違う人が書いた本を一緒くたに表示するより
○○△△という著者は2人見つかりましたとかして選択させる方が良いだろうに。
0341334
2009/03/19(木) 23:17:28ID:???私の場合、基となるデータを感想文(本のタイトル、著者名、日付、題名、クラス、出席番号、学生名, 本文)だけと想定したためです。
本はタイトル・著者名、学生は学生名・クラス・出席番号で一意に区別できるが、
著者名は、本を探してきて著者履歴などを確かめないと同一人物かどうかを断定できないと考えました。
また、本が見つからず適当に同姓同名を同じ著者として登録されても困るので、あえてテーブルを分けませんでした。
参照する側としては、確かに区別してくれていた方がより便利ですよね。
0342NAME IS NULL
2009/03/19(木) 23:40:26ID:???0343NAME IS NULL
2009/03/20(金) 22:56:04ID:???俺が「夏目漱石」名義で本を出したり。
0344NAME IS NULL
2009/03/21(土) 03:02:54ID:???0345NAME IS NULL
2009/03/22(日) 03:17:18ID:???それは、著作者と中の人の関係をどう管理するかの問題だな
著作者が同姓同名の別人の可能性があるのか？
複数の人間が一つの著作者として扱われる必要があるのか？
一人の人間が複数の著作者となることがあり得るのか？
このへんの要件を確定させれば決まってくる
ほかの人も言ってるが、要件をもうすこし詰めないとこれ以上の論議はむずかしいんじゃ
まあ、今回のは著作者やその著作（本）を管理するのが目的じゃないし、
著作者に対してそこまでシビアに考える必要はないと思うが
0346NAME IS NULL
2009/03/22(日) 04:20:01ID:???0347NAME IS NULL
2009/03/22(日) 04:32:51ID:???それがあるかどうかって事だろ
0348NAME IS NULL
2009/03/22(日) 06:27:09ID:???著者単位で考えればいいのに変に人間単位で考えるなよ
0349NAME IS NULL
2009/03/22(日) 19:20:58ID:???「この本を書いた山田太郎さんとこの本を書いた山田太郎さんは同一なのか」
ってのをいちいち調査しなきゃならん、ってのもな。
300人の中学校の読書感想文管理でそんなのいらんだろ。
0350NAME IS NULL
2009/03/22(日) 20:05:19ID:???0351NAME IS NULL
2009/03/22(日) 20:15:43ID:???0352NAME IS NULL
2009/03/22(日) 20:16:57ID:???0353NAME IS NULL
2009/03/22(日) 20:28:06ID:???0354NAME IS NULL
2009/03/22(日) 20:32:40ID:???0355NAME IS NULL
2009/03/22(日) 21:07:11ID:???0356NAME IS NULL
2009/03/22(日) 21:47:55ID:???はいはい面白い面白い、と
0357NAME IS NULL
2009/03/23(月) 03:52:28ID:???同じ著者名がずらっと並んでるってのはどういう事態を想定してるんだ？
同姓同名の著者名があったとして、それを区別する必要がホントにあるのか？
たとえば夏目漱石という著者がいたとして、
夏目漱石の著作としてみとめられてる本があったとする
その本の著作者は「夏目漱石」として認識してるのだから
その本を実際に書いたのが、猫の人だろうが>343の人だろうがゴーストライターだろうが、
その本の著作者は「夏目漱石」で何の問題があるんだ？
0358NAME IS NULL
2009/03/23(月) 05:57:45ID:???結局仕様次第でしょ。
0359NAME IS NULL
2009/03/23(月) 08:17:40ID:???著者名を真の著者ごとに区別するって話に誤解してないか？
同じ名前の別人を区別するかしないかって話だと思ってたけど
0360NAME IS NULL
2009/03/23(月) 09:07:07ID:???それはそれで余計ややこしくなりそうな…
0361NAME IS NULL
2009/03/23(月) 12:30:07ID:???後者は区別しないほうがややこしいと思うが
0362NAME IS NULL
2009/03/23(月) 12:36:54ID:???複雑にしすぎても最後はグダグダになるからある程度シンプルにした方がトラブルの
原因が少なくなると思うんだけどね
0363NAME IS NULL
2009/03/23(月) 12:40:57ID:???0364NAME IS NULL
2009/03/23(月) 15:28:35ID:???>中学の図書館での運用だから管理するのは大人だとしても運用するのは中学生だろ
いやだから仕様を勝手読みしても仕方がないかと。
そんなことは>>332には全く書いていないしそれ抜きにどっちが
良いも悪いもないというか>>332はどこいったんだこんちくしょう。
0365NAME IS NULL
2009/03/23(月) 15:31:56ID:???0366NAME IS NULL
2009/03/23(月) 19:42:27ID:???後者の同じ名前の別人、てのは、同じ著作者名で別人がいるってことだろう
前者も後者も同じことで、区別する必要がないんじゃないか、と思うが
断片での議論は楽しいが結論は出せんのがなぁｗ
0367NAME IS NULL
2009/03/23(月) 20:51:41ID:???0368NAME IS NULL
2009/03/23(月) 20:59:56ID:???のは簡単だけど、一度区別しないことを前提としてスキーマ作って
あとから区別出来るようにして下さいと言われると面倒くさい。
なので区別することを前提に作る方が後々都合が良いと思う。
どうせ大した手間じゃないでしょう。
0369NAME IS NULL
2009/03/23(月) 21:32:37ID:???「夏目漱石Aが書いた本一覧」と「夏目漱石Bが書いた本一覧」をデータとして持つ必要があって。
全書籍・全著者についてそういったデータを持つかっつーと絶対やらないだろ。
感想文にはISBNを必ず記入すること、とかの方が現実的か。
0370NAME IS NULL
2009/03/23(月) 22:04:26ID:???>「夏目漱石Aが書いた本一覧」と「夏目漱石Bが書いた本一覧」をデータとして持つ必要があって。
0371NAME IS NULL
2009/03/23(月) 22:05:34ID:???0372NAME IS NULL
2009/03/23(月) 22:53:47ID:???当然の意味が分からん
0373NAME IS NULL
2009/03/23(月) 23:01:59ID:???0374NAME IS NULL
2009/03/23(月) 23:26:12ID:???全書籍・全著者って、感想文が提出されたものに限った話じゃないよ。
（提出された分だけ持ってても登録時に識別の役に立たない）
0375NAME IS NULL
2009/03/24(火) 03:46:27ID:???ISBNで管理して、著者名とタイトルは、ISBNから紐付けるべき。
0376NAME IS NULL
2009/03/24(火) 06:58:31ID:???感想文が提出されたものだけでいいじゃん
0377NAME IS NULL
2009/03/24(火) 07:39:41ID:???提出の度に毎回調べて登録するんですね。分かります
0378NAME IS NULL
2009/03/24(火) 09:21:51ID:???0379NAME IS NULL
2009/03/24(火) 09:41:17ID:???同姓同名の著作者が同一著作者じゃまずいのか？
そもそも同姓同名の別人な著作物なんてそんなにあるのかね
0380NAME IS NULL
2009/03/24(火) 11:44:54ID:???IDから名前がひけるけど同じ名前の人だっている。
普通にやればこうなる
0381NAME IS NULL
2009/03/24(火) 15:03:11ID:???0382NAME IS NULL
2009/03/24(火) 15:56:12ID:???最初は「こんな本も出してるのか、この人」とか思ってしまったぜ
0383NAME IS NULL
2009/03/24(火) 16:27:22ID:???名前を隠した332当人だけなんじゃないか？
本職の人間がそんなことを主張するとは俺には考えられん。よほどの新人なら
ともかく。
No.1335 ／懼懼｀ヽ ... - コピペ運動会
http://copipe.cureblack.com/copipe/2008/03/17/1335
0384NAME IS NULL
2009/03/24(火) 20:56:21ID:???0385NAME IS NULL
2009/03/24(火) 22:46:07ID:???0386NAME IS NULL
2009/03/25(水) 02:52:05ID:???学生の名前を主キーにしていいと主張してるひとって誰だ？
学生は同姓同名でも区別する必要があるってのは共通認識だと思ってたんだが
0387NAME IS NULL
2009/03/25(水) 05:02:04ID:???0388NAME IS NULL
2009/03/25(水) 19:32:39ID:???0389NAME IS NULL
2009/03/25(水) 21:25:51ID:???0390NAME IS NULL
2009/03/25(水) 21:34:25ID:???0391NAME IS NULL
2009/03/26(木) 00:28:03ID:???この程度でテーブルレイアウト丸投げするるような初心者がつくるんだから、
なるべく単純な要件ですました方がいいだろう、と
だから著作者の同姓同名なんて無視しといたら良いんじゃないかと言ってるんだ
0392NAME IS NULL
2009/03/26(木) 01:53:44ID:???0393NAME IS NULL
2009/03/26(木) 02:15:45ID:???おまいらが毎度デスマってるいつものパターンじゃないか。
0394NAME IS NULL
2009/03/27(金) 00:12:25ID:???0395名無し募集中。。。
2009/03/27(金) 00:25:42ID:ZRXm0Q5jExcelの方が逆に接続とかめんどいわ
0396NAME IS NULL
2009/03/27(金) 08:10:03ID:???0397NAME IS NULL
2009/03/27(金) 08:50:24ID:???0398NAME IS NULL
2009/03/27(金) 11:41:15ID:???http://0xcc.net/blog/archives/000135.html
0399NAME IS NULL
2009/04/01(水) 00:44:14ID:???基本的にはラジオボタンでの3択なのですが、未選択も可な質問があります。
未選択の時、列に格納すべきはNULLでしょうか、0でしょうか。
(「どれにも当てはまらない」ボタン設置は無しとして)
テーブル構成は
学籍番号 int,
質問1 int,
質問2 int,
質問3 int...
という風に各質問ごとに列を分ける方よりも、やはり
学籍番号 int,
質問CD int,
回答CD int
とした方がよいのでしょうか。
30問程度あるので出来れば後者にしたいのですが、その場合、
「その他」選択時にテキストボックスへ任意の文字列入力を許可するのですが、
この文字列はどこへ格納すればよいでしょうか。NULL可な備考列を追加して、そこへ?
0400NAME IS NULL
2009/04/01(水) 01:13:13ID:???> 未選択の時、列に格納すべきはNULLでしょうか、0でしょうか
どちらでも。自分が後で集計するときに使いやすい方を選べばいい。
(IS NULL を使わなくて済むから)自分なら 0 を使う。
> テーブル構成は
後者で良い。楽できる方を選ぶ。
> NULL可な備考列を追加して、そこへ?
それが妥当
(どっちでも良いが自分ならNULL可じゃなくて既定値を空文字にするけど)。
単純なシステムの場合は、
入力時と出力時にどんな SQL を書かなきゃいけないかだけを考えて作れば良いよ。
少々間違えたって、すぐ直せるし。
0401NAME IS NULL
2009/04/01(水) 01:17:22ID:???回答はtextにして数字と文字列を区別せず扱えば？
0402NAME IS NULL
2009/04/01(水) 04:41:09ID:???意味が分からない…
0403NAME IS NULL
2009/04/01(水) 05:46:34ID:???アンケートの相手が事前に分かってるかとかにもよるんだが、俺なら
アンケートそのものに未回答のもの=NULL
アンケートに回答して、その設問に答えてないもの=0
かな
テーブル構成は、未来永劫絶対に質問内容が変わらないなら前者も有り
でも普通はそうじゃないだろうから後者が無難
その他の回答欄についても、NULL可能な項目（備考じゃなくて、その他回答とかのほうがいいが）作って
その他を選んで回答してない=空文字列
その他を選んでいない=NULL
にする
ただし、DBによっては空文字列とNULLを区別できなかったりするし、
NULLの扱いは結構はまりやすいので、なるべくNULLを使わないようにする、って考え方もありだと思う
>>401
未選択はレコード作らない、って考え方はありだとおもうが、
単一項目に複数の意味合いのデータを入れるのはDB設計としては間違ってるとおもうぞ
0404NAME IS NULL
2009/04/01(水) 08:53:40ID:???0405NAME IS NULL
2009/04/01(水) 10:57:37ID:???の話だろ。
未選択時レコード作らないのは参照時に面倒だと思うよ。
もし取得できなければ○○、取得できた場合1なら□□、とか。
0406NAME IS NULL
2009/04/01(水) 13:12:46ID:???NULLは積極的に使うものではない。
0407NAME IS NULL
2009/04/01(水) 13:25:52ID:???Oracleの批判はやめてください
0408403
2009/04/01(水) 13:58:23ID:???すまん、何と何が同じ意味だと？
>>405
俺も面倒だと思うんで項目にNULLでレコード作る方がいいと思うんだが、
項目にNULL入れると、その項目使う時にNULL判定しないといけない場合があるから
結局面倒さは変わらないかもしれない
レコードなくても、マスタとつき合わせたりするなら、外部結合するって手もあるからな
>>407
別に批判しているつもりはない。あえてDBを名指ししていないし
ただ、OracleがNULLと空文字列の区別がつけれないのは事実で、
そうなるとその区別を必要としないよう設計する必要があるのも事実だ
それが良いとか悪いとか言ってないぞ
まあ、個人的には俺のOracleに対する、ほとんど唯一にして最大の不満点だがなｗ
0409NAME IS NULL
2009/04/01(水) 14:29:10ID:???特定しましたと同じ意味しかないだろうに。
0410NAME IS NULL
2009/04/01(水) 15:27:12ID:???>すまん、何と何が同じ意味だと？
一番最後の行
>俺も面倒だと思うんで項目にNULLでレコード作る方がいいと思うんだが
何が面倒なの？
未選択時に○○，とか場合わけする必要性が分からない
合計数や平均を取る際にそのまま集計すればいいのでは？
0411403
2009/04/01(水) 16:17:54ID:???>単一項目に複数の意味合いの
ってところか
たしかに広い意味では回答という同じ意味なんだが
たとえば、”はい”、”いいえ”、””（無回答）とかならいいんだが
数字とその他の文字による回答になると、数字はコード化された回答、文字はコード化されてない回答、となる
単純に数字と文字を同一項目に入れるなってのもあるし、意味合いって言葉がまずかったか
レコードありなしで面倒なのは、このDBを使うアプリケーションを作る時に、
アプリ側の作りこみが面倒になるかもしれないな、ってこと
たとえばこの結果を表示するアプリを作るとして、未選択時は特別な表示を要求されるかもしれないだろ
SQLのみの世界で見ればあんまり大差はないとおもう
0412NAME IS NULL
2009/04/02(木) 00:00:15ID:???0413NAME IS NULL
2009/04/02(木) 00:30:43ID:???MySQLやSQL ServerはDB側になんでも任せられるから
それによってクソ重い設計とかできちゃうけど
OracleやPostgreSQLはそういうのやりづらい感じになってる
0414NAME IS NULL
2009/04/02(木) 06:26:34ID:???DBに任せることができて、任せると設計が重くなる例ってのが想像つかん
たとえばどういうことをDBに任せるとどう重くなるのだ？
0415NAME IS NULL
2009/04/02(木) 07:21:11ID:???ノリは漏れは嫌いなんだけどな。
あと、よくもわるくもOracleとPostgresを一緒にスナ（ｗ
「普通に設計」させれ。
0416NAME IS NULL
2009/04/02(木) 07:52:28ID:???クライアントよりサーバーに負担がかかるってことだろ
0417NAME IS NULL
2009/04/02(木) 08:56:01ID:???なるほど。つまり、DBで処理するかアプリで処理するか、って問題か
DB設計段階で、元来DBですべき処理をアプリでするってのは本末転倒な気はする
性能設計って話もあるんだが、負荷軽減は運用に入ってチューニングと合わせて検討すべき内容だと思うなぁ
0418NAME IS NULL
2009/04/02(木) 12:23:34ID:???Oracleとかそういうのショボいからアプリ側でやらんと駄目だしね
0419NAME IS NULL
2009/04/02(木) 13:10:13ID:???0420NAME IS NULL
2009/04/02(木) 16:08:53ID:???0421NAME IS NULL
2009/04/02(木) 16:50:50ID:???0422NAME IS NULL
2009/04/02(木) 17:13:37ID:???どんだけ言語使えないのｗｗｗ
0423NAME IS NULL
2009/04/02(木) 19:13:11ID:???って取り出して
プログラム側で
str = ret.pref + ret.city;
ってやんのか
ret = SELECT (pref || city) as addr FROM address
str = ret.addr;
かって話だよな
後者はかなりもっさり祭りになるぞ
アクセス少ないならともかく
0424NAME IS NULL
2009/04/02(木) 19:39:21ID:???0425NAME IS NULL
2009/04/02(木) 19:45:40ID:???最近は負荷分散の意味で
サーバーサイドのcgiよりも
クライアントサイトのjavascriptを使うって動きが出てるけど
ソースは忘れた
0426NAME IS NULL
2009/04/02(木) 23:46:00ID:???まあ確かにAJAX系ではselect結果をxmlにしたら、
あとはクライアント側でどうぞという感じではある。
0427NAME IS NULL
2009/04/04(土) 07:20:07ID:???判定(where〜)がイカれているから、設計が歪んでいくって事だろ。
同じフォーマットでデータをinsertしても、selectするとOracleだけが判定結果がおかしいからな。
0428NAME IS NULL
2009/04/04(土) 12:16:25ID:???そもそも必須だと言ってるのに空文字入れられちゃうのもどうかと。
0429NAME IS NULL
2009/04/04(土) 16:11:42ID:???スキル低いだけの様な。
0430NAME IS NULL
2009/04/04(土) 18:16:23ID:???オラクルはRDBMSの世界ではかなりスタンダードかもしれないが
問題は、オラクルにだけ特別必要なスキルがあるってことなんだと気付けよ
0431NAME IS NULL
2009/04/04(土) 18:49:08ID:???0432NAME IS NULL
2009/04/05(日) 00:24:18ID:???うんこ取扱師乙種とか甲種って名前に変更するべきだと思うんよ
0433NAME IS NULL
2009/04/05(日) 00:26:33ID:???0434NAME IS NULL
2009/04/05(日) 00:39:54ID:???0435NAME IS NULL
2009/04/05(日) 03:47:24ID:???レガシーな仕様を引きずりすぎて今に至ってる部分があるから
あれはあれで仕方ないんだよ
COBOLみたいなもんだ
0436NAME IS NULL
2009/04/05(日) 07:13:05ID:???DB2は伝統的な記述しか許さない思想の性か、ちゃんとselectできるわけだが。
Oracleは資格士が必須な感があるにはあるな。
最新のバージョンは多少世間(?)に歩み寄っている感があるが昔のバージョンの
結合の構文から見てキモいんだが。普通にLEFT OUTER JOINとか書かせろと。
0437NAME IS NULL
2009/04/05(日) 07:17:07ID:???0438NAME IS NULL
2009/04/05(日) 10:17:38ID:???0439NAME IS NULL
2009/04/05(日) 10:20:12ID:???0440NAME IS NULL
2009/04/05(日) 15:45:17ID:???0441NAME IS NULL
2009/04/05(日) 19:58:52ID:???0442NAME IS NULL
2009/04/05(日) 22:11:19ID:???0443NAME IS NULL
2009/04/06(月) 00:16:23ID:???0444NAME IS NULL
2009/04/06(月) 06:19:24ID:???0445NAME IS NULL
2009/04/06(月) 06:32:13ID:???Javaと融合してインターネットサイトで使いやすくなった
0446NAME IS NULL
2009/04/06(月) 13:41:18ID:???とにかく８の初期のころと分けて8iと呼ばれた
iはインターネットのiだったらしい
0447NAME IS NULL
2009/04/06(月) 13:56:07ID:???それまでWindows版しかGUIインストーラなかった
0448NAME IS NULL
2009/04/07(火) 05:16:05ID:???0449NAME IS NULL
2009/04/09(木) 20:18:13ID:???必要なテーブルは以下のとおりです。
1.マスタ関係のテーブル(複数)
2.スケジュールを入れるテーブルとその付属テーブル(複数)
3.アクセスログのテーブル
特にアクセスログはすぐに大きくなりそうなので別のファイルに保存しようと考えているのですが、
1,2,3のテーブルを1つのmdbファイルにするのと、
別のmdbファイルにしてリンクで結ぶのとでは処理速度が大きく違うものでしょうか？
また、同時openの負荷を考えるとユーザーごとにmdbファイルを用意して
その中にメインのテーブルに対するリンクを置くような形にすべきでしょうか？
0450NAME IS NULL
2009/04/09(木) 21:52:29ID:???って、この板には無くてビジネスsoft板の方なんだな。
0451NAME IS NULL
2009/04/10(金) 00:02:55ID:???0452NAME IS NULL
2009/04/10(金) 00:09:17ID:???0453NAME IS NULL
2009/04/10(金) 00:57:55ID:???せめて、SQL Server Express Edition にすべき。最大4Gの制限に
引っかからなければ、だけど。
0454NAME IS NULL
2009/04/10(金) 06:38:27ID:???DBに突っ込んでくとそれがネックになって主要機能部分の性能落ちるぞ
0455NAME IS NULL
2009/04/10(金) 14:38:50ID:???0456NAME IS NULL
2009/04/10(金) 21:24:07ID:???監視系のシステムとかだと、ネックに成ろうが、ログをDBに突っ込むけどな。
そうしないと膨大なログを処理しきれない。毎回テキストから抜くのも大変だし。
0457449
2009/04/10(金) 23:02:49ID:???コマンドプロンプトっぽいところが慣れないです。
ダブルクリックですぐ中身表示みたいなのがあれば便利なのですが。
まあ使い方がわかれば余計な心配しなくてよさそうなのでひと安心です。
0458NAME IS NULL
2009/04/10(金) 23:12:07ID:???0459NAME IS NULL
2009/04/10(金) 23:12:47ID:???0460NAME IS NULL
2009/04/11(土) 00:10:53ID:???なにそれ？
0461NAME IS NULL
2009/04/11(土) 01:00:17ID:???0462NAME IS NULL
2009/04/11(土) 05:35:01ID:???http://www.db.is.kyushu-u.ac.jp/rinkou/mysql/mysql.html
0463NAME IS NULL
2009/04/11(土) 12:30:16ID:???http://pc11.2ch.net/test/read.cgi/db/1227475230/
MySQL 総合 Part15
http://pc11.2ch.net/test/read.cgi/db/1056947097/
mysqlについて語ろう
http://pc11.2ch.net/test/read.cgi/db/1156557521/
PHP＋ODBC＋MDB
0464NAME IS NULL
2009/04/28(火) 03:22:34ID:aHnBfSXl(取引日付 DATE, 銘柄コード int, 取引市場 int, 始値 double, 終値 double, 高値 double, 安値 double, 出来高 double)
これ1個のテーブルで3000万件くらいになってます。このテーブルを使う処理が時間がかかるので、テーブルをわけてしまおうかと思っているのですが、
銘柄ごとにテーブルを分けるとテーブルが5000個とかになるし、
日にちごとにテーブルを分けると10000個近くになります。
銘柄ごとのテーブルと日にちごとのテーブルの両方を準備するとデータの冗長性ひどすぎという感じがします。
アプリからは、銘柄／日付／銘柄と日付の両方、を指定してデータ取得というのをよくやるのですが、
こういう場合どういう形でDBに入れておくのがよいでしょうか？
0465NAME IS NULL
2009/04/28(火) 13:22:48ID:???趣味のレベルを超えてるな。
時間ってどれくらいかかるの？
インデックスは適切に張ってるの？
分けるなら年度毎とかかな。
0466NAME IS NULL
2009/04/28(火) 14:05:38ID:???すでにアクセスすることがめったにない昔のデータなら分けるかもなあ
0467NAME IS NULL
2009/04/28(火) 14:47:32ID:???単に特定の日付の株価を検索しているのか、期間別の
平均値など集計を多用しているのか。
0468NAME IS NULL
2009/04/28(火) 15:29:08ID:???検索時間は7倍程度って認識でおｋ？
0469NAME IS NULL
2009/04/28(火) 20:41:55ID:???OLAP、DWH、スタースキーマあたりでググるといいと思うよ。
これはSQL Server に特化した話だけど参考になると思う。
http://sqlcat.com/whitepapers_japanese/archive/2008/10/18/450.aspx
とりあえず、こんな感じ？
取引日付順にデータが並んで保存されるように、取引日付でクラスタ化する。
これで取引日付による範囲検索が高速化される。
インデックスは以下の2つがあればいいかな。
1) 取引日付
2) 銘柄、取引日付
テーブルは月や年度でパーティショニング。
0470NAME IS NULL
2009/04/29(水) 00:30:43ID:???システムトレードなら出来高上位1000銘柄の直近5年分程度に絞ってもよさげのような気もするけど…
0471NAME IS NULL
2009/04/30(木) 22:40:03ID:???0472NAME IS NULL
2009/05/02(土) 15:46:47ID:???漏れは、銘柄でテーブル分けかなあ。
為替のほうも取り込みたいから結構大変。
証券会社や取引業者に依存しない自分用のシステム作るのって結構大変だよな。
0473NAME IS NULL
2009/05/25(月) 01:35:09ID:rfk82z3Iチェックボックスが30個くらいあって、それぞれのON/OFF状態をDBに
保存しなければならないとき、
1)チェックボックスの数だけカラムを作る
2)可変長文字列のカラムを1個作り、チェックボックスの状態をカンマ区切りかなんかで放り込む
のどっちが正解でしょうか？
仕様変更などでチェックボックスの位置が入れ替わったり、数が変わったりする
可能性もあります。
SQL Server2005です。よろしくお願いします。
0474NAME IS NULL
2009/05/25(月) 01:45:32ID:???0475NAME IS NULL
2009/05/25(月) 02:12:56ID:???0476NAME IS NULL
2009/05/25(月) 02:23:51ID:???約束だ。
あとチェックボックスの数はともかく位置はDB設計とは無関係じゃないの。
dbから動的にチェックボックス作成するってこと？
0477473
2009/05/25(月) 03:00:14ID:rfk82z3Iチェックリストボックスを読み込んだ順に1か0のカンマ区切りでDBに格納して、
チェックリストボックスを復元するときもDBを1カラム読むだけで楽かなぁと思ったのですが。。
>>476
上述の通り、読み込んだ順に処理してるので、位置が変わると過去データに矛盾が出るなと・・・
SQL Server上で配列定義ができればいいのですが。
0478NAME IS NULL
2009/05/25(月) 03:44:28ID:???・チェックボックスの位置が変わる可能性はあるようだけど
数に関してはどうか。「30個くらい」で不変か。
・チェックボックスの状態をDBに格納したとして、その情報を
どのように利用するのか。単にチェックボックスの状態を
復帰するのに使うだけなのか、「チェックボックス1がonの
xxxを列挙」みたいな感じで検索にも使うのか。
このあたりが分からないとにんともかんとも。
0479NAME IS NULL
2009/05/25(月) 04:48:15ID:???0480NAME IS NULL
2009/05/25(月) 05:10:47ID:???なんのための"R"DBMSなんだよと
0481NAME IS NULL
2009/05/25(月) 09:06:30ID:???なんだこのコボラー・・・
0482NAME IS NULL
2009/05/25(月) 09:19:31ID:???0483NAME IS NULL
2009/05/25(月) 15:16:57ID:???たとえば病院の診療科（内科、小児科、外科）みたいのがズラズラと並んだ
チェックボックスで、過去受診履歴がある科のチェックがONになります。
この過去受診診療科情報は特に重要では無く、参考情報程度の扱いです。
将来的には診療科の増減があったり、科が細分化（内科が内科1、内科2のように）したりする
可能性があります。
単純にテーブルが増えたり、カラムを作ったりするのが非常にめんどうなだけなんですが、
後々仕様変更があった場合、労力がかからないのは1)、2)どちらなのかと。。
診療科の全一覧は別テーブルに持っているため、受診科履歴は
当初チェックがONの科をカンマ区切りで1カラムに放り込んでおけばいいやと思っていました。
情報の後出し、申し訳ないです
0484NAME IS NULL
2009/05/25(月) 15:18:58ID:???0485NAME IS NULL
2009/05/25(月) 16:03:47ID:???0486NAME IS NULL
2009/05/25(月) 16:42:55ID:???それくらいだったら2でいいんじゃない？
わざわざテーブル作る必要ねぇよ
0487NAME IS NULL
2009/05/25(月) 22:49:39ID:???その仕様ならば尚更1）以外に選択肢が見当たらないけど・・・
2)はケースをよく考えてみろ、データ崩れる可能性がある。
0488NAME IS NULL
2009/05/25(月) 23:10:02ID:???＞2)がまずい原因って何でしょう
「チェックされた項目の名称をマスタから引っ張ってくるとか」
「○○科受信歴がある患者一覧」とか
「○○科受信歴があり△△科受信歴が無い患者の人数」とかいった、
DB的使い方に全く適さない格納方法だから。
>>483みたいな使い方であれば2でも大して問題ないんじゃないの。
0489NAME IS NULL
2009/05/25(月) 23:31:46ID:???いいんじゃね？2)で。
CLOBにしてXMLでデータ突っ込むようにしたら、もう一生このスレの世話になる必要はないぞ。
0490NAME IS NULL
2009/05/25(月) 23:56:37ID:???一意番号＋科目マスタID(内科1,内科2,外科1,外科2...)みたいな明細テーブル持って、
1-内科1
1-内科2
2-内科1
2-外科1
みたいなレコードの持ち方すればいいんじゃね？
科目マスタをメンテナンスすれば動的にデータ追加できるぞ。
0491NAME IS NULL
2009/05/26(火) 07:24:41ID:???作り直したら、２で格納したデータを更新すれば良い。
心療科の増減でごちゃ混ぜになるほうが医療事故で怖い気がするけどな。
小児科２消滅→内科２統合→小児科３新設→内科３統合→小児科２統合
とか増減有って、履歴追えるような仕様なら結構大変だ。
0492NAME IS NULL
2009/05/26(火) 09:57:18ID:???単にチェックの状態を押さえておきたいだけなら２でもいいと思うけど、情報が足りない。そのチェックの並び情報ももう１カラム追加して管理したらどう？
create table checks(
ID number(10)
,checkItems number(1) -- number of checks (max 9)
,checklabels varchar(100) -- example: 内科1,内科2,外科1,外科2,小児科
,checks varchar(9) -- '0':off '1':on
)
checklabelでチェックの順番を保存しておく。'内科1,内科2,外科1,外科2,小児科'みたいに。別に文字列でなくて診療科のコードでも構わない。
checksが '01010' だったら内科２と外科２がチェックされた、てな感じ。checks['内科1']='0'、checks['内科2']='1'、....の連想配列イメージ。
表示順なんかはアプリで制御せざるをえない。
でも後々を考えるなら >>474 の方法を検討した方が良いと思う。
0493NAME IS NULL
2009/05/26(火) 11:33:34ID:???素直に別テーブル
・患者ID
・受診科ID
・最終受信日
みたいなの作って管理すればいいんちゃう？
まぁ他の人が言ってるように、単なる一時保存なら2、後々統計情報に使いたいなら1かと・・
表示順を気にするなら診療科IDのつけ方のほうが重要だったりするけどね。。
増減があることを見越して、十分な隙間をとって採番してかないとアプリの工数が増える。
0494NAME IS NULL
2009/05/26(火) 19:54:01ID:???表示対象と表示順を持ったテーブルを準備して、目的のテーブルとJOINして使う。
order by 句で表示順をソートすればいいんだから。
0495NAME IS NULL
2009/05/27(水) 07:38:26ID:???2を推してる奴は>>477が自分の客だと想定しても同じことが言えるのか？
確実に将来に渡ってチェックだけを記録するだけの為に使うって保証なんてないぞ。
前提としてこれを抑えてる奴がいるが、こちらの設計思想を理解してもらえると思ってるのが甘い。
0496NAME IS NULL
2009/05/27(水) 14:13:45ID:???0497NAME IS NULL
2009/05/27(水) 18:01:13ID:???簡単な事を難しく遣ろうとして、請求を水増ししようとしても客の理解は得られないぞ。
0498NAME IS NULL
2009/05/27(水) 18:11:08ID:???0499NAME IS NULL
2009/05/27(水) 21:24:15ID:???迷っているなら一度やってみるのがいいさ。
0500NAME IS NULL
2009/05/27(水) 21:36:34ID:???客もその情報をあまり重要視していないようだし、理解できない方法で下手打つよりは、ダサダサでも自身で理解できる方法で実装した方が安全、ってなところ。
客が納得いかないとか設計がどうとか言うなら、 473 に理解できるようお勧めの方法を説明してあげて。
その方が他の人もそれをネタに色々議論できるだろうし。
0501NAME IS NULL
2009/05/28(木) 00:17:52ID:???自分でもうすうす2の実装に疑問があるわけだろ
だったら正規化で解決する方法を学ぼうとする姿勢くらい見せてくれても
0502NAME IS NULL
2009/05/28(木) 13:59:35ID:???MySQLに姓名、メールアドレスや誕生日などの個人情報を保存して
住所録を作りたいのですが、友人から個人情報保護法とやらで
ＷＥＢ上に個人情報を保存するのは禁止されてるって聞きました。
だとしたら、ネット通販とかで一度購入していたら個人情報が引っ張り出されますが
あれはどうやって作っているのでしょうか？
または、ある基準さえ満たせば保存してもいいのでしょうか？
0503NAME IS NULL
2009/05/28(木) 14:09:59ID:???スレ違い
必要であれば取り扱いに注意して管理すればいいんだよ。
ここでも見てくれば。
ttp://www.kantei.go.jp/jp/it/privacy/houseika/hourituan/index.html
0504NAME IS NULL
2009/05/28(木) 14:11:55ID:???お前程度の知識でそんな事やったら絶対に漏洩する。
悪いことは言わないからやめとけ。
0505NAME IS NULL
2009/05/28(木) 14:47:57ID:???すれ違いでしたか・・すみません。
なのに答えていただいてありがとうございます！
>>504
やっぱりそうでしょうか・・・orz
業者に頼むと高いのでお前がやれと言われたんですが、
ちょっと上司に掛け合ってみます。
有難う御座います。
すれ違いな質問をして、皆さんすみませんでした。
0506NAME IS NULL
2009/05/29(金) 02:03:56ID:???AP鯖経由ならいいんじゃねえの。
まあネット上で個人情報漏らしてるのはたまに見るけどな。
0507NAME IS NULL
2009/05/29(金) 02:21:30ID:???絶対だぞ
0508NAME IS NULL
2009/05/29(金) 03:39:09ID:???馬鹿な上司の居る担当が作ったサイトは使いたくないねｗｗｗ
0509NAME IS NULL
2009/06/09(火) 00:03:27ID:???DBはまずどこから直すべきでしょうかｗ
もうどうしていいかｗ
鬱に成りそう
0510NAME IS NULL
2009/06/09(火) 00:46:18ID:???既存のものありきで考えると思考が硬直化するよ。
0511NAME IS NULL
2009/06/09(火) 01:50:31ID:???まず第一正規化します。次に第二正規化します。最後に第三正規化します。
0512NAME IS NULL
2009/06/09(火) 05:25:12ID:???むしろ業務フローに合わせたほうが効率的。
どうせどんどん機能付け足しで正規化崩れてくるから。
0513NAME IS NULL
2009/06/09(火) 11:22:25ID:???コボルベースの横長テーブルは正規化しないと実用的では無いよね
0514NAME IS NULL
2009/06/09(火) 11:31:47ID:???一所懸命正規化してテーブル分けたり、
逆にメモだろと思ってコード化も正規かもやらなかったフィールドが
重要なキーになったり。
もう少しDB設計に時間かけさせてくれよぉ。
0515NAME IS NULL
2009/06/09(火) 11:53:27ID:???作った本人はどこがわるいのかわからない、さいてー
0516NAME IS NULL
2009/06/10(水) 23:51:32ID:???1テーブルカラムが100列超えてます
どうやって治せばいいの？
0517NAME IS NULL
2009/06/11(木) 00:00:29ID:???全テーブルがって訳じゃなかったが、テーブル名がtable1〜tableN、更にカラム名がcol1〜colNというDBを見た事がある。
業務とデータと現行アプリから地道にマッピングしていった。
現行アプリのソースが無かったら、作り直し以外受けれなかった。
0518NAME IS NULL
2009/06/11(木) 00:59:32ID:???今見てみたんだが4割ぐらいのテーブルで
IDとかいうcharのカラム1個に、最大までとったvcharカラム１つ
という構成になってた。ｗ
もう俺逃げる
0519NAME IS NULL
2009/06/11(木) 19:57:32ID:???べつにそれで良ければ問題はないと思うのだが。
0520NAME IS NULL
2009/06/11(木) 19:59:42ID:???BLOBですらないんだぞｗ
0521NAME IS NULL
2009/06/11(木) 21:34:32ID:???これがなにに使われているかが問題。
>>518は「なにに使われているか」の説明が欠けている。
たとえばＩＤ＋テキスト文書だったら、これでかまわんだろ。
0522NAME IS NULL
2009/06/11(木) 22:26:16ID:???ここはもちろん、長さ100バイトに及ばんばかりのビットの羅列だな。
それぞれが別個のフラグになっている。
0523NAME IS NULL
2009/06/11(木) 23:51:41ID:???0524NAME IS NULL
2009/06/11(木) 23:55:21ID:???長さ50バイトぐらいのデータが4000個から32000個
詰め込んでるようです。とりあえず退職願出したけど
ダメって言われて危うく軟禁されそうになったけど
トイレから逃げてきた
0525NAME IS NULL
2009/06/13(土) 15:02:36ID:???0526NAME IS NULL
2009/06/13(土) 15:40:57ID:???> 長さ50バイトぐらいのデータが4000個から32000個
なんのデータなんだろう。
社員マスターのデータ（社員番号、氏名、所属・・）などをCSV形式で格納したものなのだろうか？
なんらかの計測データなんだろうか？
前者なら言語道断だが、後者なら納得できるもの。
0527NAME IS NULL
2009/06/13(土) 18:10:29ID:???各アカウントの権限の状態（アカウントAには公開、削除を、
アカウントBには公開、閲覧を許可するなど）を
保存するテーブルの作成を考えています。
はじめはカラムを
アカウント名 公開フラグ 削除フラグ 閲覧フラグ
として、実際に格納するデータを
A 1 1 0
B 1 0 1
というように各フラグには有効/無効を1か0で格納しようと考えていたのですが、
「将来新たに権限が増えた場合、カラムを追加しないで済むテーブル構成を考えて欲しい。
今のままでは権限が増えるたびにカラムが増えてしまう」
と要望がありました。
この要望を満たすテーブル構成はどんなものがありますでしょうか。
0528NAME IS NULL
2009/06/13(土) 18:26:55ID:???アカウントごとのアクセス制限を設定するにはGRANT文を使うんじゃね
GRANT文で設定された権限の状況はSYSTABLEPERMSなどのシステムテーブルを見ればわかるし
ユーザテーブルで管理する意味がわからない
勘違いしていたらごめん
0529NAME IS NULL
2009/06/13(土) 18:36:44ID:???0530NAME IS NULL
2009/06/13(土) 19:50:48ID:???>>529
説明不足ですみません。
ここでいうアカウントや権限は、DBに関係する権限ではなく、
例えば、ビジネス文書の編集、公開、削除といった動作を許可するかどうか
といったものの権限を指します。
0531NAME IS NULL
2009/06/13(土) 20:31:15ID:???0532NAME IS NULL
2009/06/13(土) 21:26:40ID:???アカウントマスタのカラム
アカウント名
権限マスタのカラム
権限名
アカウント権限テーブルのカラム
アカウント名 許可したい権限名
として、
アカウントマスタ.アカウント名=アカウント権限テーブル.アカウント名
と
権限マスタ.権限名=アカウント権限テーブル.許可したい権限名
で3つのテーブルを結合する、という認識でいいのでしょうか。
0533NAME IS NULL
2009/06/13(土) 21:31:39ID:???基本的にすべて突っ込むようにして、許可・拒否フラグを用意するのか、
その辺は仕様次第かな。
あと、名称を直接、ではなくて、ID でリレーションを保持するように、
ってのは、RDBMS の基本。
0534NAME IS NULL
2009/06/13(土) 21:53:06ID:???細かいところは自分でもう少し練ってみます。
0535NAME IS NULL
2009/06/13(土) 23:09:32ID:???どこの世界の基本だ？
あと「リレーション」って使い方間違えているような気がするな。
どっちの意味にしてもおかしいけど。
0536NAME IS NULL
2009/06/14(日) 03:04:06ID:???こういうのはいけないって事？
create table ユーザテーブル(
ユーザＩＤ varchar(4)
, 有効 char(1) -- 1 or 0
);
create table 権限テーブル(
ユーザＩＤ varchar(4)
, 権限ＩＤ varchar(3)
, 権限 char(1) -- 1 or 0
);
・ユーザＩＤ X001 さんの権限ＩＤ A01 を取得
SELECT A.ユーザＩＤ
,B.権限 as 権限A01
FROM ユーザテーブル A LEFT OUTER JOIN 権限テーブル B ON(A.ユーザＩＤ=B.ユーザＩＤ)
WHERE A.ユーザＩＤ='X001' AND A.有効='1' AND B.権限ＩＤ='A01' ;
・ユーザＩＤ X002 さんの権限ＩＤ A01、権限ＩＤ A02 を取得
SELECT A.ユーザＩＤ
B.権限 as 権限A01
,C.権限 as 権限A02
FROM ユーザテーブル A LEFT OUTER JOIN 権限テーブル B ON(A.ユーザＩＤ=B.ユーザＩＤ)
LEFT OUTER JOIN 権限テーブル C ON(A.ユーザＩＤ=C.ユーザＩＤ)
WHERE A.ユーザＩＤ='X002' AND A.有効='1' AND B.権限ＩＤ='A01' AND C.権限ＩＤ='A02' ;
全部の権限を1レコードに集約する必要が無いなら上記の権限テーブルの内容で充分だと思うけど。
せいぜい有効期間を設定するくらい。
使いもしない項目を全部横に並べないと気が済まないのはＣＯＢＯＬの人によくありがち。
レコード全部読み込んで自前ジョインやってたのを見て怖ぇと思った。
0537NAME IS NULL
2009/06/14(日) 10:35:12ID:???COBOLERはほんと害悪。
「1レコード読むだけで全部の情報が手に入って便利だろ」
「テーブル増やしたらパフォーマンス上不利」
「ちなみにNULLはオール9に置換してある」
0538NAME IS NULL
2009/06/14(日) 13:28:40ID:???まあどちらも滅んで欲しいには違いない。
0539NAME IS NULL
2009/06/14(日) 14:05:23ID:???RDBM無しの太古のやり方のまま使い続けてるよな。
オンメモリDBとか提案すると渋々対応するけどな。
0540NAME IS NULL
2009/06/14(日) 22:51:52ID:dUBFuZEU「リレーションシップ」（エンティティ（テーブル）間の関連）
「リレーション」（関係＝テーブル）
DB設計されるみなさま、なるべく用語は正しく使いましょう
0541NAME IS NULL
2009/06/14(日) 23:39:23ID:???間違いは間違いだが、流れで把握してやりゃいいもんを・・・まぁ、それが出来ないからこんなレスするんだろうが
0542NAME IS NULL
2009/06/14(日) 23:40:56ID:???・・・
0543NAME IS NULL
2009/06/15(月) 03:04:48ID:???文脈から明らかな場合はいいいけど、>>533は意味不明だぞ。
0544NAME IS NULL
2009/06/15(月) 03:11:59ID:???0545NAME IS NULL
2009/06/15(月) 05:25:05ID:???仕事で嫌な事でもあったのか？
0546NAME IS NULL
2009/06/15(月) 06:32:15ID:???「てにをは」がおかしいだろ。それを無理に解釈するならば、
「IDでテーブルを保持する」でも意味が通じると思い込むことが
可能だ。
0547NAME IS NULL
2009/06/15(月) 07:16:31ID:???0548NAME IS NULL
2009/06/15(月) 07:37:51ID:???この2つの値の間になんらかの対応関係があることを表現したものがリレーションであり
すなわちテーブルであるということ。
0549NAME IS NULL
2009/06/15(月) 07:45:10ID:???「すなわち」って言われてもなぁ・・・
テーブルとテーブルの関係 ＝ リレーションだとしたら、
テーブル != リレーション だろ。
0550NAME IS NULL
2009/06/15(月) 08:36:47ID:???ここで言っているのは(アカウント名,権限名)という
テーブルのこと。
このように両方の値を含むテーブルがどこかに存在
しない限り、どうやってもその寛刑を表現することは
できない。
0551NAME IS NULL
2009/06/15(月) 09:18:17ID:???0552NAME IS NULL
2009/06/15(月) 11:38:11ID:???相手に「コミュ力無し」と言ってしまう奴は
DB設計なんかに関わるな
0553NAME IS NULL
2009/06/15(月) 12:16:53ID:???関係データベースモデルにおける「関係」(relation)と、
その実装である表(table)は本来別物。
数学的にもそれぞれ異なる性質を持っている。
なので安直にテーブル=リレーションと括るのはどうも。
0554NAME IS NULL
2009/06/15(月) 12:44:24ID:???ついてなさそうな人にそこから説明してたらさらにわけわかになるような。
0555NAME IS NULL
2009/06/15(月) 16:22:18ID:???リレーションシップの意味でリレーションって言ってるのは耳にするよ
で、そういうヤツに限って、客に専門用語で喋って
理解されないのは客が無知だとか言い出す(笑)
0556名無し募集中。。。
2009/06/15(月) 16:56:16ID:xNy+RduF0557NAME IS NULL
2009/06/15(月) 17:08:13ID:???0558NAME IS NULL
2009/06/15(月) 18:39:47ID:???「IP？IPアドレスのことだろ」とか
「携帯って持ち運ぶって意味なんだけど。携帯電話って言えよ」とか
得意げに言い出すヤツはなー。
0559NAME IS NULL
2009/06/15(月) 19:37:02ID:???メールとかでIPって言う分にはスルーするが、テーブルのカラム名にXxxIpとか使い始めたときは
さすがにつっこんだわ。
0560NAME IS NULL
2009/06/15(月) 20:33:50ID:???テーブルの関係性がリレーションだろ普通に
テーブルがリレーションなら
それの関係性はリレーションのリレーション
ってことにならないと辻妻合わない
0561NAME IS NULL
2009/06/15(月) 20:50:38ID:???概念がそもそも存在しないんだよ。
あるとすれば、E-RモデルのRelationshipか、実装での FOREIGN KEY とか。
0562NAME IS NULL
2009/06/15(月) 22:15:06ID:???以後、JavaServletでもPHPでも何でもWebアプリ＝CGIって呼んでるよ。
0563NAME IS NULL
2009/06/15(月) 23:04:49ID:???0564NAME IS NULL
2009/06/16(火) 00:35:27ID:???客に話す場合と「DB設計を語るスレ」とでは使い分けるよ
0565NAME IS NULL
2009/06/16(火) 01:24:11ID:???0566NAME IS NULL
2009/06/16(火) 03:23:04ID:???こんなので盛り上がれてうらやましいよ
0567NAME IS NULL
2009/06/16(火) 03:29:00ID:???定期的におかしなのは出てきてた
0568NAME IS NULL
2009/06/16(火) 20:50:30ID:???直積 D1×D2×…×Dn の有限部分集合である．
だから、関係(relation)はテーブルと考えていい。
0569NAME IS NULL
2009/06/16(火) 20:53:26ID:???射影，選択，結合，商などの関係モデルの基本操作をいう。
0570NAME IS NULL
2009/06/16(火) 21:35:23ID:???実務でＤＢいじってる奴が テーブル＝リレーション とか言ってるのは今のところ見たこと無い。
リレーショナルモデルの学問では テーブル＝リレーション なのかな。
だとすると、リレーショナルモデル視点とリレーショナルデータベース（の実装）視点では食い違いが出るはず。
0571NAME IS NULL
2009/06/16(火) 21:56:07ID:???0572NAME IS NULL
2009/06/16(火) 22:14:45ID:???クエリーの結果もビューもリレーション。
0573NAME IS NULL
2009/06/16(火) 22:23:06ID:???どっち視点で？
0574NAME IS NULL
2009/06/16(火) 22:32:30ID:???0575NAME IS NULL
2009/06/16(火) 22:34:16ID:???リレーショナルモデルの視点で。
リレーショナルモデルでは表形式のデータはリレーションだから。
0576NAME IS NULL
2009/06/16(火) 22:36:20ID:???実務だとそうだねぇ。それだけ現場にはキチンと理論を学んだ人がいないってことだな。
で、そういう人に限って「コボラーwwww」なんて言ってんだよな。
自分より下の存在があることを確認してないと生きていけないみたいに。
0577NAME IS NULL
2009/06/16(火) 22:40:39ID:???プログラミングとはちょっと勝手が違うしな。
DB専任技術者なんていないプロジェクトの方が当たり前だし（いてもインフラ系で物理設計しかやらんとか）。
0578NAME IS NULL
2009/06/16(火) 22:47:10ID:???0579NAME IS NULL
2009/06/16(火) 22:51:03ID:???リレーショナルデータベース視点だと、クエリーの結果もビューも演算結果。
0580NAME IS NULL
2009/06/16(火) 22:56:09ID:???ＤＢを単なる順編成ファイル置き場としてしか見てないＣＯＢＯＬな人が多いですよ。
理解してる人はちゃんとクエリ出すし、必要に応じてカーソル使う処理書いたりしてる。
でも圧倒的に前者が多い。他所だと違うのかもしれんけど。
0581NAME IS NULL
2009/06/17(水) 02:00:46ID:???出来るだけ少人数に抑えれば、それだけ儲けるし。中途半端でも兼任出来る香具師のほうが好まれてしまう罠。
DB専任は、周りに理解されてない香具師が多いのかもな。
ちゃんとSEやプログラマや上司や客とも仲良く成れよ。
0582NAME IS NULL
2009/06/17(水) 03:11:33ID:???0583NAME IS NULL
2009/06/17(水) 04:20:32ID:???釣り?
ちゃんと丁寧に書いてある教科書ならリレーションとテーブルの
似て異なる点が書いてあると思うけど・・・
>>570
>リレーショナルモデルの学問では テーブル＝リレーション なのかな。
普通区別します。リレーションは数学上の抽象概念で、テーブルは
その視覚的表現だったりSQLで扱うテーブルのような実装を指します。
実際のテーブルには行に順序があったり重複があったりしますので、
「ドメインの直積の有限部分集合」という一般的なリレーションの
定義とは異なる部分も出てきます。
0584NAME IS NULL
2009/06/17(水) 19:44:15ID:???関係を格納するテーブルを使うからリレーション＝テーブルとかいってるんじゃないのか？
0585NAME IS NULL
2009/06/18(木) 09:37:55ID:???0586NAME IS NULL
2009/06/18(木) 11:44:31ID:???リレーションは、属性間での関係のこと。
0587NAME IS NULL
2009/06/18(木) 15:09:19ID:???実装としてはテーブルがこれに該当する（差異はあるが）
0588NAME IS NULL
2009/06/18(木) 21:43:18ID:???エンティティとリレーションシップで考えるのはE-Rモデル。リレーショナルモデルと
イコールではない。
やっぱり混同している人は多いんだな。
0589NAME IS NULL
2009/06/18(木) 22:52:11ID:???アクセスのユーザーはリレーション＝テーブル間の関係＝JOINのキー設定というイメージが
ついてしまう。
0590NAME IS NULL
2009/06/19(金) 00:48:43ID:???0591NAME IS NULL
2009/06/19(金) 00:53:31ID:???テーブルをリレーションと表記しているDBMSをいくつか挙げてくれ
0592NAME IS NULL
2009/06/19(金) 06:03:55ID:???0593NAME IS NULL
2009/06/19(金) 12:33:46ID:???0594NAME IS NULL
2009/06/19(金) 23:33:59ID:???0595NAME IS NULL
2009/06/20(土) 02:53:32ID:???0596NAME IS NULL
2009/06/20(土) 03:20:53ID:???0597NAME IS NULL
2009/06/23(火) 10:42:38ID:tL+3Dp5kＤＢは PostgreSQL , Oracle ,MSSQL のいずれかを考えており、まだ決まっていないので
一般的に、ということで教えてください。
パフォーマンスを考慮すると、長い文字列を主キーとして使っていいものか、それとも１：１に
対応される数値型のコードを作成すべきか、悩んでいます。
本来であれば１：１に対応できるコードであれば無駄、と思うのですが、 Indexの性能を
発揮できるのは 数値型なのかとも思います。
製品コード（英数ＭＡＸ３０桁）
データ量: ＭＡＸ１０００万件
リレーション貼られるテーブル数：約１０個
皆さんであればどのような設計しますか？
0598NAME IS NULL
2009/06/23(火) 15:12:59ID:???0599NAME IS NULL
2009/06/23(火) 15:31:35ID:???0600597
2009/06/23(火) 17:26:51ID:tL+3Dp5kググってみたところ、 MySQL の InnoDB では長いＰｒｉｍａｒｙＫｅｙを持つと遅くなる、
という記載があったので、 他のＤＢでも同じなのかな？と思っていました。
MySQL自体あまり知らないので何とも言えないのですが。
ソース：
http://dev.mysql.com/doc/refman/5.1/ja/innodb-tuning.html
> InnoDB 内では、長い PRIMARY KEY を持つと、その値が全てのセカンダリ インデックス
> レコードを利用して格納される為、ディスク領域の無駄遣いになります。（詳しくは 項13.5.13.
> 「InnoDB テーブルとインデックス構造」 をご確認ください。）
> もし主キーが長かったら、AUTO_INCREMENT カラムを主キーとして作成してください。
ありがとうございました。気にせず 文字列を主キーとして使ってみます。
0601597
2009/06/23(火) 18:03:13ID:tL+3Dp5kもう１つ教えてください。
ＰｒｉｍａｒｙＫｅｙが複合キーだった場合でも同じですか？
製品コード＋リビジョン でユニークになる場合、とか。
この場合は他テーブルとのリレーションシップも複合キーになってしまうので、
製品コード＋リビジョン と １：１になるユニークなＩＤを付けたほうがいいのでしょうか。
0602NAME IS NULL
2009/06/23(火) 18:12:35ID:???変わらない変わらないといわれてもどうせ時間がたてば
「製品コードの桁数とかコード体系変更するから」とあっさり言われるのがオチなので
最初っから製品コードなんか主キーには使わないな俺は。
0603NAME IS NULL
2009/06/23(火) 19:18:43ID:???0604597
2009/06/23(火) 19:21:59ID:tL+3Dp5kそれを踏まえて 主キーであっても varchar() にしておき、桁数もちょっと余裕をみておく、
というのと、 AutoNumber でＤＢ内独自コードを主キーとして追加する、というのでは
主流は ＡｕｔｏＮｕｍｂｅｒなんですかね。
varchar を主キーに使わない理由、ってあるんでしょうか。
それともいつ変わるかわからないものを主キーにはしたくない、という思想なのでしょうか。
0605NAME IS NULL
2009/06/23(火) 19:38:29ID:???型に関係なく「なんちゃらコード」の類いはだいたい>602の理由で主キーにするのが避けるのがノウハウってだけ。
業務用件しだい(コード体系変更の場合でも古いコード体系も蓄積していく、とか)でコードをそのまま主キーにできる場合もあるし。
0606NAME IS NULL
2009/06/23(火) 19:41:51ID:???客先は一意だと言ってても、それが将来的に保証されることはない。（実際に食らわされたことあり）
DB内独自コード（サロゲートキーといいます）をつければ、どんな理不尽なことがあっても主キーの条件は守られる。
varcharでもいいと思うよ。ただし、後に泣くことが1%もないとは言い切れない。ただそれだけ。
0607NAME IS NULL
2009/06/23(火) 19:55:20ID:???IDをプライマリにしていたからそれでも良かったんだけど、
「製品コードが無い分の納品書は製品コードで検索できない」って当たり前のことをいくら説明してもわかってくれなかったよ。
0608NAME IS NULL
2009/06/23(火) 20:14:06ID:???0609NAME IS NULL
2009/06/23(火) 20:44:40ID:???MySQLはハッシュキーをサポートしてないからね。
サロゲートキーあたりの議論は相当古くから存在していて宗教問題みたいなものなのだけど、検索してみると双方の主張を見つけらるから興味があれば調べてみるといいよ。
0610NAME IS NULL
2009/06/23(火) 20:51:15ID:???0611597
2009/06/23(火) 21:42:17ID:tL+3Dp5kググってみても、やはりサロゲートキーをやっておけばあとあと何があっても対応できる、との
記事が目立ちました。
サロゲートキーを使うと、複数テーブルを見ないとわかんないので何か面倒くさいなぁ、と思っていたのですが
この部分は過去に痛い思いをした人しか実感できない重みのようなものがふつふつと見えてきましたので
皆さんの忠告どおり、サロゲートキーで作ることにします。
ありがとうございました。
0612NAME IS NULL
2009/06/23(火) 23:07:34ID:???ここまで極端だとサロゲート「厨」と言っていいレベルだな。
どうせ後で変更されるから業務分析も要件定義も意味ないと
言っているようなもん。
そもそもセマンティクスが変わってるのに「主キーの条件」だけ
守ることにどんな意味があるの。
0613NAME IS NULL
2009/06/23(火) 23:18:10ID:???そこまで病的に主キーに拘る理由が解らん。
サロゲートを使うのは要件次第と思うが。
アフォな要求にムリに答える事はないと思うが。
顧客に対して「はい」しか言えないエンジニアは常に痛い思いしかしない。
0614NAME IS NULL
2009/06/24(水) 00:12:30ID:???2chに書かれてる実体験てのを見てると、検討が甘かったのをなんとか
辻褄合わせようとする一種のバッドノウハウにしか思えないもんね。
0615NAME IS NULL
2009/06/24(水) 10:28:16ID:???セカンダリインデックスって何？
0616NAME IS NULL
2009/06/24(水) 10:47:22ID:???「サロゲート」キーという名前が悪いかもな。
あくまで存在そのものに対する識別子は非常に有用なんだけども。
0617NAME IS NULL
2009/06/24(水) 11:16:07ID:???多くの場合権限がなかったり、
業務系の深い知識が身に付くのがシステムが完成してからだったりする。
バットノウハウというより必要悪だろう。
権限も知識もないのにごり押しでキーを決めちゃって業務手順まで変えさせた挙句、
動かないシステムを作っちゃった人もいたなぁ。
0618NAME IS NULL
2009/06/24(水) 13:02:25ID:???キチンと意識して、本来のサロゲートキーとして使う分には問題ないんだけどね。
それを主キーの将来の変更が容易になるなどと考えて安易に使うのがおかしいだけで。
特に対応する自然キーが存在せず内部的な人工キーでしかレコードを特定できない
テーブルなどは、余計に注意しないとそれが何を表しているかわからないカオス
状態になりかねないからねぇ。
ID=1のレコードと2のレコードのどちらを選択すべきか、IDしか手掛かりがなければ
お手上げでしょ？
0619NAME IS NULL
2009/06/24(水) 13:16:09ID:???主キーをどうするかという全く実装上の話にすぎないで、自然キーを無くすわけじゃないよ。
0620NAME IS NULL
2009/06/24(水) 13:25:11ID:???0621NAME IS NULL
2009/06/24(水) 18:06:44ID:???システムの都合で決定されるものではない。
それをシステムの主キーにしていたからコード体系を変更することができませんとか、
改修費用がかかりますとかは論外だろｊｋ
ユーザをサポートするのがシステムの役割であって足をひぱってどうする。
0622NAME IS NULL
2009/06/24(水) 18:23:11ID:???0623NAME IS NULL
2009/06/24(水) 19:04:13ID:???業務のためにシステムを作ってんだったら、業務ルールが変更されたらシステム改修が
必要になるのは当たり前だと思うけどね。
改修が必要になっても費用を払ってくれないような困った顧客と付き合っているのなら
ともかく。
0624NAME IS NULL
2009/06/24(水) 19:21:24ID:???まずいないからねぇ。
外注SEに出来ることは限られる。
0625NAME IS NULL
2009/06/24(水) 19:21:51ID:???0626NAME IS NULL
2009/06/24(水) 20:40:47ID:???「後で必要になるかもしれないから」と言って予備のカラムをたくさん
作っちゃうんだろうな。こういう人達は。
0627NAME IS NULL
2009/06/24(水) 20:56:01ID:???事前に「変わらない」という合意を得ていたのに
後から「やっぱ変えます」じゃあ費用がかかりますと言われて当然
変えちゃいけないんじゃなくて
変える可能性があるものを「変わりません」なんて言うなって話。
0628NAME IS NULL
2009/06/24(水) 21:18:06ID:???お客さんが「変わらない」と言うからなんてのはアレだな。
0629NAME IS NULL
2009/06/24(水) 21:39:33ID:???普通にビジネスしろよ。
0630NAME IS NULL
2009/06/24(水) 21:56:36ID:???ちゃんとドキュメント書けよ、議事録残せよ。
何度か痛い目見れば、誰のためでもなく自分のためだとわかるはず。
0631NAME IS NULL
2009/06/24(水) 22:07:42ID:???話が食い違うな。
ドキュメントも書くし、議事録も残すし、顧客とコミュニケーションもとるよ。
その上で顧客の言う「製品コードは不変です」の上を行くようにしないとな。
議事録突きつけて「変わらないって言ったよね」って金を取るのもいいけどさ。
0632NAME IS NULL
2009/06/24(水) 22:18:58ID:???0633NAME IS NULL
2009/06/24(水) 22:26:17ID:???0634NAME IS NULL
2009/06/24(水) 22:27:57ID:???「ひょっとしたら客が間違ってるかもしれない」をクリアにするのがあるべき姿。
疑い出せばテーブルの主キーだけですむ話ではない。
例えば製品コードは一意です、という前提が無いと
製品コードを入力し決定ボタンを押したらその製品の画面に飛ぶ、ということすら出来ない。
不変であるという前提が無ければ画面で製品コードを変更できるようにしておかなければならない。
画面も全部何パターンも用意するか？
ちゃんと「ひょっとしたら客が間違ってるかもしれない」をクリアしとけよ。
0635NAME IS NULL
2009/06/24(水) 22:29:47ID:???0636NAME IS NULL
2009/06/24(水) 22:33:01ID:???0637NAME IS NULL
2009/06/24(水) 22:34:55ID:???合意の上で結局サロゲートキーを持つことになるんだけどな。
言質取った議事録書いたやったーなんて態度のエンジニアは少なからずいるけど、
やっぱり煙たがられているよ。本人は賢く立ち回ってるつもりらしいけど。
0638NAME IS NULL
2009/06/24(水) 22:37:47ID:???勝手にいろんなケースをたくさん想像して「ああなってもこうなっても対応しとこう」みたいなヤツは出来ないヤツだよ。
本人は賢く立ち回ってるつもりらしいけど。
0639NAME IS NULL
2009/06/24(水) 22:38:08ID:???実際には>>637なサロゲート厨が「現場からは煙たがられてる」に１票。
0640NAME IS NULL
2009/06/24(水) 22:42:00ID:???なんも問題ないじゃん。
きちんとそういう検討をした上での結果ならいいんだよ。
ただ、全部のテーブルでそんな手間かける気にはならんだろ？
0641NAME IS NULL
2009/06/24(水) 22:46:42ID:???0642NAME IS NULL
2009/06/24(水) 22:51:29ID:???コードが一意でなくなる可能性のある部分の設計は「話し合いの結果サロゲート」ではなく
「最初からサロゲート」で問題ないはずなのに、「ここでサロゲート使う俺SUGEEE」て自慢が
あるのはなんとも厨房臭い。
粗悪な設計をして工数とりたいだけと違うのか？と小一時間(ry
0643NAME IS NULL
2009/06/25(木) 00:10:10ID:???業務知らないのに、業務に最適化された設計なんて無理なんじゃｗｗｗ
客先に伺ってもうちょっとヒアリング詰めてまともな要件策定しろよ。
ヲレの設計はすばらしいから、ユーザは従えだろう。
ユーザは、実際に業務で使ってみて、このシステム使えないなと評価して、作ってるエンジニアは信用を失っていく。
製品コードって顧客でどの程度不変なのかヒアリングすれば(ry
簿記とか業務知識有れば、納品書には連番振って会計上の抜けが出ないようにするべきとか思いつくのにな。製品コードでしか検索出来ない仕様の時点で糞システム認定。
現場の他にも、経理とかからも納品書についていろいろ突っ込まれてそうｗｗｗ
いざ納品してみて、業務に合ってないからシステム使えないのに、更に改修費用を請求するのも詐欺だろう。
最初の設計が甘いのが原因だし、その甘い設計で業務まで変更してユーザに迷惑かけてたら目も当てられない。最初の開発費には、業務のヒアリングや設計も含まれてるでしょ。
0644NAME IS NULL
2009/06/25(木) 02:18:57ID:???>「ここでサロゲート使う俺SUGEEE」て自慢があるのはなんとも厨房臭い。
パラノイア気味だね。だれもそんなこと言ってないよ
小一時間とか○○厨房とか2ch語の使い方、以前も見た気がする。
もちろん候補キーは制約を含めてしっかり洗い出す。
その上で人工キーを主キーにすることでシンプルな実装になる。
無駄な予備フィールドもつようなバカ設計とは次元が違う話をしてるんだが。
で、自然キーのメリットって何よ？
0645NAME IS NULL
2009/06/25(木) 06:15:28ID:???0646NAME IS NULL
2009/06/25(木) 06:18:22ID:???業務を知ろうとしてないという以前にヒアリング段階でアサインされるレベルに立ってない人か作り投げなんだろう。
まぁ、うまく中間取れない性質っぽいから客先出したり、企画なんか無理だろうけどね。
しかし、ほんとお前らサロゲートネタ好きだよなｗ
0647NAME IS NULL
2009/06/25(木) 06:27:03ID:???正直、サロゲートを使うべきってヤツは大抵レベル低くてﾂﾏﾝﾈ
0648NAME IS NULL
2009/06/25(木) 06:39:51ID:???0649NAME IS NULL
2009/06/25(木) 07:10:55ID:???自作自演が痛々しい。
0650NAME IS NULL
2009/06/25(木) 07:38:19ID:???分析も何もしないまま、サロゲートキーにしておけば後々の変更に強いから良い、
という>>606みたいなバカ設計の話をしているんだが？
0651NAME IS NULL
2009/06/25(木) 10:15:39ID:???0652NAME IS NULL
2009/06/25(木) 11:02:28ID:???朝っぱらからご苦労さん
0653NAME IS NULL
2009/06/25(木) 20:45:13ID:???>製品コードでしか検索出来ない仕様
反論できなくてよっぽど悔しかったんだろうが
人の発言を勝手に「反論しやすい形」に歪めるのは感心しないな。
客からも「人の話ちゃんと聞いてます？都合のいいように曲解するのはやめてください」ってよく言われるだろ。
0654NAME IS NULL
2009/06/25(木) 20:48:54ID:???ここにいる連中全員だろ（笑
全体的にかみ合ってないし。
0655NAME IS NULL
2009/06/25(木) 20:59:28ID:???0656NAME IS NULL
2009/06/25(木) 22:16:04ID:???ははーん、このスレを盛り上げたいときはサロゲートキーの話題を書き込めばいいんだ
0657NAME IS NULL
2009/06/25(木) 22:18:03ID:???マルチスレッドスレにvolatile
DBスレにサロゲート
そろそろ満足したかい？
0658NAME IS NULL
2009/06/25(木) 22:36:49ID:???0659NAME IS NULL
2009/06/25(木) 22:38:40ID:???頭でっかちになるのもいいが、世の中は理屈だけじゃ通らないこともあるんだぜ？
客の言質が取れて金が貰えればいいってのはガキの主張だ。
0660NAME IS NULL
2009/06/25(木) 22:47:31ID:???0661NAME IS NULL
2009/06/25(木) 23:04:39ID:???その理屈をどう通すかってのも仕事として大事だわな。
だいたい、客の言うことが信用できないというときに
それを正面から質すことができないで小手先の対応を
するような奴がそんなセリフ吐くのはおこがましいと
いうかなんというか。
0662NAME IS NULL
2009/06/25(木) 23:09:42ID:???0663NAME IS NULL
2009/06/25(木) 23:11:10ID:???「製品コードが不変かどうか」を曖昧にしたまま設計はしないわな。
テーブル以外にも影響出まくりだし。
とかいうと
「製品コードでしか検索できない仕様がクソ」
とか見えない相手に反論始めるんだろうけど。
0664NAME IS NULL
2009/06/25(木) 23:31:14ID:???○サロゲート厨
客は仕様をコロコロ変えるからテーブル設計はサロゲートがベスト。
俺は大人。反論するヤツはガキ。
○その他
サロゲートを使うのは要件次第。要件をしっかりと顧客と検討し設計する。
0665NAME IS NULL
2009/06/25(木) 23:38:32ID:???底辺の人はヤクザと仕事しているからそういう考えに至るのですね。解ります。
>客の言質が取れて金が貰えればいいってのはガキの主張だ。
普通に職業プロの行動原理かと。
ボランティア精神溢れるアマチュア精神丸出しでナニ言ってんだが。
0666NAME IS NULL
2009/06/25(木) 23:44:14ID:???こういうケースは自然キーがいい、こういうケースはサロゲートキーのほうがいい
というのはないの？
0667NAME IS NULL
2009/06/26(金) 00:29:12ID:???って、サロゲートキーって正確なところの意味は何。
正確には自然キーの対義語じゃないんじゃないの。
0668NAME IS NULL
2009/06/26(金) 01:02:37ID:???>というのはないの？
業務知識とか欠如した人間が設計する時に下手にサロゲートを導入していくと、
システムが複雑になって工数がかかり、顧客からカネをブン取れて、
メンテも面倒なケースがあるので、維持コストも高くて保守費用が
高くなるから、そういう意味でメリットはあると思うが。
0669NAME IS NULL
2009/06/26(金) 02:24:06ID:???>業務知識とか欠如した人間が設計する時に下手に
であれば、サロゲートキーでも自然キーでもだめでしょ。ばかなの？
要件をしっかりと検討するのとは別の次元で、IDを主キーにするのは有用だと思うよ。
0670NAME IS NULL
2009/06/26(金) 02:51:12ID:???0671NAME IS NULL
2009/06/26(金) 04:46:20ID:???0672NAME IS NULL
2009/06/26(金) 06:27:29ID:???たいしてない。
設計者のエゴ。
0673NAME IS NULL
2009/06/26(金) 07:34:32ID:???コメントなりなんなりに「○○で一意になる」などと書いておくのが定石なのですか？
ご批判お願いします。
0674NAME IS NULL
2009/06/26(金) 07:47:36ID:???それ逆じゃないの？
サロゲートキーは自然キーが複合キーなど技術的な理由で扱いづらい場合に
使うもので、関連のあるテーブルは当然サロゲートキーで結合するものだよ。
これまでも出てるけど、
自然キーについての十分な検討をしないままID列をつけておけばいい
といった考え方をするのがおかしいといってるわけで、
そういった考え方をしている人は否定派の脳内にしかいないように思えるんだがね。
0675NAME IS NULL
2009/06/26(金) 09:00:18ID:???逆に肯定派の脳内にしかいないな。
0676NAME IS NULL
2009/06/26(金) 10:15:47ID:???そんなこと言っているやつは君の脳内にしかいないな
0677NAME IS NULL
2009/06/26(金) 10:31:01ID:???ON句は関係ないんじゃないかね？
SELECT * FROM foo JOIN bar ON foo.id = bar.foo_id
「○○で一意になる」というのは普通にユニークインデックスや制約をつければいい。
否定派（というか一人だけ？）は主キー以外のキーは存在しないと思っているのだろうか？
0678NAME IS NULL
2009/06/26(金) 11:43:37ID:???EJBやRoRといった近頃のフレームワークを使うなら人工キーが主流。
複合主キーはレガシーシステムを扱わざるを得ない場合のオプション的な扱い。
システムがシンプルになって工数が減り、メンテも容易なケースがあるので、維持コストも低くて保守費用が安くなるかもね
One fact in one placeの理念から言っても自然キーは分が悪い。
「○○コード２桁＋△△区分１桁＋・・・、で××の場合は最後２桁が９９」
のように識別子や外部キーとしては不要で、変なしがらみをもった情報が複数箇所に散らばってしまいやすい。
0679NAME IS NULL
2009/06/26(金) 12:35:24ID:???客の理解可能なキーの話をして理解してもらった上で 、もしもの保険、サロゲートキーの話に持って行けば良い。
客は今問題になっている点を解消したい訳なんだから、あんまり未来の話(キーが変わるかも云々)をされたって嬉しくない。
フレームワークで勝手に作られる物に関してなら大して気にはしないけど。
0680NAME IS NULL
2009/06/26(金) 12:50:11ID:???そりゃギャップがあるわ。
もしかして、「最近のフレームワーク」しか使ったことがなくて、そもそも
インピーダンスミスマッチすら意識したことがないのかもね。
0681NAME IS NULL
2009/06/26(金) 13:01:41ID:???0682NAME IS NULL
2009/06/26(金) 13:39:46ID:???0683NAME IS NULL
2009/06/26(金) 13:46:48ID:???0684NAME IS NULL
2009/06/26(金) 14:02:13ID:???自然な話だよな。だから普通にそうすればいい。それが自然キー
主キーたる候補がない場合、あるいはその主キーが使いにくい場合
代わりの項目をつかう。それがサロゲート
主キーが自然キーなのはメリットないよ。自然にそうなるだけで
自然キーを主キーにするのにデメリットが多ければサロゲート使うだけ
>>678
「○○コード２桁＋△△区分１桁＋・・・、で××の場合は最後２桁が９９」
あのな、コードの一部を抜き出してなんかしないといけない時点で、設計が間違ってるんだが
最近のフレームワークが代理キー推奨なのは、こういうアホな設計でもなんとかできるようにだな
代理キーつくった時点で、代理キーと本来の自然キーとのしがらみを増やしてることにも気づけよ
0685NAME IS NULL
2009/06/26(金) 14:06:16ID:???0686NAME IS NULL
2009/06/26(金) 14:06:37ID:???客も設計者も理解が早い。そのシステムの世界での共通語で構成されてるから。ほぼ妥当だろうしユーザレベルでの検証も可能だしアンドキュメンテッドな仕様による不都合の指摘も貰える可能性が高い。
…まとめが見てみたいからとりあえず書いてみた。
0687NAME IS NULL
2009/06/26(金) 14:35:04ID:???主キーたる候補って「○○コード２桁＋△△区分１桁＋・・・」が多数じゃね？
いくらユーザが「変わらない」と言ったって、主キーにするには弱いと思う。
>主キーたる候補がない場合、あるいはその主キーが使いにくい場合
>代わりの項目をつかう。それがサロゲート
ここで思考停止してるんだろうな
自然キーの代わりとしてではなく、積極的に情報を指すポインタとして主キーの実装は人工キーにしたら良いと主張しているのですよ。
>>686
ありがとう
仕様、外部設計と呼ばれるような部分は、もちろんそれで良いと思う。
0688NAME IS NULL
2009/06/26(金) 14:48:02ID:???ユーザと打ち合わせるのは正規化前の状態。
正規化したテーブル構造をユーザは理解できないし必要もない。
情報の分散、重複をなくして変更に強くする。
そういえば正規化を理解していない人を相手にしているのと同じ感じを受ける。
0689NAME IS NULL
2009/06/26(金) 15:50:00ID:???0690NAME IS NULL
2009/06/26(金) 15:57:25ID:???その必要はないな。非NULLでユニークなキー（候補キー）がテーブルに２つあるでいい。
0691NAME IS NULL
2009/06/26(金) 17:29:16ID:???○○コード＋△△区分で主キー候補なら、人工キー作れば良いと思うよ
○○コードの下２桁＋△△区分の上１桁とか言い出したら設計が間違ってる
で、お前の言う
>自然キーの代わりとしてではなく、積極的に情報を指すポインタとして主キーの実装は人工キーに
ってのは、○○コードだけで主キー候補たる場合でも
○○コードを主キーにせずに人工キーを作れって主張だと理解してＯＫなのか？
0692NAME IS NULL
2009/06/26(金) 18:27:34ID:???>○○コードを主キーにせずに人工キーを作れって主張だと理解してＯＫなのか？
そうだよ。
○○コード＋△△区分って程度の複合キーでも人工キーにしちゃうの？
だったらかなりの部分が人工キーにならないかい？
いっそ全部人工キーに統一しちゃえばすっきりすると思わないかな。
それ以外で主キー候補たる自然キーって少ないよね。例えば何かあるかい？
0693NAME IS NULL
2009/06/26(金) 18:45:02ID:???たけど、>いっそ全部人工キーに統一しちゃえ ってのはそれこそ思考停止
全部に人工キー作れって主張があるのはしってるし
実際俺は全部のテーブルに人工キー作ってみたこともあるぞ
その結果で言えば、全部に人工キーつくるのは明らかに無駄な作業を増やすだけ
ＯＲマッピングとか前提なら話は違うのかもしれんがな
0694NAME IS NULL
2009/06/26(金) 19:32:36ID:???「分類区分１桁＋西暦２桁＋連番２桁＋サイズ＋色」
「入学年２桁＋学科区分２桁＋連番」
のような体系になっているんだよねえ
0695NAME IS NULL
2009/06/26(金) 21:49:48ID:???漏れの知っている保険関係のテーブルだと、加入者テーブルは
加入者コードが一意で主キーで、保険商品が４種類(A,B,C,D)あったとしたら
A+連番10桁
B+連番10桁
C+連番10桁
D+連番10桁
てなかんじでほどよい(?)いい加減さがあったぞ。
個人的には、こんなん連番12桁にしておいて、別カラムで保険商品コード持たせれば？
って思ったものだけど。
とは言えこれでサロゲートキー作って主キーにしようとは思わんな。
これらの関連として会員テーブル、送付先住所テーブル（愛人対策テーブルとも言うｗ）、家族テーブル、変更履歴テーブル
とかあるが、それらにサロゲートとか使っていたらウザくてしょうがない。むしろミスが増えそうだ。
0696NAME IS NULL
2009/06/26(金) 22:44:40ID:???人が扱うにはその方が都合が良いから、そのコード体系が悪いわけではない。
人かコンピュータかどちらが扱うのか、ドメインが違えば正しい解も違う。
> 連番12桁にしておいて、別カラムで保険商品コード持たせれば？
> って思ったものだけど。
それが人工キーだろw
0697NAME IS NULL
2009/06/26(金) 22:54:42ID:???0698NAME IS NULL
2009/06/26(金) 22:57:32ID:???それって古のネットワーク型DBや、その焼き直しであるオブジェクトDBの考え方。
主張するのは別に悪いとは言わんが、それが当然と考えているならアレだ。
0699NAME IS NULL
2009/06/26(金) 23:02:17ID:???そうじゃなければただの連番になるだろうし、そうなるとコンピュータが採番するか人が採番するかの違いだけで、そりゃ人工キーだろって話よ。
0700NAME IS NULL
2009/06/26(金) 23:06:06ID:???0701NAME IS NULL
2009/06/26(金) 23:23:41ID:???0702NAME IS NULL
2009/06/26(金) 23:39:02ID:???そうならないように管理されているなら問題ないが、
一意性と可読性を両立するのは難しいこともあるなぁ。
0703NAME IS NULL
2009/06/27(土) 00:08:29ID:???賑わってるｗｗ
>積極的に情報を指すポインタとして主キーの実装は人工キーにしたら良いと主張しているのですよ。
そういう考え方があるのも理解してる。DWHで使うようなスタースキーマ構造を作るんならそれだろうと思う。
理論というか、理想としてそういうのはあってもよいと思う。
でもね、企業の業務コードってのはその企業が活動するための物だから、活動が続く以上変化し続けるのよ。都合のよいように。
「業務コードが変わったり｣する事は織り込み済み。定期的なコード洗い替え処理やるしね。
業務コードを変えて、ひも付けや関連情報を変更することを必要としてることも多いのよ。
サロゲートキーで｢業務コードが変更されてもだいじょうぶ｣にするのもやり方だけど、変更を許してそれによって円滑に進めるやり方もある。
だから
> 仕様、外部設計と呼ばれるような部分は、もちろんそれで良いと思う。
なんて聞くと、と正直｢大丈夫？｣とか思う。ヒアリングの結果どうすべきか（大好きなサロゲートキーを使うかどうか）判断するくらいの余裕を持とう。
0704NAME IS NULL
2009/06/27(土) 00:38:08ID:???>サロゲートキーで｢業務コードが変更されてもだいじょうぶ｣にするのもやり方だけど、変更を許してそれによって円滑に進めるやり方もある。
違いがわからん。
>業務コードを変えて、ひも付けや関連情報を変更することを必要としてることも多いのよ。
これは完全にズレてる。
0705NAME IS NULL
2009/06/27(土) 00:52:22ID:???>でもね、企業の業務コードってのはその企業が活動するための物だから、活動が続く以上変化し続けるのよ。都合のよいように。
だから主キーにはしない方がいいんじゃないの？
むちゃくちゃだな。
0706NAME IS NULL
2009/06/27(土) 01:59:25ID:???>サロゲートキーで｢業務コードが変更されてもだいじょうぶ｣にするのも
>やり方だけど、変更を許してそれによって円滑に進めるやり方もある。
何が言いたいのかわからんw
0707NAME IS NULL
2009/06/27(土) 04:38:44ID:???>だから主キーにはしない方がいいんじゃないの？
別にさっきの流れの話で言うなら保険商品テーブルに保険商品コードがあって
今まで企業がA,B,C,Dの商品を持っていて、新たにE,Fと言う
商品を扱いだしたら、別にテーブルに内容追加するだけでは？
この場合保険商品コードがそのまんま主キーでも問題ない。
なんかサロゲート厨ってなんでRDBの利点を自ら否定しているノリがあるよな。
0708NAME IS NULL
2009/06/27(土) 07:37:52ID:???のに変わってきたのかな。この話題なら興味はあるよ。
基本的に有意キーは一意性と不変性が保障できれば主キーとして使える。
構造もシンプルになる。
業務系のコードの場合はこの条件を満たすことが多い。
トランザクションや台帳系の場合は変更が多いから不変性が保てないことが多い。
一意性の確保ために枝番を付けたり、
逆に一意性のためには冗長なほど多くの意味のあるコードを含んでしまっているケースがある。
この場合は人工キーを主キーとしてその他必要な情報はタグとして別途付けるのがよい。
一意なキーが不要で存在しないレコードの場合は人工キーを付ける。
0709NAME IS NULL
2009/06/27(土) 07:40:39ID:???頑張れアンチ！
0710NAME IS NULL
2009/06/27(土) 09:07:30ID:???EJBのほうはシラネ。
サロゲート使えば解決出来るってことだと結局、設計が不味くても何とかなるってだけでうやむやになって、これまでと同様にこれからも変わらないと思うけどね。
サロゲート設定しなくても済む様なまともな設計をまず行うべきだと思う。
現場の業務で、製品コード無しで処理している以上、製品コード無しで検索出来ないのようなのは糞システムでしょ。現場の業務のヒアリングが足りない。
0711NAME IS NULL
2009/06/27(土) 09:27:33ID:???710が根源的に勘違いしているのだけど、「全部idを主キーにする」からって業務キーの洗い出しをしないわけではないんだよ。
ってか主キー以外では検索できないと思ってる？
> 現場の業務で、製品コード無しで処理している以上、製品コード無しで
> 検索出来ないのようなのは糞システムでしょ。
わけわからん。落ち着け。
0712NAME IS NULL
2009/06/27(土) 09:36:27ID:???>今まで企業がA,B,C,Dの商品を持っていて、新たにE,Fと言う
>商品を扱いだしたら、別にテーブルに内容追加するだけでは？
RDBの利点ってそんなとこにないよw
そして保険の例も下らなすぎ。
業務拡張や合併に合わせて既存の商品コードをA1,A0,B0,Xにします。
ときたらどうなる？
「不変です」と言う顧客のシステム担当の権限をはるかに越えたところで
業務コードの変更というのは起きるんだよ。
0713NAME IS NULL
2009/06/27(土) 09:36:29ID:???それを混同しているところがやっぱり厨なんだよな。
オブジェクトモデリングの考え方では、オブジェクトは厳然と存在していて、それを
特定できるIDがあればよい。そもそもリレーショナルモデルと考え方が異なるから、
キーという概念やリレーションの正規化という考え方が存在しない。
問題は現実の問題領域との対応が正しいかどうか、例えば実際の商品は1つだけなのに
システム上のオブジェクトが2つになっていたりしないか、というところなんだけれども、
オブジェクト指向設計ではそれはデータモデルには表現されず、オブジェクトの
「ふるまい」によって保証されなければならない。
変更に強いと言っているのがおそらくこのためで、データモデルを大きく変えなくても
ふるまいを変えればいいジャン、と。プログラムよりデータの方が安定だとするところ
から出発するDOAとは逆の考え方になる。
これも最初に抽出したオブジェクトは安定だという前提なわけで、それがひっくりかえる
ような変更があったら同じことなんだけどね。
0714NAME IS NULL
2009/06/27(土) 09:44:20ID:???>基本的に有意キーは一意性と不変性が保障できれば主キーとして使える。
>構造もシンプルになる。
そして複合主キーにならなければ、でしょ？
なんだかなあ
>業務系のコードの場合はこの条件を満たすことが多い。
多くないでしょw
0715NAME IS NULL
2009/06/27(土) 09:46:41ID:???ユニークインデックスやユニーク制約ってしってる？
0716NAME IS NULL
2009/06/27(土) 09:48:55ID:???>変更に強いと言っているのがおそらくこのためで、データモデルを大きく変えなくても
>ふるまいを変えればいいジャン、と。プログラムよりデータの方が安定だとするところ
>から出発するDOAとは逆の考え方になる。
これだけなのに矛盾してるw
データモデルを大きく変えなくても振る舞いを変えればいいから、データの方が安定するんでしょ？
不安定な業務キーを主キーにしてしまえばデータが不安定になっちゃうのに.
0717NAME IS NULL
2009/06/27(土) 09:51:57ID:???0718NAME IS NULL
2009/06/27(土) 10:57:46ID:???複合キーは避ける、ORMではID列が推奨、
とはいうのはDBMSやミドルウェアを使う上での要求や制限であるわけで、
本質的な設計が終わってから追加すればよい話なんだがね。
0719NAME IS NULL
2009/06/27(土) 12:40:41ID:???0720NAME IS NULL
2009/06/27(土) 12:49:54ID:???0721NAME IS NULL
2009/06/27(土) 13:01:51ID:???>人工キーの導入は正規化
なるほど
0722NAME IS NULL
2009/06/27(土) 13:08:45ID:???0723NAME IS NULL
2009/06/27(土) 17:16:51ID:???な構図？頑張れってアンチ！
0724NAME IS NULL
2009/06/27(土) 17:40:56ID:???「安定であるとする」というのは考えｋ他の前提であって、「安定させる」という
目的とは違うんだが。安定なコードを選択するのは分析段階の仕事であって、
仮にそれが実は安定じゃなかったといったら分析の失敗。
なぜか「業務キー」は後から変更されると決めてかかっているようだけれども、
そういう先入観に囚われていたりすると間違いやすいわけだな。逆もしかり。
というか、思い込みとしては確かに逆の方が多いと思うけど。
0725NAME IS NULL
2009/06/27(土) 18:14:06ID:???>ときたらどうなる？
現実に起きないケースを言われてもな。
仕事したことあるの？
仮にそんな命令だす会社があるなら晒してみれば？
銀行が合併や統廃合しても旧支店名や旧支店コードが変わることはないんだが。
「既存の○○コードを■■にします」と言うのなら、新規にコード追加と
変換テーブル用意すればいいだけで、サロゲートなんて仕組みは必要ない。
>「不変です」と言う顧客のシステム担当の権限をはるかに越えたところで
>業務コードの変更というのは起きるんだよ。
単にシステム責任者が「はい」しか言わないヴァカだからじゃないのか？
システムでソレを実行したら、どれほどのリスクが発生しそれらに関する修正体力がどれほど必要か
説明すれば、いくら上がヴァカでも、システムに対する理不尽な要求を撤回してくれる。
0726NAME IS NULL
2009/06/27(土) 18:53:23ID:???0727NAME IS NULL
2009/06/27(土) 18:57:42ID:???0728NAME IS NULL
2009/06/27(土) 19:46:22ID:???・主キーは自然キーでもサロゲートでも良い
・大事なコードが「可変か不変か」「一意か重複か」は主キー云々とは関係なく当然事前にキッチリつめておくべき
・「サロゲートキー使うから要件確認なんて適当でいいだろ」とはかありえない
0729NAME IS NULL
2009/06/28(日) 00:05:44ID:???0730NAME IS NULL
2009/06/28(日) 01:00:16ID:???「製品コード 変更」でググってみなよ
>>703ではこんなふうに言ってるのにね
>でもね、企業の業務コードってのはその企業が活動するための物だから、活動が続く以上変化し続けるのよ。都合のよいように。
>「業務コードが変わったり｣する事は織り込み済み。定期的なコード洗い替え処理やるしね。
>業務コードを変えて、ひも付けや関連情報を変更することを必要としてることも多いのよ。
0731NAME IS NULL
2009/06/28(日) 03:00:02ID:???そんな設計ミスで後から改修費用取るのは詐欺。金貰って喰ってるプロなら最初からちゃんと設計ぐらいしないと。
急にボールが来たとかいい訳して仕事しなかったサッカーの素人並。
0732NAME IS NULL
2009/06/28(日) 03:48:57ID:???>>728
0733NAME IS NULL
2009/06/28(日) 03:58:51ID:???そこをちゃんと確認しとかなきゃ仮にDBが無事でもプロジェクトはボロボロだっての。
0734NAME IS NULL
2009/06/28(日) 04:13:17ID:???とユーザーに尋ねたら、
「将来、変更がかかっても最小の修正ですむような設計にしてください。」
という返事が返ってくるんじゃないの？
「将来にわたって変更はありません」
とは言わないだろ。
0735NAME IS NULL
2009/06/28(日) 04:19:06ID:???曖昧なまま「どっちでもいいよ。なんせサロゲートキーを使ってるからな」がありえないって話だ。
0736NAME IS NULL
2009/06/28(日) 04:23:20ID:???それはOKなんだｗ
よくわかんねーやつだなｗｗｗ
0737NAME IS NULL
2009/06/28(日) 04:27:36ID:???いや何もおかしくないだろ。
「サロゲートキーか否か」がプロジェクトより大事な人にはわからんだろうけど。
別にこっちは「サロゲートキーを使わない」事に命をかけてるわけでもないんで。
0738NAME IS NULL
2009/06/28(日) 04:39:49ID:???0739NAME IS NULL
2009/06/28(日) 04:43:43ID:???そうやってワザと馬鹿のフリをしてスレを盛り上げようとしてくれてるんだろ？
わかってる、愛してるよ。
0740NAME IS NULL
2009/06/28(日) 04:44:22ID:???>曖昧なまま「どっちでもいいよ。なんせサロゲートキーを使ってるからな」がありえないって話だ。
林: まさかとは思いますが、この「どっちでもいいよ。なんせサロゲートキーを使ってるからな厨」とは、あなたの想像上の存在にすぎないのでは
ないでしょうか。もしそうだとすれば、あなた自身が統合失調症であることに
ほぼ間違いないと思います。
0741NAME IS NULL
2009/06/28(日) 04:46:41ID:???それに対する反論が「サロゲートキーを使え」だからな。
そんなレッテル貼りやったりネタで逃げたりしなきゃならないんだろ。
0742NAME IS NULL
2009/06/28(日) 04:51:37ID:???それに対する反論が「要件を確定しろ」だからな
0743NAME IS NULL
2009/06/28(日) 04:54:11ID:???必要だと確定して使うんなら問題ないだろ、と言ったはずだが。
そんなウソをついてまで「まだ反論できてるフリ」しなくていいよ。
0744NAME IS NULL
2009/06/28(日) 04:56:58ID:???人工キーを活用するという話とサロゲートキーの話が混ざってないかい？
製品コードは有意キー（人間から見て意味のあるキー）にしたいというニーズは強いんだが、
製造と販売で盛り込みたい情報が違ってたり、世代の管理をしたいとかいろいろあるんで、
主キーは人工キーにしてバーコード化している。
と同時に製造タグコードと販売タグコードを別にふって印刷している。
タグコードは両方ともユニークではない意味のあるコード。
ひとつの考え方でいかなる場合もそうであるわけではないのだが、
枝番をふって主キーにするよりも人工キーを活用したほうがよい場合もある。
0745NAME IS NULL
2009/06/28(日) 05:05:18ID:???そんな感じだと思うよ。
絡んでくる変なのがいるからかまってるだけで。
しかしみんな朝早いなw
0746NAME IS NULL
2009/06/28(日) 05:06:59ID:???おいおい>>744は「要件を確定させ、必要だとわかった上で」「人工キーを活用した方が良い場合もある」という話だぞ。
君が全否定されてんの。
0747NAME IS NULL
2009/06/28(日) 05:07:49ID:???0748NAME IS NULL
2009/06/28(日) 05:17:00ID:???A＋連番１０桁とかそんなんだもんな
0749NAME IS NULL
2009/06/28(日) 05:18:03ID:???>銀行が合併や統廃合しても旧支店名や旧支店コードが変わることはないんだが。
合併するなら重複が発生するだろう
http://www.bk.mufg.jp/oshirase/tenban/furiwake.html
http://www.resona-gr.co.jp/group/group_0101.htm
ちなみに「製品コード 変更」で検索
https://ruo.mbl.co.jp/news/information/number_change-1.html
http://www.platonjapan.co.jp/pdf_platon/code.pdf
>>「不変です」と言う顧客のシステム担当の権限をはるかに越えたところで
>>業務コードの変更というのは起きるんだよ。
> 単にシステム責任者が「はい」しか言わないヴァカだからじゃないのか？
「業界でコード体系を統一しよう」という大きな動きを、システム責任者ごときが「NO」と言えるか？
「システムで主キーにしちゃってるんで」って。
0750NAME IS NULL
2009/06/28(日) 05:55:33ID:???0751NAME IS NULL
2009/06/28(日) 06:47:08ID:???アンチの方が変なの多い気もする。
0752NAME IS NULL
2009/06/28(日) 09:34:28ID:???サロゲート使えばおk
そもそもサロゲート使う設計が糞。
サロゲート使わない事に命掛けてる訳ではない。 ＜今ここ
要件確定してるのでサロゲートなんて使ってませんが？
じゃあサロゲート要らないね。
終了。
銀行の支店コードが統廃合で実際変わってたね。まだ現金で給料貰ってる香具師なんだろうか。
0753NAME IS NULL
2009/06/28(日) 10:53:09ID:???だれがどんな主張かわからんぞ
0754NAME IS NULL
2009/06/28(日) 12:15:50ID:???0755NAME IS NULL
2009/06/28(日) 15:41:31ID:???「必要かどうかを判断すべき派（中立派）」と「何が何でも使え派（サロ厨）」がいるだけで
0756703
2009/06/28(日) 16:00:10ID:3qHYmqKK発生する企業コードの変更に、意味ある対応ができるならならサロゲートキー使えばいいと思いますよ。
だけど単純に｢変更が発生するから云々｣でサロゲートキー使う反射神経野郎はどうかしてる。と思ってる。
＃サロゲートキーを否定してる訳じゃないので。
企業コードなんてのはガンガン変わるもの。その変化するコードに後生大事に不変のキーをくっつけて持ちまわすことに意味があるのか？
洗い替え作業って、単にコードを直すだけじゃない。組織構造の変更や移管・移行に伴う関連性の張替え組換えだってやる。場合によっちゃ元の構造を壊して作り変える。
企業コードの他に、使いもしないような別キーについても面倒見なくちゃならないのは正直ろくでもない手間としか映らない。
もちろん、ろくでもない手間ではない、ちゃんとメリットの見える設計なら歓迎。
「〜な理由で不変なキーが必要です｣とか言った企業活動に必要な、明確な理由があってのサロゲートキーやら何とかキーなら理解できる。
ただ｢将来の保険｣的なものや「コードが変わっても元の構造を維持できる｣とか、でしかないなら余計な工数が必要なお粗末設計なだけ。
0757NAME IS NULL
2009/06/28(日) 16:08:43ID:???サロゲートキーをつける事で発生する「余計な工数」ってなんだ？
0758NAME IS NULL
2009/06/28(日) 16:10:50ID:???「キーが変わる・重複する」事を考慮して全体を作ると結構な工数。
そこは要件をきちんと詰めて「これだけかかりますが両対応にしますか」と合意を取らなければならない。
0759NAME IS NULL
2009/06/28(日) 16:45:23ID:???>「必要かどうかを判断すべき派（中立派）」
自分ではそう思ってるんだな。
すまんが、傍観者から言わせて貰うとまったくそうは見えないぞ。
>>756
君はアンチサロゲっつーか日本語でおｋっつーか・・・
0760NAME IS NULL
2009/06/28(日) 16:50:24ID:???0761NAME IS NULL
2009/06/28(日) 16:51:59ID:???・話をそらす
・見えない敵と戦い始める
・バレバレのウソをつく
・自演を始める
もう飽きたよサロ厨
0762NAME IS NULL
2009/06/28(日) 16:53:16ID:???「何が何でもサロゲートキーを使うべき」に同意しない人は全てアンチか。
怖いなｗ
0763NAME IS NULL
2009/06/28(日) 17:28:11ID:???>>735->>736のやりとりを見れば
「何が何でもサロゲートキーを否定するアンチ」を脳内で作り出して
それと戦っているつもりになってるのは明白だろう。
相手が中立であってはならない。
0764NAME IS NULL
2009/06/28(日) 17:48:38ID:???反論っぽいのも的外れだしなぁ。
必死にググった結果もアレだったし。
中二病とおなじく「サロゲート」といいたいだけと違うのか？って希ガス。
0765NAME IS NULL
2009/06/28(日) 18:13:58ID:???>http://www.bk.mufg.jp/oshirase/tenban/furiwake.html
漏れ、ここの銀行の２世代前（倒壊銀行）の古い合併前の通帳やキャッシュカード使っても問題ないよ。
つかサロゲートの人ってシステム設計した事無いんじゃね？
とりあえず、漏れはちょっと中の人だけど銀行の統廃合で過去のコードは無かったことにされないよ。
サロゲートキーとか使わずに実装している。合併したらそれは新しい銀行なので、旧銀行とは区別されている。
>「業界でコード体系を統一しよう」という大きな動きを、システム責任者ごときが「NO」と言えるか？
全銀の世界ではすでにコードが統一されているよ。銀行のシステム担当者はこれに合わせるだけ。
と言うかあわせないといけない。
基本的に旧コードをないがしろにしていない。古い手形・小切手を持っている人が泣くだろ。
手形には主キーと言う概念がないので例えとしてはアレだが。
とりあえず、そんなに自説に自信があるならMUFGにいって「オレに設計させれ」と言って来い。
サロゲートの人は本気で病気だと思うからここで現実逃避してないで、
マジで精神カウンセリングを受けたほうがいいと思うよ。
0766NAME IS NULL
2009/06/28(日) 18:52:47ID:???そりゃあできるだろう。
できるかできないかではなくて、改修にかかわるコストの論議をしているんだと思うんだが。
ちがうか？
0767NAME IS NULL
2009/06/28(日) 19:07:04ID:???製品コードで検索出来なくて文句言われた。
サロゲート使えばおk
そもそもサロゲート使う設計が糞。
サロゲート使わない事に命掛けてる訳ではない。
サロゲート使えば改修費用が安く出来る。 ＜今ここ
要件確定してるので実はサロゲートなんて使ってませんが？
じゃあサロゲート要らないね。
終了。
コストなんて末端のPGを低賃金で雇うなり、サビ残では足らせればいくらでも圧縮可能と、予算管理者や経営者は考えてる罠。
予算はサロゲートで決まるんじゃない。エクセルの上で決められている。
0768NAME IS NULL
2009/06/28(日) 19:21:03ID:???君の書いた要件定義書をぜひ見てみたい。
0769NAME IS NULL
2009/06/28(日) 19:22:50ID:???> コストなんて末端のPGを低賃金で雇うなり、サビ残では足らせればいくらでも圧縮可能
あはーん、だからよくダウンするんだ。MUFGのコンピューターシステムは。
0770NAME IS NULL
2009/06/28(日) 19:30:38ID:???サロ厨が何の反論も出来なくなったところに、わざわざエサをまきに来るなよ
0771NAME IS NULL
2009/06/28(日) 19:57:15ID:???0772NAME IS NULL
2009/06/28(日) 20:25:10ID:???0773NAME IS NULL
2009/06/28(日) 20:26:18ID:???>サロゲートキーとか使わずに実装している。合併したらそれは新しい銀行なので、旧銀行とは区別されている。
実際の口座テーブルの主キーは何なのでしょうか。
0774NAME IS NULL
2009/06/28(日) 22:52:35ID:???>アンチってのはいないだろ。
>「必要かどうかを判断すべき派（中立派）」と「何が何でも使え派（サロ厨）」がいるだけで
何が何でも使え派ってどれ？
あなたが総合失調症の人ですか？
0775NAME IS NULL
2009/06/28(日) 23:00:02ID:???ん？君も「状況を判断して使うかどうか決めるべき」って考え？
0776NAME IS NULL
2009/06/28(日) 23:35:45ID:???0777NAME IS NULL
2009/06/28(日) 23:52:57ID:???>製品コードで検索出来なくて文句言われた。
>サロゲート使えばおk
>そもそもサロゲート使う設計が糞。
>サロゲート使わない事に命掛けてる訳ではない。
>サロゲート使えば改修費用が安く出来る。 ＜今ここ
>要件確定してるので実はサロゲートなんて使ってませんが？
>じゃあサロゲート要らないね。
>終了。
これがまるっきり意味分からんのだが。
誰か解読してください
0778NAME IS NULL
2009/06/29(月) 00:01:46ID:???本当にアレだな。
>ここの銀行の２世代前（倒壊銀行）の古い合併前の通帳やキャッシュカード使っても問題ないよ。
問題ないように苦労してシステム作るだろ、普通。
その時に自然キーよりも人工キー使ってたシステムの方が対応しやすいんじゃないかなって。
>ちょっと中の人だけど銀行の統廃合で過去のコードは無かったことにされないよ。
「過去のコードをなかったことにする」なんて誰か主張したかい？
>全銀の世界ではすでにコードが統一されているよ。銀行のシステム担当者はこれに合わせるだけ。
>と言うかあわせないといけない。
もっと一般的な話をしたつもりなんだが。
0779NAME IS NULL
2009/06/29(月) 00:04:55ID:???0780NAME IS NULL
2009/06/29(月) 00:05:15ID:???0781NAME IS NULL
2009/06/29(月) 00:12:01ID:???>漏れはちょっと中の人だけど銀行の統廃合で過去のコードは無かったことにされないよ。
当たり前だバカ。そんな話してるんじゃないよ。
どうかこの人と仕事で関わりませんように
0782NAME IS NULL
2009/06/29(月) 00:20:24ID:???>企業コードなんてのはガンガン変わるもの。その変化するコードに後生大事に不変のキーをくっつけて持ちまわすことに意味があるのか？
過去との紐付け
0783NAME IS NULL
2009/06/29(月) 00:26:31ID:???0784NAME IS NULL
2009/06/29(月) 00:32:19ID:???第一正規化、繰り返し項目の排除についてどう思う？
「必要かどうかを判断すべき」だったりする？
0785NAME IS NULL
2009/06/29(月) 00:40:13ID:???完全に反論できなくなったのを「無かったこと」にしに来たなｗ
0786NAME IS NULL
2009/06/29(月) 00:44:50ID:???0787NAME IS NULL
2009/06/29(月) 00:49:09ID:???0788NAME IS NULL
2009/06/29(月) 00:53:28ID:???専スレ立てようか？
正直、サロゲネタはお腹いっぱい。
0789NAME IS NULL
2009/06/29(月) 00:56:29ID:???>>737
>>739
>>741
>>744
>>761
>>770
>>776
>>779
>>783
>>785
>>787
0790NAME IS NULL
2009/06/29(月) 00:56:56ID:???>完全に反論できなくなった
は？
0791NAME IS NULL
2009/06/29(月) 00:57:49ID:???>正直、サロゲネタはお腹いっぱい。
同意
専用スレもいらんよ
0792NAME IS NULL
2009/06/29(月) 00:57:55ID:???0793NAME IS NULL
2009/06/29(月) 23:41:48ID:???0794NAME IS NULL
2009/06/29(月) 23:56:15ID:???0795NAME IS NULL
2009/06/30(火) 00:17:18ID:cjciCkCN0796NAME IS NULL
2009/06/30(火) 00:19:30ID:???0797NAME IS NULL
2009/06/30(火) 01:20:43ID:???0798NAME IS NULL
2009/06/30(火) 02:11:46ID:???>>795
>>797
0799NAME IS NULL
2009/06/30(火) 06:30:50ID:???0800NAME IS NULL
2009/06/30(火) 12:54:48ID:???サロゲートキーのメリット、デメリットと
どんな時に使うと良くて、どんな時は良くないのか。
0801NAME IS NULL
2009/06/30(火) 13:50:35ID:???こういう業務を想定した上で、これをシステム化する。
A) 電話番号を主キーとして使用。
B) ユニークな連番（ID）を発行し、主キーとするが電話番号も候補キーである。
ユーザーは主に電話番号を使う。IDは管理番号としてバーコードなどに使用する。
C) ユニークな連番（ID）を発行しユーザーに通知、これを主キーとする。
電話番号は問い合わせに使用できるが基本的に一属性である。
D) ユニークな連番（ID）を付加するがユーザーには非通知。システムの内部だけで使用する。
電話番号は候補キー
Aは自然キー、Dはサロゲートキーで間違いないと思うが、BとCは解釈が分かれると思う。
ABCが自然キーでDが人工キー＝サロゲートキーが正しいらしいが、
Aが自然キー、BCDがサロゲートキーでないが人工キー、
Dがサロゲートキーというのが一般的だと思うけどどうだろう。
BCDがサロゲートキーと解釈してる人もいそうだけど、
この辺の意識あわせはしないとややこしくなりそうだ。
0802NAME IS NULL
2009/06/30(火) 13:52:28ID:???＞Aが自然キー、BCDがサロゲートキーでないが人工キー、
Aが自然キー、BCがサロゲートキーでないが人工キー、
私的にはABCが自然キー、Aは特に有意キーと呼んでる。
0803NAME IS NULL
2009/06/30(火) 14:52:20ID:???そもそもユーザ番号を一意にすれば良いじゃないか。やっぱり設計が大事。
サロゲート廚はまともな設計が出来ないだけじゃ。
0804NAME IS NULL
2009/06/30(火) 14:58:37ID:???0805NAME IS NULL
2009/06/30(火) 15:00:59ID:???なにを騒いでるんだか。
0806NAME IS NULL
2009/06/30(火) 15:04:09ID:???「うちの業務は電話番号で検索できればいいから、変な契約番号なんてつくりたくないんですけど。弊社の業務分析はちゃんとできてます？」
「電話番号は変更されることもある？そんな事わかってますよ。とにかく電話番号で検索できることが重要なんです！」
0807NAME IS NULL
2009/06/30(火) 15:09:09ID:???つうかBもサロゲートということにしないとサロゲート派の立つ瀬がないな（笑
0808NAME IS NULL
2009/06/30(火) 15:16:35ID:???0809NAME IS NULL
2009/06/30(火) 15:19:14ID:???なるほどかみ合わないわけだ。
0810NAME IS NULL
2009/06/30(火) 16:08:07ID:???>つうかBもサロゲートということにしないと
普通にサロゲートキーじゃん
0811808
2009/06/30(火) 17:40:06ID:???0812NAME IS NULL
2009/06/30(火) 17:45:16ID:???0813NAME IS NULL
2009/06/30(火) 18:24:30ID:???0814NAME IS NULL
2009/06/30(火) 20:40:18ID:???サロゲートだなんだ言う前に、
>世帯単位なので電話番号をそのままユーザー番号として使っている。
これが適切なのかどうかはっきりさせてから設計に入るべきだね。
で、一旦これが適切だ=世帯と電話番号の関係性に変更はない、という
判断がされたのだったら、それ以降電話番号の変更の可能性を考える
必要はないわけだし。
0815NAME IS NULL
2009/06/30(火) 22:16:46ID:???> 電話を使った会員サービス、世帯単位なので電話番号をそのままユーザー番号として使っている。
> こういう業務を想定した上で、これをシステム化する。
はっきり｢想定した上で、これをシステム化する｣と書いてますから、ここでは既に｢はっきりさせて｣あると思うのですが...まだ足りないと言うことでしょうか？
0816NAME IS NULL
2009/06/30(火) 22:55:12ID:???業務ルールとかも詳しく見てみると、人が判断してるからなんとか
回っているけどシステム的には全然つながらない、なんてのが
あったりするしね。
0817NAME IS NULL
2009/06/30(火) 22:55:46ID:???んで、実装はB〜Dのどれかに落ち着きそう。
電話番号が変わったときに過去履歴を見るのに別にキーがあると便利そう。
もちろん顧客に電話番号以外にキーを持たせることによるメリット等を説明した上でね。
ちなみにアンチサロゲの人から言わせると俺はサロゲ厨ｗ
0818NAME IS NULL
2009/06/30(火) 23:00:52ID:???774 名前：NAME IS NULL[sage] 投稿日：2009/06/28(日) 22:52:35 ID:???
>>755
>アンチってのはいないだろ。
>「必要かどうかを判断すべき派（中立派）」と「何が何でも使え派（サロ厨）」がいるだけで
何が何でも使え派ってどれ？
あなたが総合失調症の人ですか？
775 名前：NAME IS NULL[sage] 投稿日：2009/06/28(日) 23:00:02 ID:???
>>774
ん？君も「状況を判断して使うかどうか決めるべき」って考え？
0819NAME IS NULL
2009/06/30(火) 23:05:02ID:???？？？
0820NAME IS NULL
2009/06/30(火) 23:06:37ID:???それを前提に話すのがおかしい
0821NAME IS NULL
2009/07/01(水) 00:11:48ID:???今日も来たんですか。ご苦労様です。
0822NAME IS NULL
2009/07/01(水) 00:14:48ID:???君の「都合が悪いレスは見えないフリ」を隠そうともしない姿勢は凄いね。
0823NAME IS NULL
2009/07/01(水) 00:22:25ID:???おれは何が何でも使え派と言ってもいいかもな。
「何が何でも」というのは語弊があるが。
自然キーを主キーにしてOKといえるケースの少なさ。
人工キー導入コストと主キーの変更コストの比較
設計ルールの単純化のメリット
これらをしっかり理解できれば、作業としては人工キー一択で良いと思う。
0824NAME IS NULL
2009/07/01(水) 00:23:11ID:???もういいじゃん。
そいつマジ病気なんだから。
0825NAME IS NULL
2009/07/01(水) 00:25:06ID:???だからさ、専スレ立てるかって言ってんだろうがよ。
単なる煽りか？もっと賑やかなところでやれよ。
0826NAME IS NULL
2009/07/01(水) 00:26:15ID:???0827NAME IS NULL
2009/07/01(水) 00:27:39ID:???これか、「リレーションはテーブルのことだよ論争」しか話題がないじゃんw
0828NAME IS NULL
2009/07/01(水) 00:33:31ID:???0829NAME IS NULL
2009/07/01(水) 00:36:13ID:???スレが止まってもいいからその話題以外にしましょう。
0830NAME IS NULL
2009/07/01(水) 00:43:32ID:???レスがあるだけ今のほうがいいか、と聞かれると明らかにNo
0831NAME IS NULL
2009/07/01(水) 05:27:29ID:???製品番号で検索出来ないのは設計が悪いぞ。
0832NAME IS NULL
2009/07/01(水) 05:40:06ID:???それはDB設計が悪いんじゃなくてアプリの設計が悪いんだろが
製品番号で検索したらパフォーマンスが出ないってなら別だが
0833NAME IS NULL
2009/07/01(水) 07:44:06ID:???話題を変えるつもりはなかったのだと思うけど、
今を思えば>>685 が慧眼だったな。
で、製品番号のテーマではA対BCDということで行くの？
0834NAME IS NULL
2009/07/01(水) 09:31:17ID:???>製品番号で検索出来ないのは設計が悪いぞ。
これがずっと気になってたんだが
>>607の「製品コードが無い分の納品書は製品コードで検索できない」
を曲解してるのか...。
なんという読解力（どっかいりょく）のなさ。
主キー（しゅきー）がどうのこうの言（い）う遥（はる）か以前（いぜん）の段階（だんかい）ですね
0835NAME IS NULL
2009/07/01(水) 10:19:27ID:???設計ミスだな。
0836NAME IS NULL
2009/07/01(水) 11:29:11ID:???キックオフまでにつぎ込めるリソースも限られた中で、全て洗い出すなんてのは前時代的な根性論か理想論か。
「全て盛り込め」という無責任な号令のもと、巨大な体を持て余して潰れていった数々のプロジェクトの屍を乗り越えて、銀の弾丸ではないものの、よりよい手法を模索していかなければならない。
0837NAME IS NULL
2009/07/01(水) 14:07:28ID:???製品コードが変わるかどうかでマスタメンテ画面だって変わるし
マスタに紐づく諸テーブルは製品コードを表示するために（製品コードをキーとしないなら）親からとって来なければならない。
プロジェクト全体に関わる問題。
結局のところ、「製品コードは不変としてつくるか可変としてつくるか」の合意を得なきゃ前に進めない。
「変わるかもしれないからサロゲートキーにしました」は何の解決にもなっていない。
客に何を聞いても「全ての可能性を考慮してつくってください」しか言われずそれを受け入れ、
>>836が言うような対応をするのでなければね。
0838NAME IS NULL
2009/07/01(水) 14:14:33ID:???制約というものを知らないのかな？
マスタメンテ画面で何の項目を保守可能にするのかってのは別問題だし
通常、リソース系のテーブルは名称やら金額やらを取得するためにリンクするものだし
なにがネックで騒いでるのかよくわからん
0839NAME IS NULL
2009/07/01(水) 14:16:48ID:???>結局のところ、「製品コードは不変としてつくるか可変としてつくるか」の合意を得なきゃ前に進めない。
これはまさにその通り。しかしその合意というのがどこまで有効か。
どうにもならない政治的なこともよくあるからな。
本当に合意を出来るなら「人工キーは無駄」というのに賛同できないわけではない。
あと、 親から取ってこなくても製品コードが表示できる、というのは非正規化に過ぎない。
0840NAME IS NULL
2009/07/01(水) 14:19:15ID:???勝手に条件を限定して「何の問題も無し」てのは君の悪い癖だよ。
0841NAME IS NULL
2009/07/01(水) 14:20:43ID:???こいつ要件定義やったことねーな
的な匂いがしてねｗ
0842NAME IS NULL
2009/07/01(水) 14:22:44ID:???0843NAME IS NULL
2009/07/01(水) 14:26:22ID:???何か適当に作って、後から製品名とコード付けるのが普通。
単に現場知らずに設計してるだけ。現場知らないのに現場のシステム設計出来る訳が無い。
サロゲート付ければ良いってのは、現場知らなくても何とかなるって良い訳。
0844NAME IS NULL
2009/07/01(水) 14:33:44ID:???>そもそも業務でいちいち製品コード決めたりしないだろ。
え？
>何か適当に作って、後から製品名とコード付けるのが普通。
じゃあDBの主キーは全部人工キーでいいじゃんw
0845NAME IS NULL
2009/07/01(水) 14:37:01ID:???サロゲートをどうするか以前に、DB設計は業務を知らなきゃできっこないんだから。
0846NAME IS NULL
2009/07/01(水) 18:53:22ID:???サロゲートキーは、少なくともあるキーを代替していないとサロゲートキーと言えない。
Aは、電話番号が主キーということだけなので、何かを代替(サロゲート)するということは当然出てこない。
Bは、電話番号(候補キー)の代替(サロゲート)としてのユニークな連番(ID)をつける、と言えるから、
ユニークな連番(ID)はサロゲートキーと言える。ユーザーが使うとか管理番号に使うとかは関係ない。
Cは、電話番号はキーではないので、ユニークな連番(ID)が電話番号を代替しているとは言えないので、
ユニークな連番(ID)はサロゲートキーと言えない。
Dは、電話番号(候補キー)の代替(サロゲート)としてのユニークな連番(ID)をつける、と言えるから、
ユニークな連番(ID)はサロゲートキーと言える。(BとDは同じこと)
しかし、サロゲートキーが、必ずユニークな連番(ID)という人工キー
でなくてはならないかというと、そこまではサロゲートキーという意味に含まれていない。
こんなんで、どう。
0847NAME IS NULL
2009/07/01(水) 19:06:24ID:???0848NAME IS NULL
2009/07/01(水) 19:57:29ID:???0849NAME IS NULL
2009/07/01(水) 21:13:25ID:???そういうのを本当に汎用的にやろうとすると結局、市販の「いわゆる『アプリケーション』」と
変わらないものになっちゃうんだよな。
普通の設計の感覚で見るとゲロ吐きそうな代物だ。
0850NAME IS NULL
2009/07/01(水) 21:29:50ID:???汎用的なんて後付け条件つけて勝手に批判した気になってんじゃねーよｗｗ
0851NAME IS NULL
2009/07/01(水) 21:41:31ID:???なんでオマエが批判された気になってんだw
SAPの中の人とかかい？
0852NAME IS NULL
2009/07/01(水) 22:00:58ID:???0853NAME IS NULL
2009/07/01(水) 22:02:12ID:???気づいてないのかもしれないが、君1人対全員だよ？ｗ
0854NAME IS NULL
2009/07/01(水) 22:03:54ID:???君何度もいわれてるけどホントに病気だから
0855NAME IS NULL
2009/07/01(水) 22:10:07ID:???SAPまで持ち出して、サロゲ厨は汎用厨攻撃ですかぁ。
大変ですねぇ。
0856NAME IS NULL
2009/07/02(木) 00:40:37ID:???0857NAME IS NULL
2009/07/02(木) 00:50:44ID:???代替キー（サロゲートキー）は主キーたる自然キーが存在しない、あるいは複合キーとなって扱いにくい場合に、別途人工的に作成するキー
代理キーは一意になる候補キーの内、主キーに選ばれなかったもの
ただし、サロゲートキーのことを代理キーと呼ぶこともある
0858NAME IS NULL
2009/07/02(木) 01:04:01ID:???0859NAME IS NULL
2009/07/02(木) 06:24:43ID:???0860NAME IS NULL
2009/07/02(木) 06:33:08ID:???本当におかしい人なのかな。
0861NAME IS NULL
2009/07/02(木) 09:12:30ID:???あんたの一人勝ちだよ
0862NAME IS NULL
2009/07/02(木) 13:37:04ID:???0863NAME IS NULL
2009/07/02(木) 13:49:08ID:???0865NAME IS NULL
2009/07/02(木) 14:15:19ID:???0866NAME IS NULL
2009/07/02(木) 16:05:31ID:8NCxXA01例えば
・お店が一つの業種を選択できる
・一つ業種は色々なお店に選択される
このような時
お店：業種
は
一対多
というのか
多対一
どちらなのでしょうか？
0867NAME IS NULL
2009/07/02(木) 16:10:49ID:???業種１：お店多
0868NAME IS NULL
2009/07/02(木) 23:22:10ID:???なごんだ
0869NAME IS NULL
2009/07/02(木) 23:26:58ID:???「お店が一つの業種のみ選択できる」ならば多（店）対一（業種）
0870NAME IS NULL
2009/07/03(金) 01:13:00ID:???0871NAME IS NULL
2009/07/03(金) 07:43:59ID:???b. デパートが、無料梱包サービスと配送サービスを行う事
c. スーパーが、食料品と雑貨を販売している事
質問の「業種」が a の意ではなくて b や c のような意？
a だとすると、お店というよりは会社なのかな。
＃｢お店｣と「複数業種｣がなんかうまく釣り合いが取れなかっただけ
0872NAME IS NULL
2009/07/03(金) 08:02:17ID:???何を言っているんだ？
0874俺も質問の意図を把握するのに時間かかった……
2009/07/04(土) 20:58:57ID:???たぶん >>866 が言いたかったことは、a, b, c のどれでもないと思う。
そんな難しく考えなくても、普通に“お店テーブル”と“業種マスタ”の関係を
どう言い表せばいいのー？みたいな話かと。
「“お店テーブル” のデータ１件（つまり１つの店舗）につき、そのお店の業種を表す情報を１つだけ持つ
（つまり、１つのお店が複数業種を掛け持ちするようなケースは設計上想定していない）」ような場合、
なんて言えばいいの？って質問では？
答えは >>867、>>869 だよね。
0875NAME IS NULL
2009/07/04(土) 21:08:44ID:???聞きたかったのは概念的な話だろう。
例え話の前提条件に異を唱えてもしょうがない。
0876NAME IS NULL
2009/07/04(土) 22:06:11ID:???１対多や多対１の結合っていったときに
どっちが多でどっちが１か聞きたかっただけだろ
0877NAME IS NULL
2009/07/04(土) 22:09:02ID:???「いやだから」とか言われても
0878874
2009/07/04(土) 22:48:47ID:???理解しあぐねてるように見えたから、差し出がましく
「こういう質問がしたかったんでは？」って >>866宛に解説してみただけっス。
もうクローズした話題なんで、適当に流してくだしあ。すんません。
0879NAME IS NULL
2009/07/05(日) 19:29:44ID:???要件定義で漏れが有ると、現場で使えないシステムが出来上がるぞ。
0880NAME IS NULL
2009/07/05(日) 19:33:07ID:???0881NAME IS NULL
2009/07/05(日) 20:51:14ID:???0882NAME IS NULL
2009/07/05(日) 20:55:12ID:???露骨杉
0883871
2009/07/05(日) 22:55:19ID:???なんか、つまらない思いさせてしまった様で申し訳ないです。
＃おかげで｢例えば｣のかかる範囲がわかりました。
この｢例えば○○の様に｣と言われた場合、「○○」は質問する方・される方で既存の共通する認識がある実例が来る場合と、
今回の様な場合があるので...
私の読解力が足りないんです。本当に申し訳ない。
0884NAME IS NULL
2009/07/06(月) 09:22:33ID:???>要件定義で漏れが有ると、現場で使えないシステムが出来上がるぞ。
うわぁ・・・まだそんなところに居る人居るんだ
0885NAME IS NULL
2009/07/08(水) 00:18:17ID:???0886NAME IS NULL
2009/07/08(水) 16:33:43ID:???１０個以下程度の項目で、かつ項目が追加・編集される可能性のある
種別が沢山ある場合の設計は、どのようにすれば良いのでしょうか？
そのまま、下記のように記録するのは良くないとは思いますが
名前 部署 コース
------------------------
鈴木 開発部 Ａコース
佐藤 開発部 Ｂコース(特)
田中 製作部 Ｂコース(特)
それぞれ別テーブルを作るべきなのでしょうか？
名前 部署ID コースID
-----------
鈴木 1 1
佐藤 1 3
田中 2 3
ID 部署
-------
1 開発部
2 製作部
3 経理部
ID コース
-------
1 Ａコース
2 Ｂコース
3 Ｂコース(特)
それとも、項目テーブルとして１つにまとめても良いものなのでしょうか？
名前 部署ID コースID
-----------
鈴木 1 4
佐藤 1 6
田中 2 6
ID 項目
-------
1 開発部
2 製作部
3 経理部
4 Ａコース
5 Ｂコース
6 Ｂコース(特)
上記のような項目が３０個位あるので、項目毎にテーブルを作るべきか迷っています。
DB設計初心者で、プロ(仕事)では無いので、聞く人がいなくて困っています。
どなたか助言をよろしくおねがいします。
0887NAME IS NULL
2009/07/08(水) 16:44:11ID:???0888NAME IS NULL
2009/07/08(水) 17:16:34ID:???0889NAME IS NULL
2009/07/08(水) 20:01:38ID:???どんな用途で使おうと思ってる？
それでテーブルの設計は大きく変わると思う。
0890NAME IS NULL
2009/07/08(水) 21:29:18ID:???0891NAME IS NULL
2009/07/08(水) 21:49:13ID:???そういうのありますよね。
客も実物に触れて運用してみないとわからないというのがある。
0892NAME IS NULL
2009/07/09(木) 01:24:51ID:???データベース構築の本は数冊読みましたが、大体が>>886の場合だと
部署やコース毎に項目テーブルを作るようになっています。
>>888
項目と項目の関連性はありません。
>>889
例えば、windowsの画面設定では以下のような項目がありますが
テーマ:テーマ
デスクトップ:背景/表示位置
スクリーンセーバー:スクリーンセーバー
デザイン:ウィンドウとボタン/配色/フォントサイズ
設定:ディスプレイ/画面の色
これをユーザ毎のデータをテーブルに格納する場合
ユーザID テーマ 背景 … 画面の色
-------------------------------------
suzuki WindowsXP さざなみ … 32ビット
tanaka Windowsｸﾗｯｼｯｸ なし … 16ビット
となると思いますが、この時に項目毎にテーブルを作るべきか
項目テーブルみたいなのを作って、まとめるか迷っています。
>>890
そうですか。では、windowsの画面設定等ではテーマならテーマの
項目テーブル。デスクトップ背景であれば背景の項目テーブルを
作った方が良いという事ですか？
0893NAME IS NULL
2009/07/09(木) 08:34:42ID:???0894NAME IS NULL
2009/07/09(木) 08:51:15ID:???具体的な要件は、かなり特殊なので、ここに書くと
かなり長くなってしまいそうです。
>>892に例えたWindowsの画面設定にかなり近いです。
0895NAME IS NULL
2009/07/09(木) 09:42:20ID:???名前 項目ID
-----------
鈴木 1
鈴木 4
佐藤 1
佐藤 6
田中 2
田中 6
こういう手もあるかと。
でも、このテーブルを使ってどういう検索をかけるか判らないと何とも言えない。
0896NAME IS NULL
2009/07/10(金) 01:59:32ID:???0897NAME IS NULL
2009/07/10(金) 22:29:18ID:???業務を理解してなかったコボラーのファイル設計がつぎはぎだらけで
グダグダなデータベースをリプレースしろって言われた俺結構
がんばって再構築してるけど、サロゲートキーは救いの神。
0898NAME IS NULL
2009/07/10(金) 22:30:14ID:???アンチが沸くからそこでストップな。
0899NAME IS NULL
2009/07/10(金) 22:34:07ID:???0900NAME IS NULL
2009/07/11(土) 04:25:10ID:???0901NAME IS NULL
2009/07/11(土) 04:28:10ID:???テーブルをどうするとかよりXMLとか使った方がいい気がする
0902NAME IS NULL
2009/07/11(土) 05:10:01ID:???0903NAME IS NULL
2009/07/11(土) 09:50:07ID:???なんかデータベース覚えたての厨房がムリにRDBMS使いたい病にかかっている様に感じるが。
0904NAME IS NULL
2009/07/11(土) 10:18:29ID:???結局サロゲ前提の設計から抜けれない罠。
いきなりRDBじゃないと出来ない様な案件に取り組んでも失敗確実とは思う。
エクセルやアクセスで十分な程度もRDBで設計してみて、徐々にステップアップしていくのが基本かと。
0905NAME IS NULL
2009/07/11(土) 10:48:44ID:???言われたら、Excelで作ってみて無理を感じたらAccessで作り、
Accessで無理を感じたら、SQLite3(+Python)でいいんじゃね。
そういうので要件を上手く設計に落とし込めるようになってから、
Derbyとかに手を出せばいいと思うけど。
時々、目的や規模を含めてそういのを判断できずに盲目的に
「この案件Oracle使います」とかヌカすヤツがいるからなぁ。
って漏れの組織のログ収集システムがそんな感じだ。
なぜにこんな要件でOracleと言うかRDBMSを使う必要があるのかサッパリ理解不能だ。ｗ
0906NAME IS NULL
2009/07/11(土) 21:38:21ID:???Log Perserでいいだろｗ
0907NAME IS NULL
2009/07/11(土) 23:09:25ID:???0908NAME IS NULL
2009/07/11(土) 23:56:21ID:???0909NAME IS NULL
2009/07/12(日) 06:44:16ID:???漏れはやらないけど。ｗ
AccessとSQLiteとどっちがマシか？って話だと後者かな。
Accessだとそれこそ病気の様なリレーション組んだりしている素人見るし。
0910NAME IS NULL
2009/07/12(日) 09:49:03ID:???たしか、そのログのテーブル設計がこんなカンジだった希ガス。
日付：number
ログテキスト：vahchar(256)
で、カンマの無いcsvファイル(?)をちょい加工してインポートすると言う仕組みだった。
CLOBでいいんじゃないか？とかログの読み出し順が保障されてないとか
ツッコミどころ満載だったなぁ。
まあ一度も過去ログを見た事ないので問題になっていないだろうし、
それで多くの人が満足しているなら、それはそれでいい設計なのだろう。
0911NAME IS NULL
2009/07/12(日) 13:50:46ID:???なおさらoracle使う必要がねえな。
vbsで十分。
0912NAME IS NULL
2009/07/12(日) 15:33:29ID:???どうせ行き着く所はオラクル。
スキル評価でも、エクセルやアクセス使えますよりも、オラクル使えますのほうが待遇よかったり。
がんばれば簡単に出来る事でも、評価されない事は自分の評価を下げるだけ。
0913NAME IS NULL
2009/07/12(日) 15:39:02ID:???0914NAME IS NULL
2009/07/12(日) 17:41:31ID:???あんな重いもんこんな用途に使うには適してない。
0915NAME IS NULL
2009/07/12(日) 20:48:40ID:???ベンダーとしては評価があがるのかもしれんけどな・・・。
Oracleみたいなソフトを一度導入してしまうとサポートやらの保守とかで
かなり美味しい商売が展開できるし、「Oracle入れているなら次はコレも」
とか営業が夢語りやすいからなぁ。
社員として優秀と、エンジニアとして優秀は違うよな。
社内SEの人はベンダーがOracleって単語使い出したら気をつけろよ。ｗ
0916NAME IS NULL
2009/07/12(日) 20:51:39ID:???0917NAME IS NULL
2009/07/12(日) 21:07:52ID:???馬鹿いうのもいい加減にしろ。
システムを構築する上でひとつの要素でしかない。
oracleでしかできないことなんてほとんどない。
サポート？保守？そんな金のかかるシステムしか構築できんのか？
って言ってくれる客がいてもいいはずだ。
0918NAME IS NULL
2009/07/12(日) 21:42:19ID:???と言ってみたいテストｗ
0919NAME IS NULL
2009/07/13(月) 23:05:32ID:???「○×のバグです。」「△□の機能では無理です。」
これで逃げられることがどれだけありがたいことか・・・
0920NAME IS NULL
2009/07/13(月) 23:31:20ID:???逃げ口上で使っているならそれこそ無能の証明だろうに。
0921NAME IS NULL
2009/07/13(月) 23:35:30ID:???0922NAME IS NULL
2009/07/13(月) 23:43:07ID:???ような気はするけどね。「なんでそんなもの選んだ」と。
0923NAME IS NULL
2009/07/14(火) 00:15:21ID:???むしろ、高機能なOracleとかにシフトして障害発生とかあったりするし。
たとえば、Oracleやジャーナルログの辺りの設定ミスして
トランザクションの途中でコケたりリカバリ失敗するのと、
最初からそういう概念のないシンプルなフリーDBMSやらDB2の方が
マトモに動いていた、とか。
0924NAME IS NULL
2009/07/14(火) 00:22:18ID:???まだまだあるよ。
不採用の理由は？「タダだから」
真顔で言うんだぜ？
つーかさ、2行目以降は馬鹿なだけだろ、そういう奴は逆でもやらかす。
0925NAME IS NULL
2009/07/14(火) 06:32:38ID:???Javaが全否定ですか。
そーですか。
#別に金はらいたければ払えるけどな。
0926NAME IS NULL
2009/07/14(火) 07:04:58ID:???apacheやbindも
0927NAME IS NULL
2009/07/14(火) 07:08:28ID:???0928NAME IS NULL
2009/07/14(火) 07:12:31ID:???そういう個別の問題はまた別の話だと思うが、もしそのトラブルが責任問題に
発展するとしたら、今度は「なんでちゃんとしたところに頼まなかった」とくる
可能性はありそうやね。
0929NAME IS NULL
2009/07/14(火) 14:03:13ID:???個人情報を入れるテーブル名は personal。
学校は中学、高校、大学、大学院を格納するのに
テーブルに personal.school1 〜 personal.school4 を作るのではなく、
school テーブルを用意したほうがいいですよね？
school.personal_id と personal.school_id で JOIN させるような。
住所や電話番号、メールアドレスも複数、といっても最大 2 か 3 ですが、
これも正規化してテーブルを作るべきでしょうか？
0930NAME IS NULL
2009/07/14(火) 15:45:05ID:???個人的には両方無駄だと思う。
schoolテーブルにしていいのか、collegeとかhighschoolとかいうテーブルまで作るのか、
そこまでやっても、school側の管理が単に「出てくるだけ」なら意味がほとんどない。
メールアドレスも電話番号もたくさん持っている人に対応するためには必要な話かもしれないけど、
上限が概ね見えているならちょっとの予備だけでいいように思う。
と、思った。
0931NAME IS NULL
2009/07/14(火) 16:06:06ID:???なるほど。ありがとうございます。
単に書いて読んで、くらいですｗ
一つのテーブルに
email1
email2
tel1
tel2
address1
address2
school_name1
school_name2
school_name3
school_name4
という末尾に数字の付くカラムが多いので、
正規化するべきなのかな、と疑問に思ったのです。
現在は「中学、高校、大学、大学院」ですが、
そのうち大学院後の MBA や、大学院を複数回る人がいると
school_name5, school_name6 と増える可能性とか。
でも、school_name10 までいくことはないし、
とりあえず末尾に数字でやりたいと思います。
( プログラム側の CRUD 処理は一番楽ですし )
いやいや、こうだろ、というのがありましたら大歓迎ですｗ
0932NAME IS NULL
2009/07/14(火) 19:24:44ID:???0933NAME IS NULL
2009/07/14(火) 20:08:52ID:???オープンソース使うと、無料で作れば良いだろうで無茶な仕様になりやすいけどな。ジャーナル機能みたいなの作ってとか、トランザクション機能も付けてとか。
オラクルとか商用ソフト使ってる分には、カスタマイズに成るのでお金が掛かりますで解決出来る。
javaはjavaそのものにはお金払ってる意識は無い。
Cやbasicやcobolに金払ってないのと同じ。有用なライブラリやフレームワークにお金出して、ちゃんと機能が使える担保を取ってるイメージ。
金無いなら、自分で全部ヤルしか無いけど、それは大変だろ。DBソフトを作るスキルは無くても、DBを作れて使いこなせれば十分。
0934NAME IS NULL
2009/07/14(火) 21:11:37ID:???テーブルの具体的な使用方法やら想定件数やら求められるパフォーマンスやらがわからないと。
聞かれてもこちらには何も判断基準が無い。
0935NAME IS NULL
2009/07/14(火) 21:11:45ID:???まずサポートしているが･･･。
と言うかそれがなきゃデータベースは名乗れないだろう。
つか本当にOracleやらPostgresやらDB2とか使ったことあるのか？
あとzやiだとCやCOBOLは普通に金かかる。
iで金がかからんのはSQLくらいだ。
0936NAME IS NULL
2009/07/14(火) 21:17:40ID:???その際ある人は「ICU」ある人は「国際基督教大学」とか表記がバラバラでかまわないのか、とか。
0937NAME IS NULL
2009/07/14(火) 22:50:48ID:???学校名の変更があったときにどうすんの？とかね。
過去の卒業生も今の校名で出ちゃだめなら、マスタには日付が必要になるし。
だから「要件次第」としかｗ
0938NAME IS NULL
2009/07/15(水) 08:58:02ID:???テーブル数大小300以上、プライマリキーは全部ナンバリング。列名は英語の略語なのかローマ字の略なのか…何を示してるのかサッパリわからん。
テキストのメモ書き程度の説明書わたされたが既に実DBと合わない。
このDBをとりあえず自分が把握して、次の担当者にも優しい仕様にするにはどうしたらいい？
途方に暮れてる…
0939NAME IS NULL
2009/07/15(水) 09:36:49ID:???> 次の担当者にも優しい仕様にするにはどうしたらいい？
逃げ出そうってのかい？ｗ
0940NAME IS NULL
2009/07/15(水) 09:41:49ID:???きちんとした引継ぎを行わなかったのがいけない。
前任者を捕まえてきて、まっとうな仕様書を書いてもらう。Q&Aも行う。
前任者を捕まえることができなかったら、引き継いだ人間と上司に事情を説明して、
DB解析のための十分な工数をもらう。
0941NAME IS NULL
2009/07/15(水) 13:37:39ID:???上司／決裁者に、現状を報告しておくのは悪くない。つーかにちゃんで相談よりもまずそっちだな。
指示が有ればその通りに動けば良いし、指示が無ければ、自分の遣りたいように提案して承認貰って動けば良い。
これから汗水垂らして綺麗にするdbをむざむざ次の担当者に譲ってやる事も無いと思うが。
前任者に習って、自分で仕様を抱え込んで飯にありついておくのが吉。多分そういうのが許される組織だろうし。
0942NAME IS NULL
2009/07/15(水) 20:18:19ID:???汗水垂らすのが嫌
0943NAME IS NULL
2009/07/16(木) 04:08:24ID:???なんでjavaなんて糞重いの使うの？
0944NAME IS NULL
2009/07/16(木) 06:38:49ID:???後はWindowsプラットフォームに動かす事にそんなに拘りないからじゃね。
0945NAME IS NULL
2009/07/16(木) 07:16:10ID:???0946NAME IS NULL
2009/07/16(木) 08:29:27ID:???0947NAME IS NULL
2009/07/16(木) 10:00:19ID:???時代はクアッド3GHzなのに。
エクリプスもJデベロパも殺人的に重いけどみんな使ってる。
0948938
2009/07/16(木) 19:01:45ID:???日付データ全部8桁のナンバで管理してる上に…20070735ってなんじゃこりゃあああ？！
0949NAME IS NULL
2009/07/16(木) 20:37:33ID:???起動時間は掛かるけど、起動してしまえばどうってことないな。
メモリは2Gはないと苦しいけど、CPUは1.5GHz〜（Pen4なら3GHz）あれば十分では？
0950NAME IS NULL
2009/07/16(木) 20:54:52ID:???2007年7月35日だ。わからんのかたわけが。
0951NAME IS NULL
2009/07/17(金) 10:07:40ID:???0952NAME IS NULL
2009/07/17(金) 19:18:13ID:???0953NAME IS NULL
2009/07/20(月) 21:28:05ID:???自分ならまずどのテーブルが活きてるのか見極めるかなあ…。
前任者一人で面倒見てたDBのテーブルが大小300って、それ絶対に半分は使ってないよ。
0954NAME IS NULL
2009/07/20(月) 21:48:52ID:???Hoge、testHoge、testHoge2、testHoge3 ってテーブルがあってtestHoge2のみが生きてた所があった。
0955NAME IS NULL
2009/07/21(火) 02:14:07ID:???俺「ふんふん。…あ、Tってのがあるんですけど」
前「溜め込みのTです。」
俺「(…終わった) そうですか…」
他にもRやNやJなんてのがあった。
Rは履歴、つまりバックアップらしい。
Nはノーマル。ただしノーマルでないものは存在しない。
Jは次期。いつの次期かは知らない。
0956NAME IS NULL
2009/07/21(火) 06:11:33ID:???センスはどうあれ一貫したルールが存在するなら。
0957NAME IS NULL
2009/07/21(火) 22:11:36ID:???カオスすぎるだろｗ
溜め込みのTでくそわろたわ
0958NAME IS NULL
2009/07/22(水) 09:35:49ID:???コボラーとかまともな教育受けてない香具師がまともな設計出来る訳無いじゃん。
0959NAME IS NULL
2009/07/22(水) 13:41:37ID:???0960NAME IS NULL
2009/07/23(木) 03:13:05ID:???0961NAME IS NULL
2009/07/23(木) 07:03:06ID:???仕様書も設計書もなく、複数の人間が複数回触り続けて全容が誰にもわからない、そんな糞システムを引継ぎもなく渡されたことないだろ？お気楽なコメントしてんなよｗ
0962NAME IS NULL
2009/07/23(木) 07:12:49ID:???0963NAME IS NULL
2009/07/23(木) 09:03:13ID:???ﾜﾛﾀ
0964NAME IS NULL
2009/07/23(木) 13:13:32ID:???0965NAME IS NULL
2009/07/23(木) 13:42:29ID:???病気自慢？
0966NAME IS NULL
2009/07/23(木) 13:43:42ID:???0967NAME IS NULL
2009/07/23(木) 17:27:05ID:9uVZvB/4そこでテーブル設計で悩んでいます。
追加/登録は、各マスタのデータ(工程等)をコンボボックス等で選択します。
案1より案2の方が優れていると思うんですが、如何でしょうか？
また案2で重大な欠点がある場合は指摘していただけたらと思います。
■案1
[データテーブル]
・ID(PK),工程ID(数値),作業ID(数値),担当ID(数値),作業日時(文字列),作業時間(文字列)
[マスタ]
・工程ID(PK),工程名,順番,削除FG
･･･その他のマスタ
■案2
[データテーブル]
・ID(PK),工程名(文字列),作業名(文字列),担当名(文字列),作業日時(文字列),作業時間(文字列)
[マスタ]
・工程名(PK),順番
･･･その他のマスタ
===自分が思う利点欠点===
■案1の利点
・重複した名称のマスターデータが持てる。<=意味あるか？
・過去データを含めた名称の変更は、マスターを修正するだけでOK。
・なんとなく連結される部分は文字列型よりも数値型の方がよさそう。
■案1の欠点
・データの表示には全てのマスターと連結したクエリーが必要<=フィールドが多いとめんどい上に遅くなる？
・マスターデータを完全に削除する事は出来ない。
また、過去データを変えずに名称を変える場合は新規にIDを追加する必要がある。
・登録には必ず、マスタにデータを追加する必要がある。
・登録したデータを修正したい場合、既に削除されたマスタがあった場合
コンボボックスにはどのように表示/登録させる？
■案2の利点
・テーブルだけでデータの表示が可能。
・マスタデータを削除する事が出来る。修正時も過去のデータを考慮する必要が無い。
・IDを考慮する必要が無くなる。
・登録するデータに汎用性がある(マスタに無いイレギュラーな登録も可能)。
■案2の欠点
・マスタに同名の項目が作れない。
・データベースの基本としてなんとなくIDを利用したい。なんとなく見栄えが悪い。
・工程名、作業名に利用できる文字が限定される。|\'# とか無理そう。
0968NAME IS NULL
2009/07/23(木) 20:56:31ID:???たとえば「組立て」と「組み立て」が別工程と判定されたら
重大な欠陥といえるかもしれないしそうでないかもしれない
まず要件をしっかり見極めることが大事なんじゃないかね
利点欠点はその要件に対してメリットデメリットを判定しないと意味ないぞ
まああげてる利点欠点も突っ込みどころ満載なんだがｗ
0969NAME IS NULL
2009/07/23(木) 21:20:52ID:???とか言っても「順番」はマスタが持ってるんだけど、マスタに無い登録が可能でいいのか、とか。
外野には見えない「重大な欠陥」は有るかも知れない。
0970NAME IS NULL
2009/07/23(木) 21:33:24ID:???BLOB型使ってバイナリデータも格納しようかどうか迷ってる。
0971967
2009/07/23(木) 21:46:25ID:???>工程や作業をどうやってどこまで管理したいかによるだろう
例えば１0人の担当者が、20工程ある中から1つの工程で、30作業ある中から1つの作業をする。
作業をしたら、担当者(選択)、工程(選択)、作業(選択)、日時、時間を1台のPCへ入力する。
このデータは、後に修正、削除される可能性あり。
また、担当者、工程、作業のマスタの修正は1-3ヶ月に数回程度の頻度で発生する。
後に簡単に集計をしたいので「組立て」と「組み立て」などと同内容の
項目が別の文字で入力されるのは避けたい。
>まああげてる利点欠点も突っ込みどころ満載なんだがｗ
その満載な突っ込みどころを知りたいのだが。
>>969
マスタに無い登録が可能で良いのかどうか。は、確かに悩みどころです。
ただ頻度が極端に低く、担当者、工程、作業の中には期間限定の項目なども考えられるので、
あった方が良いかな？と思っています。
ちなみにマスタの順番は、工程の順番とかではなく、登録時にコンボボックスやリストで表示される順番に
なりますのでデータテーブルには関与しません。分かりづらくて申し訳ないです。
(コンボボックス等では選択しづらいとかは、論点ではないので無視してください。）
0972NAME IS NULL
2009/07/23(木) 22:19:05ID:???かつマスタ側で管理したい項目は1つもない（単にコンボボックスの表示用）てことであれば
案２でいいんじゃないの。
0973NAME IS NULL
2009/07/24(金) 00:28:49ID:???似たような工程が別工程として登録されるのを防ぐなら、工程はマスタ化すべき
突っ込みどころは
>・重複した名称のマスターデータが持てる。<=意味あるか？
案２でも重複した名称で登録はできるが、なぜこれが利点なのだ？
>・なんとなく連結される部分は文字列型よりも数値型の方がよさそう。
なんとなくで利点だって言われても正しいかどうか判断つかんぞ
これにどうメリットがあると考えたんだ？パフォーマンスか？
そもそも示されてる範囲ではこれを文字で連結する要素は見当たらないが
>・マスタデータを削除する事が出来る。修正時も過去のデータを考慮する必要が無い。
そもそもマスタが存在してないが、修正時に過去データを考慮する必要があるかどうかは
要件によるだろ。今まで「組み立て」で登録してたのに、今後「組立て」で登録します
だけどこれは同一の工程です、となったら、過去に「組み立て」で登録してあるデータどうするのさ？
>・マスタに同名の項目が作れない。
そもそもマスタが存在してないが、同名の項目は入力できるだろ
同名だけど別工程だっていうなら、どっちにしろその違いを判定する項目が必要なことには変わらない
>・データベースの基本としてなんとなくIDを利用したい。なんとなく見栄えが悪い。
なんとなくでID使うとか言いだすともめるぞｗ
>・工程名、作業名に利用できる文字が限定される。|\'# とか無理そう。
そんなことはない。つか無理そうってだけで、無理かどうか確認もせずに欠点だって言われてもな
このぐらいでいいか？
0974NAME IS NULL
2009/07/24(金) 02:05:55ID:???かんばん方式的に作業時間短縮を狙うなら、そういうテーブルで管理したほうが素直な気がする。
0975NAME IS NULL
2009/07/24(金) 11:24:30ID:???>>972
マスタ側で、どういう管理が必要になったら案2では駄目になるか
もしポイントがあれば教えていただけますか？
>>973
>>・重複した名称のマスターデータが持てる。<=意味あるか？
>案２でも重複した名称で登録はできるが、なぜこれが利点なのだ？
案2では名称がPKになっている以上、マスタ側では重複した名称では
登録できないと思うのですが･･･。
>今まで「組み立て」で登録してたのに、今後「組立て」で登録します
>だけどこれは同一の工程です、となったら、過去に「組み立て」で登録してあ
>るデータどうするのさ？
その場合は過去の名称に意味を成さないと思いますので
データテーブルを一括置換します。
以下、そもそもマスタが存在していないとは･･･？
工程、作業、担当者 は各テーブルを作成してマスタ化している(と思っている)
のですが･･･。？？
>>974
案2で再利用して困る場合はどんな時がありますかね。
0976NAME IS NULL
2009/07/24(金) 18:13:28ID:???>登録できないと思うのですが･･･。
案２で工程名に対して制約つける気なのか？
もしそうなら、案１と案２は、キーがIDか名称かの違いしかないぞ
登録できるってのは、あくまでデータに対しての話だ
>以下、そもそもマスタが存在していないとは･･･？
存在してないってのはちょっとあれか
マスタが存在しても、マスタに関係なくデータ登録できるなら
マスタとしての意味はなしてないってことだ
0977NAME IS NULL
2009/07/25(土) 03:47:08ID:DT7TRz8B・VIEW上の工程名を一括で変えたいときに面倒。
SQL一撃だがunique indexのカラムが変わるので、multi versioning系でないDMBS
だとほぼテーブルロック的挙動になるぞ。
・工程名があんまり長いとindex leafに乗ってくるのがhash値になったりして
実表アクセスが増えて処理性能的に不利。
・DBMS依存かもしれんが、左表NULL可だとNested Loopで結合できないから
結合時に性能的に不利になる。まあ、トランザクション少なそうではあるが。
0978NAME IS NULL
2009/07/25(土) 07:41:07ID:???おそらくその程度のデータ数なんだろうな。
担当者がシートを開いて見渡せる程度。
0979NAME IS NULL
2009/07/25(土) 14:56:52ID:???工程名を変更した時点で工程マスタを参照しているテーブルのデータを修正しなければ行けない。
案2を捨てる理由はそれだけで十二分。
PKに意味を持たせるのは百害あって一理無し、初心者のうちはそういう太古からの慣習には黙って
従っておいたほうがいいよ。
「意味コード」という物の欠点を、ググルか先輩諸氏に聞いてみて。
0980NAME IS NULL
2009/07/25(土) 14:58:50ID:???テーブル設計において「SQLでこう書くことになるから…」とか「こういうGUIの実装だから…」
などという事は考慮するべきじゃないよ。
0981NAME IS NULL
2009/07/25(土) 19:31:19ID:???GUIはユーザ依存なので要件きちんと把握しろとしか。
0982NAME IS NULL
2009/07/25(土) 22:42:32ID:???正規化して分割すべきテーブルを一つにしたりってのは実際よくあるが
DB設計って本来は性能を考慮するべきじゃないと思うんだがな
それはSQLでもそうであって、性能を考慮してトリッキーなSQL書くべきではないと
まあ、実際はある程度の性能は出さないと使い物にならないんだが
最近のマシンは早いし、オプティマイザも結構賢いので、よっぽど大規模じゃないと
あんまり気にする必要ないかもしれん
0983NAME IS NULL
2009/07/25(土) 22:57:55ID:???やってるとしたら本末転倒もいい所
でも意外にそんな開発現場が多い気がする。
0984NAME IS NULL
2009/07/26(日) 18:00:08ID:???「テーブル設計」なら正しいんじゃね？
「DB設計」の場合アクセスポイント(≒SQL)を意識する必要はあると思うけど。
>>983
んなとこあんのか？
正規化くずしなんぞせんでもインターフェース用意すれば済むだろ。
レス数が950を超えています。1000を超えると書き込みができなくなります。