08/10/08 18:34:13 PQV+Wmyc
引き続き語れ！！
前スレ
DB設計を語るスレ
ｽﾚﾘﾝｸ(db板)
2:NAME IS NULL
08/10/08 18:39:40
ふむ
3:NAME IS NULL
08/10/08 18:41:25
早速質問なのですが、
日付を「昭和60年2月3日」のように和暦で扱うアプリの場合、カラム型は
普通に日付型を使った方がいいでしょうか？
アプリは.NETで作っていて、
元号をコンボボックス、年月日をテキストボックスで選ばせるUIなので、
元号、年、月、日を別カラムで保持すれば楽かなーと思うのですが。
どうでしょう？
4:NAME IS NULL
08/10/08 19:52:25
また落ちたのか。12までいってたから安心してたのに。
この板の即死判定って何レス？
しかしまぁ、はっきりいって需要ないのかも。
5:NAME IS NULL
08/10/08 20:08:27
大坊設計
6:NAME IS NULL
08/10/08 23:14:26
支援ついでに
>>3
日付型を使うべき
7:NAME IS NULL
08/10/08 23:48:08
DB設計ってどうやって勉強してる？
よい書籍とかあったら教えて下さい。
8:NAME IS NULL
08/10/10 14:54:01
文字列が全部固定長・・・
３文字くらいしか入力しないのに、
１００文字の固定長ｗ
理由をたずねたら、
ﾃﾞｰﾀﾍﾞｰｽの構造上、固定長のほうが処理が
パフォーマンスがいいんだよって
ＳＱＬみてみたら
全部のＳＱＬに毎回ＴＲＩＭかけてるしｗ
ＴＲＩＭするなら、最初から可変長にしてくれｗ
9:NAME IS NULL
08/10/10 23:11:15
>>7
ERDレッスンかなあ。
業務ごとの濃い話になると別。
10:NAME IS NULL
08/10/20 14:21:28
Webのシステムでキャッシュっぽいテーブルは固定長レコードになるようにしてる
11:NAME IS NULL
08/10/20 16:38:57
＞ﾃﾞｰﾀﾍﾞｰｽの構造上、固定長のほうが処理が
＞パフォーマンスがいいんだよって
COBOLerの脳内妄想かと。
固定長しか知らん人種だし。
12:NAME IS NULL
08/10/20 19:34:57
完全な固定長のレコードにアドバンテージを設けているRDBMSはMySQLのMyISAMくらいしか知らない。
13:NAME IS NULL
08/10/20 22:34:36
削除・更新が頻繁なテーブルでは、可変長だと行連鎖・行移行が発生
しやすいというのはあるな。
まぁ、ほぼ3文字しか必要ないのに100文字ってのはページ使用効率が
悪くて逆にパフォーマンスを落としそうだが。
14:NAME IS NULL
08/10/21 22:22:08 JfHp8/7P
テーブル設計（論理設計）などの初心者が読むべき本とかありますか？
教えていただけたら幸いです
15:NAME IS NULL
08/10/22 11:05:30
>>14
>>9
16:NAME IS NULL
08/10/24 10:23:09
DB設計は、そのノウハウが書かれている書籍とか結構あるし、
テーブルの正規化はこうだといわれてたりするけれど、
人の作ったDB見てると、それらが必ずしも守られていなかったりしていて、
そのDBを作った人の個性があるように感じる。
誰かが作ったDBを、他の人が見ると、「これはこういう効率の悪さがある」と
設計を批判する事もあるようだが、システムとしては稼動しているし、
使用者にとっては特別致命的なものがあるわけでもなかったりする。
となると、DB設計というのは、これが正しい、これが結論だというものは
無くて、結局はその人の考え方（速度、保守性、拡張性、引継ぎ、などで
何処を重要視するか）の世界みたいなところなのかなと思う。
このスレに来てる人はどう思う？
17:NAME IS NULL
08/10/25 00:53:05 Hv10EAg0
基本的かも知れないけど、質問させてください。
固定長の文字列を格納するのにchar、とvarchar2ではやっぱりcharのほうが速度的に良いの？
今まで行ったたいていの現場では「文字列は固定長・可変長関わらずvarchar2で」っていう感じでした。
理由はいろいろあったんだけど、
・「こっちは固定長だからcharで、あっちは可変長varchaｒ2で」っつーのが単純にわずらわしい
→設計効率重視意見
・「固定長をvarchaｒ2に入れてもcharに入れるのと速度的に大して変わらない。大勢に影響なし」
→性能変わらない意見
・charだと「固定長だと思っていたけど、その後に可変長になった」っていう仕様変更に弱い。
→当初より短い文字列を入れることになった→アプリ側でtrimを入れることに→うざい
→心配だから全部trimを入れた→アプリ開発当初からうざい
という感じで、固定長ならcharを使おうって積極的に押す人はいませんでした。
これまで固定長文字列をvarchar2で扱ってもcharで扱っても速度的に違いを感じたことは無いんだけど、
固定長ならやっぱりcharのほうが良いの？
最大で1万レコードくらいしか扱ったことが無いんだけど、でかいと違うのかね？
18:NAME IS NULL
08/10/25 05:51:16
>>17
DBMSによる。varchar2といってるからOracleなのだろうけど。
19:NAME IS NULL
08/10/26 11:27:45
>>17
制約とかINDEXとかにも関わってくるけど、DB2とかだとCHARの方が速いな。
1万レコードってそりゃExcelでも処理できなくもない処理量だから、
性能変わらないって意見も解る。
そういう現場なら設計効率重視で可変長のみでもいいと思うけど。
個人的にはそういう重要な作業を「わずらわしい」と感じるヤツに設計は
して欲しくないんだが。
20:NAME IS NULL
08/10/27 01:45:28 eNeS7+/+
このスレの人はT字型ERをどう思います？
あれってほんとうに効果あるの？
21:NAME IS NULL
08/11/02 10:48:06
コボルの頃のじり貧ハードなら固定長で速度稼いでってテクも必要だろうけど。
今はハードの圧倒的進化とRACで、ほぼ限界無く欲しい処理能力得られるから可変長でも良いと思うけどね。
どうせミドルのCやJavaの時点でポインタという名の可変長メモリ管理してるから、速度気にしてもしょうがない。
可変長で処理できるほどの潤沢なメモリが無かった時代に使ってたようなコボルのようにどこまでも固定長で処理してる訳じゃないし。
業務だといろいろ小手先の要求が有るから、表記用の文字列と処理用の日付の両方で持ってる。
３２日って入力して月末処理したいだとか。orz
伝票や帳簿には末日って書いてたからシステムでも同じようにやりたいとか。orz
締めのタイミングが、後藤日＋末日だったりするし。日付型で末日とか持てりゃ苦労は無いが。
22:NAME IS NULL
08/11/02 21:39:17
３２日を使いたいから日付に文字列型を使うってのはそもそもの設計がイカれている印象しかないが･･･。
COBOLerがいるならある意味仕方ない感はあるんだが、
そこでCOBOLerのイカれた提案を拒否して、美しい設計を目指すべきだと思うけど。
つか月末（営業）日や五十（営業）日を算出する関数やクラスを定義するだけだろうに。
23:NAME IS NULL
08/11/02 21:49:46 JdZg49uN
アッー！
24:NAME IS NULL
08/11/03 23:29:45
何でも計算させないで、閉め日テーブル作っちゃえばいいじゃん。
1年に何十回もあるわけじゃないしユーザー側で決めさせれば良い。
規則的ではない変な締めがあっても対応出来る。
25:NAME IS NULL
08/11/07 03:23:17 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
とかいう、売価テーブルつくるのも、いくら領域いるんじゃーって感じじゃない？
なんか、いいほうほうないかな？
26:NAME IS NULL
08/11/07 04:15:33
パフォーマンスは別途検討するとして
SELECT
SUM(売上数 * 売価)
FROM
売上数テーブル
JOIN 売価テーブル ON 日付 BETWEEN 開始日 AND 終了日
WHERE
日付 BETWEEN 14 AND 24
価格がどの時点で確定するかというのが重要なので
売上テーブルに売価が必要なこともあるでしょう。
売ったあとに売価テーブルの内容が変わったら大変なことになってしまうし。
27:NAME IS NULL
08/11/07 22:16:08
>>25
人によって好みは分かれるだろうけども、自分なら日毎に持つな。
それと、開始日/終了日の方は終了日を省略して開始日のみにした方がまし。
28:NAME IS NULL
08/11/09 23:12:05 IPd6NExy
ERの記法ってどれが標準なのかね？
やっぱIE？
29:NAME IS NULL
08/11/10 00:30:01
>>25
日付ごとに売値を持ってるほうが、メンテ楽そう。
売価テーブル、売価履歴テーブル、売上数テーブルを作って、
価格改定があったら売価テーブルを更新。一日の〆でその日の
売価テーブルを売価履歴テーブルにバッチでコピー。
で、
select
sum(売上数テーブル.売上数 * 売価履歴テーブル.売価)
from
売上数テーブル
left join 売価履歴テーブル on
売上数テーブル.日付 = 売価履歴テーブル.日付
where
売上数テーブル.日付 between '2008-11-14' and '2008-11-24'
みたいな。
30:NAME IS NULL
08/11/10 08:39:10
>>25
>いくら領域いるんじゃーって感じじゃない？
１年でたった365レコードでしょ？
31:NAME IS NULL
08/11/10 11:00:54
SQLやたら長くなりがちだけど、期間指定でもできないことはない。
32:NAME IS NULL
08/11/10 20:20:30 1PkOr8o/
>>30
一品目なら３６５レコードだけど
これが、数万品目あつかう小売チェーン店とかだったら年、数百万～数千万レコード
これを何に使うのかによるけど、売り上げを算出するってことは前年比とか
数年分の比較に使うんだろうから、その３，４年分
って考えたら、結構な量になるんじゃね？
でも、実際売価が変更されるのは、週一回あればいいとこだろうし
ものによっては数年変えないとかあるだろうに、余計なデータ増やすのは
パフォーマンスからみるとイマイチな設計なきがするなぁ
＞日付 BETWEEN 開始日 AND 終了日
で取れるようにしたほうが、ＤＢサイズ小さくなってキャッシュ利き易くなるし、いいんじゃね？
33:NAME IS NULL
08/11/16 01:56:57
データベース設計にも、デザパタみたいなものあるのかね？
34:NAME IS NULL
08/11/16 03:29:23
こういう業務はこんな感じとかいう本はあるけど
デザパタというよりアナパタに近いよな。
35:NAME IS NULL
08/11/16 04:13:49
>>34
是非、その本を教えてください
お願いします
36:NAME IS NULL
08/11/16 05:39:40
アマゾンで「渡辺幸三」で検索すると何冊か出てくる。
生産管理のはかなりレベル高い。生産管理やった事ないけど
読み応えあって面白かった。
あとは「グラス片手に」シリーズとか。
DBマガジン連載時によく読んでて会社のバックナンバー揃えて貰ったら
とたんに書籍が出おった・・・。
もうちょっと業務から設計よりになると「楽々ERDレッスン」も面白いです。
渡辺氏とは犬猿の仲。でも実装はこっちのが現実的かと俺は思う。
あとは本じゃないけど渡辺氏の公開してる
データモデルはいやーお世話になりました。
URLﾘﾝｸ(homepage2.nifty.com)
37:NAME IS NULL
08/11/16 14:29:38
今ひどい自演を見た
38:NAME IS NULL
08/11/16 14:31:57
このまえ『データベース・リファクタリング』て本買って読んでたけど
結局ケースバイケースで全然逆のこと書いてあったりして、途中で
読むの放棄した。結局ケースバイケースのバランスなんだよ！
39:NAME IS NULL
08/11/16 17:22:43
>>37
ばれちゃーしょうがーねーな
でも本はいい本だから読んでね
40:NAME IS NULL
08/11/16 19:33:51
まぁ、渡辺さんの本が良いってより他にあんまりないんだよな。
羽生さんは大規模システムもちゃんとやってきてる人なのかな？
ABDとか大きいレガシーシステムでどうせいっちゅーんじゃ、みたいな。
業務系は技術系と比べて情報少ないんで、
自分のやってることになかなか自信がもてない。
各社ごとではちゃんとノウハウたまってんのかね？
41:NAME IS NULL
08/11/16 22:20:46
>>40
貯まってたら3Kとか最下層とか言われて無いだろｗ
42:NAME IS NULL
08/11/17 02:58:17
>>40
そうですね・・・他にないってだけかw
だけっていっちゃ悪いか。
業務系、バッドノウハウは立派にたまってましたねぇ。
とくに大手製造業の子会社行った時は恐れ入った。
43:NAME IS NULL
08/11/19 00:11:57
全てのテーブルは主キーをもつべきですか？
44:NAME IS NULL
08/11/19 00:23:52
リレーションテーブルは要らないかも
複合インデックスさえあれば
45:NAME IS NULL
08/11/19 00:38:37
あったほうが楽じゃね。
46:NAME IS NULL
08/11/19 02:49:26
例えばペットショップのＤＢを作るとして
犬テーブルと猫テーブルとかってわける？
動物テーブルでまとめる？
47:46
08/11/19 02:53:38 PDW1LNDk
別の言い方をすれば、
複数のテーブルで一意なIDが欲しくなった時どうする？
48:NAME IS NULL
08/11/19 03:04:51
>>46
動物テーブルで分ける
ＩＤ＋種別（イヌ/ネコ/ハムスター・・）
49:NAME IS NULL
08/11/19 03:07:52
その場合、犬専用フィールドとか猫専用フィールドがあるならどうする？
動物テーブルには犬猫以外にも数十種の動物が含まれる
それぞれが専用フィールドを持っていたら？
50:NAME IS NULL
08/11/19 03:09:43
ヌルだらけの巨大なテーブルが１つなのと
データがみっちり詰まった普通サイズのテーブルが複数なのと
どっちが良いか
後者にした場合、動物全体での一意ＩＤが欲しい場合どうするか？が問題になる
51:NAME IS NULL
08/11/19 03:18:30
テーブルを犬猫で分けて、一意ＩＤ用１対多リレーションテーブルを作る場合
フィールド：一意ID、犬ID、猫ID、、、、
これだと動物の種類の数だけフィールドが必要で、
新しく動物の種類が追加された時にテーブルの追加だけでなく
ここへのフィールド追加もやらなきゃいけない。
テーブル追加だけで済んだ方が良い。
52:NAME IS NULL
08/11/19 03:26:29
色々書いたが
１つの巨大テーブルにするほうが
実用上の障害が思いつかない
誰か思いつく？
53:NAME IS NULL
08/11/19 04:42:21
>>49
ＩＤ＋種別（イヌ/ネコ/ハムスター・・）＋属性
54:NAME IS NULL
08/11/19 10:40:33
１つの巨大テーブルがいい人はExcelでもいいんじゃ？
55:46
08/11/19 16:21:28
>>53
それは属性テーブルを動物別に作って外部キーはるってこと？
結局>>51だと思うけど
今のところの結論としては、
動物テーブルでまとめて、動物別にビューを作るのがいいかなと
56:NAME IS NULL
08/11/19 16:22:53
一意ＩＤ用リレーションテーブル作っても同等の機能は達成できるんだけど
パフォーマンス的に不利だからね
かといってテーブル間の一意ＩＤが欲しいがために１つのテーブルにまとめるってのも
おかしいとは思うけどね
57:46
08/11/19 17:43:56
一応、複数のテーブル間で一意ＩＤを得る方法はあるらしいんだが
単に一意ＩＤを振っても、あるＩＤがどのテーブルのどのレコードなのか
を特定できなきゃいけないからリレーションテーブルは必要なんだよね
そしてパフォーマンスの不利は避けられない
やはり動物テーブル＋ビューが最適と判断した
58:NAME IS NULL
08/11/19 17:52:22
>>55
例えば明日からペットショップでマンモスハナアルキの扱いを
新たにはじめるとして、そんなマイナー動物一種類のために
巨大な動物テーブルのスキーマを変更するのもどうかと。
ID+共通データの動物リレーションと動物別リレーションに分けて
ある場合、ハナアルキ類のためのリレーション一つ作成して後は
幾つかビュー定義をちょこまか修正すれば完了。
既にストアされているデータへの影響は少なくて済むはずです。
59:NAME IS NULL
08/11/19 17:53:20
>>57
下らなすぎてスルーしてたけど
> やはり動物テーブル＋ビューが最適と判断した
最適かどうかは場合によるわな。
NULLだらけの横長テーブルなんて保守したくないし。
パフォーマンスの不利がどれほどのもんかとかな。
60:46
08/11/19 18:13:15
>>58
そういえばテーブルへのフィールド追加って登録されてるレコード数に依存して負荷上がるのか。
でも動物テーブルから動物別テーブルへのリレーションはどうやって張るの？
WEBアプリフレームワークが自動認識してくれるような形で張るには、（つまりRDBの基本仕様上で張るには）
>>51みたいに動物の種類数だけフィールドを用意しないといけないと思うんだけど。
61:46
08/11/19 18:14:08
>>59
明確な答えを持っているなら教えてください。
邪魔がしたいだけならお帰りください。
62:46
08/11/19 18:17:11
動物別テーブル側に動物テーブル上のIDを持たせて
動物別テーブルと動物テーブルを結合したビューを作っておけば良いのかな
その結合処理って高速に出来るのかな？
63:NAME IS NULL
08/11/19 18:17:32
ここはお前の専用スレじゃないんで、私物化するなら出てってくれない？
64:46
08/11/19 18:18:38
>>63
スレに沿った話題であり問題はないと思います。
65:NAME IS NULL
08/11/19 18:29:09
>>60
>でも動物テーブルから動物別テーブルへのリレーションはどうやって張るの？
基本的には>>62の通りで良いのではないかと。
アプリケーションフレームワーク云々は別として、Relational Database Model
に基づいて実装するなら、動物リレーションで各動物に一意な動物IDをキーと
して振って、種類別リレーションからはその動物IDを参照。
後は動物リレーションと各種類別リレーションの間に外部キー制約を定義。
種類別にIDを振っても良いけど、基本的には冗長になるので必要無いはずです。
あとこういう分割は普通に行われているので、実用的な速度で結合処理を実現
する方法についてはちゃんと解が存在しています。
インデックス等々に関して調べると良いのではないかと。
66:46
08/11/19 18:32:26
それで良さそう。
ありがとう。
67:NAME IS NULL
08/11/22 03:29:20
>>44
あれ、もしかしてリレーションテーブルには各外部キーにインデックス張っても
意味ないの？
>>62
DB構築者がビュー作って使う利点ってあるの？
68:NAME IS NULL
08/11/23 02:48:09
>>44は、リレーションテーブルに行われる検索はほとんどの場合
他の２つのテーブルを繋ぐ処理だけだろうって事。
69:NAME IS NULL
08/11/23 02:50:12
ＤＢ構築者がビュー使う利点無かったら誰にあるんだよ
ビューの利点＝プログラムでＳＱＬ書かなくて済む、なんて理解してるんだったら
そんなの定数定義しておけば良いだけだしＤＢにビューなんて機能持たせる意味ないだろ
70:NAME IS NULL
08/11/23 11:32:04
設計レベルでビューは使わないだろうな
ビューは実装寄りの話だ
71:NAME IS NULL
08/11/23 12:07:03
>>68
リレーションテーブルって複合インデックスのほうがいいんでしょうか
72:NAME IS NULL
08/11/23 17:46:01
どんなインデックスもそうだけど、クエリによると思う。
73:NAME IS NULL
08/11/23 21:17:09
ユーザーは複数の権限を持っている事がある
ユーザーは複数の組織に所属している事がある
ユーザーが特定の部門に属しているか、特定の権限を持っている場合ににのみ
特定のテーブルと1:1の関連を持たせる
しかし、権限や部門がが重複すると、そのたびにユーザーが抽出されるので
同じユーザーのデータなのに、複数データが出来てしまう。
こういうとき、どうするのが一般的なんでしょう？
74:NAME IS NULL
08/11/23 21:48:57
とりあえず「組織」と「部門」の関連がよく分からないのですが・・・
DISTINCT一発で解決する問題のようにも見えます。
75:NAME IS NULL
08/11/23 22:12:47
DISTINCT以前にもしかしてリレーションを理解してないんじゃないか
１つのユーザーテーブルに組織も権限も部門も全部つっこもうとしてるんだろ？
76:NAME IS NULL
08/11/23 22:15:37
>>75
元のユーザーTBLがそういう感じなんよ
そこの部分はいじれない状況ということで許してくれ
やっぱり重複排除しかないのかねぇ
77:NAME IS NULL
08/11/23 22:27:58
>>76
>元のユーザーTBLがそういう感じなんよ
もうテーブルが存在するなら、質問するときはそのスキーマの概略
程度でも示さないと。でないと答える方も>>74とか>>75みたいに無駄な
推理に頭を使う事になるでしょう？
78:NAME IS NULL
08/11/23 22:37:37
>>77
すまん
79:NAME IS NULL
08/11/23 22:51:55
リレーション理解してるならそんなの問題が既存のテーブル設計にあるの明らかだし
こういう糞テーブルの保守が必要なんですけど、って話すだろｗ
80:NAME IS NULL
08/11/24 01:31:03
>>76
普通に再設計して既存アプリのインターフェース(元TBL型のVIEW)用意すればいんでね？
81:NAME IS NULL
08/11/24 02:03:02
スレ違いかもしれんが、
郵便番号マスタ、市区町村マスタ、銀行マスタ、法定休日マスタ、和暦マスタ、消費税率マスタ
みたいなマスタテーブルを作ることに疑問を覚えるのは俺だけか？
何故、日本全国共通の情報を各々のDBに持ってちまちまメンテするんだろう？
疑問に思っちゃいけないことなのか？
82:NAME IS NULL
08/11/24 02:11:33
・パフォーマンス
・完全参照系データでしかもそれほど動的に変わるものではないからWebAPIにする価値無し
83:NAME IS NULL
08/11/24 02:45:40
セキュリティ
84:NAME IS NULL
08/11/24 02:59:24
セキュリティが一番大きいね
WebAPIにしたらどこの誰が利用してるか分かる可能性がある
85:NAME IS NULL
08/11/24 09:37:58
切り替えのタイミング
86:NAME IS NULL
08/11/24 10:21:38
>>81
じゃあ、どうしろと？
87:NAME IS NULL
08/11/24 13:27:15
>>81
その中でもファイルとして公開されてる物はある。
でも、提供先が国外だったりしてデータおかしかったりする物もある。
郵便番号なんかはバッチ処理でWebから落としてきて～ってどこでもやってるでしょ。
↑をメンテ処理って言ったらそれまでだけどｗ
88:NAME IS NULL
08/11/24 15:37:55
NTPサービスみたいに、定期的に全自動的でデータが補正されるようにならんものかね。
この手のマスタを毎月（或いは毎年）メンテしてるやつらって、
ホントくだらない人生送ってるな思うよ。
89:NAME IS NULL
08/11/24 15:59:02
つまり、>>88はそんな仕事をやらされている自分の人生にうんざりしているというわけだな。
90:NAME IS NULL
08/11/24 16:09:58
いや、そんな仕事もまともにできない部下にうんざりしてる。
91:NAME IS NULL
08/11/24 16:21:56
全自動でやるシステムを提案すればいいじゃねーか
92:NAME IS NULL
08/11/24 16:22:19
>>85の切り替えのタイミングと、切り替える際の責任の所在かなぁ。
俺様に無断で祝日増やしやがって馬鹿政府のこんちくしょう。
将来なんちゃらクラウドの上にテータベースに乗っけて運用するよう
になると、この手のマスターデータは標準部品として提供されるように
なるのでしょうか。
93:NAME IS NULL
08/11/24 16:42:55
>>90
部下ねぇw
部下のことをくだらない人生送っていると思いながら、その仕事をやらせているわけか。
それが本当なら、そりゃまともにやろうという気がうせるだろう。
94:NAME IS NULL
08/11/24 18:46:07 4T2xxdv4
そういや地方自治体のシステムなんか
国会で法律が変わるたびに各々の自治体で
ベンダーに依頼して改修してるんだよな。
後期高齢者医療制度対応とかさ。
この国はどんだけアホなんだろう？
95:NAME IS NULL
08/11/24 22:59:03
>>94
ＳＩ企業にとっちゃ、仕事が増えるからいいんじゃない。
96:NAME IS NULL
08/11/25 01:12:59
ピラミッド立てるのと一緒でみんな無駄だとわかってても
世の中がまわる為に必要だから止められないんだよ
97:NAME IS NULL
08/11/25 01:28:14
自治体のは無駄だと思うが
住所データとかは各ベンダーが持たないなら国がWebAPI提供するしかないし
今の形が妥当
98:NAME IS NULL
08/11/25 03:17:40
>>94
> 後期高齢者医療制度対応とかさ。
上手に作られたシステムなら、マスターの変更だけでＯｋ。
でも、テストは必要。
結局、ベンダーに発注するしかない。
99:NAME IS NULL
08/11/25 11:32:56 rHJnodNO
全体最適化とかまったく考えず各々価格だけで競争入札するから結果的に無駄に税金がかかる。
道路や建物つくる感覚で発注してるんだろうね。
100:NAME IS NULL
08/11/25 15:22:35
ＤＢ設計を語るスレが制度設計を語るスレになっている件。
101:NAME IS NULL
08/11/25 17:56:35
このスレで聞いていいのかな
商品テーブルにジュース ポテト ハンバーガーって商品があって
この3つを組み合わせでバリューセットって商品を作りたいとすると
商品テーブルのバリューセットの主キーとジュースの主キーを組み合わせるテーブル作ればOKだよね？
102:NAME IS NULL
08/11/25 18:04:20
バリューセットっていう１商品で別に他とつなげる必要があると思えんが
103:NAME IS NULL
08/11/25 18:08:08
そもそも４行目の意味が分からん
お前は同じテーブル内のレコードを繋げるリレーションテーブルを作ろうとしてるのか
別にそれでも実装上の問題はないのか・・・
104:NAME IS NULL
08/11/25 18:18:18
>>102
この商品はこの3つの商品の組み合わせですみたいな感じで
セットの値段とバラの値段を表示したいなと思いまして。
>>103
実装上は大丈夫なんですが、もっといい方法があるかなと思って質問させて貰いました
105:NAME IS NULL
08/11/25 18:58:29
全てのバリューセットが主菜(ハンバーガ)・副菜(ポテト)・ドリンク(ジュース)の
三点セットなら、バリューセットのキーと主菜・副菜・ドリンクのキーの計4つの
キーを含むリレーションを作成。
セットによって副菜が2つになったりドリンク無しだったりと構成要素が大きく
異なる場合はバリューセットのキーと構成要素のキーを含むバイナリ
リレーションで表現。
106:NAME IS NULL
08/11/25 19:17:48
商品テーブル（IDと名前とその他共通属性）
単品テーブル（商品テーブルID＋その他属性）
セットテーブル（商品テーブルID＋その他属性）
単品セット間リレーションテーブル（単品テーブルＩＤ＋セットテーブルＩＤ）
これでセットメニューがどんな構成だろうと対応出来るぞ
バイナリも使う必要ない
107:NAME IS NULL
08/11/25 19:29:56
>>105
>>106
ありがとうございます。
家帰ったらテーブル作ってみて試してみます！
108:NAME IS NULL
08/11/25 19:30:26 Y/2zDRqR
ありゃ、誤解があったようで、
>単品セット間リレーションテーブル（単品テーブルＩＤ＋セットテーブルＩＤ）
これがまさに、バイナリリレーション(binary relation: 二項関係)ですね。
あとこの手のスキーマ設計の場合、
・単品商品とセット商品の共通部分を商品テーブルとして切り出す
・単品テーブルとセットテーブルはそれぞれ共通属性も含めて保持
全商品の共通属性に関しては別途商品ビューを用意して参照
のどちらもアリなので、お好きな方をどうぞ。
109:NAME IS NULL
08/11/25 23:18:29
まさにこんな問題が、テクデの過去問にあったな。
110:NAME IS NULL
08/11/26 00:35:25
バリューセットは難しいね。
原価とか利益をどう持つかで色々な設計のパターンが出てきそうだ
111:NAME IS NULL
08/11/26 15:15:15
リレーションテーブル・・・・難しい言葉ですね・・・
112:NAME IS NULL
08/11/26 15:18:27
正しい言葉だと思うけど、何か意見があるなら聞かせて欲しい。
具体的な指摘をして欲しい。
俺がリレーションテーブルと言う言葉を使うのは、
マスタもテーブルもテーブルなのにおかしいと思うから。
かといってリレーションと言うだけではＦＫなども含まれてしまう。
113:NAME IS NULL
08/11/26 16:16:47
>>112
>>111はなんだか意地悪な感じだね。
「リレーション」というのは「テーブル」の事を指します。
なので「リレーションテーブル」っていうと「犬ドッグ」的な感じになっちゃいます。
RDBの基となる関係代数からの用語ですが。
テーブル：リレーション
レコード：タプル
フィールド：カラム
テーブルとテーブルの関連のことは「リレーションシップ」と呼びます。
114:NAME IS NULL
08/11/26 16:18:20
>>112
>マスタもテーブルもテーブルなのにおかしいと思うから。
>かといってリレーションと言うだけではＦＫなども含まれてしまう。
ってか、この２行の意味が分かんない。
115:NAME IS NULL
08/11/26 16:29:01
>>113
それは文脈によらない？
DBの実装上の用語ではおかしい事は言ってないよ。
URLﾘﾝｸ(pgyougo.seesaa.net)
マスタなのかテーブルなのかを明示したい場合、どういい分ければいいの？
リレーションとリレーションシップで言い分けるより通じる。
116:NAME IS NULL
08/11/26 16:46:11
ついでに
URLﾘﾝｸ(homepage1.nifty.com)
さらに、リレーションシップという言葉がＦＫを含む例は
mysql workbenchがある。
リレーションシップという言葉はＦＫもリレーションテーブルも含んで使われている。
リレーションシップを示す”テーブル”のみを表現する言葉を俺は知らない。
ここで言うテーブルとはRDBMSに対するSQLでcreate tableで作成されるもののみを指す。
関係代数における概念は、実際のRDBMSやその関連ソフトにおいて
「不都合なく実装出来る形」にしか実装されていない。
概念的に忠実に再現されているとは限らない。
マスタ＝基幹データ
（マスタと比較される文脈で出される）テーブル（俺がリレーションテーブルと呼ぶもの）＝マスタ間のリレーションシップを示したテーブル
テーブル＝マスタとリレーションテーブルを含んだもの（SQLでcreate tableで生成するもの）
果たして、この世に存在し得るデータ一般を表現する一形式を議論する場合と
ある業務のＤＢ設計を議論する場合で
同じ用語体系が使われるべきだろうか？
117:NAME IS NULL
08/11/26 17:00:17
>>115
>マスタなのかテーブルなのかを明示したい場合、どういい分ければいいの？
ディメンジョンとファクトかな、と思ったりするのはOLAP畑の自分。
(いや、厳密に対応するわけではないのでツッコミは勘弁ですｗ)
>リレーションシップを示す”テーブル”のみを表現する言葉を俺は知らない。
このようなエンティティ間の関係だけを格納するテーブルを定義する
というのはデータベーススキーマ設計におけるベストプラクティスと
いうかデザインパターンの一つで、でもそれには決まり切った名前が
ない、という不幸なんでしょうね。
昨日もバイナリリレーションと書いてやばっ、と思ったらやはり誤解が。
言葉って難しいです。
118:NAME IS NULL
08/11/26 17:01:12
と自分で出したページに「ディテール・テーブル」と言う用語がかかれてたから今後はこれを使うよ。
検索してもほとんど出てこないから通じない可能性が怖いけどね。
あとさらに言えば、リレーションがリレーションシップと同じ意味で使われる場合がかなり多い。
今検索して見つけた例
URLﾘﾝｸ(support.codegear.com)
「テーブル間のリレーション」と言う言葉が使われている。
>>113によれば「ドッグ間の犬」だな。
119:NAME IS NULL
08/11/26 17:06:02
他人と話す時は、自分勝手な用語はつつしんだ方がよいと思う。
意味は通じるけど111のようなツッコミが入るのは不思議じゃない。
>>112で「正しい言葉だと思うけど」と言ってたけど、正しい言葉ではないだろ。
通じるけど。
>マスタなのかテーブルなのか
これはもう通じない。なにを言ってるの？
>リレーションとリレーションシップで言い分けるより通じる。
まともに勉強している人はリレーションとリレーションシップで通じる。
120:NAME IS NULL
08/11/26 17:14:56
そもそもrelationとは米中関係のことらしいという件。
121:NAME IS NULL
08/11/26 17:21:30
>リレーションがリレーションシップと同じ意味で使われる場合がかなり多い
誤用が広まっていても、正しいことにはならないよ。
日常会話ならともかく、開発のときは気をつけるべきだね。
そして
URLﾘﾝｸ(homepage1.nifty.com)
は酷すぎ。信用しちゃいけない。
122:NAME IS NULL
08/11/26 17:44:34
確かにリレーションとリレーションシップは実際扱いにくい言葉だな
今話題になってるのは「関連テーブル」と呼ぶことが多いような気がする
T字形では「対照表」と呼ぶのかな
>>118のディテールテーブルというのは違うよね？
・単品テーブル
・セットテーブル
・単品セット関連テーブル
で言うと、単品テーブルの事をディテールテーブルと呼ぶ。
マスタ/ディテールという呼び方は、マスタ/トランザクションのマスタと用語が重複してしまうので、ヘッダ/ディテールとか親/子を使うようにしている。
>>121
>URLﾘﾝｸ(homepage1.nifty.com)
>は酷すぎ。信用しちゃいけない。
ひどいね
123:NAME IS NULL
08/11/26 17:47:40
>>119
＞自分勝手な用語は
一般的な用語しか使っていない。
リレーションテーブルと言う言葉はテーブルと言う言葉を含んでいてマスタと比較する文脈であれば問題は無いと思う。
＞これはもう通じない。なにを言ってるの？
一般的な用語であるかどうか検索して確認してから発言しろ。
>>121
酷すぎるという根拠は貴方の主観以外にあるの？
俺は検索と言う方法でそれが一般的な用語であると言う客観的な根拠を示したつもりなんだけど。
124:NAME IS NULL
08/11/26 17:55:56
ディテールテーブルと言う言葉を上で使うべきかと書いたけど、
それは間違いだったね。
>>122の通りディテールテーブルと俺が言うマスタ文脈上のテーブルは意味が違う。
関連テーブルだと英訳すればリレーションテーブルになるけど、
もし英語で設計書かけと言われたらどう書くの？
125:NAME IS NULL
08/11/26 18:18:41
さらに検索
URLﾘﾝｸ(q.hatena.ne.jp)
これのtbl_は恐らく関連テーブルを指してるだろうね。
マスタとトランが示されてるのに同列で語られるものは関連テーブルしかないからね。
本来の意味通りのテーブルならテーブル名の接頭辞にする意味ないからね。
URLﾘﾝｸ(72.14.235.132)
これも同じで、本当は質問者が遭遇していたのは「関連テーブルを指す”テーブル”」なんだろうけど、
回答者はテーブルという用語が文脈によって意味が変わる場合もある事に気付いてない。
本当にただのテーブルと言う意味なら質問者はマスタやトランと並べて質問しないだろうね。
126:NAME IS NULL
08/11/26 18:30:04
ちなみにマスタという言葉も曖昧で実際のシステムの保守においては多様な意味を知っている必要がある。
URLﾘﾝｸ(blog.goo.ne.jp)
結局、関連テーブルに対し適当な名前が付けられていない。
関連テーブル以外には名前が付けられている事があって、
単にテーブルと呼べば関連テーブルを指すと言うケースがある。
関連テーブルは英訳すればリレーションテーブルになってしまい、これも適当な用語ではない。
127:NAME IS NULL
08/11/26 18:41:31
突っ込みどころが多すぎてめんどくさい
128:NAME IS NULL
08/11/26 18:43:50
>関連テーブルは英訳すればリレーションテーブル
バリューセットの例でいえばmany-to-manyの関連なので
「association table」かなぁ。
129:NAME IS NULL
08/11/26 19:11:52
> URLﾘﾝｸ(q.hatena.ne.jp)
> これのtbl_は恐らく関連テーブルを指してるだろうね。
質問には「普通のテーブル」って書いてあるよw
普通のテーブルって何よ！！！
ってくらいの低レベルな質問者なので、こんなの引用されてもなあ
> 本当にただのテーブルと言う意味なら質問者はマスタやトランと並べて質問しないだろうね。
質問者はそのくらいDBについて分かってないだけでしょ。
>結局、関連テーブルに対し適当な名前が付けられていない。
「関連テーブル」でいいじゃん。
>単にテーブルと呼べば関連テーブルを指すと言うケースがある。
非常に特殊な低レベルのバカの場合だけだろ。
「リレーションテーブル」は正確ではないけど意味も通じるしいいけど
「マスタテーブルとディテールテーブル」を「マスタとテーブル」と表現するのは
だめすぎだよ。
> 関連テーブルは英訳すればリレーションテーブルになってしまい、これも適当な用語ではない。
relationship tableではいかんのか？
T字形だと「対照表」と呼ぶよな。
ネットで初心者が用語を混同して質問しているのをいくら挙げられても、なんにもならないよ。
130:NAME IS NULL
08/11/26 19:17:56
ふと思ったけど
「マスタとテーブル」って汎用機時代のオッサン用語だったりするかも。
131:NAME IS NULL
08/11/26 20:12:46
>>129
＞質問には「普通のテーブル」って書いてあるよw
その質問者が普通のテーブルが何を意味してるのかが分かってないから聞いてるんだよね？
俺が挙げたのは用語を混同している初心者の質問でなく、
用語を混同して設計されたＤＢの保守作業をする事になった初心者の質問だよ。
実際俺も保守作業において、実際のテーブル名及び設計書でそういう用語が使われていて知った。
事実、その用語を紹介しているサイトも紹介した。
マイナーだとしても認知されている用語なのは間違いないと思うが？
カタカナ化せず関連テーブルと呼ぶなら、
mst_ trn_ とつけて kanren_ってつけるの？
それとも普段からの呼び方は「関連テーブル」で設計書上では「rel_」とするの？
132:NAME IS NULL
08/11/26 20:20:22
>>123
> >>121
> 酷すぎるという根拠は貴方の主観以外にあるの？
正しい事が書いてある項目を見つけるのが難しいっす
133:NAME IS NULL
08/11/26 20:27:43
>>132
そのサイトに書かれている項目のうち何割が間違っていますか？
偏りが発生しない方法で２０件程度を抜き出して答えてもいいです。
それをしないうちはサイトに対する信憑性の低さを根拠には出来ないはずです。
俺の認識では、確かに誤用かもしれないが確実にこの用語で作られたシステムはかなりある。
かなりのエンジニアに通じる。
全く認知されていない「勝手な用語」であると思えてしまう人が居るのは、単に知らないだけ。
と言う認識。
134:NAME IS NULL
08/11/26 20:41:20
>>131
"rel_"とか"r_"とか"kanren_"とかなんでもいいけど"tbl_"とはしないよな。
ダメ設計者が関連テーブルに"tbl_"と接頭辞をつける事例はあるんだろうけども
それは積極的に「関連テーブルはtbl_とつけよう」とした訳ではないと思う。
ほんのちょっと、ほんのちょっとだけでも論理的に考える頭を持っているならば
「関連テーブルはtbl_」なんて考えるわけがないし。
>>133
>この用語で作られたシステムはかなりある。
じゃあ俺が寡聞にして知らないだけなんだろうね。
なるべくならそんな「エンジニア」さんとは仕事したくないけど。
件のサイト、２０件とかメンドクサイです。ただこの先参照する時には
眉につばをつけてみる、本を読んだり他で調べて自分で考えてみる、
ということをお薦めします。
スクリプト言語 = 文法が簡単なプログラミング言語
シーケンシャルファイル =「1行1データ」で表されるデータ。
トランザクション・ファイル = プログラムの処理の過程で削除されてもよいファイル
オブジェクト指向 = 既にあるものを組合せ、短期間でよりよいプログラムを作ること。
135:NAME IS NULL
08/11/26 20:42:53
追加。これももちろん違う
■テーブル
マスター・データの関連データを格納したファイル
またの名を「ディテール・テーブル」
136:NAME IS NULL
08/11/26 20:43:35
>>135
というか汎用機時代はそうだったのかもしらん
137:NAME IS NULL
08/11/26 23:17:28
>>130
汎用機出身のオッサンはテーブルのことを「ファイル」と呼んだりするからあなどれないw
138:NAME IS NULL
08/11/26 23:19:51
>>134
>スクリプト言語 = 文法が簡単なプログラミング言語
これは間違ってはいないと思う
139:NAME IS NULL
08/11/26 23:24:13 v/u6t0ex
>>138
かなり的を外していると思う。
140:NAME IS NULL
08/11/26 23:32:56
>>133
>そのサイトに書かれている項目のうち何割が間違っていますか？
>偏りが発生しない方法で２０件程度を抜き出して答えてもいいです。
>それをしないうちはサイトに対する信憑性の低さを根拠には出来ないはずです。
なんという上から目線www
141:NAME IS NULL
08/11/26 23:51:18
＞本来の意味通りのテーブルならテーブル名の接頭辞にする意味ないからね。
テーブルなのかビューなのかファンクションなのか接頭語で分かるように
テーブル（オブジェクトとしてテーブルに分類されるもの）には全てT_を付ける、とか
珍しくも無いと思うけど。
142:NAME IS NULL
08/11/27 00:38:24
>>137
コボラはDB屋の敵だ
143:NAME IS NULL
08/11/27 01:29:46
>>141
それやるとDB側だけ変更でテーブル→ビューって置き換えた時にT_XXXってビューが出来る。
144:NAME IS NULL
08/11/27 02:52:23
>>116
そんなアホサイトじゃなくて書籍を買って読んでみなよ。
お母さんにお小遣いもらってさ。
145:NAME IS NULL
08/11/27 06:43:29
なんか実務経験とかがロクになさそうな厨房が
俺ルールを押し付けるスレって雰囲気だな。
146:NAME IS NULL
08/11/27 19:36:08
どの辺が俺ルール？
147:NAME IS NULL
08/11/27 20:23:03
コボラーのときは本当にテーブル単位でファイル弄ってただけ。
148:NAME IS NULL
08/11/29 04:44:35
>>147
だからってRDBのテーブルを「ファイル」って呼ぶなよ
149:NAME IS NULL
08/11/29 11:00:42
テーブル操作＝ファイル操作だから同じ事。
150:NAME IS NULL
08/11/29 13:37:59
ファイルメーカー
151:NAME IS NULL
08/11/29 14:38:32
>>149
同じ事なわけねーだろw
152:NAME IS NULL
08/11/29 20:58:43
COBOLから見るとまったく同じに見える
ミドルウェアってえらいね
横に長いテーブルまんせー
153:NAME IS NULL
08/11/30 02:02:41
殺意が沸いた
154:NAME IS NULL
08/11/30 02:14:29
URLﾘﾝｸ(homepage1.nifty.com)
ここ作ってるやつもコボラっぽいな
URLﾘﾝｸ(homepage1.nifty.com)
> 1999年にはＹ２Ｋ対策としてＣＯＢＯＬを修正できるスキルが一時的に見直された。
って、コボラが問題をまき散らしてただけだろ。
もしかして将来の職のためにわざとやってたのか？
155:NAME IS NULL
08/11/30 03:18:18
実務の世界にいないのでどのような確執があるのか見当も
つかないのですが・・・
かつてDB屋さんとコボル屋さんの間で血で血を洗う闘争でも
あったのでせうか（(；ﾟДﾟ)ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
156:NAME IS NULL
08/11/30 05:29:09
現在も戦いは続いている
157:NAME IS NULL
08/11/30 06:02:15
>>155
メインフレームＤＢとUnix系ＲＤＢとだろ。
前者で使われている言語は主にＣＯＢＯＬ。
後者で使われている言語はかつてはＣ、現在ではスクリプト系言語などさまざま。
Unix系ＲＤＢの登場は1980年代で日本で普及しはじめたは1990年前後から。
メインフレームＤＢはもっと歴史が古くて1970年代から実用化されていた。
メインフレーム＝ＣＯＢＯＬのほうが20年以上先輩であるわけだ。
メインフレームＤＢで古くからあるものはＲＤＢ=リレーショナルデーターベースではない。
階層データーベースを使っているものが多い。ＤＢをアクセスするためにミドルウェア
が存在する。
まあ、歴史的にはこんなかな。とメインフレームを知らない俺が言ってみる。
階層データーベースにはテーブルというものがない。「ファイル」というのはそのせいか。
ものが
あって、
158:NAME IS NULL
08/11/30 11:09:41
かゆ
うま
159:NAME IS NULL
08/11/30 15:27:50
別にCOBOLと言う言語が悪い訳でもないとは思うが、
コボルを扱う人間の設計には欠陥が多いのは事実ではあるな。
オマエラは一生２０年前のシステムのだけ見てれば文句はないのだが、
現代のRDBのシステムにクチを出してくると、ほぼプロジェクトは火を噴く結果になる。
160:NAME IS NULL
08/11/30 18:43:39
「俺たちの戦いはこれからだ」的な実情ですね。大変だなぁ。
先ほどの「横長のテーブル」もそういうCOBOL畑だった人が持ち込みがちな
「困った設計」なのでしょうか。
単に正規化に無頓着なのか、それともまた別の異なる設計論があるのか、
まるで異文化コミュニケーションですね。
161:NAME IS NULL
08/11/30 19:59:12
ある程度、先入観が混じっている見方だけど、
メインフレームを使う金融系COBOL畑と言うのは、技術畑のエンジニアが
やった仕事ではなく、大昔のIBMのテンプレートを真似ただけの、
マニュアル仕事であって、競争とかそういうのは無い狭く閉じた世界の
物語と言う感触がある。
昔は昔なりの事情があるから全否定はしないけど、
老人から「俺は昔こんな事をしたんだぜ」と自慢げに話されても
「ふーん、大変でしたね」と言う感想しか沸いてこない。
JavaとかC#,Python,Rubyなんかは過去の反省と言うかそれなりの
理想を持って進化している言語であり、それらを選択するエンジニアは
「過去よりは少しはマシに」と言う未来に向かって試行錯誤するタイプなんだけど、
COBOL畑の人間は「俺はこう教えられた。俺は今までコレでやってきた。
これ以上俺は何も覚える気がない。俺は正しい」と人間的に
成長が止まっているタイプが圧倒的（ｗ）に多い。
さらにヤやこしいのが金融系と言う仕事が謎なステータスがあり、
そこでCOBOLがある程度ブイブイ言わせているので、COBOL畑の
人間が高給取りかつ増長している現実がある。
162:NAME IS NULL
08/11/30 20:55:35
つかCOBOL馬鹿にするだけで、開発自体まともに理解出来てない奴がいるな。
163:NAME IS NULL
08/12/01 00:48:22
「俺は昔こんな事をしたんだぜ」
が自慢だけならいいが
「俺は昔こんな事をしたから、これからもこれでOK」
というおっさんが権力だけ持ってるのがうざい
164:NAME IS NULL
08/12/01 01:46:40
昔と今で技術に隔絶の差があるのになぜおまえらはおっさんにそれを伝えることができないの？
165:NAME IS NULL
08/12/01 02:10:20
>>164
そこまで力がないからでしょ。
力があって理解せられてれば自慢じゃなくて添削依頼になる。
166:NAME IS NULL
08/12/01 03:08:50
添削依頼なんてならねえよ。社内上の立場ってもんがあらあ。
簡単にウン１０年の情報化の歴史を小僧っこに否定されてみろ。
167:NAME IS NULL
08/12/01 14:17:25
>>166
話にならん
168:NAME IS NULL
08/12/01 14:21:02
そんなこんなで日米の証券システムは、乳母車とスペースシャトルに例えられるくらいの差がついてしまったわけで
169:NAME IS NULL
08/12/01 15:33:13
>>166
普通にされてるんだが・・・自分より10以上離れた年齢の人に。
そうでもないと思ってたがずいぶんとマシな所に勤めてたようだ。
170:NAME IS NULL
08/12/01 21:25:43
ﾋﾟｺｰﾝ
171:NAME IS NULL
08/12/01 23:26:52
悲惨な前線での戦闘の話を聞き、自分の身の上が恵まれていることに
気が付いた>>169であった・・・。
172:NAME IS NULL
08/12/02 17:56:54
>>161
残念だが、そういう人間はCOBOLやJava、C#にかかわらず非常に多い。
実際COBOLって方言が多くて、年代や機種によってさまざまに変化しているから
１つのシステムだけを延々やってた人以外は、毎回やり方を変えていたよ。
＃メインフレームだと新機能を使わないってルール付けしてたりもする。
システムそのものも、１００万件以上ならDBをキーをつけて並び替えて抽出するより
前件なめて、ソートして抽出したほうが早いという時代から、やっぱりちゃんと
抽出したほうが早いって切り替わる時期でもあったので、こちらでは常識でも
あちらでは非常識がまかり通っていた時代だよ。
＞さらにヤやこしいのが金融系と言う仕事が謎なステータスがあり
こんなの金融に限らずどこのシステムにもある。
JavaやC#で代替できないものはないし、そこだけJavaからCOBOLを
呼び出して実行してもいい。
どんな仕事の仕方をしてきたかで決まるのであって、どんな言語を使うかではない。
>>163
２０年前からそうだよ。そんなやつは今も昔も変わらず多い。
>>168
砂利を運ぶのに「カウンタックを作れ」と指示されて、カウンタックを作っちゃう日本と
ちゃんと目的にあったカスタマイズされたダンプを作るアメリカとの違いだよ。
173:NAME IS NULL
08/12/02 20:18:19
JEFをUNICODEに完全に変換できないのが悩み。DB関係ねえ。
174:NAME IS NULL
08/12/02 23:11:27
２０年後「俺がやってたＣ＃ではな・・・」と自慢話をして、煙たがれる人もいるだろうな。
でもどうだろうな、技術というものはいつも同じスピードで進歩するものでなくて
ある時期に急激に進歩してその後停滞するものであるから
ＩＴ関連の技術は、今後２０年間あまり変わらないのではないかな
175:NAME IS NULL
08/12/03 00:17:39
>>174
まだまだ変わる思うよ。
次の劇的な変化は、関数型言語が実用的なレベルになるくらいにハードが進化した時に来ると思う。
176:NAME IS NULL
08/12/03 00:25:44
つか、今現在CやUNIXでそういうパターンの奴はいて、本人は気付いていない
というのがあるだろ。
COBOLerも、自分の技術は普遍的でメインストリームで、そこいらのPCのような
おもちゃとは違うと信じているし、それが時代遅れだとは露ほども考えていない
というのはおんなじだな。
177:NAME IS NULL
08/12/03 00:26:52
DBはどうでしょうか。Relational database model自身はもうすぐ40周年
ですが、この次に別な何かは来るのでしょうか。
178:NAME IS NULL
08/12/03 01:10:21
ＳＱＬを使わないデータベースが出てくるんでしょうかね
オブジェクトデータベースというのはどうなんでしょ
179:NAME IS NULL
08/12/03 06:51:45
xmlを扱うデータベースは今までのRDBと毛色がやや違う程度で
チマチマ普及すると思うが、メインはRDBだと思われ。
180:NAME IS NULL
08/12/03 22:54:59
色々言われ続けながらも結局生き残ったもんなァ・・・
181:NAME IS NULL
08/12/03 23:14:26
db4oもサンプル見るとすげぇって思うけどちょっと調べると・・・
182:NAME IS NULL
08/12/03 23:48:06
今扱っているDBスキーマには何十個もテーブルがありますが、
全てのテーブルでカラム数が2です。
スキーマ設計の欠陥でもネタスキーマでもなく、カラム数は
2で固定、という仕様のDBMSなのです。
このやり方でも大抵のデータを表現できる自信はありますが、
このやり方の時代が来ることも、また無いような気がします。
(内心は、あるかも、そんなときめきもちょっと感じています)
183:NAME IS NULL
08/12/04 04:18:16
なにそれどういうDB？
184:NAME IS NULL
08/12/04 23:53:14
>>182
そういう作りはちょっと考えてんだけど、実際にやってるとこあるんだなw
いまから趣味でつくろうとしてるOSSで試してみようかな・・・
185:NAME IS NULL
08/12/05 00:05:17
MonetDBというDBMSです。
URLﾘﾝｸ(monetdb.cwi.nl)
RDB/SQLやXMLDB/XQueryを実装したパッケージとして配布されて
いますが、MonetDBのコアは二項関係だけをストアする最低限の
ストレージとそれを操作するアセンブリ言語で構成されています。
Javaアプリケーションに対するJavaVMのような、DBMSを実装して
実行するためのvirtual machineのように使えるソフトです。
大抵のデータ構造は二項関係の集合に分解して表現できるので、
目的のデータ構造を二項関係の集合に分解するルールを決めて、
後は使いたいクエリ言語をアセンブリ言語に書き下すコンパイラを
実装「出来れば」どんなデータ構造もクエリ言語もどんと来い、
そんな考えのDBMSです。
研究ではRDBやXMLDB以外にもGISやRDFDB/SparQLなんかも
実装しているみたいです。
実用向けではなく実験的なDBMSですが、SDSSという天文分野の
大きなDBをこれに乗せるプロジェクトも走っているようです。
更新系は弱いですが、参照系に関しては商用DBも上回ることも
あるようです。
186:NAME IS NULL
08/12/05 03:51:53
バッチ処理に一晩コースだな。
リアルタイム更新のインターネット用途は不適っぽいな。
187:NAME IS NULL
08/12/05 17:13:10
仮に20カラムのリレーションが欲しければ代わりにテーブル20個
作っちゃえ、というやり方ですから行単位で参照したり更新したり
というOLTPアプリでは既存のRDBMSの実装の方が優れます。
基本は参照のみ、集約値の計算等のためにフルテーブルスキャン
を多用する、しかもどんなクエリが来るか事前に読めない(クエリを
決めうちしたIndexやMaterialized viewを使うことが出来ない）用途
を意図した設計のようです。
なのでOLAPやData mining、学術用のデータ解析など向けですね。
188:NAME IS NULL
08/12/05 22:58:34
設計の自由度は高いでしょうね。
性能は悪そう。
189:NAME IS NULL
08/12/06 00:27:38
設計の自由度は、あまり変わらないかな。
MonetDBのアセンブリ言語使って何かしようというのは相当変な事 orz
をしようという人だけであって、普通はSQLとかXQueryで使うはずです。
性能はDMやOLAPなどの用途に関しては相当に速いはずです。
実際のところ商用DBではSybase IQがよく似た設計を持っています。
(そもそもSybase IQは初期のMonetにインスパイアされたらしい）
なのでコラム単位のVertical fragmentationの用途と利点に関しては
次のSybase IQの記事が参考になります。
URLﾘﾝｸ(www.thinkit.co.jp)
あとGoogle Tech Talkでの次期MonetDBの話も面白い。
URLﾘﾝｸ(jp.youtube.com)
190:NAME IS NULL
08/12/06 02:26:08
つーかなんだな
OODBって結局一度もブームこなかったな
ポストRDB！！とか騒がれていたのに
191:NAME IS NULL
08/12/06 13:57:59
だって遅いし。
実データをオブジェクト指向で扱うのって無理が有りすぎる。無限に要素を想定する事に成るし。
加工するにはオブジェクト指向で操作したほうが直感的では有るけど。
192:NAME IS NULL
08/12/06 19:51:06
なんだかんだでSQLって良く出来てるよなぁ
ORでインピーダンスミスマッチとかよく言われるけど、
SQLからクラスとマッピングコード生成するスクリプトを書けば
いいだけだしな
何もＤＢ自体がOOである必要はねーよ
193:NAME IS NULL
08/12/06 19:57:07
カラム数が２だとキーと値を持たせたら終わりじゃないの？
A りんご
A 100
A 青森産
B みかん
B 150
B 愛媛産
みたいに。
「このレコードは名称、このレコードは値段」とか判断付かなくない？
194:NAME IS NULL
08/12/06 20:15:21
「あれができない、これもできない」っていってたらキリがないだろw
195:NAME IS NULL
08/12/06 20:17:37
そうだな。
判断付かなくて困るって程のことでもないし、いいのか。
196:NAME IS NULL
08/12/06 20:37:18
>>192
無能は黙ってろ
197:NAME IS NULL
08/12/06 20:53:52
>>193
カラム数は2で固定ですが、テーブル自体は沢山作る事ができるので、
この例だとキー:名称、キー:値段、キー:産地の三つのテーブルを作るのが
一つの解です。
各テーブルでキー->名称、キー->値段、キー->産地の関数従属性を表現
出来て、これらの三つからキー->(名称, 値段, 産地)の関数従属性を導出
出来ますから、この分解は無損失です。
198:NAME IS NULL
08/12/06 20:58:29
組織マスタ
組織
上位組織
社員マスタ
社員番号
役職
権限マスタ
権限
とあるときに、ある社員の役職が自分の所属する組織だけで通用する
権限を持たせるようにするにはどう関連を引けばいいの？
199:NAME IS NULL
08/12/06 21:12:21
外部キー無いじゃねぇかｗ
200:193
08/12/06 21:36:41
>>197
あー、そりゃそうだ。
名称と値段と産地が同じテーブルに入ってるという普通のDB的考え方がそもそも違うのか。
201:NAME IS NULL
08/12/07 11:02:15
まあ総当たりで再利用考えなければｗｗｗ
202:NAME IS NULL
08/12/08 01:00:44
>>200
MonetDBもSQLを使えば普通にnカラムのリレーションを作れますよ。
JDBCやODBCもあるので、ただRDBMSとして使う分にはMySQLとか
その辺のOSSのデータベースサーバと変わりません。
なんかMonetDBがとても普通でない変態DBみたいな誤解が生じても
アレなので、念のため。
2カラム限定なのは低水準のアセンブリ言語を直接使って変な事を
する時だけです。変態なのはDBMSではなく、私。
203:NAME IS NULL
08/12/09 22:31:44 8rN2YWi9
すいませんトーナメント表を作りたいのですが
DBはどのように設計したらよろしいでしょうか？
こんな感じのドラゴンボールの天下一武道会みたいなトーナメント表です
優勝
|
|~~|
|~~~|~~~|
A B C
204:NAME IS NULL
08/12/10 01:06:13
>>203
俺なら一試合一選手で1レコードにしてこうする
PK ID
対戦相手ID
X回戦（一回戦とか二回戦とか）
X試合（第一試合とか）
選手
勝敗フラグ
205:NAME IS NULL
08/12/10 01:11:09
と思ったけど勝ち上がった後のキーもいるかな。
このやり方だとトーナメントの下から追うのはいいが上から追えないが。。。
206:NAME IS NULL
08/12/10 19:07:05 8RNJEsTT
ちょっとみんなの意見をききたい
休日マスタのような、主キーを日付にしたいけど、時間はいらないってときに、
日付型でやる？数字か文字でやる？
日にちのみのと時間のみの型があるなら日にちのみの型でやるんだが、
日付型って時間とセットなんだよなぁ
日付型で時間入らないように制約つけるのがベスト？
207:NAME IS NULL
08/12/10 22:25:29
レスしてもいいが貴様の態度が気に食わない
208:NAME IS NULL
08/12/10 23:47:56
MSSQL2008なら日付単位でもてる
209:NAME IS NULL
08/12/11 01:30:53
日付型でやった方が型で制約つけれるし
日付関係の関数が使えるので日付でやる
変に文字列とか数値とかでやると後で型をキャストする必要がある時めんどいし。
210:NAME IS NULL
08/12/11 06:36:02
＞日付型って時間とセットなんだよなぁ
そうでないRDBMSもあるんだから、そういう環境依存な話されてﾓﾅｰ
漏れは日付は日付型を使う派。
そうしておかないと、あとでCOBOLerの様な人種が「9999-99-99」とかﾄﾝﾃﾞﾓ日付を入れて
アプリでﾄﾝﾃﾞﾓ実装をやりはじめそうだし。
211:NAME IS NULL
08/12/11 19:06:44
>>210
むしろその制約のために日付を無理やり文字列管理ってDBがいかに多いか…
212:206
08/12/11 20:16:12
>>208
２００８はデータ型増えてるのか．．．
>>209
確かに日付関係の関数は便利だな。
自分で日数計算とかやってられんな
>>210
俺の中では、日付型は日にちと時間せっとなのがスタンダードで、
日にちだけとか時間だけとかの型があるほうが特殊だと思ってた
まあ、どっちにしろ環境依存といえばそうなんだが、
それ言いだすとまず環境を決めないと設計語れないしな
>>211
すまん、よく意味がわからん。
9999-99-99を入れたいがために、文字列で定義されているシステムが多いってことか？
まあ、やはり日付入れる項目には日付型使うほうがよさそうなんで、
やっぱりその方針でやるよう検討するわ。
213:NAME IS NULL
08/12/11 20:48:31
>>212
> 9999-99-99を入れたいがために、文字列で定義されているシステムが多いってことか？
２０００年問題で有名になったYYMMDDというのがある。
214:206
08/12/12 00:19:34
>>213
いや、あるのは知ってる。YYnnnとかな
ＤＢ使わない、それこそコボラーな世界では普通だった。
その世界ではそれが間違ってるとは思ないが、
ＤＢ設計としてはどうなの？って話だ
いまどきメモリの１バイトは血の一滴ってわけじゃあるまいｗ
215:NAME IS NULL
08/12/12 01:09:26
日付で思い出した問題ですが、例えば
リレーション社員＜社員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で直接サポートしてくれぇ」でしたｗ
216:NAME IS NULL
08/12/12 02:00:56
(1)はDATEDIFF関数で。（ORACLEとSQL Serverで若干書式が異なるが）
(2)は普通に入社日と退職日でGROUP BYしてCOUNT取れば出来ないか？
217:NAME IS NULL
08/12/12 17:25:06
＞俺の中では、日付型は日にちと時間せっとなのがスタンダードで、
ソレって主にOracleの事情だったっけ？
DB2,Postgre,MySQLは日付と時間を自由に出来たはずだが。
218:NAME IS NULL
08/12/12 22:41:18
SQL Serverも2005までならそうだと思うが
219:NAME IS NULL
08/12/13 15:20:28
普通３２ビットだから、時間も一緒でしょ。
別に二つカラム持って、こっちは日時しか見ない、こっちは時間しか見ないでもいいと思うが。
どうせ日時の二倍データ量使うでしょ。
１バイトでも件数大量なら無視できないけどな。
オープンソースとかで安易に電網鯖構築してるとレスポンスめちゃめちゃ悪いサイトが出てくるのはそんな理由も大きい。
商品情報とか数万件じゃ済まないし。
220:NAME IS NULL
08/12/13 18:13:10
＞普通３２ビットだから、時間も一緒でしょ。
ナニを言っているのかよく解らんが、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を使う要件の多くは「数万件ですまない」ケースがほとんど」だしなー。
221:NAME IS NULL
08/12/13 23:33:34
>>215
(2)は日付テーブルを持っておいて、1日ごとにジョインしたあとにgroup byして…
とかで出来そうだけど死ぬほどパフォーマンス悪そう。
プロシージャとかで必要に応じてデータ作るのが現実的な気がする。
222:NAME IS NULL
08/12/14 06:39:14
timestampはデフォ３２ビットでおま。
223:NAME IS NULL
08/12/14 07:16:32
>>221
(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で書くには結構大変なクエリで、でも実務の現場
では案外良くありそうなクエリなので、どうやって実現しているのか
興味がありました。やはりストアドプロシジャでゴリゴリでしょうか。
224:206
08/12/14 07:24:05
>>219
前半いわんとすることが全く理解できないんだが．．．
日付型が時間とセットでしか格納できな処理系で、時間を設定しない項目に
日付型を使うか否かというのが論点だったんだが．．．
>１バイトでも件数大量なら無視できないけどな。
これには同意
ただ、数万から数十万程度の件数でレスポンス悪化するようでは、
そもそもの設計がおかしいと思うぞ
>>220
ＲＤＢＭＳのオーバーヘッドを避けるためにＤＢをつかわないシステムを見たことがある
つまり、ＤＢつかう以上ある程度のオーバーヘッドは了承の上だと思う。
日付型が文字や数字より（ＤＢに格納する上で）ある程度のオーバーヘッドが生じるわけだが、
百万件オーダー程度ではあんまり考慮しなくていいかとおもってるんだが
>>222
それってどんなＤＢＭＳでもそうなのかね？
まあ、はじめに処理系依存な話をしだしたのは確かに俺だが、
特定のＤＢＭＳでしか通用しない話は、そのＤＢＭＳを明示してくれないか
ついでに聞くが、デフォで３２ビットってことは、変更も可能ってことかね？
225:NAME IS NULL
08/12/14 07:52:35
>>223
在職期間の重なりを判定するならこれで十分だろ。
(A.入社日 < B.退社日 and B.入社日 < A.退社日)
(2)も、集計期間のリレーションが用意されているなら同じように可能。
226:211
08/12/14 08:13:55
>>212
すまん、遅レス。
俺が遭遇したのでは
「値が未設定の項目はHigh Valueをセットしましょう。日付のHigh Valueは99999999です」ってのとか
「99999999にしておきゃ日付範囲の検索時に有効だろうがJK」ってのとか
いずれにしろなんだその言い訳？みたいのばっかだったよ。
特殊パタンだと
「2008-12-32」を入れておきたいとか、「26:59:00」まで一日の範囲にしたいってのもあったな。
227:NAME IS NULL
08/12/14 08:50:07
>>222
>>224
＞timestampはデフォ３２ビットでおま。
DB2のTIMESTAMP型は10バイトな。
Oracleは12バイト。（Verや使い方で9-11バイト）
日時関連の型は処理系や実装は各RDBMSでけっこう違う。
DB2だと'20081204'をINSERTすると例外出すが、MySQLはOKとかな。
>>226
まあ、日付は日付以上の意味はない罠。
判定したけりゃnullかどうかで判定汁。と言うのがDB屋としての回答ではある。
DB2だとINSERTの時に不正な日付は例外だすから、そこらは安心だ。
MySQLだとINSERTをスルーするから後の結果が怖いな。
＃違っていたらﾂｯｺﾐﾖﾛ
228:206
08/12/14 17:43:40
>>226
その手の話は、コボラーの時代には普通の設計だったな
まあ、未設定なら俺ならLow Value入れるがなｗ
特殊パターンは悩みどころだな
だが>>227 が言うように、
>まあ、日付は日付以上の意味はない罠。
>判定したけりゃnullかどうかで判定汁。と言うのがDB屋としての回答ではある。
というのが正しいスタンスなんだろうな
結局のところ、日付以上の意味合いを持つものを一つの項目に格納しようとするからそうなる
ＤＢ設計としてはそれはやめるべきだろうと理解した
ちなみに、たとえば、有効期限みたいな項目があったとして、
期限日が入ってる場合以外に、未設定と永久があって区別したい、とか言うと
未設定はNULLでいいとして、永久ってのは別途フラグかなんかで項目作るのが正しいＤＢ的設計？
229:NAME IS NULL
08/12/14 20:22:51
9999-99-99がでふぉ。
230:NAME IS NULL
08/12/14 21:13:47
その日付型が持つHIVALでいいんじゃないのか？
'9999-12-31'と'9999-99-99'なんて現実的に同じ意味だし。
ただ単に9999-99-99を許すと今度は8888-88-88とか使いだすだろうし。
そんなつまらん理由の為、日付型の美味しいところを捨てるのはワリに合わんだけだし。
しかし、そういう実装はCOBOL等のバッチ屋はアタマ使わなくて済むかも知れんが、
UIを担当する部署(Webチームとか）から「ふざけんな」と言われるのがオチなので、
フラグで持つ方が親切だろうなぁ。
Web系のフレームワークと連動させるケースだと'9999-99-99'の実装は殺意しか
沸いてこない。
まあ、ここらも現代においてCOBOLerが嫌われる要因のひとつでもあるな･･･。
231:211
08/12/14 21:31:32
>>230
すげえ、あたりｗｗ
後から High Value ２ って規格ができたよ。
もろ8888-88-88だった。
バッチ組の仕様でHigh Valueでも2タイプを判断しなくちゃいけなくて云々と説明されたけど、理解不能だったorz
UI側はただただ面倒臭くてたまんなかったわー。
他の項目の状態判断して、設定するHigh Value値を切り替えなきゃいけないんだから。
232:NAME IS NULL
08/12/15 00:37:50
まあ、あいつらが'9999-99-99'や'8888-88-88'を好むのはメインフレームやらのホストの流派を組んでいる
からある意味仕方ないのはあるな。NULLと言う概念は存在しないし、データには
なんでもヘッダ(01)、データ(10)、トレーラー(88,99)とかつけたがるし。
COBOLerにはＳＱＬにある3値論理が理解できんのだろう。
コレもRDBを操作するSQLの基礎だと思うが、COBOLerはRDBを操作するのにSQLを使わないケースがあるし。
とは言え、RDBMSなんだからCOBOLerがSQLやらフレームワークを考慮してくれないと困るんだが
あいつらの上司はモノを知らんくせにやたら立場と態度がデカいのがウザいったらありゃしねぇ。
233:206
08/12/16 02:13:45
>>232
>データにはなんでもヘッダ(01)、データ(10)、トレーラー(88,99)とかつけたがるし。
さすがにそれはお前のとこだけだろうと思うが
>とは言え、RDBMSなんだからCOBOLerがSQLやらフレームワークを考慮してくれないと困るんだが
まあ、ＣＯＢＯＬとＲＤＢっていまいち相性悪いよな
そもそもＣＯＢＯＬ全盛のときはＤＢは実用的ではない場合がほとんどで、
ＤＢ導入するならＣＯＢＯＬもやめて作り直せば良いんだが．．．なかなかそういかない現実がある
234:NAME IS NULL
08/12/16 19:16:08
店舗ごとの品目売り上げ実績一覧テーブルがあるのですが、
品目一つに対して一列になっているため、
品目の調整がはいるたびに大変な状況です。
実績は金額、件数、率を含んでいるため
単純に列を行に移し替えることはできません。
こういった場合、実績の単位ごとにテーブルを分けて
管理するといった方法でよいでしょうか？
言い忘れてましたが、実績には対応するコードがあり
それで特定可能です。
（今はなぜか列名にそのコードが設定されていますが…）
235:NAME IS NULL
08/12/16 20:34:23
>>232
COBOLerはCOBOLerで、「なんでCODASYL標準のDBMS使わないんだよ。」
と思っている希ガス。
236:NAME IS NULL
08/12/16 22:48:38
店舗マスタ(店舗コード、店舗名、住所・・・）
品名マスタ（品名コード、品名、値段・・・）
実績テーブル（実績コード、店舗コード、品名コード、実績、・・・）
こんな感じ？
237:NAME IS NULL
08/12/16 23:02:45
現状だと
実績一覧テーブル（みかん金額、みかん件数、みかん率、りんご金額、りんご件数、りんご率…）
になっている、という話？
238:NAME IS NULL
08/12/17 00:52:18
>>236,237
今の構成としては
YYYYMM、店舗コード、実績001、実績002、実績016、実績003…
といった感じです。実績列の名前末尾三桁が実績コードです。
つまり、品目を特定するキーがないのが現状です。
前任者の意図としては、web側で出力するのに
SELECT一発で出せるようにということのようです。
>>236さんの方法ですと、実績の単位の型ごとに
列を持つことになるかと思います。
実績_金額、実績_件数、実績_率のように。
この場合、１レコードに対して、必ず２つのNULL列が出ますが
設計上良いものでしょうか。
他に案も浮かばないですが…。
239:NAME IS NULL
08/12/17 08:18:50
金額か件数か率かは実績コードから決まるんなら
実績テーブル（実績コード、店舗コード、YYYYMM、実績）
でいいんじゃない？
これをクロス集計すれば一発だと思うけど
240:NAME IS NULL
08/12/17 18:41:13
>>239
はい、単位は品目コードで一意に識別できます。
今日ちょうどリーダーに同じ案を出したのですが、
違う単位の実績を同じ列に入れることに少し難色を示されました。
（実績単位ごとの列、テーブルを設けるという案でも同じような反応でしたが）
でも、>>239の方法が一番シンプルに
まとめられるやり方ですし、また話してみようと思います。
ありがとうございました。
241:NAME IS NULL
08/12/19 10:35:49
どんなデータの集合体であればマスタとみなすのでしょうか？
イベントとリソースの分類で定型的な手法ってありますか？
242:NAME IS NULL
08/12/20 05:53:23 4lEGcef7
3つ以上のテーブルをjoinする場合、
一般的にどういう順番でjoinするのが速いですか？
243:NAME IS NULL
08/12/20 06:25:23
>>242
大きいテーブルを先に持ってくる。
実データの入ったＤＢで計測するのが一番。
244:NAME IS NULL
08/12/21 04:57:19 Qp++Fn0M
過疎だメシウマ。
ところでテーブルに画面表示用のデータ入れたカラム容易したり、
アプリ依存の使いまわし効かないようなデータ入れたりって皆さんしてます？
DBの勉強は一通りしてみましたが、実務に当たってこのあたりの良し悪しに悩んでます。age
245:NAME IS NULL
08/12/21 09:41:35
普通はやるべきじゃない。
結果セットに直結する形のフォームや帳票のコントロールのせいで
そういう作りにしてしまってるものを見ることがあるが、
これは、ある種のバッドノウハウの類。
オンメモリで処理しにくいものだったらローカルDBを活用したらどうだろう。
246:NAME IS NULL
08/12/21 15:34:35 Qp++Fn0M
>ローカルDB
成る程です。
例えば、DBサーバとAPPサーバが別々に存在したとする。
APP依存、固有のデータに関してはAPPサーバ側にローカルDBを構築して活用する感じですかね。
仮に予算や客都合でローカルDBを用意できない場合は、
せめてテーブルを切り分けて管理したいと考えてます。
しかしJOINが重なるとパフォーマンスや管理の面で劣る…
なかなか難しいですね。
247:NAME IS NULL
08/12/21 18:55:34
SQL ServerのExpress Editionをその目的に使ったことがある。
他にもSQLiteとかSQL Server Compactがそういう目的に使える。
248:NAME IS NULL
08/12/21 22:12:17
ローカルDBって、そんなのクライアントごとに固有の情報を保持するとかでもなきゃ
使わんだろ？サーバーサイドでわざわざ複数のDBに分ける理由はない。
>>246の別テーブルでというのが普通。その上で、アプリ固有の情報といっても
変更の可能性が低くて1:1あるいは1:0リレーションシップであれば1テーブルに
まとめてしまうくらい。
249:NAME IS NULL
08/12/21 22:26:04
＞ところでテーブルに画面表示用のデータ入れたカラム容易したり、
＞アプリ依存の使いまわし効かないようなデータ入れたりって皆さんしてます？
やらないし、やらせない。
それをやりだすと、アタマの悪い後任者が「ここにこのデータがあるから、コレ使えばいいじゃん。
オレ賢い！」と勘違いして、データベースの基本の「One Fact In One Place」の
理念がパーになる。そして黒歴史が始まる。
250:NAME IS NULL
08/12/22 09:50:29
一時表ならよくね？
251:NAME IS NULL
08/12/22 13:24:18
表示順とかどうすか
252:NAME IS NULL
08/12/22 19:20:00 7uJOOUG4
一覧ソート用とか
253:NAME IS NULL
08/12/22 22:32:50
>>249
まともなドキュメントが作られてない or 作られていても後任の教育ができていない場合なら
そういうのも考えられるけれども、まぁ、設計の問題というより組織の問題だな。
254:NAME IS NULL
08/12/23 08:06:38
現実問題、組織の問題を言い出すと、外注丸投げや派遣ばっかなご時勢で
マトモなドキュメントやら教育云々なんて絵空事だよなぁ････。
そういうった組織を含めて「システム」と言うのだと思うが。
それにアタマの悪い管理者ほど「マニュアルがあれば誰でも出来るだろ」と
言い出す始末だしな。
「○○が出来ていれば」なんて絵に描いた餅なんて食べられないよ。
255:NAME IS NULL
08/12/23 10:52:22
手元にあるのはERDと現物のDBのみ、
カラムのコメントは歯抜けだらけ、
アプリの仕様書もない状態。
「このアプリの仕様を踏襲した新システムを作れ」
見えないルールを予測するエスパーたち。
誰かが言った。
「DBがシステムそのものだ」と。
そんな事判ってる。
ならせめて、そのDBの利用ルールを網羅した仕様書を用意しておいてくれ。
256:NAME IS NULL
08/12/23 12:28:52
>>244の
＞画面表示用のデータ入れたカラム
＞アプリ依存の使いまわし効かないようなデータ
ってそれぞれ具体的にどんなの？
257:NAME IS NULL
08/12/23 12:43:34
だから表示順なんかどうすか？と。
258:NAME IS NULL
08/12/23 12:45:18
表示順は無いとどうしようも無い場合も有るから
要・不要を語る意味が無いと思う
259:NAME IS NULL
08/12/23 14:18:21
要・不要の観点で誰も話してないと思うよ。
仮に同一DBを利用するアプリが増えた場合、
設けた表示順が利用できず、新たに用意する事もありえる話。
これってまさしくアプリ依存だよね。
で、この依存したデータたちをどう扱うべきかって流れかと。
260:NAME IS NULL
08/12/23 14:19:04
じゃあ>>244への回答は
「してまーす」でいいわけね。
他にいい方法ないもんですかねー。
261:NAME IS NULL
08/12/23 15:04:28
>>259
よくわからん。
マスタとかを別とすれば基本的にテーブル自体アプリ依存とかだと思うけど。
将来有るか無いかわからない他のアプリでの再利用とかまで考えるのがおかしな話だと思う。
262:NAME IS NULL
08/12/23 19:32:27
ユーザーや端末依存の情報は他のテーブルと区別している。
他のテーブルと結合させないで、専用のクラスや関数でラップして読み書きさせてる。
たまたま、同じデータベースに同居しているというイメージ。
パラメータ系のテーブルもこれに倣っている。
263:NAME IS NULL
08/12/23 22:58:50
>>261
特定アプリだけの専用DBなら、画面プログラマがO/Rマッパで生成するDBで充分だろう。
業務システムの場合、組織・人・商品のような共通データを一元化するべきだから、
きちんとDB設計することが重要になる。
264:NAME IS NULL
08/12/23 23:05:50
>>263
＞マスタとかを別とすれば
265:NAME IS NULL
08/12/23 23:37:10
>>264
マスタは不変の固定情報だけにしないと、時系列のデータを扱った時に矛盾してしまう。
例えば人の場合、生年月日はマスタ上の固定データで良いとして、
配属情報なんかは日々のトランザクションの中にあるわけで、
これを例えば、社員マスタに所属部署の列なんかを作って、常に最新の配属情報で
上書きしたら、そのテーブルは今日のデータとしてしか使えないし、兼務情報も得られない。
実際、いろんなアプリで共通に使うデータの多くがトランザクション上にあるから、
やはり特定アプリの表示用データなんかをDBに置くことには危険がともなう。
266:NAME IS NULL
08/12/23 23:46:23
マスターテーブルにカラムを追加するのは問題だが
特定のアプリ用の独立したテーブルを作るのはいいんじゃないか
267:NAME IS NULL
08/12/23 23:50:02
だね。
スキーマ分けて権限で制御とかなら分かるけど
DBに置いちゃダメってのは行きすぎだと思う。
268:NAME IS NULL
08/12/24 00:32:17
＞特定のアプリ用の独立したテーブルを作るのはいいんじゃないか
それこそDB上に保持する理由が解らんな。
テンポラリテーブルやＰＣのローカル上に落として好き勝手やるならともかく。
269:NAME IS NULL
08/12/24 00:35:15
思いつきなんだけど、hsqldbやfirebird,h2,oracle liteなんかの組込DBを、
今議題になってる各アプリ専用のDBとして、
基幹系DBと独立させる設計はどうだろう？
今、業務で扱ってるDBが監査用の設定が入ってて、
DDLとか大量検索が走ると警告メールが部署内に飛び交うんで、
あんま基幹系DBのスキーマを弄りたくない空気があるんだよね。
270:NAME IS NULL
08/12/24 05:35:01
>>268
テンポラリテーブルやローカルDBじゃセッション間、クライアント間で共有できないだろ。
もしかして、そういう共有する必要のあるデータは全部「アプリ依存」じゃないと考えているとか？
271:NAME IS NULL
08/12/26 07:15:53
>>270
クライアント間で共有と言う時点でその設計が糞だと言ういい証明なワケだが。
272:NAME IS NULL
08/12/26 19:39:01
でもニーズとしてはクライアント間で共有したいって言われるのは自然。
そこでばっさり切り捨ててあいつ使えないなと思われるか、何か工夫してあげてあいつ神と必要な人間に評価されるかは、これからの正社員リストラで生き残れる分かれ目だったり。
組織の運営上は、きちんとマニュアル整備して、誰でもマニュアル通りに対応する体制にしてないと、監査も通らないし危機管理上もマズい。
情報やノウハウを属人化させてるから、退職だので、前任者居なく成ったとたんに困るんだよ。
273:NAME IS NULL
08/12/26 23:15:51
「特定のアプリ用のデータ＝共有の必要が無いデータ」で
「共有が必要だとすると設計がクソ」か。
またとんでもない決め付け厨が現れたもんだ。
274:NAME IS NULL
08/12/26 23:33:33
学生かなんかなのだろう
275:NAME IS NULL
08/12/27 01:05:33
>>272
具体的にどんなニーズなんだろう。
なんかエンジニアが実力不足を言い訳で乗り切ろうとしているだけにしか見えんが。
276:NAME IS NULL
08/12/27 01:09:34
実力があれば、共有すべきデータをローカルのみに保持してても何とかなるらしいｗ
277:NAME IS NULL
08/12/27 03:32:10
ちょっとわかった。
「特定のアプリ用のデータはローカルに置け」といってる人の言う「特定のアプリ」とは
「ローカルPC上からDBにアクセスして、個人的に何かをするツール」的なもののみを指してるに違いない。
それだと話が通る（というか噛み合わない理由がわかる）
そのツールだけで使うデータであり、ツールはその人以外誰も使わないのであれば
データをサーバーに置くべきでは無いわなｗ
278:NAME IS NULL
08/12/27 03:41:57
特定のアプリの位置づけ、それが扱うデータ
これがわからなければ議論はできない
279:NAME IS NULL
08/12/27 09:14:51
なんかここの一部の人は具体例をださずに話をするのが好きだよなー。
会社の宿題をここで解決してるのがバレるのが嫌なんだろうか。
仮に前に話題に上った「特定アプリの表示用データ」なんか、
ほとんどの場合は共有するモンでもないと思うが、
「共用データをＤＢに置くオレカッコイイ、オレ神だぜ」と言うケースは
具体的になんなんだろう？と激しく疑問だったりする。
280:NAME IS NULL
08/12/27 10:24:55
まあ特定アプリが何なのか詳細が分からないからなんとも。
281:NAME IS NULL
08/12/27 10:46:01
ローカルって、端末PCのことを言ってたの？
オレはてっきり、Web/Appサーバに軽量DBMSかXMLか何かでUI層絡みの
データを置くのを、DBサーバに対して（Web/Appサーバの）ローカルと言ってると
思ってたんだが
282:NAME IS NULL
08/12/27 15:59:13
>>279
逆に共用データをみんなが個別に端末に保存して
「オレカッコイイ、オレ神だぜ」って具体例を挙げてくれやｗ
283:NAME IS NULL
08/12/28 02:28:30
>>281
それはローカルとはいわないと思う。
284:NAME IS NULL
08/12/28 02:53:39
毎日一回しか更新しなくていいけど量が膨大なデータとか？
業務アプリならその手のデータがほとんどかもしれない。過去１０年分ぐらいのデータなんてほとんど更新される事も無いし。
後はアイテム数膨大なアプリとか。１０万アイテムぐらいならいちいちオンラインでネット上をばんばんデ－タ流すよりも、ローカルにキャッシュして差分更新で扱ったほうが快適かもしれない。
285:244
08/12/29 00:57:50
皆さんアバウトで申し訳ない。
ローカルというのはWebアプリ視点で物申しておりましたorz=3
つまりWebサーバー上にある軽量DBやXMLなどの事です。
一応、例を提示しておきます。
[DBサーバー]
DB : Oracle
… 顧客情報、商品情報、販売情報、生産情報などが入っている。
[Webサーバー１]
「販売管理システム」というWebアプリケーションが動いている。
ローカルDB : Postgresql
… この「販売管理システム」依存のデータを管理。
例えば、「一覧表示用の順序データ」や「検索条件」、「ログ」など。
[Webサーバー2]
「生産管理システム」というWebアプリケーションが動いている。
ローカルDB : Mysql
… この「生産管理システム」依存のデータを管理。
例えば、「一覧表示用の順序データ」や「検索条件」、「ログ」など。
[端末にインストールされているシステム１]
「商品開発支援システム」というVC++で作成されたWindowsアプリケーション。
286:NAME IS NULL
08/12/29 03:02:11
表現が悪い意味で「いい加減」「アバウト」なひとは気を付けてね
いくら良い設計しても、プログラマーに伝わらなければデスマの元だよ
287:NAME IS NULL
08/12/29 03:05:44
>>285
そういうことは>>256-257辺りで早く言えｗ
288:NAME IS NULL
08/12/29 17:10:41
商品開発支援システムは直接オラクルにアクセスしてるのではなくて、販売管理システムか、生産管理システムにアクセスしてるとか？
統合して全部オラクルで共用データも含めて情報持っても良さそうだが。
システム付け足すのは簡単だっただろうけど、管理大変でしょ。あちこちにデータベース有って全部違うし。
そのうち経営情報システムとかで横断的に情報欲しい時にどこにデータが有るか探すの大変で嵌まると思うｗｗｗ
289:NAME IS NULL
08/12/29 17:27:30
業務ごとにDB立ててバラバラに情報持ち出して結びつけるキーも無くて
「なんとか統合してくれ」的なプロジェクトに参加したことがあるなー。
他社のDBの情報を利用するとか止むを得ない事情でも無ければ
分けたくないところ。
290:NAME IS NULL
08/12/29 21:43:14
285は一見きれいに作られてる風だけど、
>>288-289の言うとおりシステム統合とかで大変な感じ。
DB鯖にアプリ専用Tableが一番いいんじゃないかね。
291:NAME IS NULL
08/12/30 05:43:43
teenage sex ってかんじ
292:NAME IS NULL
08/12/31 11:18:09
そしてshotgun marriageに至と。
とりあえずシステムできちゃったから面倒見ろよと。
293:NAME IS NULL
09/01/05 02:31:06
teenage sex って耳年増みたいな意味じゃなかったっけ？
理想論にかぶれて運用しにくい建付けにしたりってことかと。
でも最近のteenage sexは意味が違ってるよな確かに・・・
294:NAME IS NULL
09/01/07 19:10:01
URLﾘﾝｸ(www.dotup.org)
データーベースとはこのように設計するものなのか
295:NAME IS NULL
09/01/12 16:24:21
該当スレがわからないんですけどたぶんSQLスレじゃないと思うのでここで質問を。
例えで書籍のDBがあるとして書籍テーブルと著作者テーブルを著作者IDでつなげていたのですが
共著のものがでてきて今のままだと対処方法がわからなくなりました。
いちおう新たにテーブルを作って書籍IDと著作者IDを持たせ
本A＝著作者A、本A＝著作者Bの2レコードで表現できるようではあるのですが、
書籍テーブルとかぶって大半が無駄なように思えます。
他にうまいやりかたはあるのでしょうか。
296:NAME IS NULL
09/01/12 16:41:45
大概の場合は結果的にそれが一番無駄のない設計になる。
297:NAME IS NULL
09/01/12 16:59:02
そういうものなんですか。
ではこのやりかたで進めようと思います。
ありがとうございました。
298:NAME IS NULL
09/01/12 16:59:37
一般的な多対多の解決法だね。
どうしてもっていうなら、追加するテーブルは「2人目以降のみを管理する」ことにすればレコード数は減るかもしれないけど
お勧めはしない
299:NAME IS NULL
09/01/12 17:44:39
>>295
新たに作るっていうかそもそも「著作者テーブル」がそれじゃないの？
300:NAME IS NULL
09/01/12 18:19:42
著作者テーブルは書籍IDを含まないでしょう、多分。
301:NAME IS NULL
09/01/12 18:36:34
>>295
言い忘れていたけど、仮に>>295の解決策をとるのであれば
書籍テーブルにあった著作者IDのカラムは削除した方が良い。
「書籍テーブルとかぶって大半が無駄なように」と書いてあった
ので一応補足します。
302:NAME IS NULL
09/01/12 21:43:44
>>300
ああすまん、著作者じゃなくて295で作ったという関係テーブルのこと
>>301
それはないだろ
303:NAME IS NULL
09/01/16 00:30:44 aohFMQX5
>>302
＞それはないだろ
いやあると思いますよ。下のようにするのが一般論だと思います。
[書籍テーブル] キー：書籍コード
書籍コード、書籍名
[著作者テーブル] キー：著作者コード
著作者コード、著作者名
[書籍・著作者リンクテーブル]キー：書籍コード、著作者コード
書籍コード、著作者コード
304:NAME IS NULL
09/01/16 23:33:46
>>303
それが295だ。ちゃんと流れを読め。
305:NAME IS NULL
09/01/17 00:26:21
>>303
フォローどうも
>>304
いや、301で書いたのは、単著の書籍だけの頃はきっと
[書籍テーブル(単著だけ)] キー：書籍コード
書籍コード、書籍名 、"著作者コード"
のようなスキーマだったろうから、この書籍テーブル(単著だけ)から
"著作者コード"のカラムは不要なので削除した方がよい、ということ
です。
306:NAME IS NULL
09/01/17 01:59:35 VBakR5WF
>>304
お前がちゃんと読め
307:NAME IS NULL
09/01/17 02:01:07
>>305-306
だめだこりゃ
308:NAME IS NULL
09/01/17 02:10:59
どうだめか言ってもらえると
309:NAME IS NULL
09/01/17 02:51:42
14 ： すずめちゃん(四国地方) [] ：2009/01/17(土) 00:55:57.15 ID:fadPh4uo (2/17)
T_顧客マスタに【2008年度】のデータがあることが発覚！
日付のところ2008年になってるのがちらほらある
URLﾘﾝｸ(mj.dip.jp)
310:NAME IS NULL
09/01/17 02:52:15
>>309
この設計ってどうよ。
311:NAME IS NULL
09/01/17 12:44:39
>>309
どういうことなん？これ
312:NAME IS NULL
09/01/17 13:16:26
>309
登録年月日と変更年月日が同一のデータばっかりってな話？
313:NAME IS NULL
09/01/17 13:18:50
あー判った。
「変更年月日 < 登録年月日」 のデータが存在するって話か。
例えば、「顧客コード」 が 000020 のレコード。
314:NAME IS NULL
09/01/17 13:20:04
つーか、初っ端のレコードからそーなってるなw
315:NAME IS NULL
09/01/17 16:43:09
で何のデータなの？これ
316:NAME IS NULL
09/01/17 23:26:13
SQL（MySQL、PsotgreやMSなど特定RDBMSではなく標準的なSQL）と
DB構築に関する基礎を学ぶのにお勧めの書籍・サイトないでしょうか。
317:NAME IS NULL
09/01/18 00:59:39
SQLはポケットリファレンスで十分だと思う。
DB構築はどこを指しているかによる。
318:NAME IS NULL
09/01/18 01:00:56 tHveqmjS
汚い設計だなあ
いいからしゃぶれよ
319:NAME IS NULL
09/01/19 15:43:47
Dateの標準SQLガイドがDate先生の辛口も読めて勉強になるけど高いよね・・・
320:NAME IS NULL
09/01/30 17:33:52
このチンカス設計クセーぞｗｗｗ
全部舐めとれよ。
321:NAME IS NULL
09/03/08 18:49:29
スレチと言われたんでこっちで。
SQL質疑応答スレ 8問目
ｽﾚﾘﾝｸ(db板:46番)
>>46
正規形のなかで第1正規形だけは異質とされている通り、これだけは純粋に
モデリングと区別できる正規化とは言えないですね。第2正規形以上の「正規化」は
従属性を「保持」したままスキーマを操作するものであるのに対し、非正規形から
第1正規形にする操作は逆にリレーショナルモデルに落とし込む際に失われた
従属性を修復する操作であるとも言えるので。
いずれにせよ、第1正規形でないものは本来のリレーショナルモデルとは言えない
という意味において、それがモデリングの問題であることには違いはないということと、
スキーマだけ見てそれが正規形かそうでないか議論することはナンセンスであると
いう点では>>46に同意するけど。
322:NAME IS NULL
09/03/08 18:54:43
で？
323:NAME IS NULL
09/03/08 19:54:16
>>321
第一正規形が異質な点はその通りだと思います。
以下雑談なのでちょっとくだけた言い方になりますが、私は恩師の指導が
珍妙とくしゅだったせいか、リレーションがあまり好みではありません。
所詮は関数を実装したり表現したりする方法の一つだよね、その程度です。
なので入れ子リレーションも多値関数や高階関数ですね、そうですか、
良いんじゃない？ぐらいの認識です。
ただ非第一正規形から第一正規形を作るにはデータ構造中に含まれている
ヘンテコ関数全てにトドメを指さないといけないので2NF以下続く正規化とは
異なりデータ構造が当然大きく変化しますし、データモデリングとも絡んで
突っ込むと実は案外面白い問題だと考えています。
ただあのスレでがっかりだったのが、ただ「勉強しろ」「正規化しろ」という
コメントが続いた事です。
ちょっとひどいと思ったので>>13と>>15のスキーマを示して「データベース
理論的にどう異なりますか」と聞いてみたら「正規化について基礎から勉強
しなおそう」と返されました。おぉ～い、もう正規形だよｗ
他方で誰もデータ設計については言い出さなかったので、あのような流れに
なりました。
324:NAME IS NULL
09/03/08 21:21:26
向こうで言えない愚痴を言いたいだけならスレチ
325:NAME IS NULL
09/03/08 22:16:22
>>324
愚痴の部分は申し訳ない。
326:NAME IS NULL
09/03/08 23:05:05
>>321
Javaとかのオブジェクト指向な言語で、
dogクラスはanimalクラスを継承して、って学習のネタで言われるなんだろうけど、
実務で使うケースとかフレームワークが既に決まっている場合とかだと、
それらを考慮してＤＢ設計した方がみんなが幸せになれるので、
2chでああいった質問ってほとんど意味ないとｵﾓ。
327:NAME IS NULL
09/03/09 02:17:57
>>324
向こうで設計の話を延々と続けたら確かにスレ違いだが、そこでの回答が
ひどかったと言うのにスレ違いもなにもないじゃん。
言ってることはむこうの「正規化勉強しろ」ってレスと変わらんわけだし。
それにしても、この板でCOBOLerを馬鹿にする人は多いけど、こういう
話題を振っても反応がそのCOBOLerと同じなんだから笑ってしまうよな。
328:NAME IS NULL
09/03/09 22:27:26
とCOBOLerが申しております。
329:NAME IS NULL
09/03/11 17:55:10
>>321
私には面白かったです。
2chでこんな話が読めるとは思いませんでした。
これからも時々、何か書いてくれるとうれしいです。
自分はまだよくわかってないので、勉強します。
それにしてもカリー化という言葉を、DB板で見るとは思いませんでした。
自分はHaskellとかの関数型言語で知りましたから。
関係ないけど、↓この連載は面白いです。
ベンチャー社長で技術者で
URLﾘﾝｸ(el.jibun.atmarkit.co.jp)
330:NAME IS NULL
09/03/12 01:41:39
>>329
>カリー化という言葉を、DB板で見るとは思いませんでした。
実際スキーマを理解する際に便利な考え方です。
上司の変な教育のたまものですね。いちいち数学の言葉に
ブレイクダウンしないと気がすまない人です。
彼にいわせると、GROUP BYは逆関数なんだそうです(笑)。
あとその連載、読んでます
DB畑の人間としては納得出来るところが多いです。
331:NAME IS NULL
09/03/15 00:44:22
>>330
>あとその連載、読んでます
>DB畑の人間としては納得出来るところが多いです。
あぁ、それまだやってるんだ。
大規模システムを知らない人風だったから読むの止めてまった。
332:NAME IS NULL
09/03/19 12:40:57
中学の図書館で簡単な読書感想文DB作ることになったんだけど
学生名から著者→タイトル→感想文表示
著者からタイトル→学生名→感想文表示
この２つをできるようにしたいんだけど、みなさんならどんなテーブル用意します？
１テーブルでいいのかな・・・？学生数は300人程です
333:NAME IS NULL
09/03/19 14:16:14
何を管理したいかによるかな。
同姓同名のケースがあるが学生名で学生の判別してかまわないか？
出来ないなら別途学生番号を振りキーとする。
タイトルと著者を独立して管理するか？
しないなら
学生のレコードの属性として保持すればよい。
するなら、
さらに著者とタイトルの関連は管理するか？
著者に対してタイトルが複数
共著の扱い
同名タイトルや同姓同名の著者の扱いは？
感想文は学生の属性としてよいか？
学生に対して感想文は１つか？学生の共同作成はないか？
こういったところは >>332でないと分からん。
334:NAME IS NULL
09/03/19 14:38:04
>>332
私ならとりあえず、こんな感じかな。
テーブル
本: (本ID), タイトル
本著者: (本ID, 著者名)
学生: (学生ID), 学生名
感想文: (感想文ID), 学生ID, 本ID, 提出日, 題名, 本文
リレーションシップ
本.本ID 1-* 本著者.本ID
学生.学生ID 1-* 感想文.学生ID
本.本ID 1-* 感想文.本ID
本のタイトルや学生名が重複しても見分ける必要がないなら1テーブルでも良いけどね。
>>333 の言うとおり、要件によるよ。