X

結局開発で最も大切なのはテーブルの正規化と制約 [無断転載禁止]©2ch.net

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
垢版 |
2017/08/24(木) 07:52:17.47ID:PyrFLEpH
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
開発の中で最も大切

炎上してるプロジェクトは
必ずと言って良いほど
これらを軽視している
0102デフォルトの名無しさん
垢版 |
2017/08/28(月) 23:33:14.45ID:8heg7vkK
>>100
テストしてなければ簡単に潰せるバグが大量に出るね
だけど意外と影響は小さい
「技術者への不信感が強くなる」というのが最も問題

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

それから「コード設計」って何？
0103デフォルトの名無しさん
垢版 |
2017/08/28(月) 23:33:45.46ID:ml0Q9t1V
正規化することより正規化されていないレガシーDBをどうにかするテクニックを研究した方が有益
ゼロから正しく作るのは簡単
困るのはいつも引き継いだ時だ
0106デフォルトの名無しさん
垢版 |
2017/08/28(月) 23:40:08.73ID:0eH/9F76
正規化をしていなくても別に後から修正すればいいだけだし、
それよりもコードだよ。

一旦書いてしまったら全部書き直しになってしまう
0107デフォルトの名無しさん
垢版 |
2017/08/28(月) 23:42:57.04ID:8heg7vkK
>>103
それはその通りだね

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

データ不整合が起きてる旧システムのデータを
そのまま新システムのデータベースにブチこむという決断が行われましたと
0109デフォルトの名無しさん
垢版 |
2017/08/28(月) 23:44:07.06ID:8heg7vkK
>>106
後から修正とか
まず不可能ですわ
0110デフォルトの名無しさん
垢版 |
2017/08/28(月) 23:48:09.43ID:ml0Q9t1V
>>107
うちも今まさにそれやってるわ
というかDB担当が使えねえカスで非正規のテーブル増やしやがったからもっと酷い
5年10年も勤めてる奴らなのに呆れ果てるわ

愚痴すまんな
0111デフォルトの名無しさん
垢版 |
2017/08/28(月) 23:52:26.36ID:8heg7vkK
>>110
(　ＴДＴ)

大変やね

俺は「金が出ればホワイト。残業代が出るからホワイト」ってアタマの中で唱え続けて乗りきった
0112デフォルトの名無しさん
垢版 |
2017/08/29(火) 00:06:42.81ID:rUOtN+gs
>>106
いやいや
本番運用開始したらDB構造を変えるのに比べればプログラムを変えるほうが簡単
DBは複数のシステム/アプリケーションから使われてることがほとんどだから
0113デフォルトの名無しさん
垢版 |
2017/08/29(火) 00:09:43.35ID:LVYauoO8
>>112
「コード設計」でググったからわかったのだが
ID:0eH/9F76が言ってる「コード」ってソースコードのことじゃないんだわ
0115デフォルトの名無しさん
垢版 |
2017/08/29(火) 01:57:11.98ID:oqFekZxP
せめてモデル層をクラスで集約出来ていれば正規化して正規化する前の形をSQL-VIEWで復元してあげればわりとやりやすくはなるかも
0116デフォルトの名無しさん
垢版 |
2017/08/29(火) 02:01:49.56ID:6sGVgGr/
Railsとかのフレームワークを使っていれば
普通に設計しても正規化状態になるので
フレームワークを導入しなければ炎上するって
言ったほうが良いと思う

もちろんオレオレフレームワークは
実績が少ないので意味がない
0117デフォルトの名無しさん
垢版 |
2017/08/29(火) 02:02:57.99ID:6sGVgGr/
フレームワークを導入してないところは
時代が20〜30年ぐらい遅れてると思う。

結局開発で最も大変なのは
最新技術を取り入れていくことかな
0118デフォルトの名無しさん
垢版 |
2017/08/29(火) 02:06:13.74ID:LVYauoO8
開発で最も大切なのは

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

この3つ
0119デフォルトの名無しさん
垢版 |
2017/08/29(火) 02:06:51.41ID:TMhzTuGH
ローテク極めていくほうがだいたい早い
30年前のCOBOLでもやってること大差なし
0121デフォルトの名無しさん
垢版 |
2017/08/29(火) 08:13:33.58ID:X4Q/TPlH
ようするにDRYだよ
１つの事実(知識)を１つの場所に
正規化はDRYのサブセット
0123デフォルトの名無しさん
垢版 |
2017/08/29(火) 10:25:48.19ID:mN0xls38
> 1.テーブルを正規化する
> 2.適切なデータ型を決定する
> 3.制約を定義する

まぁ、それができてたってアンチパターンにははまる可能性はあるわけで。
ということで、知らなかった人は書籍「SQLアンチパターン」を読むといい。
https://www.oreilly.co.jp/books/9784873115894/
0126デフォルトの名無しさん
垢版 |
2017/08/29(火) 15:22:36.62ID:PNzW02X+
>>125
テーブルの正規化以前に人に依存していると言う主張してか？
やはりスレタイは正しく無くて、>>1のようなカスを排除する事が炎上防止の最善策
0127デフォルトの名無しさん
垢版 |
2017/08/29(火) 15:40:18.67ID:mN0xls38
プロジェクトが炎上する要因は複数ある。

そこから合意してかないといけないのか？
0128デフォルトの名無しさん
垢版 |
2017/08/29(火) 17:41:41.49ID:PNzW02X+
「最も大切」というお題だから
自分で設定したお題を忘れてもらっちゃ困る
0129デフォルトの名無しさん
垢版 |
2017/08/29(火) 18:22:47.86ID:rUOtN+gs
>>121
正規化はDRYよりもSRPに近い
DRYは意味を理解しなくても機械的にほぼ判断できるが
正規化はエンティティ・キー・属性の意味や関係性を理解しないと判断できない

その時その時の主観によって意味や理解が変わりうる点や
原則を過剰に適用するとわかりにくく使いにくいものになる点が似ている
0130デフォルトの名無しさん
垢版 |
2017/08/29(火) 18:35:37.73ID:rUOtN+gs
>>122
読んだけど、この人はちょっと理論に寄り過ぎだね

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

↑いいたいことはわけるけど、こういう指針だけだと実践では役に立たないし
DB設計が原因で炎上してるようなところだと火に油を注ぐことになると思う
0131デフォルトの名無しさん
垢版 |
2017/08/29(火) 18:59:38.55ID:UC+DdZRH
開発で最も大切なのは

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

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

>>128
その通りだね
この3つより大切なモノを挙げてみるといいと思う
0132デフォルトの名無しさん
垢版 |
2017/08/29(火) 19:07:47.55ID:mN0xls38
>>130
> 読んだけど、この人はちょっと理論に寄り過ぎだね
たしかに『理論から学ぶデータベース実践入門』も理論がうざかったけどね。

ま、でも、このスレの有象無象のゴミレス読む暇があったら、「漢のコンピュータ道」の
DB関連記事読んだ方が、よっぽどためになると思うよ。
0133デフォルトの名無しさん
垢版 |
2017/08/29(火) 22:00:48.63ID:6sGVgGr/
>>131
> この3つ
> これらをやってなければ炎上して当然

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

それらをやってない所は少ないと思う
0134デフォルトの名無しさん
垢版 |
2017/08/30(水) 06:15:13.11ID:6oCjgbIk
それらをきっちりやらなくても済まされるようなド底辺で生きてるんだろ
さっしてやれ
0135デフォルトの名無しさん
垢版 |
2017/08/30(水) 07:29:56.75ID:ca1piqKW
どこまで正規化すんの？
大抵の落としどころはボイスコッドだと思うけど
おまいらだと第5正規化までやってそうｗ

システムに不要なほど過剰な正規化はするべきじゃない
0136デフォルトの名無しさん
垢版 |
2017/08/30(水) 07:34:51.44ID:ev9FmYBb
>>133
そりゃ予算に無理があるんじゃね？

>>134
炎上してるのだから「済まされる」とは言えないかな
0137デフォルトの名無しさん
垢版 |
2017/08/30(水) 07:50:02.99ID:ev9FmYBb
>>135
開発で最も大切なのは

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

この3つ

2や3について言うことは無いのかい？
0139デフォルトの名無しさん
垢版 |
2017/08/30(水) 21:01:44.13ID:RiHZq49u
開発で最も大切なのは

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

この3つ


んなわけない
0140デフォルトの名無しさん
垢版 |
2017/08/30(水) 21:09:48.80ID:vAN9hjOo
汎用機の考え方を引きずっているひとか設計すると正規化うんぬんの話が出るが、そもそもリレーショナルデータベースを理解している人間が設計した場合は、正規化という作業がほぼ発生しない。
0141デフォルトの名無しさん
垢版 |
2017/08/30(水) 21:17:21.02ID:E7OSkm2F
わかってなければ
リレーショナルとは無縁な
単なるデータの置き場所となる
0142デフォルトの名無しさん
垢版 |
2017/08/30(水) 21:21:36.74ID:Cx/iJc4q
正規化って何時頃からあるの?
それ以前は殆どのプロジェクトは炎上してたの?
0144デフォルトの名無しさん
垢版 |
2017/08/30(水) 22:19:01.02ID:cSzTCLjb
正規形を知っているからRDBを理解してるんじゃね？無意識に正規化してるって事だろ
0145デフォルトの名無しさん
垢版 |
2017/08/30(水) 22:32:47.74ID:E7OSkm2F
>>144
同意
0147デフォルトの名無しさん
垢版 |
2017/08/31(木) 00:34:28.16ID:J2aSRpVx
>>146
用途によるけど業務アプリケーションならトランザクションデータも普通は正規化するでしょ
注文明細に受注単価が入ってるのとかは正規化違反じゃないよ
0149デフォルトの名無しさん
垢版 |
2017/08/31(木) 00:50:48.09ID:j9yVEoD5
トランザクションデータを正規化しておけば
例えば処理が終わったトランザクションに含まれる
○○コードマスタを書き換えるだけで
過去に終わったトランザクションデータを
後から変更できて便利！
0150デフォルトの名無しさん
垢版 |
2017/08/31(木) 01:04:47.41ID:x3jdwRS7
マスターがバージョニングされて有効期間がきられていたら完全かもだけど普通はそこまでしない
0152デフォルトの名無しさん
垢版 |
2017/08/31(木) 09:49:05.97ID:j9yVEoD5
つまり注文データを正規化して

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

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

例えば受注履歴テーブルや受注明細履歴テーブル
サイズ履歴テーブル、色履歴テーブル
ありとあらゆるその時の情報を履歴テーブルにコピーする
0156デフォルトの名無しさん
垢版 |
2017/09/01(金) 00:03:45.67ID:A4rxsWGh
>>151
説明が短すぎてわからないや
「トランザクションも正規化するの？」の質問とつながってるの？
0157デフォルトの名無しさん
垢版 |
2017/09/01(金) 00:09:29.76ID:A4rxsWGh
>>155
イベントソーシングと履歴テーブルはちょっと違うよ

履歴テーブルは状態変更イベントを記録するんじゃなくて
変化した状態そのものを記録していく
基本的にTemporal Tableと同じ
0158デフォルトの名無しさん
垢版 |
2017/09/01(金) 08:19:46.16ID:s82kToZ5
>>152
カーボンコピーを受注テーブルに持たせるんだよ
それかカーボンコピーを受注リソースに分離して参照を貼る
少なくとも受注に絡む事実を注文に持たせるものではない
0159デフォルトの名無しさん
垢版 |
2017/09/01(金) 09:53:47.01ID:Z9Fha70u
○次受けが多いほど退場率が早くなる。高くなる

直受けの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に加入して公表価格で応募ができる
0160ワハハ！！
垢版 |
2017/09/01(金) 15:41:47.31ID:HLMXttPm
816 名無しさん＠お腹いっぱい。 2017/09/01 15:28:38
まそふぱぞ
>>815
そうだなキチガイ撲滅平和維持軍である俺様の勝ちだな♪
AA無職キチガイをブチ殺してスレの正常化に成功！
うぇーい☆
はい勝った♪
0161デフォルトの名無しさん
垢版 |
2017/09/02(土) 07:09:47.97ID:TvzMBAqs
データベースを伴わない開発業務なんでさっぱり
テーブルの正規化って何それ
0162デフォルトの名無しさん
垢版 |
2017/09/02(土) 18:27:11.77ID:xFUbH9ih
>>161
学生さんですか？
0163デフォルトの名無しさん
垢版 |
2017/09/02(土) 18:51:01.16ID:x3xo3AHA
学生さんは視野が狭いですからねぇ。
この世は全てデータベースを使っているのですよ。
0164デフォルトの名無しさん
垢版 |
2017/09/03(日) 19:16:01.09ID:TRtZ/EY8
>>161
確かにデータベースを使わない業務もあるだろうけど
それこそ「データベースを使わない業務もある」というレベルの話だわな
0165デフォルトの名無しさん
垢版 |
2017/09/10(日) 01:03:09.87ID:T3zRvirf
>>82
意味なくない
ローマは一日にしてならず

リファクタリングが必要なとこから一つ一つやってきゃいい
デグレはコードをいじるから生じるんだ
0166デフォルトの名無しさん
垢版 |
2017/09/10(日) 10:29:13.81ID:CNj3ELqz
ほんそれ
入れやすい部分に入ってるだけでも全然違うっつーの
0167デフォルトの名無しさん
垢版 |
2017/09/10(日) 11:27:51.04ID:G4ZVCKWZ
重要な部分じゃなくて入れやすい部分？
入れにくい所を入れやすいように変えると
デグレを生むしなーｗ
0168デフォルトの名無しさん
垢版 |
2017/09/10(日) 11:48:05.91ID:Ten/S+rP
リファクタリング下手くそな奴ほどデグレを恐れるよね
普段からマトモなテストをしてない証拠
スキル不足を公言するようなものだ
0169デフォルトの名無しさん
垢版 |
2017/09/10(日) 12:26:22.14ID:CNj3ELqz
リファクタリング
自動テスト
正規化
適切なデータ型
制約

デグレを怖れる者ほど
これらを否定する
0170デフォルトの名無しさん
垢版 |
2017/09/10(日) 13:20:05.93ID:PwzOYpRH
コード触らない人間ほど否定的だあな

組織、チームとして動脈硬化が末期的
0174デフォルトの名無しさん
垢版 |
2017/09/10(日) 19:57:35.46ID:+BHhCGE8
>>172
言う言うw
0175デフォルトの名無しさん
垢版 |
2017/09/11(月) 09:37:54.90ID:vJ3AiMg+
○次受けが多いほど退場率が早くなる。高くなる

直受けの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) 　プログラマーズ
0176デフォルトの名無しさん
垢版 |
2017/09/12(火) 00:06:50.77ID:HbvMS5Mi
正規化してないプロジェクトが原因不明のデータ不整合多発で大炎上しててわろた
早いうちに別案件に逃げ出せてよかった
0177デフォルトの名無しさん
垢版 |
2017/09/12(火) 00:23:18.06ID:U1/fLtdM
それ原因不明じゃないwww
0178デフォルトの名無しさん
垢版 |
2017/09/12(火) 09:04:32.20ID:EOOe72TQ
eJobgo　JIET　JISA　で検索

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

首都圏IT(PE-BANK) クラウドテック　プログラマーズ
0179デフォルトの名無しさん
垢版 |
2017/09/19(火) 14:58:02.69ID:4nMrrTsq
引き継ぎ資料に「どういう所に注意しなければいけないか」というのを書かないといけないらしい
「正規化されておらず制約も無いのでデータ不整合が多発するでしょう」って書いたら間違いなく俺のせいにされるな

書かなくても俺のせいにされそうだけど
0180デフォルトの名無しさん
垢版 |
2017/09/19(火) 23:06:24.80ID:8Nvi84xk
「制約が無いのでデータ不整合に注意してください」
でいいんじゃない
正規化されていないとか多発するでしょうとか文章の目的にそぐわないからいらない
0181デフォルトの名無しさん
垢版 |
2017/09/20(水) 01:16:17.18ID:DOSxYj0U
外部キー制約やユニーク制約なら
なんで追加しなかったんですか？ってなる
単純に追加できなかった理由こそ注意点として書くべき
0182デフォルトの名無しさん
垢版 |
2017/09/20(水) 07:30:25.14ID:S4RtYHtC
旧システム側が既にデータ不整合を起こしており
不整合を起こしているデータを移行する時に問題になるから
by上司
0183デフォルトの名無しさん
垢版 |
2017/09/20(水) 09:47:51.51ID:AMouiYzy
コンバートプログラムかけばいいだろ
或いは不整合一覧を出力するようなプログラム
0184デフォルトの名無しさん
垢版 |
2017/09/20(水) 11:09:17.98ID:9s4WD3hZ
コンバートプログラム作製は上司の担当
不整合を起こしてるデータを検出するプログラムを勝手に作ってることがバレたらどうするんだ？
0185デフォルトの名無しさん
垢版 |
2017/09/20(水) 12:19:51.63ID:woEI7sSr
最も大切なのは上司の指示や規約ではなくテーブルの正規化と制約
バレても問題ない
0186デフォルトの名無しさん
垢版 |
2017/09/20(水) 12:44:06.80ID:xbK0Hqs4
いーこと言うね
0187デフォルトの名無しさん
垢版 |
2017/09/20(水) 21:08:31.58ID:8N1Ug+q3
エラーが出るので制約外せってクレーム来た
もうどうでもよくなって外しちゃった
これで不正データ混入確定
あ〜もうやだみんな死ねばいいのに
0188デフォルトの名無しさん
垢版 |
2017/09/20(水) 21:29:21.54ID:DOSxYj0U
>>182
不整合データをそのまま移行してて問題ないのかとか、
その承認を文書で顧客に貰っているのかとか、
その不整合に起因するあらゆる不具合については免責されるのかとか、
芋づる式に注意点が出てくる

担当上司が転職でもしたら
引き継ぎされたやつと会社が損害被るパターン
0189デフォルトの名無しさん
垢版 |
2017/09/20(水) 21:38:34.84ID:DOSxYj0U
>>187
きちんとリスクを説明して顧客がそれを理解した上で
制約を外すことを命じたという証拠がなければ
担当者が変わればバグ扱いになるし訴えられたら負ける可能性もあるよ
その文面だと力関係に相当な差がありそうだし
0192デフォルトの名無しさん
垢版 |
2017/09/26(火) 22:12:11.97ID:QDxeQPV4
いわゆる「コード値の先頭N文字がコード区分になってる」アンチパターンってどう扱うのがいいの?
業務ルールで決まってるからコード体系変えるわけにもいかないのが歯がゆい
0193デフォルトの名無しさん
垢版 |
2017/09/26(火) 22:59:04.53ID:fvF/8EVL
>>192
[論理レベル]
コード区分と先頭N文字以外の部分はそれぞれ独立した属性として
2つを合成した値は導出属性として扱う
(コード区分は参照テーブルを作って外部キー参照で)

[物理レベル]
導出属性を計算列やユーザー定義関数等を使って実装する
非正規化して合成した値をそのままカラムに入れる方法もよくやる
その場合は導出属性だけ更新した場合やその逆の場合で不整合が発生する
0194デフォルトの名無しさん
垢版 |
2017/09/27(水) 06:14:05.65ID:rJhIuBz0
>>192
客が考えたコードは一才信用せず
敢えてサロゲートキーのIDリクワイアドで物理設計を行う
サロゲートキーは原則としてユーザーに見せない

コード値にはユニーク制約やチェック制約などで対応
0196デフォルトの名無しさん
垢版 |
2017/09/27(水) 23:38:08.77ID:I+73OQfD
>>193
これやるなら計算列のサポートが欲しいね
なんでM$しか計算列をサポートしてないんだろ
オラクルだと列追加してチェック制約がベターかな
0198デフォルトの名無しさん
垢版 |
2018/05/23(水) 21:40:23.91ID:Au5e7VGg
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

31KGG
0199デフォルトの名無しさん
垢版 |
2018/07/05(木) 00:20:00.41ID:RfoszcD2
27G
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況