結局開発で最も大切なのはテーブルの正規化と制約

1 ：デフォルトの名無しさん：2017/08/24(木) 07:52:17.47 ID:PyrFLEpH.net

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

炎上してるプロジェクトは
必ずと言って良いほど
これらを軽視している

2 ：デフォルトの名無しさん：2017/08/24(木) 09:04:18.74 ID:EpnGEQYH.net

整理整頓、ちゃんとしようってことなんだな。
炎上なんてのは当たり前のことが当たり前にできてないってことがほとんどで。

3 ：デフォルトの名無しさん：2017/08/24(木) 11:59:02.99 ID:XuqrQefm.net

DB側で管理できることは
DB側でやれってことでいいの？

4 ：デフォルトの名無しさん：2017/08/24(木) 12:41:55.80 ID:zJQXGEF9.net

そんな話じゃないよ

テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する
というのをやっておけば
そうそう炎上なんかしない
という話

5 ：デフォルトの名無しさん：2017/08/24(木) 14:30:20.09 ID:CR+/HOHS.net

そんな馬鹿な

6 ：デフォルトの名無しさん：2017/08/24(木) 17:48:40.28 ID:C4W+CfmQ.net

そんな馬鹿なと思うかもしれないけど
意外と事実だよ

7 ：デフォルトの名無しさん：2017/08/24(木) 18:29:53.40 ID:CR+/HOHS.net

> テーブルを正規化したり
> 適切なデータ型を決定したり
> 制約を定義する
なんて基本中の基本で、それでも炎上するプロジェクト多数なんだが

8 ：デフォルトの名無しさん：2017/08/24(木) 19:06:37.16 ID:FkBgbj51.net

それは、顧客仕様を分析できてないからだお

9 ：デフォルトの名無しさん：2017/08/24(木) 19:07:46.08 ID:C4W+CfmQ.net

>>7
そんなことはない
炎上するプロジェクトの大半は

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

というのをやってない

10 ：デフォルトの名無しさん：2017/08/24(木) 20:45:00.02 ID:JbiFzDA2.net

大半: 全体の半分以上

(全体 - 大半)は
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する
事をしてても炎上してるって事だね

定量的なデータあるの? 大半って何% 母集団は何?

11 ：デフォルトの名無しさん：2017/08/24(木) 20:53:03.51 ID:C4W+CfmQ.net

誰に何を聞いてるんだ？

12 ：デフォルトの名無しさん：2017/08/24(木) 21:05:02.33 ID:gfjynZsV.net

>>8
だよね

原因と結果を混同してたら根本原因にはたどり着けない

13 ：デフォルトの名無しさん：2017/08/24(木) 21:11:48.10 ID:gfjynZsV.net

デスマ案件の原因Top3
・低品質な要求分析・要件定義
・最初から無理めなスケジュール・予算
・わがまま傲慢顧客

次点
・顧客担当者の社内調整力不足
・PMの調整力・交渉力不足

次々点 (※マネジメントが優秀ならこれらの理由だけで炎上する可能性は小さい)
・既存システム・連携システムの負の遺産
・エンジニアの技術力不足
・採用技術の不確実性

14 ：デフォルトの名無しさん：2017/08/24(木) 21:16:50.03 ID:C4W+CfmQ.net

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

A.やっていて炎上するプロジェクト
B.やっていなくて炎上するプロジェクト
C.やっていて炎上しないプロジェクト
D.やっていなくて炎上しないプロジェクト

の4つに分けたら

A＜Bであるし
C＞Dである

15 ：デフォルトの名無しさん：2017/08/24(木) 21:21:32.21 ID:C4W+CfmQ.net

>>13
それは幻想
現実には

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

というのを
やってるかやってないかで
簡単に決まってしまう

16 ：デフォルトの名無しさん：2017/08/25(金) 03:29:00.56 ID:um5Q9HrD.net

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

以後この3つを「正規化など」って俺は書くね

17 ：デフォルトの名無しさん：2017/08/25(金) 03:31:40.26 ID:um5Q9HrD.net

正規化などと炎上プロジェクトの間には
ビックリするほど関係性がある

嘘だと思うなら調べてみるといい

18 ：デフォルトの名無しさん：2017/08/25(金) 11:14:11.33 ID:Yqz1DVXO.net

肌感覚だけどそりゃそうだろうね。
正規化をまじめに考える余裕もないような現場なら炎上しやすいってか炎上中というか。

19 ：デフォルトの名無しさん：2017/08/25(金) 13:32:04.14 ID:wQ+5Hsyr.net

結局開発で最も大切なのは仕様
上手くいかないのは仕様が滅茶苦茶な時
仕様が糞だと設計もコードも乱雑になり糞になる

客先常駐やSIerはその場しのぎの糞コードばかり書くことになる
基本自社開発な企業行くと、意味不明な仕様もなくなって楽になった

20 ：デフォルトの名無しさん：2017/08/25(金) 17:46:33.07 ID:GmykFKX/.net

>>18
正規化などを「余裕のある時にやればいいこと」と位置づけた時から炎上は始まってる

21 ：デフォルトの名無しさん：2017/08/25(金) 17:47:56.47 ID:GmykFKX/.net

>>19
「仕様が糞」って具体的にどんな状態？

22 ：デフォルトの名無しさん：2017/08/25(金) 18:14:26.28 ID:sBQQtGzP.net

正規化・適切なデータ型選択・制約の定義をすれば炎上しないと思ってるなら
自分でそれをやればいいと思うんだけど何でやらないの？

23 ：デフォルトの名無しさん：2017/08/25(金) 18:21:40.86 ID:GmykFKX/.net

>>22
君がやってみれば？
実際に正規化などが行われていない
炎上プロジェクトでさ

上の方でも書いたけど「正規化など」というのは
1.テーブルを正規化する
2.適切なデータ型を決定する
3.制約を定義する
の3つね

24 ：デフォルトの名無しさん：2017/08/25(金) 18:36:46.50 ID:sBQQtGzP.net

>>23
>実際に正規化などが行われていない

行われてないって何で他人事なの？
行われてないなら行えばいいじゃん

25 ：デフォルトの名無しさん：2017/08/25(金) 18:41:26.71 ID:GmykFKX/.net

>>24
君がやってみれば？

26 ：デフォルトの名無しさん：2017/08/25(金) 18:46:25.29 ID:sBQQtGzP.net

>>25
3つとも基本だからね
当たり前にやってるよ
君がやらない理由を教えてよ

27 ：デフォルトの名無しさん：2017/08/25(金) 18:48:37.12 ID:GmykFKX/.net

>>26
許可が出れば当然やってる

28 ：デフォルトの名無しさん：2017/08/25(金) 20:15:09.10 ID:sBQQtGzP.net

>>27
そっか。じゃまず許可出してもらえるように頑張らないといけないね

自分で正規化などをやる立場になったら
そういう基本的なことすら行われない原因が何なのか
もう少し違う視点から見れるようになると思うよ

29 ：デフォルトの名無しさん：2017/08/25(金) 20:27:03.43 ID:CEzIFhYx.net

>>27
許可がでればってw

だからお前はry

30 ：デフォルトの名無しさん：2017/08/25(金) 20:59:55.57 ID:58ENjuei.net

>>27
たぶん今の位置が幸せだと思うよ

31 ：デフォルトの名無しさん：2017/08/25(金) 21:14:43.02 ID:Yqz1DVXO.net

データベースのデータ設計を変更するのは相当広い範囲に影響するからね。
後から入ったやつが簡単にどうこうできることじゃない。
だからこそ大事だという言い分はそんな間違ってはいない。

32 ：デフォルトの名無しさん：2017/08/25(金) 22:29:46.18 ID:qYmRzh7v.net

>>30
それは同意かな

33 ：デフォルトの名無しさん：2017/08/25(金) 22:40:28.35 ID:qYmRzh7v.net

>>28

「締切に間に合えば好きにしてもらっていいよ」
と言われることもあるし
許可が出ることもあるし
1人プロジェクトなら当然やってる

もちろん

ダメだと言われることもある

34 ：デフォルトの名無しさん：2017/08/26(土) 02:19:36.07 ID:YVaPdeR/.net

確かに正規化とか出来てないと後の辻褄合わせが無茶苦茶大変だわw

データのライフサイクルなんかも全く考慮されてないしw

35 ：デフォルトの名無しさん：2017/08/26(土) 02:25:23.12 ID:YVaPdeR/.net

大企業でもデータを統括する部署なり役職なり全然ないからなw

データベースを単なるデータの入れ物ぐらいにしか思っていない奴がやりたい放題だよw

36 ：デフォルトの名無しさん：2017/08/26(土) 08:37:38.87 ID:Uw/VUUHZ.net

データベースなんて要はエクセルだろ?

37 ：デフォルトの名無しさん：2017/08/26(土) 08:47:04.50 ID:PFJfBtDX.net

ﾜﾛｽ

38 ：デフォルトの名無しさん：2017/08/26(土) 09:15:37.31 ID:aZ+D16Yp.net

>>36
そんな感覚だよねー

39 ：デフォルトの名無しさん：2017/08/26(土) 13:40:09.00 ID:RLeWOsq7.net

以前関わったプロジェクトで10個ぐらいのフィルードの複合キーを主キーにしてるテーブルをみた時はさすがに設計した奴死ねと思ったわ

主キーが
都道府県コード + 市区町村コード + 支店コード + 部門コード + ラインコード + 品種コード + グループコード + 製品コード + 製造年月 + 連番

みたいな感じだった
あぁ、こりゃ炎上するわと納得した

40 ：デフォルトの名無しさん：2017/08/26(土) 14:42:02.27 ID:3FHeSYNk.net

>>36
クエリかけられる excel と考えればそんなに間違ってもいないかな。
excel だろうとなんだろうと正規化は意識した方が良い。

41 ：デフォルトの名無しさん：2017/08/26(土) 16:01:07.97 ID:ZKx1xKF8.net

>>40
外部キー制約あってこその正規化だよ

42 ：デフォルトの名無しさん：2017/08/26(土) 16:10:41.94 ID:3FHeSYNk.net

なるほど確かにエクセルだと、その種の制約かけるのが相当めんどい。

43 ：デフォルトの名無しさん：2017/08/26(土) 16:18:53.65 ID:nwDxp1oi.net

お前が関わったプロジェクト全般てなだけで開発全般とは言えないな。

44 ：デフォルトの名無しさん：2017/08/26(土) 16:40:35.97 ID:azDqTcfP.net

>>39
いい例だと思うんだけど、それは正規化されてないのが原因じゃないんだよね
そんな主キーでもきちんと正規化されてる場合だってあるから


正規化はたいていの人が少し慣れればほとんど意識せずに出来るようになるけど
それと優れたデータベース設計が出来るかどうかとは全く別の話
だから「データベース設計≒テーブルの正規化」的な考え方の人が
設計してるうちは炎上の可能性は下がらない気がする

45 ：デフォルトの名無しさん：2017/08/26(土) 16:51:27.16 ID:Q9fQ6bxK.net

正規化ゆうても第1から第5まであるわな
さすがに第5までやるのもやりすぎなんで、ほとんど第3までやろうけど
というか第3正規化できてないと大概炎上するわな

46 ：デフォルトの名無しさん：2017/08/26(土) 23:41:10.41 ID:ZKx1xKF8.net

正規化などが行われていなければ
ほぼ確実に炎上するとすれば
結局開発で最も大切なのは正規化などだよ

47 ：デフォルトの名無しさん：2017/08/26(土) 23:48:12.61 ID:o6LH0P6q.net

え？なに？正規化することで炎上が解決した事例でもあんの？
ないじゃんｗｗｗ

48 ：デフォルトの名無しさん：2017/08/26(土) 23:59:32.28 ID:ZKx1xKF8.net

>>47
君は正規化をやらないの？

49 ：デフォルトの名無しさん：2017/08/27(日) 00:18:49.27 ID:sNhXAArf.net

>>48
重要なのは正規化することで炎上しないのが
本当かってことでしょう？ｗ

50 ：デフォルトの名無しさん：2017/08/27(日) 00:33:18.16 ID:VryqwFGe.net

>>49
正規化などが行われていない炎上プロジェクトで
「正規化などをやるべきだ」と言った人がいるとして
その人の意見は通るかな？

51 ：デフォルトの名無しさん：2017/08/27(日) 00:36:24.38 ID:5LlLs1qL.net

まあ行き当たりばったりな設計で力押しが多いよな

52 ：デフォルトの名無しさん：2017/08/27(日) 00:46:07.69 ID:QZuIwK0r.net

>>50
正規化してないことが炎上の真の原因だと納得させられるなら
その人の意見は通るでしょ
みんな炎上なんて嫌なんだから

53 ：デフォルトの名無しさん：2017/08/27(日) 00:55:59.03 ID:VryqwFGe.net

>>52
納得させることが出来ると思う？

54 ：デフォルトの名無しさん：2017/08/27(日) 00:56:07.71 ID:QZuIwK0r.net

　
顧客ID, 氏名, メールアドレス, 郵便番号, 都道府県, 市町村, …

↑住所のところが正規化されてないけど
こういう顧客テーブル使ってても炎上とは無縁の会社いくつも知ってるよ
炎上防ぐために正規化する？

55 ：デフォルトの名無しさん：2017/08/27(日) 00:57:53.81 ID:QZuIwK0r.net

>>53
そう主張できる論拠がないからね
少なくとも今のところこのスレでは

だから誰も納得しない

56 ：デフォルトの名無しさん：2017/08/27(日) 00:58:43.29 ID:VryqwFGe.net

>>55
だから君は正規化などをやらないと

57 ：デフォルトの名無しさん：2017/08/27(日) 01:05:41.41 ID:QZuIwK0r.net

>>56
それ論点ずらしって言うんだよ
「炎上するのは正規化してないから」や「正規化すれば炎上の可能性が小さい」という主張に対する反証を出してるだけ

俺が正規化するかどうかとは何の関係もない
都合が悪くなると論点ずらしするのはよくないね
もっと考えないと

58 ：デフォルトの名無しさん：2017/08/27(日) 01:11:16.15 ID:lDZtG8Od.net

>>54
市町村合併とかの時に大変そうだな
まぁもう暫くはないだろうけど
あ！金もらえるなら別に大変でもいいか
タダでやれとか言われたら涙目だけど

59 ：デフォルトの名無しさん：2017/08/27(日) 01:11:33.07 ID:5LlLs1qL.net

そもそも正規化が何たるかを知らない

知った上で正規化崩ししているなら話はまた別

60 ：デフォルトの名無しさん：2017/08/27(日) 01:22:38.07 ID:VryqwFGe.net

>>59
それは正論
「敢えて正規化を崩している」とか
「敢えて制約を外してる」とかなら
それはそれでok

61 ：デフォルトの名無しさん：2017/08/27(日) 01:29:04.48 ID:VryqwFGe.net

>>57
それは話が逆

正規化などは「当然やるべきこと」だよ

説明が必要だとすれば
敢えて正規化を崩したり
敢えて制約を外したりする場合だよ

62 ：デフォルトの名無しさん：2017/08/27(日) 01:50:48.68 ID:sNhXAArf.net

そいで正規化して炎上が収まった実例でも有るの？

63 ：デフォルトの名無しさん：2017/08/27(日) 01:55:57.44 ID:VryqwFGe.net

>>62

正規化などが行われていない炎上プロジェクトで
「正規化などをやるべきだ」と言った人がいるとして
その人の意見は通るかな？

64 ：デフォルトの名無しさん：2017/08/27(日) 02:00:25.45 ID:lDZtG8Od.net

炎上してるプロジェクトで、設計の初期段階まで戻って正規化をやり直す時間なんかくれるわけないわな
つまり、進むも地獄、戻るも地獄の状況で、地獄の深みに突き進んでいくしかないわけさ
まさに、デスマーチ
笑いながらウンコ漏らすってもんよ

65 ：デフォルトの名無しさん：2017/08/27(日) 02:09:04.83 ID:QZuIwK0r.net

>>61
それ正規化しないと炎上しやすいっていう主張の根拠になってるの？

ループしすぎじゃないか？

66 ：デフォルトの名無しさん：2017/08/27(日) 02:13:54.74 ID:VryqwFGe.net

>>65
「正規化しないと炎上しやすい」っていう主張に根拠が必要とは思えん

67 ：デフォルトの名無しさん：2017/08/27(日) 04:17:04.67 ID:0cj4lMWm.net

炎上してる場合、テストを書こうだってほとんど通らないよｗ
ただひたすら言われたことやるだけｗ

68 ：デフォルトの名無しさん：2017/08/27(日) 05:29:14.49 ID:sNhXAArf.net

>>63

コーディング規約がない炎上プロジェクトで
「コーディング規約を作るべきだ」と言った人がいるとして
その人の意見は通るかな？


つまり、あんたが言いたいことはどういうこと？

69 ：デフォルトの名無しさん：2017/08/27(日) 06:49:44.81 ID:5LlLs1qL.net

上がポンコツだとなにやっても無駄無駄無駄ァッ！って事じゃないかと

70 ：デフォルトの名無しさん：2017/08/27(日) 09:30:22.66 ID:2IgWlIeb.net

>>67
少しづつテストを入れるなら
普通に通ると思うよ

>>68
少しづつコーディング規約を適用していくなら
普通に通ると思うよ

>>69
それはある

71 ：デフォルトの名無しさん：2017/08/27(日) 09:39:07.87 ID:5LlLs1qL.net

本当に上が体育会系の脳筋のごますりと金勘定しか興味ない奴だと大変だわ

72 ：デフォルトの名無しさん：2017/08/27(日) 13:02:52.37 ID:7sdTDI+/.net

>>71
そんな連中ばかりでも
正規化などの「当然やるべきこと」を
普通にやらせてくれるなら
まだマシだけどね

73 ：デフォルトの名無しさん：2017/08/27(日) 13:14:26.04 ID:VryqwFGe.net

「テーブル数が増えると管理が面倒だから〜」確実にあんたが面倒にしている

74 ：デフォルトの名無しさん：2017/08/27(日) 13:27:18.19 ID:7sdTDI+/.net

>>73
本当にそれだよね

75 ：デフォルトの名無しさん：2017/08/27(日) 14:53:14.86 ID:V0hwi73r.net

正規化するとパフォーマンスに影響があるから
崩しましょうとか、正規化する前にやるなよw

76 ：デフォルトの名無しさん：2017/08/27(日) 14:58:15.64 ID:sNhXAArf.net

>>70
> 少しづつテストを入れるなら
> 普通に通ると思うよ

あんたテスト書いたこと有る？
テストの量は実装コード以上になる上に
炎上しているようなものは実装コードも
テスト可能になってないのだから、
ようするに工数が今の3倍ぐらいになるってことだよ

テストなんてのは最初から書いて
テスト可能なように設計しておくのが前提

77 ：デフォルトの名無しさん：2017/08/27(日) 16:04:34.86 ID:1mZPOaVb.net

>>76
カバレッジ100%でも目指してるの？

78 ：デフォルトの名無しさん：2017/08/27(日) 16:17:02.37 ID:5LlLs1qL.net

どの工程の設計であろうと、「やる前によく考えろ」の一言に尽きる

期間がない、予算がない、で取り敢えずのその場しのぎの設計が多い

結局いい加減な設計は後で何十倍にもなって自分に返ってくるってのにな

何事も初動が大事

79 ：デフォルトの名無しさん：2017/08/27(日) 16:23:14.96 ID:sNhXAArf.net

>>77
100%は目指してないが
意味があるぐらいは目指すだろ

たった一個書いて終わりか？

80 ：デフォルトの名無しさん：2017/08/27(日) 16:47:00.08 ID:okZux0mu.net

正規化とか知らない素人同然のなんちゃってＳＥが設計してるからどうしようもない
未熟者が上流に従事することなど医療や建設の業界ではあり得ないことだが、それが
平然とまかり通るのがIT業界
目に見える形での直接的な人命への影響がないから見過ごされているが、実は人の体力ばかりか精神をも蝕み最悪殺すこともあるというのに

81 ：デフォルトの名無しさん：2017/08/27(日) 17:34:22.83 ID:AdHUTbRj.net

>>79
工数が増大しないように要所要所に入れればいいじゃん

>>80
ほんそれ

82 ：デフォルトの名無しさん：2017/08/27(日) 18:37:07.73 ID:sNhXAArf.net

>>81
工数を増やさずに入れるのは無理
だからちょっとだけ入れて満足しましょうって話をしたんだろう？

テストがあればデグレが防げます
ただしテストは全体のごくわずかしか入れてません。
じゃ意味が無いって言ってるの

83 ：デフォルトの名無しさん：2017/08/27(日) 19:37:01.59 ID:0cj4lMWm.net

とくにテストを意識していないコードにテストを注入していくのは
かなり至難の業なわけ。
不可能ではないが、企業としてよっぽど本気になることがないとまず無理。

84 ：デフォルトの名無しさん：2017/08/27(日) 21:24:12.45 ID:SWHCUx4b.net

>>83
言葉がおかしい

85 ：デフォルトの名無しさん：2017/08/27(日) 21:46:51.08 ID:m+VUF/Wq.net

>>83
え？なんで意味が無いの？

86 ：デフォルトの名無しさん：2017/08/27(日) 22:17:02.74 ID:42wr1dDO.net

おっと乗り遅れたか
第1正規化は当然やるとして
第3正規化は基本やる必要ないぞ

87 ：デフォルトの名無しさん：2017/08/28(月) 07:48:06.86 ID:8/dWo19X.net

>>86
どこまで正規化するかは状況しだいかもしれないけど
全くやらないのは論外だね

88 ：デフォルトの名無しさん：2017/08/28(月) 08:06:02.98 ID:8/dWo19X.net

ちょっとまとめてみた

1.テーブルを正規化する
2.適切なデータ型を決定する
3.制約を定義する

この3つが実施されなければ炎上して当然

実施されなければ炎上して当然の重要事項であるから
「この3つを実施したい」と主張する側に説明責任は無く
「この3つを実施させない」と主張する側に説明責任はある

実施されなけれは炎上して当然の重要事項であるから
「テーブルが増えるから」なんて理由で実施させないのは
あってはならない

正規化した上で何か事情があって正規化を崩すのは構わない
それと正規化を実施しないというのは話が別

どこまで正規化するのかは状況しだいかだが
全く実施しなければ炎上して当然

89 ：デフォルトの名無しさん：2017/08/28(月) 10:37:04.40 ID:FadrHY99.net

データベース板でやってくれませんかね

90 ：デフォルトの名無しさん：2017/08/28(月) 13:19:41.42 ID:u/z24YLE.net

>>89
あら
目障りだった？

91 ：デフォルトの名無しさん：2017/08/28(月) 13:44:39.31 ID:Q6Vyd4iZ.net

ここでいいです

92 ：デフォルトの名無しさん：2017/08/28(月) 16:24:07.41 ID:FadrHY99.net

>>90
妥当なスレが既にあるので、そっちでやってください

何故データベース設計は軽視されるのか？
http://mevius.2ch.net/test/read.cgi/db/1228061247/

頼むから正規化しろよ　第二正規形
http://mevius.2ch.net/test/read.cgi/db/1116097001/

93 ：デフォルトの名無しさん：2017/08/28(月) 16:52:16.58 ID:/IEjfDVp.net

>>92
あら？
ウザかった？

94 ：デフォルトの名無しさん：2017/08/28(月) 18:26:46.83 ID:TLOgdRRE.net

スレ違いってだけだろ

95 ：デフォルトの名無しさん：2017/08/28(月) 18:27:20.78 ID:TLOgdRRE.net

いやスレどころか鼬飼い

96 ：デフォルトの名無しさん：2017/08/28(月) 18:53:17.36 ID:FadrHY99.net

>>1の範囲なら別にかまわないと思う
（マ板でやれという意見の人もいるかもしれない）

具体的な話をしたければ、データベース板でどうぞ

97 ：デフォルトの名無しさん：2017/08/28(月) 21:26:14.86 ID:Z2A2Xztk.net

開発でDBが絡まない案件の方が少ない気がするな

それに向こうはここより過疎だし

98 ：デフォルトの名無しさん：2017/08/28(月) 23:00:32.12 ID:E9bYmb9B.net

正規化しないと炎上するだろうって事は分かるが
炎上してるからって正規化してないとは限らないと思う

99 ：デフォルトの名無しさん：2017/08/28(月) 23:13:40.97 ID:8heg7vkK.net

>>98
もちろん正規化などをやってるプロジェクトでも炎上することはある

だけど

正規化などをしていなければ炎上して当然

これも仰る通り

100 ：デフォルトの名無しさん：2017/08/28(月) 23:20:15.80 ID:0eH/9F76.net

>>99
テストをしていなければ炎上して当然だし、
コードレビューをしていなければ炎上して当然だし
コード設計をしていなければ炎上して当然だし
SEが役立たずだと炎上して当然だが？

101 ：デフォルトの名無しさん：2017/08/28(月) 23:29:49.72 ID:a0dmO7FI.net

まあ、要するに

酒飲むのと残業が好きな連中が集まると大抵炎上する

102 ：デフォルトの名無しさん：2017/08/28(月) 23:33:14.45 ID:8heg7vkK.net

>>100
テストしてなければ簡単に潰せるバグが大量に出るね
だけど意外と影響は小さい
「技術者への不信感が強くなる」というのが最も問題

コードレビューは「やらない方がマシ」というプロジェクトが結構ある

それから「コード設計」って何？

103 ：デフォルトの名無しさん：2017/08/28(月) 23:33:45.46 ID:ml0Q9t1V.net

正規化することより正規化されていないレガシーDBをどうにかするテクニックを研究した方が有益
ゼロから正しく作るのは簡単
困るのはいつも引き継いだ時だ

104 ：デフォルトの名無しさん：2017/08/28(月) 23:34:42.24 ID:a0dmO7FI.net

フィールドに入る中身の話じゃないかと

105 ：デフォルトの名無しさん：2017/08/28(月) 23:39:32.22 ID:0eH/9F76.net

>>102
ぐぐれ

106 ：デフォルトの名無しさん：2017/08/28(月) 23:40:08.73 ID:0eH/9F76.net

正規化をしていなくても別に後から修正すればいいだけだし、
それよりもコードだよ。

一旦書いてしまったら全部書き直しになってしまう

107 ：デフォルトの名無しさん：2017/08/28(月) 23:42:57.04 ID:8heg7vkK.net

>>103
それはその通りだね

旧システムを新システムに置き換える仕事をやってる時に
正規化しない理由が「データ移行が大変だから」なんて言われた日には・・・

データ不整合が起きてる旧システムのデータを
そのまま新システムのデータベースにブチこむという決断が行われましたと

108 ：デフォルトの名無しさん：2017/08/28(月) 23:43:14.54 ID:a0dmO7FI.net

コード量にも影響するけどな

109 ：デフォルトの名無しさん：2017/08/28(月) 23:44:07.06 ID:8heg7vkK.net

>>106
後から修正とか
まず不可能ですわ

110 ：デフォルトの名無しさん：2017/08/28(月) 23:48:09.43 ID:ml0Q9t1V.net

>>107
うちも今まさにそれやってるわ
というかDB担当が使えねえカスで非正規のテーブル増やしやがったからもっと酷い
5年10年も勤めてる奴らなのに呆れ果てるわ

愚痴すまんな

111 ：デフォルトの名無しさん：2017/08/28(月) 23:52:26.36 ID:8heg7vkK.net

>>110
(　ＴДＴ)

大変やね

俺は「金が出ればホワイト。残業代が出るからホワイト」ってアタマの中で唱え続けて乗りきった

112 ：デフォルトの名無しさん：2017/08/29(火) 00:06:42.81 ID:rUOtN+gs.net

>>106
いやいや
本番運用開始したらDB構造を変えるのに比べればプログラムを変えるほうが簡単
DBは複数のシステム/アプリケーションから使われてることがほとんどだから

113 ：デフォルトの名無しさん：2017/08/29(火) 00:09:43.35 ID:LVYauoO8.net

>>112
「コード設計」でググったからわかったのだが
ID:0eH/9F76が言ってる「コード」ってソースコードのことじゃないんだわ

114 ：デフォルトの名無しさん：2017/08/29(火) 00:34:21.28 ID:TMhzTuGH.net

おまえら論理設計と物理設計わけてないな

115 ：デフォルトの名無しさん：2017/08/29(火) 01:57:11.98 ID:oqFekZxP.net

せめてモデル層をクラスで集約出来ていれば正規化して正規化する前の形をSQL-VIEWで復元してあげればわりとやりやすくはなるかも

116 ：デフォルトの名無しさん：2017/08/29(火) 02:01:49.56 ID:6sGVgGr/.net

Railsとかのフレームワークを使っていれば
普通に設計しても正規化状態になるので
フレームワークを導入しなければ炎上するって
言ったほうが良いと思う

もちろんオレオレフレームワークは
実績が少ないので意味がない

117 ：デフォルトの名無しさん：2017/08/29(火) 02:02:57.99 ID:6sGVgGr/.net

フレームワークを導入してないところは
時代が20〜30年ぐらい遅れてると思う。

結局開発で最も大変なのは
最新技術を取り入れていくことかな

118 ：デフォルトの名無しさん：2017/08/29(火) 02:06:13.74 ID:LVYauoO8.net

開発で最も大切なのは

1.テーブルを正規化する
2.適切なデータ型を決定する
3.制約を定義する

この3つ

119 ：デフォルトの名無しさん：2017/08/29(火) 02:06:51.41 ID:TMhzTuGH.net

ローテク極めていくほうがだいたい早い
30年前のCOBOLでもやってること大差なし

120 ：デフォルトの名無しさん：2017/08/29(火) 03:34:44.52 ID:6sGVgGr/.net

>>118
最も大切なことではないと思う

121 ：デフォルトの名無しさん：2017/08/29(火) 08:13:33.58 ID:X4Q/TPlH.net

ようするにDRYだよ
１つの事実(知識)を１つの場所に
正規化はDRYのサブセット

122 ：デフォルトの名無しさん：2017/08/29(火) 10:23:19.86 ID:mN0xls38.net

この記事読んだ方が100倍ためになるよ。

データベースアプリケーション開発を炎上させる負のスパイラル
http://nippondanji.blogspot.jp/2013/11/blog-post.html

123 ：デフォルトの名無しさん：2017/08/29(火) 10:25:48.19 ID:mN0xls38.net

> 1.テーブルを正規化する
> 2.適切なデータ型を決定する
> 3.制約を定義する

まぁ、それができてたってアンチパターンにははまる可能性はあるわけで。
ということで、知らなかった人は書籍「SQLアンチパターン」を読むといい。
https://www.oreilly.co.jp/books/9784873115894/

124 ：デフォルトの名無しさん：2017/08/29(火) 12:55:58.92 ID:PNzW02X+.net

>>123
読むの面倒だからトップ3くらい紹介してくれない?

125 ：デフォルトの名無しさん：2017/08/29(火) 14:25:57.92 ID:mN0xls38.net

>>124
こういう奴を切っていくのが、プロジェクトを炎上させないコツ。

126 ：デフォルトの名無しさん：2017/08/29(火) 15:22:36.62 ID:PNzW02X+.net

>>125
テーブルの正規化以前に人に依存していると言う主張してか？
やはりスレタイは正しく無くて、>>1のようなカスを排除する事が炎上防止の最善策

127 ：デフォルトの名無しさん：2017/08/29(火) 15:40:18.67 ID:mN0xls38.net

プロジェクトが炎上する要因は複数ある。

そこから合意してかないといけないのか？

128 ：デフォルトの名無しさん：2017/08/29(火) 17:41:41.49 ID:PNzW02X+.net

「最も大切」というお題だから
自分で設定したお題を忘れてもらっちゃ困る

129 ：デフォルトの名無しさん：2017/08/29(火) 18:22:47.86 ID:rUOtN+gs.net

>>121
正規化はDRYよりもSRPに近い
DRYは意味を理解しなくても機械的にほぼ判断できるが
正規化はエンティティ・キー・属性の意味や関係性を理解しないと判断できない

その時その時の主観によって意味や理解が変わりうる点や
原則を過剰に適用するとわかりにくく使いにくいものになる点が似ている

130 ：デフォルトの名無しさん：2017/08/29(火) 18:35:37.73 ID:rUOtN+gs.net

>>122
読んだけど、この人はちょっと理論に寄り過ぎだね

「データベース設計においては、正規化できる部分だけをきっちり正規化すれば良いのである」
「どのテーブルが正規化できるかという見極めが重要なのである」
「正規化の対象となるテーブルでは、NULLはご法度である」

↑いいたいことはわけるけど、こういう指針だけだと実践では役に立たないし
DB設計が原因で炎上してるようなところだと火に油を注ぐことになると思う

131 ：デフォルトの名無しさん：2017/08/29(火) 18:59:38.55 ID:UC+DdZRH.net

開発で最も大切なのは

1.テーブルを正規化する
2.適切なデータ型を決定する
3.制約を定義する

この3つ
これらをやってなければ炎上して当然

>>128
その通りだね
この3つより大切なモノを挙げてみるといいと思う

132 ：デフォルトの名無しさん：2017/08/29(火) 19:07:47.55 ID:mN0xls38.net

>>130
> 読んだけど、この人はちょっと理論に寄り過ぎだね
たしかに『理論から学ぶデータベース実践入門』も理論がうざかったけどね。

ま、でも、このスレの有象無象のゴミレス読む暇があったら、「漢のコンピュータ道」の
DB関連記事読んだ方が、よっぽどためになると思うよ。

133 ：デフォルトの名無しさん：2017/08/29(火) 22:00:48.63 ID:6sGVgGr/.net

>>131
> この3つ
> これらをやってなければ炎上して当然

殆どの炎上はそれらをやっていて
炎上していると思うけど？

それらをやってない所は少ないと思う

134 ：デフォルトの名無しさん：2017/08/30(水) 06:15:13.11 ID:6oCjgbIk.net

それらをきっちりやらなくても済まされるようなド底辺で生きてるんだろ
さっしてやれ

135 ：デフォルトの名無しさん：2017/08/30(水) 07:29:56.75 ID:ca1piqKW.net

どこまで正規化すんの？
大抵の落としどころはボイスコッドだと思うけど
おまいらだと第5正規化までやってそうｗ

システムに不要なほど過剰な正規化はするべきじゃない

136 ：デフォルトの名無しさん：2017/08/30(水) 07:34:51.44 ID:ev9FmYBb.net

>>133
そりゃ予算に無理があるんじゃね？

>>134
炎上してるのだから「済まされる」とは言えないかな

137 ：デフォルトの名無しさん：2017/08/30(水) 07:50:02.99 ID:ev9FmYBb.net

>>135
開発で最も大切なのは

1.テーブルを正規化する
2.適切なデータ型を決定する
3.制約を定義する

この3つ

2や3について言うことは無いのかい？

138 ：デフォルトの名無しさん：2017/08/30(水) 20:59:15.14 ID:6oCjgbIk.net

>>136
炎上が恒例行事になってるんだろ

139 ：デフォルトの名無しさん：2017/08/30(水) 21:01:44.13 ID:RiHZq49u.net

開発で最も大切なのは

1. 単一責任の原則(SRP)
2. 適切な型の定義
3. 入力チェック

この3つ


んなわけない

140 ：デフォルトの名無しさん：2017/08/30(水) 21:09:48.80 ID:vAN9hjOo.net

汎用機の考え方を引きずっているひとか設計すると正規化うんぬんの話が出るが、そもそもリレーショナルデータベースを理解している人間が設計した場合は、正規化という作業がほぼ発生しない。

141 ：デフォルトの名無しさん：2017/08/30(水) 21:17:21.02 ID:E7OSkm2F.net

わかってなければ
リレーショナルとは無縁な
単なるデータの置き場所となる

142 ：デフォルトの名無しさん：2017/08/30(水) 21:21:36.74 ID:Cx/iJc4q.net

正規化って何時頃からあるの?
それ以前は殆どのプロジェクトは炎上してたの?

143 ：デフォルトの名無しさん：2017/08/30(水) 22:02:52.42 ID:/2RlUBL9.net

>>140
確かに最初から正規形だわな普通

144 ：デフォルトの名無しさん：2017/08/30(水) 22:19:01.02 ID:cSzTCLjb.net

正規形を知っているからRDBを理解してるんじゃね？無意識に正規化してるって事だろ

145 ：デフォルトの名無しさん：2017/08/30(水) 22:32:47.74 ID:E7OSkm2F.net

>>144
同意

146 ：デフォルトの名無しさん：2017/08/30(水) 22:35:24.91 ID:ca1piqKW.net

おまえらトランザクションも正規化するの？

147 ：デフォルトの名無しさん：2017/08/31(木) 00:34:28.16 ID:J2aSRpVx.net

>>146
用途によるけど業務アプリケーションならトランザクションデータも普通は正規化するでしょ
注文明細に受注単価が入ってるのとかは正規化違反じゃないよ

148 ：デフォルトの名無しさん：2017/08/31(木) 00:49:29.64 ID:x3jdwRS7.net

受注時点のスナップショットだからね

149 ：デフォルトの名無しさん：2017/08/31(木) 00:50:48.09 ID:j9yVEoD5.net

トランザクションデータを正規化しておけば
例えば処理が終わったトランザクションに含まれる
○○コードマスタを書き換えるだけで
過去に終わったトランザクションデータを
後から変更できて便利！

150 ：デフォルトの名無しさん：2017/08/31(木) 01:04:47.41 ID:x3jdwRS7.net

マスターがバージョニングされて有効期間がきられていたら完全かもだけど普通はそこまでしない

151 ：デフォルトの名無しさん：2017/08/31(木) 08:20:50.40 ID:hTVV6oVW.net

>>147
違う違う
add onlyな受注テーブルを作るんだよ
んで注文明細とリレーションを張る

152 ：デフォルトの名無しさん：2017/08/31(木) 09:49:05.97 ID:j9yVEoD5.net

つまり注文データを正規化して

受注テーブルや受注明細テーブル
もしその中でコード、例えば服のサイズコードや
色コードなど正規化すべきものを使っていれば
そのテーブル

それらのテーブル全てに対して
履歴テーブルを作るというわけか？

例えば受注履歴テーブルや受注明細履歴テーブル
サイズ履歴テーブル、色履歴テーブル
ありとあらゆるその時の情報を履歴テーブルにコピーする

153 ：デフォルトの名無しさん：2017/08/31(木) 10:15:40.17 ID:iGMaENMY.net

>>152
お前がやりたいようにやれ

154 ：デフォルトの名無しさん：2017/08/31(木) 10:19:51.27 ID:nBZaZbsR.net

性器化

155 ：デフォルトの名無しさん：2017/08/31(木) 18:18:35.80 ID:Jii3x0cI.net

>>152
そうだよ
イベントソーシングね

156 ：デフォルトの名無しさん：2017/09/01(金) 00:03:45.67 ID:A4rxsWGh.net

>>151
説明が短すぎてわからないや
「トランザクションも正規化するの？」の質問とつながってるの？

157 ：デフォルトの名無しさん：2017/09/01(金) 00:09:29.76 ID:A4rxsWGh.net

>>155
イベントソーシングと履歴テーブルはちょっと違うよ

履歴テーブルは状態変更イベントを記録するんじゃなくて
変化した状態そのものを記録していく
基本的にTemporal Tableと同じ

158 ：デフォルトの名無しさん：2017/09/01(金) 08:19:46.16 ID:s82kToZ5.net

>>152
カーボンコピーを受注テーブルに持たせるんだよ
それかカーボンコピーを受注リソースに分離して参照を貼る
少なくとも受注に絡む事実を注文に持たせるものではない

159 ：デフォルトの名無しさん：2017/09/01(金) 09:53:47.01 ID:Z9Fha70u.net

○次受けが多いほど退場率が早くなる。高くなる

直受けの50万 客：いつまでもうちにいていいよ
3次受けの50万（客は90万払ってる) 客：短期延長していい？
5次受けの50万（客は150万払ってる) 客：作り終わったらとっと出てけ　できなかったら即退場だ　
長時間労働　高稼働　高スキル要求が多い

零細フリーランスサイトは5次受けから誰もできない難易度の高い仕事　余り物の仕事を紹介してくる。40万円代でやってくれと
これならJIETから3次でいったほうがいいな

446非決定性名無しさん2017/08/02(水) 22:12:48.95

JIETに毎月5千円払えば３次から入場できるだろ？
高額をうたうフリーランスのサイトはだいたい５次から４５万円
JIETで閲覧応募できる末端価格からさらに搾取するのが高額をみせつけるフリーランスサイトでした
高額案件をみせつけるフリーランスサイトも案件の取得はJIETでした

JIETに加入すれば誰でも3次60万からスタートだ。フリーランスのサイトをやってる
自称エージェントもそこから案件情報を取得しきてる。サイトで60万で釣って40万から55万の間でやらしている。

372仕様書無しさん2017/08/11(金) 10:31:43.41
フリーランスで検索すると引っかかる零細ITがやっているフリーランスのサイトはだめだ。
高額に見せているけど実際は50万前後
JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円　平凡な稼働時間の80万円の案件もある。
ユー子も求人をだしてる。名刺も渡せる。ユー子に名刺が渡せるんだぞ。夢のようだ

自称エージェントはJIETから流れてくる案件を転売してるだけだった。
JIETに加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む

エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×3　= 言い値50万以下
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×1 悪質な言い値で50万以下
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - JIETに加入して公表価格で応募ができる

160 ：ワハハ！！：2017/09/01(金) 15:41:47.31 ID:HLMXttPm.net

816 名無しさん＠お腹いっぱい。 2017/09/01 15:28:38
まそふぱぞ
>>815
そうだなキチガイ撲滅平和維持軍である俺様の勝ちだな♪
AA無職キチガイをブチ殺してスレの正常化に成功！
うぇーい☆
はい勝った♪

161 ：デフォルトの名無しさん：2017/09/02(土) 07:09:47.97 ID:TvzMBAqs.net

データベースを伴わない開発業務なんでさっぱり
テーブルの正規化って何それ

162 ：デフォルトの名無しさん：2017/09/02(土) 18:27:11.77 ID:xFUbH9ih.net

>>161
学生さんですか？

163 ：デフォルトの名無しさん：2017/09/02(土) 18:51:01.16 ID:x3xo3AHA.net

学生さんは視野が狭いですからねぇ。
この世は全てデータベースを使っているのですよ。

164 ：デフォルトの名無しさん：2017/09/03(日) 19:16:01.09 ID:TRtZ/EY8.net

>>161
確かにデータベースを使わない業務もあるだろうけど
それこそ「データベースを使わない業務もある」というレベルの話だわな

165 ：デフォルトの名無しさん：2017/09/10(日) 01:03:09.87 ID:T3zRvirf.net

>>82
意味なくない
ローマは一日にしてならず

リファクタリングが必要なとこから一つ一つやってきゃいい
デグレはコードをいじるから生じるんだ

166 ：デフォルトの名無しさん：2017/09/10(日) 10:29:13.81 ID:CNj3ELqz.net

ほんそれ
入れやすい部分に入ってるだけでも全然違うっつーの

167 ：デフォルトの名無しさん：2017/09/10(日) 11:27:51.04 ID:G4ZVCKWZ.net

重要な部分じゃなくて入れやすい部分？
入れにくい所を入れやすいように変えると
デグレを生むしなーｗ

168 ：デフォルトの名無しさん：2017/09/10(日) 11:48:05.91 ID:Ten/S+rP.net

リファクタリング下手くそな奴ほどデグレを恐れるよね
普段からマトモなテストをしてない証拠
スキル不足を公言するようなものだ

169 ：デフォルトの名無しさん：2017/09/10(日) 12:26:22.14 ID:CNj3ELqz.net

リファクタリング
自動テスト
正規化
適切なデータ型
制約

デグレを怖れる者ほど
これらを否定する

170 ：デフォルトの名無しさん：2017/09/10(日) 13:20:05.93 ID:PwzOYpRH.net

コード触らない人間ほど否定的だあな

組織、チームとして動脈硬化が末期的

171 ：デフォルトの名無しさん：2017/09/10(日) 14:13:09.69 ID:CfAD8p5O.net

>>169
混ぜるな危険

172 ：デフォルトの名無しさん：2017/09/10(日) 14:16:30.66 ID:ncSAfY/F.net

>>169
定時に帰りたいんで仕事でそういうのやめてもらえます？

173 ：デフォルトの名無しさん：2017/09/10(日) 14:22:56.67 ID:PwzOYpRH.net

そういうのに限ってトラブルで終電まで帰れない

174 ：デフォルトの名無しさん：2017/09/10(日) 19:57:35.46 ID:+BHhCGE8.net

>>172
言う言うw

175 ：デフォルトの名無しさん：2017/09/11(月) 09:37:54.90 ID:vJ3AiMg+.net

○次受けが多いほど退場率が早くなる。高くなる

直受けの50万 客：いつまでもうちにいていいよ
3次受けの50万（客は90万払ってる) 客：短期延長していい？
5次受けの50万（客は150万払ってる) 客：作り終わったらとっと出てけ　できなかったら即退場だ　
長時間労働　高稼働　高スキル要求が多い

フリーランスサイトを運営している零細ITの自称エージェントは労働市場から流れてくる案件を転売してるだけだった。
労働市場に加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む

エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×3　= 言い値50万以下
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×1 悪質な言い値で50万以下
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - JIETに加入して公表価格で応募できる

eJobgo　JIET　JISA　で検索

優良エージェント・優良サイト

首都圏IT(PE-BANK) 　プログラマーズ

176 ：デフォルトの名無しさん：2017/09/12(火) 00:06:50.77 ID:HbvMS5Mi.net

正規化してないプロジェクトが原因不明のデータ不整合多発で大炎上しててわろた
早いうちに別案件に逃げ出せてよかった

177 ：デフォルトの名無しさん：2017/09/12(火) 00:23:18.06 ID:U1/fLtdM.net

それ原因不明じゃないwww

178 ：デフォルトの名無しさん：2017/09/12(火) 09:04:32.20 ID:EOOe72TQ.net

eJobgo　JIET　JISA　で検索

優良エージェント・優良サイト

首都圏IT(PE-BANK) クラウドテック　プログラマーズ

179 ：デフォルトの名無しさん：2017/09/19(火) 14:58:02.69 ID:4nMrrTsq.net

引き継ぎ資料に「どういう所に注意しなければいけないか」というのを書かないといけないらしい
「正規化されておらず制約も無いのでデータ不整合が多発するでしょう」って書いたら間違いなく俺のせいにされるな

書かなくても俺のせいにされそうだけど

180 ：デフォルトの名無しさん：2017/09/19(火) 23:06:24.80 ID:8Nvi84xk.net

「制約が無いのでデータ不整合に注意してください」
でいいんじゃない
正規化されていないとか多発するでしょうとか文章の目的にそぐわないからいらない

181 ：デフォルトの名無しさん：2017/09/20(水) 01:16:17.18 ID:DOSxYj0U.net

外部キー制約やユニーク制約なら
なんで追加しなかったんですか？ってなる
単純に追加できなかった理由こそ注意点として書くべき

182 ：デフォルトの名無しさん：2017/09/20(水) 07:30:25.14 ID:S4RtYHtC.net

旧システム側が既にデータ不整合を起こしており
不整合を起こしているデータを移行する時に問題になるから
by上司

183 ：デフォルトの名無しさん：2017/09/20(水) 09:47:51.51 ID:AMouiYzy.net

コンバートプログラムかけばいいだろ
或いは不整合一覧を出力するようなプログラム

184 ：デフォルトの名無しさん：2017/09/20(水) 11:09:17.98 ID:9s4WD3hZ.net

コンバートプログラム作製は上司の担当
不整合を起こしてるデータを検出するプログラムを勝手に作ってることがバレたらどうするんだ？

185 ：デフォルトの名無しさん：2017/09/20(水) 12:19:51.63 ID:woEI7sSr.net

最も大切なのは上司の指示や規約ではなくテーブルの正規化と制約
バレても問題ない

186 ：デフォルトの名無しさん：2017/09/20(水) 12:44:06.80 ID:xbK0Hqs4.net

いーこと言うね

187 ：デフォルトの名無しさん：2017/09/20(水) 21:08:31.58 ID:8N1Ug+q3.net

エラーが出るので制約外せってクレーム来た
もうどうでもよくなって外しちゃった
これで不正データ混入確定
あ〜もうやだみんな死ねばいいのに

188 ：デフォルトの名無しさん：2017/09/20(水) 21:29:21.54 ID:DOSxYj0U.net

>>182
不整合データをそのまま移行してて問題ないのかとか、
その承認を文書で顧客に貰っているのかとか、
その不整合に起因するあらゆる不具合については免責されるのかとか、
芋づる式に注意点が出てくる

担当上司が転職でもしたら
引き継ぎされたやつと会社が損害被るパターン

189 ：デフォルトの名無しさん：2017/09/20(水) 21:38:34.84 ID:DOSxYj0U.net

>>187
きちんとリスクを説明して顧客がそれを理解した上で
制約を外すことを命じたという証拠がなければ
担当者が変わればバグ扱いになるし訴えられたら負ける可能性もあるよ
その文面だと力関係に相当な差がありそうだし

190 ：デフォルトの名無しさん：2017/09/23(土) 21:06:11.35 ID:W04mp06A.net

動きゃーいーんだよ動きゃー

191 ：デフォルトの名無しさん：2017/09/23(土) 21:10:02.06 ID:4jYbiDn+.net

今はね

192 ：デフォルトの名無しさん：2017/09/26(火) 22:12:11.97 ID:QDxeQPV4.net

いわゆる「コード値の先頭N文字がコード区分になってる」アンチパターンってどう扱うのがいいの?
業務ルールで決まってるからコード体系変えるわけにもいかないのが歯がゆい

193 ：デフォルトの名無しさん：2017/09/26(火) 22:59:04.53 ID:fvF/8EVL.net

>>192
[論理レベル]
コード区分と先頭N文字以外の部分はそれぞれ独立した属性として
2つを合成した値は導出属性として扱う
(コード区分は参照テーブルを作って外部キー参照で)

[物理レベル]
導出属性を計算列やユーザー定義関数等を使って実装する
非正規化して合成した値をそのままカラムに入れる方法もよくやる
その場合は導出属性だけ更新した場合やその逆の場合で不整合が発生する

194 ：デフォルトの名無しさん：2017/09/27(水) 06:14:05.65 ID:rJhIuBz0.net

>>192
客が考えたコードは一才信用せず
敢えてサロゲートキーのIDリクワイアドで物理設計を行う
サロゲートキーは原則としてユーザーに見せない

コード値にはユニーク制約やチェック制約などで対応

195 ：デフォルトの名無しさん：2017/09/27(水) 08:16:38.86 ID:dD0p7RBG.net

２重管理うぜえ
まだそのアンチパターンのがましじゃ

196 ：デフォルトの名無しさん：2017/09/27(水) 23:38:08.77 ID:I+73OQfD.net

>>193
これやるなら計算列のサポートが欲しいね
なんでM$しか計算列をサポートしてないんだろ
オラクルだと列追加してチェック制約がベターかな

197 ：デフォルトの名無しさん：2017/09/27(水) 23:56:25.63 ID:60RbULmH.net

>>196
virtual columnが計算列と同じだよ

198 ：デフォルトの名無しさん：2018/05/23(水) 21:40:23.91 ID:Au5e7VGg.net

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

31KGG

199 ：デフォルトの名無しさん：2018/07/05(木) 00:20:00.41 ID:RfoszcD2.net

27G