何故データベース設計は軽視されるのか？ (659ﾚｽ)
上下前次1-新
508: 2015/12/10(木)17:40 ID:9MpJNZja(2/2) AAS
データをどう持つのかを初めから考えていないとUIもデータモデルも失敗する。
509: 2016/01/21(木)04:46 ID:??? AAS
途中で持ち方換える事もあるけどな
510: 2016/12/16(金)06:28 ID:??? AAS
柔軟に設計しろよ。ただしスタンダードはある。
511(2): 2017/08/18(金)10:52 ID:??? AAS
>>216
Googleの検索システムがKVSの御時世に何言ってっだこいつ？
512(1): 2017/08/18(金)13:05 ID:??? AAS
>>511
8年前の書き込みに何言ってっだこいつ？
513: 2017/08/18(金)22:51 ID:41NDIrx4(1) AAS
>>511
>>512
自演なのかも知れんがクッソワロタ
514: 2017/08/22(火)21:43 ID:??? AAS
スレタイが気になっから来てみたが
データベース設計を「テーブルレイアウトを決める」という作業と捉えてる時点でDB設計を軽視してるんだよね
テーブル設計はDB設計の中でも末端作業だから、そういう認識から変えたほうがいい気がする
経験上、DB設計出来ますってやつのうち概念設計や論理設計がまともにできるやつは20人に1人いればいいほう
515: 2017/08/23(水)00:07 ID:xUh+Pb4A(1) AAS
論理設計とかについて偉そうに語れるほど
論理設計が出来るとは思ってないが
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことを
末端作業と言って軽視すのは
どうかと思うよ
516: 2017/08/23(水)01:15 ID:??? AAS
軽視してるってわけでもないんだがテーブルレイアウトを決めるのはDB設計全体の一部でしかなく
それも最後のほうにやる作業だって意味
ある業務に関わるデータをどういうデータ構造で管理するのが適切かを考えようとしてる時に
「Excelのフォーマットを決める」ような作業が、RDBなら「テーブルレイアウトを決める」という作業
「どういうExcelフォーマットにしようか」ってのと同じ観点から始めて
テーブル定義書と申し訳程度のER図を書くことがDB設計だと思ってる人がすごく多い
DB設計はテーブルレイアウトを決める作業じゃなくて、DB設計の結果としてテーブルレイアウトが決まる
517: 2017/08/23(水)02:10 ID:??? AAS
システム設計を「クラスの定義を決める」作業として捉えてるのと同じって言ったほうがわかりやすいか
クラス図とクラス定義書を書くのが設計だと思ってる人はほとんどいないけど
DB設計においてはそのレベルの人がたくさんいるよね
518(1): 2017/08/23(水)08:18 ID:ZPvWL1rI(1) AAS
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それだけの話
それらを必要に応じて
敢えて崩すのはアリだけど
正規化をやらないとかはありえない
519(1): 2017/08/23(水)22:05 ID:??? AAS
>>518
それって結局、DB設計をテーブルレイアウトを決める作業と捉えてて
テーブルレイアウトを決めるのにはそれらが最も大切だって言ってるんじゃねーの？
例えば正規化ってOOにおけるSRPやOCPみたいな設計原則に相当するものだよ
SRPに従ってクラスを分けることがシステムやプログラム全体の設計の中で最も大切だったりする？
クラス定義においてならまだ理解できるけどさ
それと同じで正規化の知識は必須だし、業務アプリなら当然その設計原則に従ったモデルを作るんだけど
DB設計において正規化することが最も大切なわけではないよ
520(2): 2017/08/23(水)22:20 ID:HAUVK0b0(1/2) AAS
>>519
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それより大切なことって何かな？
521: 2017/08/23(水)22:52 ID:??? AAS
>>1
>何故データベース設計は軽視されるのか？
理由を考えてみたが、教育不足と経験不足が大きな原因だと思う
まず一般的なプログラムの設計に比べてDB設計はその機会自体が圧倒的に少ない
それはプログラムに比べてDBは数も少なくライフライクルも長いし、プログラム設計に比べればDB設計は一人で担当できる規模が大きいから
機会自体が少ないから、業務アプリに関わるエンジニアの中で繰り返し何度もDB設計の経験が積めるような人も当然少ないし
その中でも優れたDB設計者となるともっと少ない
だから一部のDB設計に特化した会社や部門を除くと、かなり大手でもDB設計に関してまともに後進の教育や育成ができるような人はすごく稀
そうでない人たちに教育・育成されたエンジニアが大多数を占めるからDB設計が軽視されることが自然と多くなる
省5
522(2): 2017/08/23(水)22:56 ID:??? AAS
>>520
DB設計において最も重要なことは
ビジネスドメインと要求を深く理解して適切なデータモデルを作ること
523(2): 2017/08/23(水)23:33 ID:HAUVK0b0(2/2) AAS
>>522
ビジネスドメインと要求を深く理解するというのは
そもそもデータベース設計レベルの話かい？
524(1): 2017/08/24(木)00:54 ID:??? AAS
>>523
そうだよ
ちゃんとしたデータベース設計には必須だよ
対象のドメインと要求を深く理解しないと適切なデータモデルは作れないから
だからプログラムの実装に近い人がDB設計するよりも
要求分析をする人で技術力もある人がDB設計をしたほうがまともな設計ができることが多いよ
後者の場合は組織や責任者がDB設計にとって何が重要か理解しててDB設計を軽視してないっていう理由も大きいけどね。
525: 2017/08/24(木)01:09 ID:3UP+EtyQ(1/2) AAS
>>524
ふむ
要求分析をする人で技術力もある人が
ビジネスドメインと要求を深く理解して適切なデータモデルを作れば
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するのは
やらなくて良いと仰りたいなかな？
526(1): 2017/08/24(木)01:22 ID:??? AAS
>>523
大局的には「計算機で効率的に処理可能な形式で対象を表現したモデル」――「対象領域の計算機向けモデル」（数理モデルとか、あっちの意味でのモデル）の構築こそが根本であるので、
それを重要視する、ということ？
でも個人的には正規化などのtuple（型）の設計しながらフィードバックしていって上記の概念を理解・把握・構築している感じがある
具象から始まり抽象化する、というか、つまり何なのか、を追求していくとそこに至るというか
なので個人的には>>522 兼 >>520 ww
データベースに長けた人からみるとまた違うのかな？
527: 2017/08/24(木)01:41 ID:3UP+EtyQ(2/2) AAS
>>526
ビジネスドメインと要求を深く理解して適切なデータモデルを作る
という作業の中に
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する
という作業が内包されてるなら
そもそも比較することが間違い
上下前次1-新書関写板覧索設栞歴
あと 132 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 6.756s*