何故データベース設計は軽視されるのか？

**NAME IS NULL** · 2012/07/24(火) 22:49:28.17

>>477
レコード数が多いからこそ、カラム数を減らすべきだってことが分からないのか？

**NAME IS NULL** · 2012/07/24(火) 22:55:57.42

COBOL脳だとRDBにおいてはテーブルサイズが大きくなるとパフォーマンスが加速度的に劣化する場合があることを理解できない。

あいつらなんでもかんでも一行づつ処理しようとする。

処理時間=一行の処理時間(一定)×行数

はRDBじゃ通用しないんだよ

**NAME IS NULL** · 2012/07/24(火) 23:29:57.10

某H関連会社に訪れた際、若手ＳＥが仕様レビューを受けていた
「ここでSQLのSUM関数で合計を取得します」
「それ信用できるの？ちゃんと一つずつ足さないとダメだよ」

２１世紀でこれかと驚いた

**477** · 2012/07/26(木) 22:49:50.88

>>478
ケースバイケースだと言ってるんだよ。
絶対どっちか、というものではない。

予備カラムがあっても、理由が充分なら、
それでよいではないか。

**NAME IS NULL** · 2012/07/26(木) 23:25:44.93

予備カラムなんて持たせたら、いざ使う時、意味合いとカラム名が乖離するよね。
検索パフォーマンスが必要無いならxml型にするって手もあるけど

**NAME IS NULL** · 2012/07/26(木) 23:36:01.31

DB変更は仕様変更になるから別契約だけど
予備項目を活用する分には保守の範囲内で出来るから
予備を多めに作っとくっていうのがあったな

クソだと言われてる設計でも事情でそうなってるのも結構あるよね

**NAME IS NULL** · 2012/07/27(金) 00:24:21.29

予備カラム多用すると、後々どの予備カラムが何の目的で使われてるか分からなくなるw
画面から予備カラムにセットする値にも制限掛からないから、変な値入ってバグってみたり。

**NAME IS NULL** · 2012/07/27(金) 20:28:23.51

そもそも可変長ランダム入出力が基本なRDBのレコードにおいて
予備カラムをあらかじめ作る必要性はうすい

COBOLだから予備カラムつくるんじゃなくて、それが動いているプラットフォームが
固定長バッファのシーケンシャル入出力を基本としてたから必要なだけ

**NAME IS NULL** · 2012/07/28(土) 01:31:34.34

>>439
あんな天下り先確保のための試験を
ボッタクリ価格で受けるとか、
怒りが湧いてくる。

**NAME IS NULL** · 2012/07/28(土) 02:12:21.50

まるで意味のない資格では無いだろ。

とはいえ午後1は酷い問題混じってることあるから、選択運の要素が強いけど。

**NAME IS NULL** · 2012/07/28(土) 10:54:33.10

>>486
安いので許せや

**NAME IS NULL** · 2012/07/28(土) 10:55:35.76

>>487
酷い問題のってどれですか

**NAME IS NULL** · 2012/08/04(土) 09:12:32.99

>>487-488
>>486 は取れなかった奴の言い訳じゃね (w

**NAME IS NULL** · 2013/10/13(日) 20:53:47.26

保守age

**ＮＰＣさん** · 2014/01/15(水) 06:23:23.94

66427727358778987766457232625+40=66427727358778987766457232665
www.2ch.net
toro.2ch.net/db/
toro.2ch.net/test/read.cgi/db/1228061247/

**NAME IS NULL** · 2014/01/29(水) 00:39:34.78

>>1
せっかく合意のとれた業務フローとテーブル設計を
180度ひっくり返しに来る奴（客・身内問わず）がいるから
それが最初からわかってるから軽視される

**NAME IS NULL** · 2014/01/29(水) 01:16:58.43

この前某中古ショップですごく安いパソコンを発見しました。
ちょうど私はその時新しいパソコンがほしいと思っていて本当に買おうかと悩みました。
というのも２０１１年製でCPUがCorei5、メモリも４ＧＢあるしHDDが１ＴＢもあってお値段がなんと３８０００円でした。
まだ発売日からあまり期間も経っていないしこのスペックでこの値段ならかなりお買い得かなと思ったのですが、問題は少スペース型というか拡張性がないタイプのものだったんです。
それにグラフィックボードもついておらず後々の事を考えるとやめといたほうがいいかなという結論に達しました。
結局ネットでBTOのパソコンを後で注文しました。
いやぁしかしまさか周りにあるパソコンの中で一番スペックが高いのに一番安い値段になってるとは思いませんでした。

http://toro.2ch.net/test/read.cgi/hp/1382021349/
http://toro.2ch.net/test/read.cgi/hp/1352858999/

**NAME IS NULL** · 2014/02/02(日) 00:06:45.66

自分で競馬データベースや競馬新聞を作りたいんだが
どんなプログラミング言語を学習すればいいですか？
競馬を通してプログラミングを勉強すれば楽しいと思うし、
仕事にも役立つとなれば一石二鳥。

データーソースは外部の物を利用。

**NAME IS NULL** · 2014/02/14(金) 21:34:14.86

↓こういう提供されたexcelデータがあるとします
　　　　　日本小学校
　　　　　１年　　　|２年
　　　　　1組　２組 |　1組　　２組
座席番号１安藤　伊藤|五十嵐　飯田
座席番号２臼井　榎本|上田　　岡田
座席番号３０（全クラス３０で統一）

↑をデータベースに格納しようとすると
こういう風な感じになると思いますが
日本小学校一年　1組　座席番号1　安藤
日本小学校一年　1組　座席番号2　山田
日本小学校２年　1組　座席番号1　伊藤

視覚的に編集するには前者の方がやりやすいですよね
こういう前者のデータ構造は何か名称があったりしますでしょうか

また前者のテーブルの横にアメリカ小学校を追加する場合もあります
こういうデータを管理するために何かいいツールとかないでしょうか？
データベースに格納できるよう変換してくれたり

　　　　　１年　　　|２年
　　　　　1組　２組 |　1組　　２組
日　座席番号１安藤　伊藤|五十嵐　飯田
本　座席番号２臼井　榎本|上田　　岡田
小　
ア　座席番号１ボブ　トム
メ　座席番号２マリー
リ
カ
小

こんな風にしたり

**NAME IS NULL** · 2014/02/15(土) 11:02:45.63

>>496
そもそもそれはデータ構造と呼べる代物かが疑問なんだが
表現方法としては「マトリクス表」とか呼べばいいんじゃね？

ツール？excel使えばいいじゃん
excel VBAでcsvを出力するマクロを作れば終いだ

**NAME IS NULL** · 2014/02/15(土) 20:26:44.89

やっぱ自作ですかね
どうもです！

**NAME IS NULL** · 2014/07/22(火) 14:35:32.25

★2ch勢いランキングサイトリスト★

◎ +ニュース板
・ 2NN
・ 2chTimes
◎ +ニュース板新着
・ 2NN新着
・ Headline BBY
・ unker Headline
◎ +ニュース板他
・ Desktop2ch
・記者別一覧
◎ 全板
・全板縦断勢いランキング
・スレッドランキング総合ランキング
・ログ速
◎ 全板実況込み
・ 2勢
・ READ2CH
・ i-ikioi

※ 要サイト名検索

**NAME IS NULL** · 2014/07/23(水) 19:35:38.12

　埼玉県警川口署は２０日、小学生の女児の下半身を触ったとして強制わいせつの疑いで、
同県蕨市南町、東大大学院博士課程の内藤慶一容疑者（２６）を逮捕した。

　川口署によると、内藤容疑者は「研究が忙しく、ストレスがたまっていた。少女に興味があった」と供述している。

　逮捕容疑は１月４日午後５時半ごろ、埼玉県川口市並木２丁目の書店１階の階段近くで、
当時９歳で小学４年だった女児の下半身を触った疑い。

　書店の防犯カメラ画像を解析するなどして内藤容疑者が浮上した。
３月上旬に近くのスーパーで別の女児が下半身を触られる被害があり、関連を調べる。
http://www.47news.jp/CN/201407/CN2014072001001585.html

**NAME IS NULL** · 2015/02/08(日) 18:11:12.29

色々あるけど結論として
役に立たないんだよ。

まじで。

**NAME IS NULL** · 2015/08/22(土) 10:22:18.62

テーブル設計がきちんとしてるだけで
オプティマイザがいい仕事するんやで

**NAME IS NULL** · 2015/10/22(木) 23:00:56.18

☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。

**NAME IS NULL** · 2015/11/22(日) 12:48:10.28

インターフェイスが決まってからデータベースを設計するのに今更気づいた。

**NAME IS NULL** · 2015/11/24(火) 20:00:17.75

>>504
インターフェイスって何？

**NAME IS NULL** · 2015/11/24(火) 21:21:06.03

> 748 名前：名無しピーポ君：2015/11/24(火) 12:28:48.30
> 噂の日教組保育士がまた報復やったってさ
>
> 749 名前：名無しピーポ君：2015/11/24(火) 12:41:16.38
> あーーーー在日居住地にある能満幼稚園の

**NAME IS NULL** · 2015/12/10(木) 17:38:16.52

>>504
システム間インターフェイスだとしても、ユーザーインターフェイスだとしても間違っているか？

**NAME IS NULL** · 2015/12/10(木) 17:40:03.26

データをどう持つのかを初めから考えていないとUIもデータモデルも失敗する。

**NAME IS NULL** · 2016/01/21(木) 04:46:50.28

途中で持ち方換える事もあるけどな

**NAME IS NULL** · 2016/12/16(金) 06:28:37.13

柔軟に設計しろよ。ただしスタンダードはある。

**NAME IS NULL** · 2017/08/18(金) 10:52:33.77

>>216
Googleの検索システムがKVSの御時世に何言ってっだこいつ？

**NAME IS NULL** · 2017/08/18(金) 13:05:23.32

>>511
8年前の書き込みに何言ってっだこいつ？

**NAME IS NULL** · 2017/08/18(金) 22:51:50.80

>>511
>>512
自演なのかも知れんがクッソワロタ

**NAME IS NULL** · 2017/08/22(火) 21:43:07.29

スレタイが気になっから来てみたが
データベース設計を「テーブルレイアウトを決める」という作業と捉えてる時点でDB設計を軽視してるんだよね

テーブル設計はDB設計の中でも末端作業だから、そういう認識から変えたほうがいい気がする
経験上、DB設計出来ますってやつのうち概念設計や論理設計がまともにできるやつは20人に1人いればいいほう

**NAME IS NULL** · 2017/08/23(水) 00:07:55.54

論理設計とかについて偉そうに語れるほど
論理設計が出来るとは思ってないが

テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことを

末端作業と言って軽視すのは
どうかと思うよ

**NAME IS NULL** · 2017/08/23(水) 01:15:21.19

軽視してるってわけでもないんだがテーブルレイアウトを決めるのはDB設計全体の一部でしかなく
それも最後のほうにやる作業だって意味

ある業務に関わるデータをどういうデータ構造で管理するのが適切かを考えようとしてる時に
「Excelのフォーマットを決める」ような作業が、RDBなら「テーブルレイアウトを決める」という作業

「どういうExcelフォーマットにしようか」ってのと同じ観点から始めて
テーブル定義書と申し訳程度のER図を書くことがDB設計だと思ってる人がすごく多い
DB設計はテーブルレイアウトを決める作業じゃなくて、DB設計の結果としてテーブルレイアウトが決まる

**NAME IS NULL** · 2017/08/23(水) 02:10:01.71

システム設計を「クラスの定義を決める」作業として捉えてるのと同じって言ったほうがわかりやすいか

クラス図とクラス定義書を書くのが設計だと思ってる人はほとんどいないけど
DB設計においてはそのレベルの人がたくさんいるよね

**NAME IS NULL** · 2017/08/23(水) 08:18:56.25

テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ

それだけの話

それらを必要に応じて
敢えて崩すのはアリだけど
正規化をやらないとかはありえない

**NAME IS NULL** · 2017/08/23(水) 22:05:49.25

>>518
それって結局、DB設計をテーブルレイアウトを決める作業と捉えてて
テーブルレイアウトを決めるのにはそれらが最も大切だって言ってるんじゃねーの？

例えば正規化ってOOにおけるSRPやOCPみたいな設計原則に相当するものだよ
SRPに従ってクラスを分けることがシステムやプログラム全体の設計の中で最も大切だったりする？
クラス定義においてならまだ理解できるけどさ

それと同じで正規化の知識は必須だし、業務アプリなら当然その設計原則に従ったモデルを作るんだけど
DB設計において正規化することが最も大切なわけではないよ

**NAME IS NULL** · 2017/08/23(水) 22:20:54.73

>>519
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ

それより大切なことって何かな？

**NAME IS NULL** · 2017/08/23(水) 22:52:53.62

>>1
>何故データベース設計は軽視されるのか？

理由を考えてみたが、教育不足と経験不足が大きな原因だと思う

まず一般的なプログラムの設計に比べてDB設計はその機会自体が圧倒的に少ない
それはプログラムに比べてDBは数も少なくライフライクルも長いし、プログラム設計に比べればDB設計は一人で担当できる規模が大きいから

機会自体が少ないから、業務アプリに関わるエンジニアの中で繰り返し何度もDB設計の経験が積めるような人も当然少ないし
その中でも優れたDB設計者となるともっと少ない

だから一部のDB設計に特化した会社や部門を除くと、かなり大手でもDB設計に関してまともに後進の教育や育成ができるような人はすごく稀
そうでない人たちに教育・育成されたエンジニアが大多数を占めるからDB設計が軽視されることが自然と多くなる

DB設計能力の低いと、どうしてもプログラムの処理に重きを置きがちで
プログラムからデータをどう使いたいかという観点でDBを設計しちゃう人が多い(=DB設計の軽視)
そういうやり方を見てきた人たちはそれが当たり前だと考えるからDB設計軽視が再生産される

個人レベルでは優れた教育を受けたり、数多くの経験を積むことで負の連鎖からは抜け出せそう
会社レベルではDB設計の機会の少なさと重要性を認識して、優れた育成者を多く育てる努力が必須かな

**NAME IS NULL** · 2017/08/23(水) 22:56:37.93

>>520
DB設計において最も重要なことは
ビジネスドメインと要求を深く理解して適切なデータモデルを作ること

**NAME IS NULL** · 2017/08/23(水) 23:33:45.34

>>522
ビジネスドメインと要求を深く理解するというのは
そもそもデータベース設計レベルの話かい？

**NAME IS NULL** · 2017/08/24(木) 00:54:44.89

>>523
そうだよ
ちゃんとしたデータベース設計には必須だよ
対象のドメインと要求を深く理解しないと適切なデータモデルは作れないから

だからプログラムの実装に近い人がDB設計するよりも
要求分析をする人で技術力もある人がDB設計をしたほうがまともな設計ができることが多いよ
後者の場合は組織や責任者がDB設計にとって何が重要か理解しててDB設計を軽視してないっていう理由も大きいけどね。

**NAME IS NULL** · 2017/08/24(木) 01:09:48.34

>>524
ふむ

要求分析をする人で技術力もある人が
ビジネスドメインと要求を深く理解して適切なデータモデルを作れば

テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するのは
やらなくて良いと仰りたいなかな？

**NAME IS NULL** · 2017/08/24(木) 01:22:40.19

>>523
大局的には「計算機で効率的に処理可能な形式で対象を表現したモデル」――「対象領域の計算機向けモデル」（数理モデルとか、あっちの意味でのモデル）の構築こそが根本であるので、
それを重要視する、ということ？

でも個人的には正規化などのtuple（型）の設計しながらフィードバックしていって上記の概念を理解・把握・構築している感じがある
具象から始まり抽象化する、というか、つまり何なのか、を追求していくとそこに至るというか

なので個人的には>>522 兼 >>520 ww

データベースに長けた人からみるとまた違うのかな？

**NAME IS NULL** · 2017/08/24(木) 01:41:42.12

>>526
ビジネスドメインと要求を深く理解して適切なデータモデルを作る

という作業の中に

テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する

という作業が内包されてるなら
そもそも比較することが間違い

**NAME IS NULL** · 2017/08/27(日) 03:26:41.28

正規化も、データ型の決定も、それより上位の工程がちゃんとできてれば
ほぼ機械的に決定して薦めれるからなぁ

**NAME IS NULL** · 2017/08/27(日) 11:26:11.65

DB設計と、要件定義やモデリングとかとを同一視しすぎてるような気もするな。
本質的に不可分なのだという主張なら、それはそれというか、方向性としてはわかる。
もっとも、そうなるとその線引きは難しいだろうけど。

**NAME IS NULL** · 2017/08/27(日) 13:03:07.94

>>528
機械的にやれるからと言って軽視するのが
そもそも間違い

**NAME IS NULL** · 2017/08/27(日) 16:06:51.20

>>529
DB設計の一部である概念設計は要件定義の一部
という考え方なので不可分といえば不可分

フェーズの呼び方は会社によって違うだろうけど
要件定義時に概念設計,
基本設計時に論理設計,
詳細設計時に物理設計が基本

DB設計の質を一番大きく左右するのが概念設計
エンティティの漏れやリレーションの間違いがあると
制約の定義漏れやデータ型の選択ミスとは比べられないレベルの悪影響が出る
(正規化の多くは概念設計で行われる)

もっと狭義のDB設計フェーズという考え方があるのかもしれないけど
そういう考え方自体がデータベース設計軽視につながっている可能性があるのかも

**NAME IS NULL** · 2017/08/27(日) 19:45:14.75

>>531
その考え方を徹底すると、DB設計はなくなりそう。ｗ

**NAME IS NULL** · 2017/08/28(月) 10:28:40.21

>>530
機械的にやれるということと、軽視するということには関連性がない
君はいったい何と戦ってるんだ？

**NAME IS NULL** · 2017/08/28(月) 19:01:17.75

>>531
概念設計、論理設計、物理設計のどの段階で正規化するの？

**NAME IS NULL** · 2017/08/28(月) 19:05:55.75

>>534
普通は初めから正規化したようなまとまりで考える。

**NAME IS NULL** · 2017/08/28(月) 22:24:53.78

概念モデルに正規化もなにも無いと思うけど
概念を正しく論理モデルにする作業が正規化だろ

**NAME IS NULL** · 2017/08/28(月) 22:34:45.38

>>534

>>535の言うとおり、どこかで正規化の工程があるというよりは
最初からほぼ正規化されたモデルで考えて
モデルを改善するたびに正規化違反をチェックしながら都度対応する

なので概念設計が終わったらその段階まででの正規化も終わってる
論理設計時にはサロゲートキーや削除フラグみたいなのが追加されて
正規化が崩れる場合があるからその場合も都度判断して対応する
物理設計では正規化に関わるようなところは基本的にいじらない

DB概念設計のインプットになるようなドメインモデリングをする時は
概念間の関係とわかりやすさを重視するので正規化されてるかどうかは気にしない

**NAME IS NULL** · 2017/12/29(金) 11:16:22.87

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

DX2Z9GYZ7S

**NAME IS NULL** · 2018/10/13(土) 19:50:55.09

https://imgur.com/FAF05na.jpg

**NAME IS NULL** · 2020/03/17(火) 17:13:56.31

そういえば、昔、DB仕様が悪くて、日次夜間バッチ処理が2日かかるシステムがあったな。

**NAME IS NULL** · 2020/03/30(月) 23:47:53.57

今の現場にも「正規化！正規化！」キチがおる、確かに少し歪んだところもあるが、締めのバッチなどでやむを得ず放置されている
で、「じゃ、キッチリ正規化してみてよ」ってお願いしたら「影響範囲がー」とか
お前はアホか？お前はそれを改善するために「正規化！」言うてたんやろ
もう。口出しすんなってＰＭに怒られてたわ

**NAME IS NULL** · 2020/03/31(火) 19:03:26.69

わかってないやつほど正規化と言ってしまう。用語で知ったかぶりをする典型例。

**NAME IS NULL** · 2020/03/31(火) 19:48:49.04

「良い設計」を専門用語で言うと「正規化」だと思ってるような奴がこの板にも多いよね

**NAME IS NULL** · 2020/11/27(金) 18:40:16.40

いまどきまったく正規化されていない表を思いつく方が難しい。

**NAME IS NULL** · 2020/11/28(土) 00:34:19.70

それが難しいようじゃあデータベース設計に向いてないんじゃないかねぇ。

**NAME IS NULL** · 2020/11/28(土) 00:44:18.27

>>545
データベース設計よりも、日本語が向いてなさそう。ｗ

**NAME IS NULL** · 2020/11/28(土) 00:56:27.32

本人は本気で「難しい」と思ってるのかもしれんよ

**NAME IS NULL** · 2020/11/29(日) 21:29:54.99

すべてを2次元の表であらわしているデータなんて、Excelでも見たことない。

**NAME IS NULL** · 2020/11/29(日) 22:03:27.79

つか、RDBの表は2次元じゃないがな。

**NAME IS NULL** · 2020/11/30(月) 01:35:47.36

テーブルのことを表、インデックスを索引と呼ぶのはいまだに違和感がある

**NAME IS NULL** · 2020/12/04(金) 10:47:51.96

軽視していないけど、人間の脳には難しいからだよ。
人件費がいくらあっても足りない。
ディープラーニングに任せたほうがいい分野だよ。

**NAME IS NULL** · 2020/12/04(金) 21:54:56.41

設計のどの部分をディープラーニングに任せるって話なんだろうか

**NAME IS NULL** · 2020/12/08(火) 01:32:48.66

>>549
あなた職場では嫌われているよね

**NAME IS NULL** · 2020/12/08(火) 01:33:42.67

>>550
製品マニュアルを呼んだことがありますか？

**NAME IS NULL** · 2020/12/08(火) 01:34:02.37

>>550
製品マニュアルを読んだことがありますか？

**NAME IS NULL** · 2020/12/08(火) 02:01:56.21

>>553
おまえもそうやと思うで？

**NAME IS NULL** · 2020/12/28(月) 18:37:06.97

軽視したくないけどさ、設計が良いかどうかってどうやって見分けるの？
正規化をバカにする人が多いけど、あれ以外に人に教えられる観点ってあるのか？

**NAME IS NULL** · 2020/12/28(月) 21:49:44.98

RDBに関して言えば正規化ほど体系化されててわかりやすい観点は他にはないね

良い設計かどうかは求められた状況に対してどれだけ高い品質特性を備えているかで
観点としては機能性以外に使いやすさ、わかりやすさ、堅牢性、運用性、耐障害性、
保守性(柔軟性/拡張性/変更容易性)、効率性(時間/資源)、移植性なんかがある

正規化はデータ整合性、使いやすさ、保守性あたりを高めようとするもの

**NAME IS NULL** · 2020/12/28(月) 22:15:27.79

正規化は非正規形で起きる問題(更新異常等)を防ぐものであってそれ以上ではない。
実際、更新異常を考慮する必要のないDWHなどでは不要。

**NAME IS NULL** · 2020/12/28(月) 22:49:55.68

>>559
DWHでも更新異常は考慮する必要あるよ
更新異常ってCRUDのUだけのことじゃないから

DWHは正規化が不要なんじゃなく
ソースデータの正規形をベースに特定の分析用途に特化させて非正規化してるだけ

スタースキーマもスノーフレークもDWHに特化した非正規化パターン
非正規形のデメリットはDWHだろうがOLTPだろうが同じ

**NAME IS NULL** · 2020/12/28(月) 23:05:07.35

>ソースデータの正規形をベースに特定の分析用途に特化させて非正規化してるだけ

正規形非正規形というのはあくまでもリレーションの表現であって抽象的なデータモデルには
そんな区別はないんだが。
だからDWHにおいて

>ソースデータの正規形

通常これは実在しない。

**NAME IS NULL** · 2020/12/28(月) 23:56:41.44

>>561
ごめん、何言ってるかわからない
抽象的なデータモデルって何のこと？どっから出てきたの？

**NAME IS NULL** · 2020/12/29(火) 03:14:05.40

更新異常が発生しにくいだけで
考慮する必要がないわけないわな
>>561はエアプが即バレして煙に巻きたいのだろう

**NAME IS NULL** · 2020/12/29(火) 09:14:29.22

>ソースデータの正規形

これが抽象的なデータモデルを指しているのかと思ったんだが、そうでないなら話は簡単。
DWHは「ソースデータの正規形」が存在することを要求しないんで>>560は正しくない。
データソースが正規化された他のDBであることはあるが、それはそのシステム自身の
要求によって正規化されているだけ。

**NAME IS NULL** · 2020/12/29(火) 12:56:45.72

>>557
正規化がバカにされてるんじゃなく
正規化を理解してなかったり正規化されてるかどうか以外にDB設計を見る目がないのに
ドヤ顔でDB設計を語ろうとしてる人間がバカにされてるんだと思うぞ

**NAME IS NULL** · 2020/12/29(火) 14:29:23.16

それな
ちょうど当てはまるやつがいるな

**NAME IS NULL** · 2020/12/29(火) 14:46:08.18

頭おかしいやつには下手に触らず黙ってスルー推奨

**NAME IS NULL** · 2020/12/30(水) 00:27:51.52

RDBと関係ないRやPython使った統計処理の分野でも
分析をやりやすくするために下準備としてDBで言うところの正規化をしてる
更新異常を考慮する必要は全くないけど

**NAME IS NULL** · 2020/12/30(水) 09:11:39.06

そういうのごっちゃにすると話が発散するからやめて。
そもそもその「正規化」って、リレーションの正規化と違ってなにをどうするかきちんと定義されたものじゃないでしょ。

**NAME IS NULL** · 2020/12/30(水) 09:15:25.16

それに統計解析向けの加工って、クレンジングは最初に必要かもしれないけどあとは解析しやすいようにJOINしまくるのがふつう。
DWHのスタースキーマから任意に抽出した1つの表の形のデータセット、あれがまさに統計解析向けのもの。

**NAME IS NULL** · 2020/12/30(水) 18:11:29.74

エアプDWHの次はエアプ統計解析かよw
なんでろくにやったこともない事を語りたがるのかね

**NAME IS NULL** · 2020/12/30(水) 18:23:27.87

データベース設計は軽視されるの原因と
エアプ野郎が語りたがる原因の一つに
素人に毛が生えたような人間には難しさが分からず
自分でもできそうに思えてしまうところにある

**NAME IS NULL** · 2020/12/30(水) 22:22:42.93

>>571
誰のどのレスに対して言っているのか曖昧でよくわからんが、とりあえずどのレスの
どこがどう違っているのかはっきり書いたら？
反論は受けたくないけどマウントだけ取った気分になりたい中学生じゃなけりゃ。

**NAME IS NULL** · 2020/12/31(木) 00:08:25.03

エアプ素人さんはスタースキーマのファクトとディメンションがそれぞれ第何正規形か考えると良いと思うよ

>>565の言葉を借りれば正規化すら理解してないのにドヤ顔で語ろうとしてるのが丸わかりだから

**NAME IS NULL** · 2021/01/02(土) 16:36:20.20

ど底辺の土方グラマーだけどDB設計させられて「なんでちゃんとしたDB屋に頼まないんだよ、DBって根幹部分で大切だろ！」って疑問だったけどここ見て納得。
日本の企業が作る(使う）システムがクソな理由も・・・

**NAME IS NULL** · 2021/01/02(土) 18:35:41.55

ある意味当たってる。
そうやってしばらくして、曲がりなりにもER図書いたり正規化ができるようになって
いっぱしのDB屋を気取れるようになったら彼等の仲間入り。

**NAME IS NULL** · 2021/01/03(日) 14:52:40.06

>>575
根幹部分だからこそDB中心のシステムを作る開発者なら誰もが身につけておくべきスキルだぞ

要件定義や基本設計を含めて依頼するならともかく
DB設計だけを外部に依頼するのは今の時代にはそぐわないので設計専業のDB屋は絶滅危惧種

**NAME IS NULL** · 2021/01/04(月) 05:23:06.48

ホンマにうわさ以上に凄いのが金さんの億様株レシピて投資ブログ。
ここまじで神すぎる！
めちゃ当てまくる。
おすすめなのは危険な銘柄と宝石の銘柄て記事に出てくる銘柄。

**NAME IS NULL** · 2021/01/12(火) 12:19:00.49

プログラム組まないやつが設計すると保守性重視になるよな…
人間がパッと見て理解しやすい設計にしがち　
ナチュラルキー多用したり

**NAME IS NULL** · 2021/01/12(火) 15:18:33.28

>>579
ナチュラルキーを多用してるにもかかわらず保守性が高いならいいんじゃね

**NAME IS NULL** · 2021/01/12(火) 16:22:51.65

>>580
>>579は「保守性」と言っちゃってるが、実はたぶん保守性の話やないな。
初見のわかりやすさしか見えてないような、困ったちゃんの話なんやろな。

**NAME IS NULL** · 2021/01/12(火) 17:06:29.79

そうすると保守性を理解してない>>579が困ったちゃんってことになる

**NAME IS NULL** · 2021/01/12(火) 17:48:57.44

すまん、保守性って言葉が悪かったな
プログラムの保守性ではなくて
ユーザーからの問い合わせ時にデータ見てパッとわかるテーブル構造を好む

**NAME IS NULL** · 2021/01/12(火) 20:38:59.75

人間にとっての見やすさというかわかりやすさも重要な品質要素だからね
それを犠牲にして得られるメリットとのバランス次第
何と何をトレードオフしようとしてるのか理解してないうちはまともな設計は期待できない

**NAME IS NULL** · 2021/01/12(火) 21:08:10.26

パッと見理解しやすくて保守性も高いならいいことずくめに読めるが。

たぶん言いたいことは逆になにか問題があるということなんだろうけど
結論書いてないから何を言いたいのかわからない。

**NAME IS NULL** · 2021/01/12(火) 21:28:46.10

>>585
理解力なさすぎ。
人工キー+JOIN前提みたいな、不慣れだとややこしげに見えるテーブルを組みたがらない素人の話なだけやろ。

**NAME IS NULL** · 2021/01/12(火) 21:37:08.48

だから、そこで自然キーの欠点や人工キーの利点を説明しなきゃ何を言いたいのかわからんだろ。
人工キーが自然キーより優れているのは自明だと思ってるとかそんなとこかね。

**NAME IS NULL** · 2021/01/12(火) 21:45:26.42

>>587
SQL書くときに条件や結合は少ないほうがバグが発生しにくい
プログラマにとってはサロゲートキーの方がわかりやすい

しかしサロゲートキーだと生データを見たときにわかりにくいことがある

ナチュラルキーとサロゲートキーの代表的なメリットデメリットだと思うけど…

その辺天秤にかけてこのテーブルはサロゲートキー、このテーブルはナチュラルキーと決定できるのは
設計もプログラムも保守もやる人。
どれか一つしかやらない人はこのへんのさじ加減わからないのでは。

**NAME IS NULL** · 2021/01/12(火) 21:57:42.32

こうやってブレイクダウンするとどこに誤解があるか見えてくる。

複合キーは扱いづらいのでかわりにサロゲートキーを使うことはあるが
自然キーだと一律にサロゲートキーより扱いづらいなんて理由はないだろう。

**NAME IS NULL** · 2021/01/12(火) 22:30:44.50

>>589
おっしゃる通り複合キーの場合だな
大変失礼しました

設計と保守しかしない年配のSEさんはサロゲートキーを知らずに複合キーを使いまくる傾向にある
プログラマは若かったり雇われだったりなので口出しできずにクソシステムの出来上がり

**NAME IS NULL** · 2021/01/12(火) 22:34:47.77

>>589
めんどくさ。
そんな話じゃなかったやろ。。。

おまえは、自分が理解できない話を、自分が理解できるようにしたいだけ。ｗ
何が「ブレイクダウン」や。ｗ

**NAME IS NULL** · 2021/01/12(火) 22:41:52.84

>そんな話じゃなかったやろ。。。

どういう話なのか、お前はまず言いたいことを結論からハッキリ書くようにしろ。

**NAME IS NULL** · 2021/01/13(水) 00:21:46.78

呼び名はともかく人工キーは80~90年代でも普通に使われてただろうから年配だろうが知らないわけない

複合キーは見てわかりやすいわけじゃないが
人工キーに比べると整合性を維持する設計が簡単なんだよ
SQL書く時は面倒くさいから嫌がられるけど不整合が発生するのに比べればマシだから

**NAME IS NULL** · 2021/01/13(水) 00:38:42.76

>>592
自分の理解力を棚に上げんなよ。

**NAME IS NULL** · 2021/01/13(水) 00:53:04.45

>>593
不整合はユニーク制約つければいいんでないの

**NAME IS NULL** · 2021/01/13(水) 08:06:07.69

同じ型の単純キー同士なら、それが自然キーか人工キーかで扱いやすさが変わることはないやね。

**NAME IS NULL** · 2021/01/13(水) 08:13:51.20

>>596
変わらない
複合キーが問題

**NAME IS NULL** · 2021/01/14(木) 02:05:44.63

>>593
ちょっと、「整合性を維持する設計」について詳しく説明してくれ

**NAME IS NULL** · 2021/01/20(水) 22:55:59.22

>>557
仕様変更に強いかどうか。それと人間にとってわかりやすいかどうか。正規化の話はもっともらしいが、ちゃんとしたテストと運用・保守をやっていれば、ただの非現実的な理屈だとわかる。

**NAME IS NULL** · 2021/01/20(水) 23:01:10.32

>>593
論理的な整合性をアプリケーションで担保する。そうでないとアプリケーションのテストも難しい。

**NAME IS NULL** · 2021/01/20(水) 23:02:58.59

>>598
彼はアプリ屋と壁を作るタイプだから、かかわらない方がいいよ。

**NAME IS NULL** · 2021/01/20(水) 23:16:12.27

>>599
アホなの？

**NAME IS NULL** · 2021/01/22(金) 08:45:35.16

>>599
このちゃんとした
ってのがどれだけ難しいか

**NAME IS NULL** · 2021/01/25(月) 05:16:41.94

よく読め

**575** · 2021/06/22(火) 17:07:34.18

ははは・・・
晴れて？「DB屋（）」の仲間入りしそうだ・・・
PostgreSQL9.3とSQLServer2005を、プライベートで、弄ったことあるだけなのに（実務ではOracle11の炎上案件の燃料として放り込まれたぐらい）
7月からPostgreSQL12がフロントエンドで、Oracle（ナンバリングは効いてない）がバックエンドで動いてる「工場のFAのすごいやつと思えば間違いじゃない（スマートファクトリー）」とかいう謎の説明されたシステムのDBチームに配属になったわ・・・
メカ系や移動体通信系のファームしか経験ないつにいきなり・・・
ズブの素人よりはマシかもしれないけどDBそのもののスキルだったらそこらの学生以下だよ俺・・・orz.

**NAME IS NULL** · 2021/06/22(火) 18:09:02.74

いまどきDBでチームがあるのか
ある意味すごいな

**NAME IS NULL** · 2021/06/22(火) 18:59:21.66

>>606
開発対象が、工場の機械からデータ受け取る中継ボックスみたいなところから、工場の中間サーバから複数の工場の情報をまとめるサーバまで一貫してるんだそうな。
そして中継ボックス、中間サーバ、全体の情報あつめるサーバってのを全部面倒見てる１０人ほどのチームとのこと。
まだ現場に入ってないから実態判らんけど、門外漢な俺を採用しちゃうところだし、上下どころか横の連携もまともにとれないようなカオスなところでもおかしくないって個人的な経験則が言ってる。

他に仕事ないから受けたけど、今から「どんなとこかなー？　抜けるとしたらどうやって抜けようかなー？」って考えてるｗ

**NAME IS NULL** · 2021/06/22(火) 21:26:23.41

もし関係者が見たら、特定できそうやな。ｗ
ほどほどにしとけよ。

**NAME IS NULL** · 2021/06/26(土) 18:20:28.11

データベースのテーブル設計書ってどうしてる?
エクセル方眼紙にしてかいてるんだけど、なんかいいのないのかな

**NAME IS NULL** · 2021/06/26(土) 23:14:34.00

>>609
MySQL Workbenchはどや？
最近は使ってないから知らんが。

**NAME IS NULL** · 2021/07/03(土) 17:38:43.26

>>609
A5Mk-Ⅱがよく使われている。

**NAME IS NULL** · 2021/10/13(水) 12:36:34.50

データベーススペシャリストでよく問われるページサイズとか空き容量率とかどのメーカーのDBをターゲットにしてるんや？
教えてくれ

**NAME IS NULL** · 2021/10/13(水) 13:54:50.17

特にどのDBMSをターゲットにしてるとかないぞ
一般的なBTreeを前提にしてるだけ

**ド底辺PG** · 2021/11/10(水) 22:00:45.28

プロジェクトが燃え尽きたから別の案件に燃料しに行ったんだが、TEXT（可変長文字列）をPKにしてINDEX張ってて「パフォーマンス出ねぇ！」ってやってんですけど・・・
ちょう乱暴に描くと
CREATE TABLE T_TAGS(
　JPN AS TEXT NOT NULL,
　ENG AS TEXT,
　・・・品詞とか同義語とかの定義いろいろ・・・
　PRIMARY KEY(JPN)
)
て感じの定義で、SELECTのサブクエリとかでも ON TBL1.JPN = ・・・　みたいにテキストのカラムをJOINしてるんすよ？

ドテ・イ・ヘーンな俺でも「なんで数値でIDのカラムを作らないの？」ぐらいの疑問はあるんだけど、
これって「データベースあるある」だったりするの？

**NAME IS NULL** · 2021/11/10(水) 22:40:02.10

遅いのがTEXTのせいだってどうやって判断したの？

**NAME IS NULL** · 2021/11/11(木) 00:02:07.19

>>614
>これって「データベースあるある」だったりするの？
文字列をPKに使うかどうかは状況による
絶対避けるというほどのものでもない
個人的には可変長は極力避けるけどパフォーマンスクリティカルなシステムじゃなければ
全部可変長で揃えてても特に問題なかったりする

PKを数値にしたバージョン作ってさくっと比較すればいいんじゃん？

**NAME IS NULL** · 2021/11/11(木) 19:06:31.16

>>614
あなたの言っていることは頭がおかしいくらい変なことを言っている。

たまたまいままで見てきたテーブルの主キー項目が数値型だっただけで、根拠のない思い込みをしてないか？

念を押すと、頭のおかしい発言だぞ。

**NAME IS NULL** · 2021/11/11(木) 19:36:50.37

>>614
そのTEXT型がラージオブジェクト型というオチのネタ書き込みじゃないだろうな？

**NAME IS NULL** · 2021/11/11(木) 20:16:55.16

>>617
そこまでやないやろ。ｗ
テキストはCOLLATEの懸念があるし、数値のが望ましいのはたしかやし。

まあ、遅いのはテキストキーやからと決めつけてかかってるところはアタマ弱そうやが。
EXPLAINしろっつーの。

**ドテ・イ・ヘーン** · 2021/11/11(木) 21:02:49.02

俺の思い込みが解消されないレベルの現場という前提を認識ください m(_ _)m
マジ学生以下よ、俺のスキル・・・・

EXCELを読んでDBに追記して、DBを参照してEXCELに吐き出すっていう単機能のモジュール２つを並行して「これ、改良して」ってソースだけ渡されたんすよ！
周りが「おそいおそい！」って騒いでて「どんなもんじゃらほい？」って見たらJOINが５～６個あってTEXTのカラムでつないでたんよ。
さすがにSELECTのWHERE句でIN使うほどじゃなかったけど、そういうSQLあっても不思議じゃないレベルのある意味読みやすいSQLでしたｗ

あと、遅いの根拠が「本番で使ってる高負荷に耐える超高性能マシン」で動かした旧バージョンと「テスト用のレンタル屋から借りてるそこそこの性能のマシン」で動かした新バージョンというね・・・

何の比較にもなってねぇじゃん！

という新事実が発覚して、馬鹿らしくなったので今日は仕事放り出して酒飲んできましたｗ

**NAME IS NULL** · 2021/11/11(木) 21:39:46.36

説明の仕方でもうダメ

**NAME IS NULL** · 2021/11/11(木) 21:41:27.49

Excelは何と関係があるのか？

**NAME IS NULL** · 2021/11/11(木) 21:41:54.34

何が遅いのかまったくわかってねえな

**NAME IS NULL** · 2021/11/11(木) 23:17:34.86

charやvarcharの文字列って意味でtextって言ってるんじゃなくtext型って話だったのか・・
sqliteならともかくそれ以外のメジャーなサーバー系DBMSでtext型をPKにすることはまずないぞ

**NAME IS NULL** · 2021/11/12(金) 00:22:09.87

>>620
まとめたら、スペックの違いやろ。
一言ですむわ。ｗ

**NAME IS NULL** · 2021/11/27(土) 20:05:57.75

よくわかってないクライアントがよくわかってないSEに文句言って
よくわかってないフィルターで「お前らの作ったシステム遅いぞゴラァ！」ってなって現場に届くあるある案件ですな。

**NAME IS NULL** · 2022/02/12(土) 03:16:43.64

>>626
性能要件があって、データが増えてもパフォーマンスに問題がないと一言、入っているだけで違うのにな。

**NAME IS NULL** · 2022/02/17(木) 18:59:32.20

まあ、最近はフルSSDのストレージで構築したからsqlがとても早いです。statpack見るととんでもなくディスクREADしてるアホsqlあるけど、システム影響なし、いいんだか悪いんだかですねー

**NAME IS NULL** · 2022/02/22(火) 20:09:39.42

>>628
それで解決したことにするとSSDでもどうにもならないSQLが増産されることになる。

**NAME IS NULL** · 2022/03/24(木) 22:48:04.07

お前ら和歌山県出身の下村拓郎様（35歳独身、元自衛隊）をご存知か、この方は将来素晴しい人物になるから覚えておいて損はないぞ

**NAME IS NULL** · 2022/06/01(水) 14:23:26.36

スキーマの意味よくわかってないけどスキーマ設計書にテーブル構成書いてるよ

**NAME IS NULL** · 2022/06/01(水) 17:38:04.59

それっぽく聞こえるもんねw

**NAME IS NULL** · 2022/06/01(水) 20:43:48.71

スキーマの概念が後付けの製品しか知らないんだろうな

**NAME IS NULL** · 2022/06/01(水) 20:44:36.18

論理的な意味でも括りというのは必要

**NAME IS NULL** · 2023/04/11(火) 20:09:59.45

ER図を見てもよくわからない設計は典型的なダメパターン

だか大手SIerの人間はテストも運用も保守もしたことがないので、理解不能な理屈で設計したがる。

**NAME IS NULL** · 2023/07/08(土) 11:55:41.75

今月から、某メーカー系の現場入り。
50万件ぐらいしか入っていない商品マスターを検索するサイトが激重。
DB設計がもろこぼらーの発想。苦言をやんわり現場に伝えたつもりだが、超絶俺様気質の担当者で、聞き入れる気配なし。
逃げたい。
ちなみに、私はデータベーススペシャリスト餅。

**NAME IS NULL** · 2023/07/08(土) 12:27:10.70

よくある話。
「こぼらーの発想」とか言ってもどこがどう悪いのか他人には伝わらんだろうし。

**NAME IS NULL** · 2023/07/08(土) 14:07:15.72

正規化って概念がないんだろうな
エクセル感覚であるだけ用意する設計なんだろ

**NAME IS NULL** · 2023/07/08(土) 14:41:30.21

検索が重いとしか書かれていないのに正規化が出てくる人もどっこいどっこい。

**NAME IS NULL** · 2023/07/08(土) 17:41:12.84

>ちなみに、私はデータベーススペシャリスト餅。
オレはお前から逃げたいｗ

**NAME IS NULL** · 2023/07/09(日) 05:25:53.28

こぼらーがなぜ嫌われるかをこぼらー自身は検証もしないし、俺流正義マンで権力まで持ってたら。。。。
出くわしたら逃げるしかないんだろうか？

**NAME IS NULL** · 2023/07/09(日) 09:49:24.47

いまどきCOBOL知ってる人も少ないだろうしどこがどのように問題かという具体的な指摘もないから
傍で見ていてよくわからんのよね。検証のしようもないだろう。

**NAME IS NULL** · 2023/07/09(日) 15:34:31.38

RDBをよく知らない構造化ファイル時代のコボラーはJOINを嫌い
COBOLプログラムから一番扱いやすい形の構造化ファイル風にテーブルを作る
でもそんな時代は30年近く前に終わってる上に定形検索だけなら遅くはならないので
データベーススペシャリスト餅ｗが表面しか見ていないだけだろう

**NAME IS NULL** · 2023/07/09(日) 22:27:42.41

「コボラー」と言っとけば多分反論は来ないしお手軽にマウントとった気分になれる便利なワード。

**NAME IS NULL** · 2023/07/10(月) 06:12:24.27

このスレなんてそれが生き甲斐のやつばかりじゃん
初心者の質問にはまともに答えず、馬鹿にして溜飲を下げるだけ

**NAME IS NULL** · 2023/07/10(月) 22:30:41.83

ところで構造化ファイルってどんなん？

**NAME IS NULL** · 2023/08/18(金) 08:33:02.53

ﾎﾎﾎ!(^O^)

**NAME IS NULL** · 2023/09/30(土) 00:06:07.97

まじかよ、それはありえんわ

**NAME IS NULL** · 2023/10/03(火) 22:53:58.05

VSAMとか悪名高いよな

**NAME IS NULL** · 2023/12/03(日) 23:59:55.07

VSAM

**NAME IS NULL** · 2024/03/07(木) 18:22:53.35

処理速度の遅さが頻繁に問題になっていても、めちゃくちゃな設計とめちゃくちゃなSQLを使うのが優秀な開発者なのがITの世界ではエリートだったりするからなあ

目に見えない部分は評価されにくい

**NAME IS NULL** · 2024/03/09(土) 19:05:23.11

推敲してレスしなおしてくれないか

**NAME IS NULL** · 2024/03/09(土) 21:29:57.56

有名製品でもデータモデルはひどかったりする

**NAME IS NULL** · 2024/04/19(金) 07:20:06.15

アプリ開発者がただの入れ物として設計してしまうからなあ

**NAME IS NULL** · 2024/06/06(木) 23:31:21.87

>>654
それだね
他には正規化は遅くなるからだめだというやつもいる
正規化で整理してから多少崩すのは良いけど、そういう事言うやつはたいていめちゃくちゃに作る
もちろんデスペなんて持っちゃいない。
デスペごときをすげえとか言ってるレベル

**NAME IS NULL** · 2024/06/07(金) 00:35:37.40

遅くなるというより、性能はあとからどうにでもなるという謎の思想があるからなあ。

**NAME IS NULL** · 2024/06/07(金) 00:36:14.85

チューニングという言葉が嫌い
なんでチューニングという魔法で解決するのか

**NAME IS NULL** · 2024/06/27(木) 02:42:21.21

見えないところは軽視されてしまう

**NAME IS NULL** · 2024/08/11(日) 06:05:49.51

オラクルクラウド Oracle Cloud Infrastructure (OCI) スレッド
https://www.oracle.com/jp/cloud/