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