プログラマの雑談部屋 ★376 (176ﾚｽ)
上下前次1-新
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
112(1): 11/15(土)19:37 AAS
テーブル数数百ってそんな増えるもんなの？
113(1): 11/15(土)19:38 AAS
というかそんなもの把握できるもんなの？
114: 11/15(土)19:39 AAS
すぐだぞ
115: 11/15(土)19:58 AAS
数百テーブルは無駄な設計してるわけじゃなければやばいな
116: 11/15(土)19:59 AAS
それくらいすぐだってば
117(1): 11/15(土)20:09 AAS
テーブルの天板が冷たい
手首保護のためそろそろシートを出そうと思うんだけど机の上が散らかってて困る
そういう話ではない
あそうですか
118: 11/15(土)20:10 AAS
そんなもんサービスの内容と規模によるだろ当然だけど
119: 11/15(土)20:17 AAS
>>117
クソデカマウスパッド敷いてるわ
120: 11/15(土)22:08 AAS
>>108
PHPのDoctrineというORMだとエンティティ（クラス）で変数を定義したすぐ上にコメントでどのエンティティを参照するとか多対1であるとか書いてアップデートコマンドを実行するとテーブルにカラムを追加したり外部キーを設定してくれたりする。
121: 11/15(土)22:09 AAS
びっくりだ
122: 11/15(土)22:14 AAS
>>112
商品とか顧客とかはもちろんだけど何か意味のあるエンティティ（クラス、オブジェクト）を使おうと思ったらそれぞれが一つのテーブルになるからECのWEBシステムとか作ってたらあっという間に増える。もちろんマスタテーブルなんかも次々増えていくし。
123: 11/15(土)22:19 AAS
サービスの性格次第だな
成長拡大してくタイプならどうしたってデータは汚くなってくし
コードと同じでそりゃ誰だってできるだけきれいに設計したい
だが現実、ビジネスがそれを許さない
124: 11/15(土)22:22 AAS
>>113
全部を隅から隅まで把握する必要もないと思う。一つのエンティティを取得したらそれに関連するエンティティは勝手にORMがJOINしてDBからロードしてくれるので。もちろん遅延ロードとかも設定できる。
どの変数がどのエンティティ（クラス＝テーブル）を参照するかはORM用のコメントとして書いてあるのでひとつのクラスのソースを見ればそのクラスに関連するテーブルはすべてわかるし。
125: 11/15(土)22:25 AAS
スパゲティコードなんていうけど、あんなのも根本はデータに原因がある場合がほとんどで、コードはそうした病的データに対する対症療法でしかない
システム開発においてデータは将来を左右する
126(1): 11/15(土)22:26 AAS
きれいなコードになるデータ構成がどんなのかデータだけ見てわかるのか？
127: 11/15(土)22:29 AAS
最初は綺麗なんだよなぁ
頑張って設計したし
でも追加機能やら改修やらで綺麗にするとソースコードの修正範囲が大きくなるからツギハギして行くうちにゴミ化して来る
128(1): 11/15(土)22:36 AAS
事業会社なんかはサービスの売り上げ、
（当然だけど）ビジネスありきであるわけだから、求められるのは巧遅よりも拙速であり、データは自然と継ぎ足しに
コードはそうしたデータの尻拭い
結果としてのスパゲティ
>>126
少なくとも上記のような環境でなけりゃデータの設計しっかりするでしょ
129(1): 11/15(土)22:39 AAS
・時間によってバージョン切り替えするようなマスタをどうやって設計しますか？
開始時間と終了時間の両方をカラム含めさせますか？
ビューを付けたほうがいいでしょうか？
・リカーシブな読み込み前提のテーブルを作ってもいいでしょうか？後々面倒はないでしょうか？
・レコードの版をどうやって管理しますか？結合するときに面倒はないでしょうか？
・論理削除使いますか？部分的に削除したのと、親ごと削除したのと区別が付きますか。削除した情報を見たいなんて要求があるとき、どうしますか？
130: 11/15(土)22:42 AAS
協力会社の技術力のあるエンジニアを信用して任せてたらその会社の他のプロジェクトが忙しくなってそちらに手を取られて、うちの仕事はそこの外注の初心者みたいなエンジニアに投げられてぐちゃぐちゃなコードを量産しまくられて挙句の果てに協力会社ごと逃げられたことがある。今でもその時のゴミコードでバグが発生してメンテする手間がかかっている。まぁその当時のうちの人間がすべてをレビューしてなかったのも問題だとは思うが（私はいなかったので知らん）
131(1): 11/15(土)22:43 AAS
今はAIが全てのベストプラクティスをご存知なのでまだいい
当時はひとつひとつが鬼門だった
いや今でもサボったほうが楽なことが多くて後々地獄になる
簡単そうには見えるんだが
個々のSQLの膨らみ具合と
こんなはずじゃない勢いのテーブル増加を見て怖気づく
132(1): 11/15(土)22:48 AAS
>>128
まさにその状態の真っ只中にいる。とにかく責任者が思いついたらその機能を2-3日みたいなスパンで投入しないといけないのでじっくり設計とかしている暇はない。いまこれリリースしたらトラブル可能性ありますよと言ってもとにかく機能が欲しい、トラブっても動かしながら直せばいいみたいな感じ
まぁ結論としてはまともなエンジニアリングをしている会社で働こう！ということだなw
133: 11/15(土)22:51 AAS
うそです会社で設計したことない
ジジイなので記憶が改竄されてた
134: 11/15(土)22:52 AAS
>>131
テーブルやSQLが複雑になってももう気にしなくてもよいのでは？自分で書く時代は終わってAIに任せておけば複雑なSQLも一瞬で仕上げてくれるんだし。必死で勉強して大量にSQL書いてきたけど、まったくもってAIの書くスピードとSQLの内容のスマートさにはかなわんわ
135: 11/15(土)22:54 AAS
ああそっか…
時代はかわったんだ…
136: 11/15(土)22:55 AAS
下剤効いて2kg出た
137: 11/15(土)22:57 AAS
なにもさせてもらえなかった
社会に影響を与えるチャンスは
ことごとく足払いをかけられて潰されてきた
138: 11/15(土)22:58 AAS
>>132
まともなエンジニアリングしてる大手有名会社がそういう事してるからだよ
MSとかAppleとかAWSとかGoogleとかMetaとかその他諸々
139: 11/15(土)22:59 AAS
自分の状況は悪くはない
悪くはないが結局は社会に消されたんだ
140(1): 11/15(土)23:00 AAS
>>129
>時間によってバージョン切り替え
バージョンによって、じゃなくてマスタ切り替えではなくて？
>開始時間と終了時間の両方をカラム
判然とせんけどたぶんイエス
>ビューを付けたほうがいいでしょうか？
サービスによる
>リカーシブな読み込み前提のテーブルを作ってもいいでしょうか？
おつしるとおり軽々に取り入れるのではなく、運用上アンチパターン化することはないか設計時点で考えるべき
>レコードの版をどうやって管理しますか？
バージョンカラム？
危惧されている結合における面倒ごととは？
>論理削除使いますか？
>削除した情報を見たいなんて要求がある
このユースケース、要望なら当然論理
物理、保持期間は要件次第
141: 11/15(土)23:02 AAS
>>140
標準的な人間の回答をありがとう
見通しが立たなくてわからんから聞いてるんだが結局人間じゃこういう回答が返ってくるよな
当然だ
AIなら
上下前次1-新書関写板覧索設栞歴
あと 35 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.006s