何故データベース設計は軽視されるのか？ (654ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
1(12): 2008/12/01(月)01:07 ID:X6n/IiFX(1) AAS
何故データベース設計は軽視されるのか？
ここでいうデータベース設計とは、
特定の業務システムにおける
テーブルレイアウトを設計し、決める作業であるとします。
業務システムにおいては、
このデータベース設計（テーブル設計）は仕様そのものを定義する作業にも
近いと思いますし、この設計は開発工程やその後の運用における品質を
絶対的に左右するものだと思っています。
逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、
その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか？
省6
19(4): 2008/12/11(木)22:15 ID:??? AAS
>>18
そんなのまだまし。
3601112←これ昭和60年な
3201112←これ平成20年な
4011112←これ西暦2001年な
和暦は3で西暦は4な。
132(3): 2009/03/01(日)00:06 ID:??? AAS
でも使ってるうちに正規化が崩れていくのも事実。
データベースがどのような事に使われていくかはシステム稼働後にしか分からないし。
呼び出してるDBアプリほど、柔軟には、DB側は組み直しとか出来ないし。
簡単に正規化組み直しとか出来る機能が付けばいいけどね。
174(3): 2009/06/18(木)01:33 ID:??? AAS
えーと、初めてのオラクル案件でマスタテーブルを
UNIONで結合したような統合テーブルが設計されていたのだが
オラクルが特別なのか、案件が特別なのかどっちらでしょうか。
214(10): 2009/08/22(土)15:07 ID:??? AAS
最近、クラウド絡みでKVSって聞くけど、別にクラウド云々関係なしにKVS的な構造ってどうなんだろ？
例えば会員テーブルというのがあったとして通常なら（型とサイズは面倒なので略）
create table 会員(会員番号,姓,名,性別,住所,誕生日)
レコードは
00001,会員,太郎,男,東京都,2000/01/01
00002,会員,花子,女,神奈川県,2000/01/02
ってな感じだろうけど、それを
create table 会員(会員番号,属性コード,値)
省23
216(3): 2009/08/22(土)18:01 ID:??? AAS
>>214
>・SQLがきわめて単純になる。
>・DB構造に頭を悩ませる必要がなくなる。
ちゃんとしたDB設計もできない設計者、SQLもかけないようなプログラマにとってはメリットかもしれんがな
>・スケールアウトしやすい。
クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？
>複雑なSQLなんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。
すくなくとも複雑なSQLがパフォーマンス劣化の原因ではなく、（SQLにより実行される）複雑な処理が原因なわけで
>・今まで1つのSQLで取得できてたものが複数回のSQLになる。
省11
217(3): 2009/08/22(土)18:50 ID:??? AAS
>>216
>クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
>クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？
最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリットになると思います。
>ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな
SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。もちろん処理内容によりますが。
省7
400(3): 2009/11/29(日)10:42 ID:??? AAS
石板DB否定派＝DBとは実装のこと。テキストがDBの実現手段に含まれる事を想像もしない。
石板DB肯定派＝DBとは概念のこと。DBの実装形態が様々あることを理解し、色々な可能性を想定している。
DBを概念として捉えている人は、実装について勝手な思い込みはしない。
> 勝手にテキストファイルで作ってしまうのも同様に困ったチャンだろうね。
その人はポジション的に石板DB否定派だと思う。
579(3): 2021/01/12(火)12:19 ID:??? AAS
プログラム組まないやつが設計すると保守性重視になるよな…
人間がパッと見て理解しやすい設計にしがち
ナチュラルキー多用したり
593(3): 2021/01/13(水)00:21 ID:??? AAS
呼び名はともかく人工キーは80~90年代でも普通に使われてただろうから年配だろうが知らないわけない
複合キーは見てわかりやすいわけじゃないが
人工キーに比べると整合性を維持する設計が簡単なんだよ
SQL書く時は面倒くさいから嫌がられるけど不整合が発生するのに比べればマシだから
614(3): ド底辺PG 2021/11/10(水)22:00 ID:KaB0M86I(1) AAS
プロジェクトが燃え尽きたから別の案件に燃料しに行ったんだが、TEXT（可変長文字列）をPKにしてINDEX張ってて「パフォーマンス出ねぇ！」ってやってんですけど・・・
ちょう乱暴に描くと
CREATE TABLE T_TAGS(
JPN AS TEXT NOT NULL,
ENG AS TEXT,
・・・品詞とか同義語とかの定義いろいろ・・・
PRIMARY KEY(JPN)
)
て感じの定義で、SELECTのサブクエリとかでも ON TBL1.JPN = ・・・ みたいにテキストのカラムをJOINしてるんすよ？
ドテ・イ・ヘーンな俺でも「なんで数値でIDのカラムを作らないの？」ぐらいの疑問はあるんだけど、
省1
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.446s*