結局開発で最も大切なのはテーブルの正規化と制約 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
開発の中で最も大切
炎上してるプロジェクトは
必ずと言って良いほど
これらを軽視している 整理整頓、ちゃんとしようってことなんだな。
炎上なんてのは当たり前のことが当たり前にできてないってことがほとんどで。 DB側で管理できることは
DB側でやれってことでいいの? そんな話じゃないよ
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する
というのをやっておけば
そうそう炎上なんかしない
という話 そんな馬鹿なと思うかもしれないけど
意外と事実だよ > テーブルを正規化したり
> 適切なデータ型を決定したり
> 制約を定義する
なんて基本中の基本で、それでも炎上するプロジェクト多数なんだが >>7
そんなことはない
炎上するプロジェクトの大半は
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する
というのをやってない 大半: 全体の半分以上
(全体 - 大半)は
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する
事をしてても炎上してるって事だね
定量的なデータあるの? 大半って何% 母集団は何? >>8
だよね
原因と結果を混同してたら根本原因にはたどり着けない デスマ案件の原因Top3
・低品質な要求分析・要件定義
・最初から無理めなスケジュール・予算
・わがまま傲慢顧客
次点
・顧客担当者の社内調整力不足
・PMの調整力・交渉力不足
次々点 (※マネジメントが優秀ならこれらの理由だけで炎上する可能性は小さい)
・既存システム・連携システムの負の遺産
・エンジニアの技術力不足
・採用技術の不確実性 テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する
というのを
A.やっていて炎上するプロジェクト
B.やっていなくて炎上するプロジェクト
C.やっていて炎上しないプロジェクト
D.やっていなくて炎上しないプロジェクト
の4つに分けたら
A<Bであるし
C>Dである >>13
それは幻想
現実には
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する
というのを
やってるかやってないかで
簡単に決まってしまう テーブルを正規化する
適切なデータ型を決定する
制約を定義する
以後この3つを「正規化など」って俺は書くね 正規化などと炎上プロジェクトの間には
ビックリするほど関係性がある
嘘だと思うなら調べてみるといい 肌感覚だけどそりゃそうだろうね。
正規化をまじめに考える余裕もないような現場なら炎上しやすいってか炎上中というか。 結局開発で最も大切なのは仕様
上手くいかないのは仕様が滅茶苦茶な時
仕様が糞だと設計もコードも乱雑になり糞になる
客先常駐やSIerはその場しのぎの糞コードばかり書くことになる
基本自社開発な企業行くと、意味不明な仕様もなくなって楽になった >>18
正規化などを「余裕のある時にやればいいこと」と位置づけた時から炎上は始まってる 正規化・適切なデータ型選択・制約の定義をすれば炎上しないと思ってるなら
自分でそれをやればいいと思うんだけど何でやらないの? >>22
君がやってみれば?
実際に正規化などが行われていない
炎上プロジェクトでさ
上の方でも書いたけど「正規化など」というのは
1.テーブルを正規化する
2.適切なデータ型を決定する
3.制約を定義する
の3つね >>23
>実際に正規化などが行われていない
行われてないって何で他人事なの?
行われてないなら行えばいいじゃん >>25
3つとも基本だからね
当たり前にやってるよ
君がやらない理由を教えてよ >>27
そっか。じゃまず許可出してもらえるように頑張らないといけないね
自分で正規化などをやる立場になったら
そういう基本的なことすら行われない原因が何なのか
もう少し違う視点から見れるようになると思うよ データベースのデータ設計を変更するのは相当広い範囲に影響するからね。
後から入ったやつが簡単にどうこうできることじゃない。
だからこそ大事だという言い分はそんな間違ってはいない。 >>28
「締切に間に合えば好きにしてもらっていいよ」
と言われることもあるし
許可が出ることもあるし
1人プロジェクトなら当然やってる
もちろん
ダメだと言われることもある 確かに正規化とか出来てないと後の辻褄合わせが無茶苦茶大変だわw
データのライフサイクルなんかも全く考慮されてないしw 大企業でもデータを統括する部署なり役職なり全然ないからなw
データベースを単なるデータの入れ物ぐらいにしか思っていない奴がやりたい放題だよw 以前関わったプロジェクトで10個ぐらいのフィルードの複合キーを主キーにしてるテーブルをみた時はさすがに設計した奴死ねと思ったわ
主キーが
都道府県コード + 市区町村コード + 支店コード + 部門コード + ラインコード + 品種コード + グループコード + 製品コード + 製造年月 + 連番
みたいな感じだった
あぁ、こりゃ炎上するわと納得した >>36
クエリかけられる excel と考えればそんなに間違ってもいないかな。
excel だろうとなんだろうと正規化は意識した方が良い。 なるほど確かにエクセルだと、その種の制約かけるのが相当めんどい。 お前が関わったプロジェクト全般てなだけで開発全般とは言えないな。 >>39
いい例だと思うんだけど、それは正規化されてないのが原因じゃないんだよね
そんな主キーでもきちんと正規化されてる場合だってあるから
正規化はたいていの人が少し慣れればほとんど意識せずに出来るようになるけど
それと優れたデータベース設計が出来るかどうかとは全く別の話
だから「データベース設計≒テーブルの正規化」的な考え方の人が
設計してるうちは炎上の可能性は下がらない気がする 正規化ゆうても第1から第5まであるわな
さすがに第5までやるのもやりすぎなんで、ほとんど第3までやろうけど
というか第3正規化できてないと大概炎上するわな 正規化などが行われていなければ
ほぼ確実に炎上するとすれば
結局開発で最も大切なのは正規化などだよ え?なに?正規化することで炎上が解決した事例でもあんの?
ないじゃんwww ■ このスレッドは過去ログ倉庫に格納されています