結局開発で最も大切なのはテーブルの正規化と制約 [無断転載禁止]©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 >>48
重要なのは正規化することで炎上しないのが
本当かってことでしょう?w >>49
正規化などが行われていない炎上プロジェクトで
「正規化などをやるべきだ」と言った人がいるとして
その人の意見は通るかな? >>50
正規化してないことが炎上の真の原因だと納得させられるなら
その人の意見は通るでしょ
みんな炎上なんて嫌なんだから
顧客ID, 氏名, メールアドレス, 郵便番号, 都道府県, 市町村, …
↑住所のところが正規化されてないけど
こういう顧客テーブル使ってても炎上とは無縁の会社いくつも知ってるよ
炎上防ぐために正規化する? >>53
そう主張できる論拠がないからね
少なくとも今のところこのスレでは
だから誰も納得しない >>56
それ論点ずらしって言うんだよ
「炎上するのは正規化してないから」や「正規化すれば炎上の可能性が小さい」という主張に対する反証を出してるだけ
俺が正規化するかどうかとは何の関係もない
都合が悪くなると論点ずらしするのはよくないね
もっと考えないと >>54
市町村合併とかの時に大変そうだな
まぁもう暫くはないだろうけど
あ!金もらえるなら別に大変でもいいか
タダでやれとか言われたら涙目だけど そもそも正規化が何たるかを知らない
知った上で正規化崩ししているなら話はまた別 >>59
それは正論
「敢えて正規化を崩している」とか
「敢えて制約を外してる」とかなら
それはそれでok >>57
それは話が逆
正規化などは「当然やるべきこと」だよ
説明が必要だとすれば
敢えて正規化を崩したり
敢えて制約を外したりする場合だよ >>62
正規化などが行われていない炎上プロジェクトで
「正規化などをやるべきだ」と言った人がいるとして
その人の意見は通るかな? 炎上してるプロジェクトで、設計の初期段階まで戻って正規化をやり直す時間なんかくれるわけないわな
つまり、進むも地獄、戻るも地獄の状況で、地獄の深みに突き進んでいくしかないわけさ
まさに、デスマーチ
笑いながらウンコ漏らすってもんよ >>61
それ正規化しないと炎上しやすいっていう主張の根拠になってるの?
ループしすぎじゃないか? >>65
「正規化しないと炎上しやすい」っていう主張に根拠が必要とは思えん 炎上してる場合、テストを書こうだってほとんど通らないよw
ただひたすら言われたことやるだけw >>63
コーディング規約がない炎上プロジェクトで
「コーディング規約を作るべきだ」と言った人がいるとして
その人の意見は通るかな?
つまり、あんたが言いたいことはどういうこと? 上がポンコツだとなにやっても無駄無駄無駄ァッ!って事じゃないかと >>67
少しづつテストを入れるなら
普通に通ると思うよ
>>68
少しづつコーディング規約を適用していくなら
普通に通ると思うよ
>>69
それはある 本当に上が体育会系の脳筋のごますりと金勘定しか興味ない奴だと大変だわ >>71
そんな連中ばかりでも
正規化などの「当然やるべきこと」を
普通にやらせてくれるなら
まだマシだけどね 「テーブル数が増えると管理が面倒だから〜」確実にあんたが面倒にしている 正規化するとパフォーマンスに影響があるから
崩しましょうとか、正規化する前にやるなよw >>70
> 少しづつテストを入れるなら
> 普通に通ると思うよ
あんたテスト書いたこと有る?
テストの量は実装コード以上になる上に
炎上しているようなものは実装コードも
テスト可能になってないのだから、
ようするに工数が今の3倍ぐらいになるってことだよ
テストなんてのは最初から書いて
テスト可能なように設計しておくのが前提 どの工程の設計であろうと、「やる前によく考えろ」の一言に尽きる
期間がない、予算がない、で取り敢えずのその場しのぎの設計が多い
結局いい加減な設計は後で何十倍にもなって自分に返ってくるってのにな
何事も初動が大事 >>77
100%は目指してないが
意味があるぐらいは目指すだろ
たった一個書いて終わりか? 正規化とか知らない素人同然のなんちゃってSEが設計してるからどうしようもない
未熟者が上流に従事することなど医療や建設の業界ではあり得ないことだが、それが
平然とまかり通るのがIT業界
目に見える形での直接的な人命への影響がないから見過ごされているが、実は人の体力ばかりか精神をも蝕み最悪殺すこともあるというのに >>79
工数が増大しないように要所要所に入れればいいじゃん
>>80
ほんそれ >>81
工数を増やさずに入れるのは無理
だからちょっとだけ入れて満足しましょうって話をしたんだろう?
テストがあればデグレが防げます
ただしテストは全体のごくわずかしか入れてません。
じゃ意味が無いって言ってるの とくにテストを意識していないコードにテストを注入していくのは
かなり至難の業なわけ。
不可能ではないが、企業としてよっぽど本気になることがないとまず無理。 おっと乗り遅れたか
第1正規化は当然やるとして
第3正規化は基本やる必要ないぞ >>86
どこまで正規化するかは状況しだいかもしれないけど
全くやらないのは論外だね ちょっとまとめてみた
1.テーブルを正規化する
2.適切なデータ型を決定する
3.制約を定義する
この3つが実施されなければ炎上して当然
実施されなければ炎上して当然の重要事項であるから
「この3つを実施したい」と主張する側に説明責任は無く
「この3つを実施させない」と主張する側に説明責任はある
実施されなけれは炎上して当然の重要事項であるから
「テーブルが増えるから」なんて理由で実施させないのは
あってはならない
正規化した上で何か事情があって正規化を崩すのは構わない
それと正規化を実施しないというのは話が別
どこまで正規化するのかは状況しだいかだが
全く実施しなければ炎上して当然 >>1の範囲なら別にかまわないと思う
(マ板でやれという意見の人もいるかもしれない)
具体的な話をしたければ、データベース板でどうぞ 開発でDBが絡まない案件の方が少ない気がするな
それに向こうはここより過疎だし 正規化しないと炎上するだろうって事は分かるが
炎上してるからって正規化してないとは限らないと思う >>98
もちろん正規化などをやってるプロジェクトでも炎上することはある
だけど
正規化などをしていなければ炎上して当然
これも仰る通り >>99
テストをしていなければ炎上して当然だし、
コードレビューをしていなければ炎上して当然だし
コード設計をしていなければ炎上して当然だし
SEが役立たずだと炎上して当然だが? まあ、要するに
酒飲むのと残業が好きな連中が集まると大抵炎上する ■ このスレッドは過去ログ倉庫に格納されています