X
トップページ⇒DB＠2ch掲示板
1002コメント323KB
DB設計を語るスレ 10 [無断転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
0851NAME IS NULL
垢版 |
2021/02/05(金) 07:22:54.69ID:???
このスレ的には、単一参照テーブル、又の名をOTLT
は結論出てたりする？

https://gihyo.jp/dev/serial/01/sql_academy2/000301

うちの古いシステムは大量にある名称マスタをこの方法で取り扱ってるけど、
やめた方がいいのかなと。
0852NAME IS NULL
垢版 |
2021/02/05(金) 12:23:22.50ID:???
>>851
DB設計の観点からだけいえばEAVと一緒で100%やめたほうがいい
ポリモーフィズムでもなければオブジェクト指向は全く関係ない
RDB以前の汎用機で使われてたやり方

実際にやめるかどうかはシステムの寿命や変更の頻度を考えた場合に
手間をかけるメリットがあるかどうか
0853NAME IS NULL
垢版 |
2021/02/05(金) 12:31:10.80ID:???
>>852
流石に動いてるものは触れない。
仮に新しく作り直すとしたら
大量にマスタが作られて、大量にCRUDの画面が作られる問題が出てくる
これ皆どう解決してるんだろう
もう気にせず愚直に作った方が精神的にもシステム的にもいいんだろうか。
0854NAME IS NULL
垢版 |
2021/02/05(金) 17:00:05.17ID:???
>>851
自分だったら単一参照テーブルにするなら内部キー(PK)・識別子・外部キー・内容の様にして
トランザクションには内部キーを保持したい
理由はテーブルの結合の際にトランザクションとマスタを外部キーで結合して
さらに識別子をハードコードするのは抵抗があるから
でもこういう設計をしても結合の際に識別子を条件に付ける人がいそうなので困る
0855NAME IS NULL
垢版 |
2021/02/05(金) 18:14:28.40ID:???
>>854
複合キーじゃなくサロゲートキーを導入するという話なんだろうけど
識別子や外部キーって用語の使い方を間違えてるから全然伝わらないぞ

識別子は基本的にそれによって行を特定できるキーのこと
外部キーはForeign Keyのこと
商品IDとJANコードのようなのは内部ID/外部IDとは言うけど外部キーとは言わない
0856NAME IS NULL
垢版 |
2021/02/05(金) 18:17:26.28ID:???
>>853
マスタメンテ画面が必要ないものもたくさんあると思うんだけど
必要なら汎用的なマスタメンテ画面を作ればいいんじゃない
0857NAME IS NULL
垢版 |
2021/02/05(金) 19:08:27.08ID:???
>>855
お前が勝手に言葉変えてるだけだろ
0858NAME IS NULL
垢版 |
2021/02/05(金) 19:08:56.72ID:???
>>856
いっぱいお客さんいると男女ですら変更したいという要件もある…
さらにやっぱり英語名も持ちたいとか色々要件増えて管理する項目も微妙に変わってくんだよな…
で、それを汎用項目みたいな持たせ方してるんだよ…

恥ずかしながらこの記事の作者同様、若い頃は便利だなあと思ってた。

よし、一念発起してSexMaster作るか
0859NAME IS NULL
垢版 |
2021/02/05(金) 21:09:23.08ID:???
ここまで、>>851がダメな理由を明確に説明できる奴皆無
0860NAME IS NULL
垢版 |
2021/02/05(金) 21:31:59.63ID:???
>>858
メンテが必要でSQLで手動更新しないなら画面用意する他ないな
Railsのようなのでscaffoldでサクサク作るか
metadata用のAPI使ってOTLTと同じような共通汎用メンテ画面を作るか
0862NAME IS NULL
垢版 |
2021/02/05(金) 21:42:58.60ID:???
>>861
そういうスレだしな。
でも根拠なしにテキトーなこと言ってるだけの奴は「ググれ」「自分で考えろ」とかいってごまかす。
0863NAME IS NULL
垢版 |
2021/02/05(金) 22:54:38.55ID:???
>>862
記事に欠点が列挙されてるんだがそれは読んだのか？
0864NAME IS NULL
垢版 |
2021/02/05(金) 23:09:49.13ID:???
メリットデメリット併記されていて、少なくとも「100%やめたほうがいい」なんて断言はしてないと思うが
0865NAME IS NULL
垢版 |
2021/02/06(土) 00:05:44.88ID:???
それはミック氏の考え方だからな
SQLには詳しいけどDB設計に詳しい人ではないから
0866NAME IS NULL
垢版 |
2021/02/06(土) 00:11:31.24ID:???
一番大きな欠点は参照整合性を担保できなくなる点
記事にメリットとしてあげられてる点も鵜呑みにせず本当かどうか考えたほうがいい
0867NAME IS NULL
垢版 |
2021/02/06(土) 05:47:12.37ID:???
じゃあ皆さんの設計する社員マスタはセックスマスターを参照しているんですか？
0868NAME IS NULL
垢版 |
2021/02/06(土) 09:45:46.26ID:???
>>866
正確に言うと、件のマスターの主キーが複合主キーになるから参照整合性制約をかけようとするなら
面倒くさい＆無駄ってことだね。
それを必要としない用途で使う分には問題ないかもしれない。
0869NAME IS NULL
垢版 |
2021/02/06(土) 14:26:16.22ID:???
>>868
そう
担保するためには複合主キー+チェック制約がいるので
OTLTを1つ参照するたびに2カラム必要になってヒドイことになる

参照する側が取りうる値の範囲を参照制約以外で担保する前提で
異なるコード体系じゃなく統一されたコード体系のテーブルなら
DB設計的にも有りだけどそれはもうOTLTじゃない
0870NAME IS NULL
垢版 |
2021/02/06(土) 19:44:15.11ID:???
それOTLTとか関係なく複合主キーの問題なんじゃね
0871NAME IS NULL
垢版 |
2021/02/06(土) 20:44:19.48ID:???
そもそも
> OTLTを1つ参照するたびに2カラム必要になってヒドイことになる
とか感覚で語ってる奴の相手しなくていいかと
0872NAME IS NULL
垢版 |
2021/02/06(土) 21:33:46.92ID:???
これだけ解説してもらってもわからないってどういうことよ
0873NAME IS NULL
垢版 |
2021/02/06(土) 21:40:35.94ID:???
>>869
1:男←性別
2:女
3:北海道←ここから都道府県
4:青森
...
80:赤←ここから色
81:青

みたいに管理するってこと？
0874NAME IS NULL
垢版 |
2021/02/06(土) 21:58:10.25ID:???
そもそもOTLTを検討するようなデータは制約をつけるようなデータは管理しないのでは
自分が設計したDBは可変特にユーザーが何か設定するようなデータは必ずマスタとして登録してたわ
何でもかんでも使うのは乱暴だけど純粋にシステムとして値と内容だけで完結するようなデータであればありだと思う
0875NAME IS NULL
垢版 |
2021/02/06(土) 22:46:52.67ID:???
>>874
よくわからん
必ずマスタとして登録って、つまりOTLT的なマスタのこと？
0876NAME IS NULL
垢版 |
2021/02/06(土) 23:18:19.50ID:???
わからないならしかたない
0877NAME IS NULL
垢版 |
2021/02/07(日) 08:38:41.24ID:???
みんなセックスマスター作ってるのか？
0878NAME IS NULL
垢版 |
2021/02/07(日) 10:46:31.05ID:???
みんなあーだこーだ言うだけで
セックスマスター持ってるかどうかまでは言及しないな
0879NAME IS NULL
垢版 |
2021/02/07(日) 13:58:15.18ID:???
>>873
それは統一されたコード体系で扱えるデータじゃないからすぐ破綻すると思うが
データ構造だけで言えば下のように管理して特定の値はIDのみで引けるようにしておくイメージ
表示の多言語対応なんかで使う

ID:カテゴリ:表示名
1:性別:男
2:性別:女
3:都道府県:北海道
4:都道府県:青森
...
80:色:赤
81:色:青
0880NAME IS NULL
垢版 |
2021/02/07(日) 13:59:52.25ID:???
性別はわざわざ参照テーブルを用意するほどじゃないことが多い
作る場合はgenderテーブル
0881NAME IS NULL
垢版 |
2021/02/07(日) 14:01:55.50ID:???
性別には、「未回答」、「回答拒否」って場合もあるんだろうか
0882NAME IS NULL
垢版 |
2021/02/07(日) 14:58:31.26ID:???
>>881
うちは男性、女性、不明で管理してるけど
この手の区分は全てドキュメントの辞書管理してるだけでわざわざテーブルに登録してない
0883NAME IS NULL
垢版 |
2021/02/07(日) 20:16:00.19ID:???
100万件の会員データcsvで出力してください
性別は名称付きでってなったらどうするの？
0884NAME IS NULL
垢版 |
2021/02/07(日) 20:25:45.49ID:???
>>883
case で名前に変換すりゃいいだけじゃね
0885NAME IS NULL
垢版 |
2021/02/07(日) 20:48:57.88ID:???
むむ、じゃあ今日だけ、男じゃなくて雄でだしてほしいんだよな〜って言われたらどうするの
0886NAME IS NULL
垢版 |
2021/02/07(日) 21:03:19.72ID:???
αβΩとか入ってくるとややこしいなぁ
0887NAME IS NULL
垢版 |
2021/02/07(日) 21:09:16.30ID:???
データがあればいくらでも出力できるだろ
生年月日は和暦でお願いといっしょでここでする話じゃない
0888NAME IS NULL
垢版 |
2021/02/07(日) 21:11:51.65ID:???
>>885
今日だけSQL書き換えればいいだけでしょ
アドホックな要求ならそれで充分
0889NAME IS NULL
垢版 |
2021/02/07(日) 22:24:53.92ID:???
今日は♂になりました
0890NAME IS NULL
垢版 |
2021/02/07(日) 22:40:40.47ID:???
>>888
保守性が低い
あなたの会社は毎回sql書き換えてリリースされるのですか
0891NAME IS NULL
垢版 |
2021/02/07(日) 22:54:02.61ID:???
アドホックに表示名を変更するためだけに
マスタを変更するほうが保守性が低い
0892NAME IS NULL
垢版 |
2021/02/07(日) 23:07:35.14ID:???
馬鹿はかまわないほうがいいぞ
0893NAME IS NULL
垢版 |
2021/02/07(日) 23:10:40.93ID:???
性別はともかくどこまでマスタ管理するかだよなあ
令和のために元々管理していなかった元号をマスタ管理するようになったところは多いと思う
0894NAME IS NULL
垢版 |
2021/02/07(日) 23:12:38.92ID:???
保険会社みたいに性別が重要な情報で
それを含む会員データをいろんな用途で使うなら間違いなく性別マスターを作る

でも今回発送するDMに限っては”男性”じゃなく”♂”で表示したいとなっても
性別マスターを更新して対応したりはしない

アドホックに表示をカスタマイズしたいという要望が
恒常的に発生してシステム化が必要な場合は
カノニカルな表記とは別にマッピング機能を追加する
0895NAME IS NULL
垢版 |
2021/02/08(月) 05:59:15.42ID:???
>>890
アドホックの意味わかる？
まあ100万件超えないならExcelにエクスポートして置換でもいいかもな
0896NAME IS NULL
垢版 |
2021/02/08(月) 06:07:15.07ID:???
>>891
保守性と言うかどこで使われてるかわからんマスタの変更なんて簡単にできないよね
本当にいろいろな表示の仕方が恒常的に要求されるならマスタに表示用の列を複数持つわ
id|表示名1|表示名2|表示名3|…
1|男|♂|雄|…
2|女|♀|雌|…
0897NAME IS NULL
垢版 |
2021/02/08(月) 07:03:16.85ID:???
アドホック（ad hoc）は、「特定の目的のための」「限定目的の」などといった意味のラテン語の語句である。

ラテン語はわからないです…
0899NAME IS NULL
垢版 |
2021/02/08(月) 12:49:21.91ID:???
>>896
「今日だけ絵文字で表示したいんですけど〜」
「じゃ、お列追加しときますね〜」
0900NAME IS NULL
垢版 |
2021/02/08(月) 15:13:29.86ID:???
>>899
日本語理解できないのか？
> "恒常的" に要求されるならマスタに表示用の列を複数持つ
今日だけの話ならcaseでも専用の表示マスタでも好きにやってくれ
0901NAME IS NULL
垢版 |
2021/02/08(月) 15:45:13.95ID:???
恒常的に要求されてもこのケースは列持ちすべきじゃない
0902NAME IS NULL
垢版 |
2021/02/08(月) 16:19:26.78ID:???
DB設計もしたことない奴が書き込んでるだから無視したほうがいいぞ
俺の中では851なんて全体で合意をとればいい話でどっちだってかまわないと思ってる話題
ただ値（ID、コード）にAは数値、Bは文字と意味を持たせたいなら別管理したほうがストレスはないと思う
0904NAME IS NULL
垢版 |
2021/02/08(月) 17:50:13.97ID:???
>>903
id|表示名1|表示名2|表示名3|表示名4|表示名5|表示名6|表示名7|表示名8|…

↑こういう設計見たらどうするの？
0905NAME IS NULL
垢版 |
2021/02/08(月) 17:51:51.04ID:???
扱うシステムの規模にもよるだろうが、大量に名称マスタが必要なシステムだと方向性間違えると辛いことになる

マスタを全て分けると必要最低限の管理画面が必要。その開発工数がバカにならない。

上でも挙がっているが
Rubyのスキャフォールドは便利だが、大規模システムで動的型付け言語は別の点でやばくなる。
asp.net mvcのスキャフォールドはrubyのパクリだが静的型付けなのでまだマシ。
これらに限らず最近のフレームワークは似たような構築機能があるだろう。

加えてシステムの変更に強い。
この名称マスタだけカラムを追加したいみたいなことに対応しやすい。

小規模で変更がないシステムであれば…名称マスタも少ないだろからやっぱりちゃんとマスタ作ったほうがいいんじゃない？
0906NAME IS NULL
垢版 |
2021/02/08(月) 18:32:42.95ID:???
>>904
いいんじゃないの？
表示名nみたいな名前はどうかと思うけど
で、>>903の回答は？
0907NAME IS NULL
垢版 |
2021/02/08(月) 19:34:38.74ID:???
セックスマスター作る派のやつは、セックスマスターメンテナンス画面もつくるのか？
0909NAME IS NULL
垢版 |
2021/02/08(月) 20:54:45.84ID:???
"ぼくのかんがえた最強のセックスマスター"が瞬殺されて涙目の素人さんwww
0910NAME IS NULL
垢版 |
2021/02/08(月) 21:12:25.50ID:???
>>907
セックスマスターにインサートしちゃう
0911NAME IS NULL
垢版 |
2021/02/08(月) 21:27:56.93ID:???
>>909
そういうゴタクはよりマシなセックスマスター提示してから言わないと恥ずかしいだけやでww
0912NAME IS NULL
垢版 |
2021/02/08(月) 21:34:52.75ID:???
セックスマスター作らない人は
TO_DOU_FU_KEN_MASTERも作らないの？
0914NAME IS NULL
垢版 |
2021/02/08(月) 22:52:38.12ID:???
>>905
マスタを分けてもテーブルの構造に応じて
メンテ画面の内容が変わるようなのを1つ作っとけばいいだけでしょ
異なるコード体系を1カラムに詰め込むのはC#でdynamic typeを使うようなもの
0915NAME IS NULL
垢版 |
2021/02/08(月) 23:14:23.60ID:???
>>907
都道府県マスターと同じでメンテ画面は必要ないことのほうが多い
0916NAME IS NULL
垢版 |
2021/02/09(火) 12:09:04.76ID:???
>>914
異なるコード体系を1カラムに突っ込むなんて書いてないつもりなんだが。

んで、そういう動的に画面生成されるようなやつってどうなんだろ
動的にsql組み立てることになって結局メンテナンスしづらくなると思う。
0917NAME IS NULL
垢版 |
2021/02/09(火) 12:45:28.48ID:???
表示を日本語でするか英語でするかを、
使用するユーザーが決める
それと同じように作ればいい
0918NAME IS NULL
垢版 |
2021/02/09(火) 16:02:15.61ID:???
>>916
>加えてシステムの変更に強い。
>この名称マスタだけカラムを追加したいみたいなことに対応しやすい。

じゃ”この名称マスタ”ってどういう構造を想定して言ってるの？
0919NAME IS NULL
垢版 |
2021/02/09(火) 16:11:20.57ID:???
>>917
それをRDBでやる方法がよくわからないからOTLTみたいなものになってるんだろうね
0920NAME IS NULL
垢版 |
2021/02/09(火) 17:16:30.95ID:???
わかってるやつは話題にはいってこない内容だし
バカが話を脱線させるから851みたいな話はおわらないｗ
0921NAME IS NULL
垢版 |
2021/02/09(火) 17:51:32.88ID:???
>>918
おれはOTLTじゃなくて
性別マスタ、都道府県マスタで別に管理しましょう派だよ？

たとえば都道府県マスタに名産物列を追加しましょう。
メンテナンス画面はめんどくさいけどちまちま直しましょう。
ってこと。
0922NAME IS NULL
垢版 |
2021/02/09(火) 17:56:14.58ID:???
コードと名称以外の属性持つ前提ならOTLTなんて考えないのでは
OTLTを前提にするならコードと名称以外の属性はもたないでしょ
0923NAME IS NULL
垢版 |
2021/02/09(火) 18:15:45.02ID:???
>>922
そんな前提はすぐ崩れる
ソフトウェアには変更がつきもの
0925NAME IS NULL
垢版 |
2021/02/09(火) 18:44:25.95ID:???
>>923
もともとの要件にない話なら問題外
開発中の変更であれば別テーブルに変更すればいいだけ
そもそもコードと名称しか管理しない前提の都道府県情報に
名産物なんて項目を増やすようなシステムなら最初から別テーブルになるし
そんなこと言い出したらOTLT禁止の前提でシステム（DB）設計してると思うわ
こういう話はごねたいだけの話題にしかならんね
0926NAME IS NULL
垢版 |
2021/02/09(火) 18:45:47.69ID:???
>>916
>動的にsql組み立てることになって結局メンテナンスしづらくなると思う。

動的sql的なものは使わざるをえないけどORM使えば全然大変じゃない
0927NAME IS NULL
垢版 |
2021/02/09(火) 19:25:24.73ID:???
>>925
だから禁止っつうかOTLT使うなって言ってるつーの
0928NAME IS NULL
垢版 |
2021/02/09(火) 19:27:36.02ID:???
>>926
そんなORMあるか…？
そのobjectの型定義はどうなってるんだ？
AcriveRecord？
0929NAME IS NULL
垢版 |
2021/02/09(火) 19:53:07.87ID:???
>>927
0なし
1あり
しか持たない〇〇テーブルたくさん持つの？
0930NAME IS NULL
垢版 |
2021/02/09(火) 20:30:48.58ID:???
>>929
他の人も書いてるように、メンテナンスが発生しない&コードが少ないのであれば
メモリ内に持つ

意外とOTLT派が多いね
自分も大昔使っていたが、害の方が多いという印象。
0931NAME IS NULL
垢版 |
2021/02/09(火) 21:24:37.20ID:???
>意外とOTLT派が多いね

「OTLT派」ってほど積極的に肯定している人はいないんじゃないかな。
ダメな理由がないなら使ってもいいじゃん、程度だと思うけどね。

>自分も大昔使っていたが、害の方が多いという印象。

その「害」を具体的に挙げたら建設的な議論になると思う。
ひとつは上で参照制約の話が挙げられていたが。
0932NAME IS NULL
垢版 |
2021/02/09(火) 21:47:29.79ID:???
こんな害

レコードが増えすぎると性能に影響が出る。そんな大量に突っ込むなよってはなしだが、使い所を分かってない人間はなんでも入れてくる。

変更に強いようで弱い。汎用性を意識して予備カラムみたいなのを用意するが結局足りなかったり、数値型と言ってもintとnumber、日付も時間まで持つかどうかで変わる。
型は厳密に。null非許容にできないのも痛い。

汎用性を重視するあまりカラム名が曖昧になる（なんとか1,2,3）
名前が適当だと後でわからなくなる。

それぞれにViewを定義したりして誤魔化してきたけど、使い所を誤る人がどうしても出てくるのだ。
0933NAME IS NULL
垢版 |
2021/02/09(火) 21:56:11.05ID:???
ありがとう。
そうやって具体的に挙げてもらえたら、あとは自分の案件にとってそれが
「害」になるのかどうか判断すりゃいいだけだね。
0934NAME IS NULL
垢版 |
2021/02/09(火) 22:13:24.03ID:???
>>928
ActiveRecordにしろEFにしろORM経由でテーブルを扱うタイミングでは
ORMがテーブルの型を認識できてる必要はあるよ

Rubyなら動的に型定義可能なので
実行時に汎用メンテ画面で扱うテーブル一覧をDBから読み込んで
それ用のclassを定義したらActiveRecordで扱える

C#でも動的に型定義できるけどちょっと面倒くさいので
テーブルを新規に追加した時はスキャフォールドして型定義をプログラムに追加しとけばいい
テーブル名を変数で渡されたらリフレクションで型にすればあとは普通に使える
0935NAME IS NULL
垢版 |
2021/02/09(火) 22:33:31.23ID:???
>>934
スキャフォールドって
モデルからViewとコントローラーのコードが生成されるけど
それぞれモデル名が頭につくから
SexControllerみたいになるよね
それにテーブル名渡すの？

urlがapi/v1/Sex/Index?table=sexみたいになるのかな？
で、EFは使わず、動的にsqlを組み立てるってこと？
なかなか強引だな。
0936NAME IS NULL
垢版 |
2021/02/09(火) 22:38:32.80ID:???
>>932
これ書いといてなんだけど、同じデータベースの構成でいろんなお客さんにシステム導入しようとするとEAVの問題が出てくるんだよな
で、xmlやjsonを列に突っ込んでる

型を厳密にと言っときながら厳密でない型の列を定義してる俺を罵ってくれ
0937NAME IS NULL
垢版 |
2021/02/09(火) 22:53:09.69ID:???
別に同業他社の人に評価してもらうのではなく使ってもらうユーザーに評価してもらってOKならそれでよくね？
誰が見ても使っても満点の設計なんてできない以上それでかまわないと思うけど
0938NAME IS NULL
垢版 |
2021/02/09(火) 22:58:26.92ID:???
うん、でもそれいっちゃうとこのスレ要らなくない？
0939NAME IS NULL
垢版 |
2021/02/09(火) 23:00:45.47ID:???
>>935
ビューやコントローラを生成する必要はないから
モデルファーストでテーブルを追加/更新するならそのモデル定義をプログラムに追加するだけ

スキャフォールドって言ったのはデータベースの定義を読んでEFで扱えるようにするための話
> dotnet ef dbcontext scaffold --table Hoge
0940NAME IS NULL
垢版 |
2021/02/09(火) 23:38:34.79ID:???
>>939
ViewContoroller使わないのは納得した。

渡したテーブル名はどこで使うの？

pocoで定義されたクラスに値入れて、addしてsavechanges
てのがEFの普通の流れだけど
そのクラス名はhogeだよね

そのクラス名が動的に変わる？
0941NAME IS NULL
垢版 |
2021/02/11(木) 09:05:41.50ID:???
>>921
この手のほぼ更新のないマスタテーブルはDB管理者がsqlでメンテだな
0942NAME IS NULL
垢版 |
2021/02/11(木) 11:59:29.12ID:???
>>940
リフレクション使うんだよ
カラム名やデータ型を共通化できるなら
リフレクションじゃなくジェネリックでも対応可
0943NAME IS NULL
垢版 |
2021/03/27(土) 19:52:09.74ID:JXErytnT
>>1000

日本人はカス民族。世界で尊敬される日本人は大嘘。

日本人は正体がバレないのを良い事にネット上で好き放題書く卑怯な民族。
日本人の職場はパワハラやセクハラ大好き。 学校はイジメが大好き。
日本人は同じ日本人やアジア人には厳しく白人には甘い情け無い民族。
日本人は中国人や朝鮮人に対する差別を正当化する。差別を正義だと思ってる。
日本人は絶対的な正義で弱者や個人を叩く。日本人は集団イジメも正当化する。
日本の芸能人は人の悪口で笑いを取る。視聴者もそれで笑う民族性。
日本人はコロナ感染者を一方的に差別し叩く。感染する奴が悪い主義の民族。
日本人は犯罪者の死刑拷問大好き。でもネットに書くだけで実行は他人任せ前提。
日本人は己の手は汚さない。
日本人は鯨やイルカを殺戮して何が悪いと開き直るが猫や犬には虐待する事すら許さない動物差別主義的民族。
日本人は「外国も同じだ」と言い訳するが文化依存症候群の日本人限定の対人恐怖症が有るので日本人だけカスな民族性なのは明らか。
世界中で日本語表記のHikikomori(引きこもり)Karoshi(過労死)Taijin kyofushoは日本人による陰湿な日本社会ならでは。
世界で日本人だけ異様に海外の反応が大好き。人の顔色を伺う媚びへつらう民族性。
世界幸福度ランキング先進国の中で日本だけダントツ最下位。欧米は上位。
もう一度言う「外国も一緒」は通用しない。日本人だけがカス。カス民族なのは日本人だけ.

陰湿な同級生、陰湿な身内、陰湿な同僚、陰湿なネットユーザー、他者を見下すのが生き甲斐の国民達。
こんなカス民族によるカス国家滅びたってどうでも良いし愛国心を持つ価値も無い。
0944NAME IS NULL
垢版 |
2021/03/27(土) 20:37:34.41ID:xBIdyDrI
カス民族日本でも世界の上位にいるんだよね
カスの日本人より
0945NAME IS NULL
垢版 |
2021/05/27(木) 22:14:23.71ID:???
なんでこんなに
いろんな仕組みが発達したのに
いまだにDBのデッドロックの回避チェックを
人間が人力でやらんといかんのだ
0946NAME IS NULL
垢版 |
2021/05/28(金) 00:25:17.31ID:???
そりゃお前のシステムがクソだからだろ
0947NAME IS NULL
垢版 |
2021/05/28(金) 00:44:50.60ID:???
SQLだけ抽出すれば簡単だろうけど
呼び出し側のコードも含めて解析するとなると面倒くさいわな

普通に設計すればデッドロックで困ることなんてないからニーズもない
0948NAME IS NULL
垢版 |
2021/05/28(金) 10:16:32.81ID:???
ある一つの商品（例えば動画とか）に現物の商品とDL商品と言うように、種類が二つないし複数ある場合

products
- id
- name
- description

product_classes
- id
- product_id
- type
- price

こんな設計でよろしいのでしょうか？
今まで1商品1レコードの単純なものしか扱った事がなかったので、こう言った場合のセオリーがわかりません
よろしければご教授下さい
0949NAME IS NULL
垢版 |
2021/05/28(金) 22:11:41.96ID:???
なんとなく想像はつくけど、設計を語るのであれば最低限ユニークキー、外部キーとかは示した方がいい。
0950NAME IS NULL
垢版 |
2021/05/29(土) 00:13:12.94ID:???
>>948
種類の軸が1つだけで固定的なら基本的にはそれでいいと思う

2つのテーブルの関係は1対多の親子関係(親が存在しないと子も存在しない)なので
product_id + typeの複合主キーにするか
id付与してproduct+id + typeはユニークかつNOT NULLにするか

あとは
商品単位で管理する項目
派生商品単位で管理する項目
現物のみ・DLのみで管理する項目
を精査してモデルを調整する

種類の軸が複数ある(複数になる確率が高そう)なら
それをモデルに取り込んでいく必要がある

classはカテゴリに近い概念に使われるのでやめたほうがいい
英語ならproduct, product_variantが定番
0951948
垢版 |
2021/05/29(土) 08:38:41.36ID:???
>>950
質問する前に調べていた所 EC-CUBEが、dtb_product, dtb_product_class と言う関係のようだったので、product_classes としましたが、正直自分も違和感があったので、product_variant採用させていただきます

主キーやユニークなども適宜設定していきたいと思います

丁寧な回答ありがとう御座いました
レス数が950を超えています。1000を超えると書き込みができなくなります。
ニューススポーツなんでも実況