何故データベース設計は軽視されるのか？ (654ﾚｽ)
上下前次1-新
555: 2020/12/08(火)01:34 ID:TMPxYOvH(3/3) AAS
>>550
製品マニュアルを読んだことがありますか？
556: 2020/12/08(火)02:01 ID:??? AAS
>>553
おまえもそうやと思うで？
557(2): 2020/12/28(月)18:37 ID:??? AAS
軽視したくないけどさ、設計が良いかどうかってどうやって見分けるの？
正規化をバカにする人が多いけど、あれ以外に人に教えられる観点ってあるのか？
558: 2020/12/28(月)21:49 ID:??? AAS
RDBに関して言えば正規化ほど体系化されててわかりやすい観点は他にはないね
良い設計かどうかは求められた状況に対してどれだけ高い品質特性を備えているかで
観点としては機能性以外に使いやすさ、わかりやすさ、堅牢性、運用性、耐障害性、
保守性(柔軟性/拡張性/変更容易性)、効率性(時間/資源)、移植性なんかがある
正規化はデータ整合性、使いやすさ、保守性あたりを高めようとするもの
559(1): 2020/12/28(月)22:15 ID:??? AAS
正規化は非正規形で起きる問題(更新異常等)を防ぐものであってそれ以上ではない。
実際、更新異常を考慮する必要のないDWHなどでは不要。
560(1): 2020/12/28(月)22:49 ID:??? AAS
>>559
DWHでも更新異常は考慮する必要あるよ
更新異常ってCRUDのUだけのことじゃないから
DWHは正規化が不要なんじゃなく
ソースデータの正規形をベースに特定の分析用途に特化させて非正規化してるだけ
スタースキーマもスノーフレークもDWHに特化した非正規化パターン
非正規形のデメリットはDWHだろうがOLTPだろうが同じ
561(2): 2020/12/28(月)23:05 ID:??? AAS
>ソースデータの正規形をベースに特定の分析用途に特化させて非正規化してるだけ
正規形非正規形というのはあくまでもリレーションの表現であって抽象的なデータモデルには
そんな区別はないんだが。
だからDWHにおいて
>ソースデータの正規形
通常これは実在しない。
562: 2020/12/28(月)23:56 ID:??? AAS
>>561
ごめん、何言ってるかわからない
抽象的なデータモデルって何のこと？ どっから出てきたの？
563: 2020/12/29(火)03:14 ID:??? AAS
更新異常が発生しにくいだけで
考慮する必要がないわけないわな
>>561はエアプが即バレして煙に巻きたいのだろう
564: 2020/12/29(火)09:14 ID:??? AAS
>ソースデータの正規形
これが抽象的なデータモデルを指しているのかと思ったんだが、そうでないなら話は簡単。
DWHは「ソースデータの正規形」が存在することを要求しないんで>>560は正しくない。
データソースが正規化された他のDBであることはあるが、それはそのシステム自身の
要求によって正規化されているだけ。
565(1): 2020/12/29(火)12:56 ID:??? AAS
>>557
正規化がバカにされてるんじゃなく
正規化を理解してなかったり正規化されてるかどうか以外にDB設計を見る目がないのに
ドヤ顔でDB設計を語ろうとしてる人間がバカにされてるんだと思うぞ
566: 2020/12/29(火)14:29 ID:??? AAS
それな
ちょうど当てはまるやつがいるな
567: 2020/12/29(火)14:46 ID:??? AAS
頭おかしいやつには下手に触らず黙ってスルー推奨
568: 2020/12/30(水)00:27 ID:??? AAS
RDBと関係ないRやPython使った統計処理の分野でも
分析をやりやすくするために下準備としてDBで言うところの正規化をしてる
更新異常を考慮する必要は全くないけど
569: 2020/12/30(水)09:11 ID:??? AAS
そういうのごっちゃにすると話が発散するからやめて。
そもそもその「正規化」って、リレーションの正規化と違ってなにをどうするかきちんと定義されたものじゃないでしょ。
570: 2020/12/30(水)09:15 ID:??? AAS
それに統計解析向けの加工って、クレンジングは最初に必要かもしれないけどあとは解析しやすいようにJOINしまくるのがふつう。
DWHのスタースキーマから任意に抽出した1つの表の形のデータセット、あれがまさに統計解析向けのもの。
571(1): 2020/12/30(水)18:11 ID:??? AAS
エアプDWHの次はエアプ統計解析かよw
なんでろくにやったこともない事を語りたがるのかね
572: 2020/12/30(水)18:23 ID:??? AAS
データベース設計は軽視されるの原因と
エアプ野郎が語りたがる原因の一つに
素人に毛が生えたような人間には難しさが分からず
自分でもできそうに思えてしまうところにある
573: 2020/12/30(水)22:22 ID:??? AAS
>>571
誰のどのレスに対して言っているのか曖昧でよくわからんが、とりあえずどのレスの
どこがどう違っているのかはっきり書いたら？
反論は受けたくないけどマウントだけ取った気分になりたい中学生じゃなけりゃ。
574: 2020/12/31(木)00:08 ID:??? AAS
エアプ素人さんはスタースキーマのファクトとディメンションがそれぞれ第何正規形か考えると良いと思うよ
>>565の言葉を借りれば正規化すら理解してないのにドヤ顔で語ろうとしてるのが丸わかりだから
575(2): 2021/01/02(土)16:36 ID:2lMlvbHe(1) AAS
ど底辺の土方グラマーだけどDB設計させられて「なんでちゃんとしたDB屋に頼まないんだよ、DBって根幹部分で大切だろ！」って疑問だったけどここ見て納得。
日本の企業が作る(使う）システムがクソな理由も・・・
576: 2021/01/02(土)18:35 ID:??? AAS
ある意味当たってる。
そうやってしばらくして、曲がりなりにもER図書いたり正規化ができるようになって
いっぱしのDB屋を気取れるようになったら彼等の仲間入り。
577: 2021/01/03(日)14:52 ID:??? AAS
>>575
根幹部分だからこそDB中心のシステムを作る開発者なら誰もが身につけておくべきスキルだぞ
要件定義や基本設計を含めて依頼するならともかく
DB設計だけを外部に依頼するのは今の時代にはそぐわないので設計専業のDB屋は絶滅危惧種
578: 2021/01/04(月)05:23 ID:THUOMM/C(1) AAS
ホンマにうわさ以上に凄いのが金さんの億様株レシピて投資ブログ。
ここまじで神すぎる！
めちゃ当てまくる。
おすすめなのは危険な銘柄と宝石の銘柄て記事に出てくる銘柄。
579(3): 2021/01/12(火)12:19 ID:??? AAS
プログラム組まないやつが設計すると保守性重視になるよな…
人間がパッと見て理解しやすい設計にしがち
ナチュラルキー多用したり
580(1): 2021/01/12(火)15:18 ID:??? AAS
>>579
ナチュラルキーを多用してるにもかかわらず保守性が高いならいいんじゃね
581: 2021/01/12(火)16:22 ID:??? AAS
>>580
>>579は「保守性」と言っちゃってるが、実はたぶん保守性の話やないな。
初見のわかりやすさしか見えてないような、困ったちゃんの話なんやろな。
582: 2021/01/12(火)17:06 ID:??? AAS
そうすると保守性を理解してない>>579が困ったちゃんってことになる
583: 2021/01/12(火)17:48 ID:??? AAS
すまん、保守性って言葉が悪かったな
プログラムの保守性ではなくて
ユーザーからの問い合わせ時にデータ見てパッとわかるテーブル構造を好む
584: 2021/01/12(火)20:38 ID:??? AAS
人間にとっての見やすさというかわかりやすさも重要な品質要素だからね
それを犠牲にして得られるメリットとのバランス次第
何と何をトレードオフしようとしてるのか理解してないうちはまともな設計は期待できない
585(1): 2021/01/12(火)21:08 ID:??? AAS
パッと見理解しやすくて保守性も高いならいいことずくめに読めるが。
たぶん言いたいことは逆になにか問題があるということなんだろうけど
結論書いてないから何を言いたいのかわからない。
586: 2021/01/12(火)21:28 ID:??? AAS
>>585
理解力なさすぎ。
人工キー+JOIN前提みたいな、不慣れだとややこしげに見えるテーブルを組みたがらない素人の話なだけやろ。
587(1): 2021/01/12(火)21:37 ID:??? AAS
だから、そこで自然キーの欠点や人工キーの利点を説明しなきゃ何を言いたいのかわからんだろ。
人工キーが自然キーより優れているのは自明だと思ってるとかそんなとこかね。
588: 2021/01/12(火)21:45 ID:??? AAS
>>587
SQL書くときに条件や結合は少ないほうがバグが発生しにくい
プログラマにとってはサロゲートキーの方がわかりやすい
しかしサロゲートキーだと生データを見たときにわかりにくいことがある
ナチュラルキーとサロゲートキーの代表的なメリットデメリットだと思うけど…
その辺天秤にかけてこのテーブルはサロゲートキー、このテーブルはナチュラルキーと決定できるのは
設計もプログラムも保守もやる人。
どれか一つしかやらない人はこのへんのさじ加減わからないのでは。
589(2): 2021/01/12(火)21:57 ID:??? AAS
こうやってブレイクダウンするとどこに誤解があるか見えてくる。
複合キーは扱いづらいのでかわりにサロゲートキーを使うことはあるが
自然キーだと一律にサロゲートキーより扱いづらいなんて理由はないだろう。
590: 2021/01/12(火)22:30 ID:??? AAS
>>589
おっしゃる通り複合キーの場合だな
大変失礼しました
設計と保守しかしない年配のSEさんはサロゲートキーを知らずに複合キーを使いまくる傾向にある
プログラマは若かったり雇われだったりなので口出しできずにクソシステムの出来上がり
591: 2021/01/12(火)22:34 ID:??? AAS
>>589
めんどくさ。
そんな話じゃなかったやろ。。。
おまえは、自分が理解できない話を、自分が理解できるようにしたいだけ。ｗ
何が「ブレイクダウン」や。ｗ
592(1): 2021/01/12(火)22:41 ID:??? AAS
>そんな話じゃなかったやろ。。。
どういう話なのか、お前はまず言いたいことを結論からハッキリ書くようにしろ。
593(3): 2021/01/13(水)00:21 ID:??? AAS
呼び名はともかく人工キーは80~90年代でも普通に使われてただろうから年配だろうが知らないわけない
複合キーは見てわかりやすいわけじゃないが
人工キーに比べると整合性を維持する設計が簡単なんだよ
SQL書く時は面倒くさいから嫌がられるけど不整合が発生するのに比べればマシだから
594: 2021/01/13(水)00:38 ID:??? AAS
>>592
自分の理解力を棚に上げんなよ。
595: 2021/01/13(水)00:53 ID:??? AAS
>>593
不整合はユニーク制約つければいいんでないの
596(1): 2021/01/13(水)08:06 ID:??? AAS
同じ型の単純キー同士なら、それが自然キーか人工キーかで扱いやすさが変わることはないやね。
597: 2021/01/13(水)08:13 ID:??? AAS
>>596
変わらない
複合キーが問題
598(1): 2021/01/14(木)02:05 ID:??? AAS
>>593
ちょっと、「整合性を維持する設計」について詳しく説明してくれ
599(2): 2021/01/20(水)22:55 ID:LfU5rlWt(1/3) AAS
>>557
仕様変更に強いかどうか。それと人間にとってわかりやすいかどうか。正規化の話はもっともらしいが、ちゃんとしたテストと運用・保守をやっていれば、ただの非現実的な理屈だとわかる。
600: 2021/01/20(水)23:01 ID:LfU5rlWt(2/3) AAS
>>593
論理的な整合性をアプリケーションで担保する。そうでないとアプリケーションのテストも難しい。
601: 2021/01/20(水)23:02 ID:LfU5rlWt(3/3) AAS
>>598
彼はアプリ屋と壁を作るタイプだから、かかわらない方がいいよ。
602: 2021/01/20(水)23:16 ID:??? AAS
>>599
アホなの？
603: 2021/01/22(金)08:45 ID:??? AAS
>>599
このちゃんとした
ってのがどれだけ難しいか
604: 2021/01/25(月)05:16 ID:cGhuaVFN(1) AAS
よく読め
605: 575 2021/06/22(火)17:07 ID:??? AAS
ははは・・・
晴れて？「DB屋（）」の仲間入りしそうだ・・・
PostgreSQL9.3とSQLServer2005を、プライベートで、弄ったことあるだけなのに（実務ではOracle11の炎上案件の燃料として放り込まれたぐらい）
7月からPostgreSQL12がフロントエンドで、Oracle（ナンバリングは効いてない）がバックエンドで動いてる「工場のFAのすごいやつと思えば間違いじゃない（スマートファクトリー）」とかいう謎の説明されたシステムのDBチームに配属になったわ・・・
メカ系や移動体通信系のファームしか経験ないつにいきなり・・・
ズブの素人よりはマシかもしれないけどDBそのもののスキルだったらそこらの学生以下だよ俺・・・orz.
606(1): 2021/06/22(火)18:09 ID:??? AAS
いまどきDBでチームがあるのか
ある意味すごいな
607: 2021/06/22(火)18:59 ID:wVCfrFWc(1) AAS
>>606
開発対象が、工場の機械からデータ受け取る中継ボックスみたいなところから、工場の中間サーバから複数の工場の情報をまとめるサーバまで一貫してるんだそうな。
そして中継ボックス、中間サーバ、全体の情報あつめるサーバってのを全部面倒見てる１０人ほどのチームとのこと。
まだ現場に入ってないから実態判らんけど、門外漢な俺を採用しちゃうところだし、上下どころか横の連携もまともにとれないようなカオスなところでもおかしくないって個人的な経験則が言ってる。
他に仕事ないから受けたけど、今から「どんなとこかなー？ 抜けるとしたらどうやって抜けようかなー？」って考えてるｗ
608: 2021/06/22(火)21:26 ID:??? AAS
もし関係者が見たら、特定できそうやな。ｗ
ほどほどにしとけよ。
609(2): 2021/06/26(土)18:20 ID:??? AAS
データベースのテーブル設計書ってどうしてる?
エクセル方眼紙にしてかいてるんだけど、なんかいいのないのかな
610: 2021/06/26(土)23:14 ID:??? AAS
>>609
MySQL Workbenchはどや？
最近は使ってないから知らんが。
611: 2021/07/03(土)17:38 ID:R35jReGz(1) AAS
>>609
A5Mk-?がよく使われている。
612: 2021/10/13(水)12:36 ID:??? AAS
データベーススペシャリストでよく問われるページサイズとか空き容量率とかどのメーカーのDBをターゲットにしてるんや？
教えてくれ
613: 2021/10/13(水)13:54 ID:??? AAS
特にどのDBMSをターゲットにしてるとかないぞ
一般的なBTreeを前提にしてるだけ
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
615: 2021/11/10(水)22:40 ID:??? AAS
遅いのがTEXTのせいだってどうやって判断したの？
616: 2021/11/11(木)00:02 ID:??? AAS
>>614
>これって「データベースあるある」だったりするの？
文字列をPKに使うかどうかは状況による
絶対避けるというほどのものでもない
個人的には可変長は極力避けるけどパフォーマンスクリティカルなシステムじゃなければ
全部可変長で揃えてても特に問題なかったりする
PKを数値にしたバージョン作ってさくっと比較すればいいんじゃん？
617(1): 2021/11/11(木)19:06 ID:NSxyRLjO(1/2) AAS
>>614
あなたの言っていることは頭がおかしいくらい変なことを言っている。
たまたまいままで見てきたテーブルの主キー項目が数値型だっただけで、根拠のない思い込みをしてないか？
念を押すと、頭のおかしい発言だぞ。
618: 2021/11/11(木)19:36 ID:NSxyRLjO(2/2) AAS
>>614
そのTEXT型がラージオブジェクト型というオチのネタ書き込みじゃないだろうな？
619: 2021/11/11(木)20:16 ID:??? AAS
>>617
そこまでやないやろ。ｗ
テキストはCOLLATEの懸念があるし、 数値のが望ましいのはたしかやし。
まあ、遅いのはテキストキーやからと決めつけてかかってるところはアタマ弱そうやが。
EXPLAINしろっつーの。
620(1): ドテ・イ・ヘーン 2021/11/11(木)21:02 ID:xQZydvmR(1) AAS
俺の思い込みが解消されないレベルの現場という前提を認識ください m(_ _)m
マジ学生以下よ、俺のスキル・・・・
EXCELを読んでDBに追記して、DBを参照してEXCELに吐き出すっていう単機能のモジュール２つを並行して「これ、改良して」ってソースだけ渡されたんすよ！
周りが「おそいおそい！」って騒いでて「どんなもんじゃらほい？」って見たらJOINが５〜６個あってTEXTのカラムでつないでたんよ。
さすがにSELECTのWHERE句でIN使うほどじゃなかったけど、そういうSQLあっても不思議じゃないレベルのある意味読みやすいSQLでしたｗ
あと、遅いの根拠が「本番で使ってる高負荷に耐える超高性能マシン」で動かした旧バージョンと「テスト用のレンタル屋から借りてるそこそこの性能のマシン」で動かした新バージョンというね・・・
何の比較にもなってねぇじゃん！
という新事実が発覚して、馬鹿らしくなったので今日は仕事放り出して酒飲んできましたｗ
621: 2021/11/11(木)21:39 ID:6iIlck1C(1/3) AAS
説明の仕方でもうダメ
622: 2021/11/11(木)21:41 ID:6iIlck1C(2/3) AAS
Excelは何と関係があるのか？
623: 2021/11/11(木)21:41 ID:6iIlck1C(3/3) AAS
何が遅いのかまったくわかってねえな
624: 2021/11/11(木)23:17 ID:??? AAS
charやvarcharの文字列って意味でtextって言ってるんじゃなくtext型って話だったのか・・
sqliteならともかくそれ以外のメジャーなサーバー系DBMSでtext型をPKにすることはまずないぞ
625: 2021/11/12(金)00:22 ID:??? AAS
>>620
まとめたら、スペックの違いやろ。
一言ですむわ。ｗ
626(1): 2021/11/27(土)20:05 ID:l5sFA9ZC(1) AAS
よくわかってないクライアントがよくわかってないSEに文句言って
よくわかってないフィルターで「お前らの作ったシステム遅いぞゴラァ！」ってなって現場に届くあるある案件ですな。
627: 2022/02/12(土)03:16 ID:Nh8yTOt3(1) AAS
>>626
性能要件があって、データが増えてもパフォーマンスに問題がないと一言、入っているだけで違うのにな。
628(1): 2022/02/17(木)18:59 ID:??? AAS
まあ、最近はフルSSDのストレージで構築したからsqlがとても早いです。statpack見るととんでもなくディスクREADしてるアホsqlあるけど、システム影響なし、いいんだか悪いんだかですねー
629: 2022/02/22(火)20:09 ID:P63gZsOo(1) AAS
>>628
それで解決したことにするとSSDでもどうにもならないSQLが増産されることになる。
630: 2022/03/24(木)22:48 ID:blhKkXUv(1) AAS
お前ら和歌山県出身の下村拓郎様（35歳独身、元自衛隊）をご存知か、この方は将来素晴しい人物になるから覚えておいて損はないぞ
631: 2022/06/01(水)14:23 ID:??? AAS
スキーマの意味よくわかってないけどスキーマ設計書にテーブル構成書いてるよ
632: 2022/06/01(水)17:38 ID:??? AAS
それっぽく聞こえるもんねw
633: 2022/06/01(水)20:43 ID:1CNMa44D(1/2) AAS
スキーマの概念が後付けの製品しか知らないんだろうな
634: 2022/06/01(水)20:44 ID:1CNMa44D(2/2) AAS
論理的な意味でも括りというのは必要
635: 2023/04/11(火)20:09 ID:+S9P9M6L(1) AAS
ER図を見てもよくわからない設計は典型的なダメパターン
だか大手SIerの人間はテストも運用も保守もしたことがないので、理解不能な理屈で設計したがる。
636: 2023/07/08(土)11:55 ID:Dzd22CIu(1) AAS
今月から、某メーカー系の現場入り。
50万件ぐらいしか入っていない商品マスターを検索するサイトが激重。
DB設計がもろこぼらーの発想。苦言をやんわり現場に伝えたつもりだが、超絶俺様気質の担当者で、聞き入れる気配なし。
逃げたい。
ちなみに、私はデータベーススペシャリスト餅。
637: 2023/07/08(土)12:27 ID:??? AAS
よくある話。
「こぼらーの発想」とか言ってもどこがどう悪いのか他人には伝わらんだろうし。
638: 2023/07/08(土)14:07 ID:??? AAS
正規化って概念がないんだろうな
エクセル感覚であるだけ用意する設計なんだろ
639: 2023/07/08(土)14:41 ID:??? AAS
検索が重いとしか書かれていないのに正規化が出てくる人もどっこいどっこい。
640: 2023/07/08(土)17:41 ID:??? AAS
>ちなみに、私はデータベーススペシャリスト餅。
オレはお前から逃げたいｗ
641: 2023/07/09(日)05:25 ID:Yld3I0en(1) AAS
こぼらーがなぜ嫌われるかをこぼらー自身は検証もしないし、俺流正義マンで権力まで持ってたら。。。。
出くわしたら逃げるしかないんだろうか？
642: 2023/07/09(日)09:49 ID:??? AAS
いまどきCOBOL知ってる人も少ないだろうしどこがどのように問題かという具体的な指摘もないから
傍で見ていてよくわからんのよね。検証のしようもないだろう。
643: 2023/07/09(日)15:34 ID:??? AAS
RDBをよく知らない構造化ファイル時代のコボラーはJOINを嫌い
COBOLプログラムから一番扱いやすい形の構造化ファイル風にテーブルを作る
でもそんな時代は30年近く前に終わってる上に定形検索だけなら遅くはならないので
データベーススペシャリスト餅ｗが表面しか見ていないだけだろう
644: 2023/07/09(日)22:27 ID:??? AAS
「コボラー」と言っとけば多分反論は来ないしお手軽にマウントとった気分になれる便利なワード。
645: 2023/07/10(月)06:12 ID:??? AAS
このスレなんてそれが生き甲斐のやつばかりじゃん
初心者の質問にはまともに答えず、馬鹿にして溜飲を下げるだけ
646: 2023/07/10(月)22:30 ID:??? AAS
ところで構造化ファイルってどんなん？
647: 2023/08/18(金)08:33 ID:??? AAS
ﾎﾎﾎ!(^O^)
648: 2023/09/30(土)00:06 ID:??? AAS
まじかよ、それはありえんわ
649: 2023/10/03(火)22:53 ID:puC6ODCi(1) AAS
VSAMとか悪名高いよな
650: 2023/12/03(日)23:59 ID:??? AAS
VSAM
651: 03/07(木)18:22 ID:4BnqPTKi(1) AAS
処理速度の遅さが頻繁に問題になっていても、めちゃくちゃな設計とめちゃくちゃなSQLを使うのが優秀な開発者なのがITの世界ではエリートだったりするからなあ
目に見えない部分は評価されにくい
652: 03/09(土)19:05 ID:??? AAS
推敲してレスしなおしてくれないか
653: 03/09(土)21:29 ID:sC2bZ4HS(1) AAS
有名製品でもデータモデルはひどかったりする
654: 04/19(金)07:20 ID:0Ztguvb/(1) AAS
アプリ開発者がただの入れ物として設計してしまうからなあ
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.434s*