DB設計を語るスレ 10 [無断転載禁止]©2ch.net

**NAME IS NULL** · 2017/05/22(月) 16:38:31.52

語れ

前スレ
DB設計を語るスレ 9
http://echo.2ch.net/test/read.cgi/db/1444733172/

**NAME IS NULL** · 2020/02/12(水) 20:49:06.79

いまどきマスターとかトランザクションとか言っとるジジイは放置でええねん

**NAME IS NULL** · 2020/02/12(水) 21:05:19.11

？

**NAME IS NULL** · 2020/02/12(水) 21:23:59.53

業務なら普通に使うぞ

**NAME IS NULL** · 2020/02/12(水) 22:35:55.16

DB設計の経験が浅いプログラマーは
マスターとトランザクションデータの区別がまともにできないから気をつけろ

30オーバーのやつも含めてチーム全員が
マスターのことをトランザクションと呼んでて震撼したことがある

**質問者** · 2020/02/12(水) 23:42:53.31

>>552
なるほどマスタとトランザクションという概念があるんですか、ためになるな
最新のデータはマスターに記録して変更履歴をトランザクションとして記録すればいいんすね

**NAME IS NULL** · 2020/02/13(木) 00:02:14.97

いや、そういうことじゃなくて
もっと基本的な所から勉強した方が良い
話を聞いている限り、テーブル設計がちゃんとできていない

**NAME IS NULL** · 2020/02/13(木) 00:03:42.63

マスターの履歴とマスターにに対する変更イベントを記録(トランザクション)は微妙に違う

**質問者** · 2020/02/13(木) 00:17:07.26

>>558
テーブル設計でいい本とかサイトありますか？
今、達人に学ぶDB設計指南って本読んでるんですけどフワッとしてるっていうかもっとテーブル設計の実例が見たい

**NAME IS NULL** · 2020/02/13(木) 17:28:06.14

>>557
コボラーのおじいちゃんの概念なw騙されんなw現代においてはなんも意味ないでw

**NAME IS NULL** · 2020/02/13(木) 21:03:05.33

ついてこれないなら黙ってて

**NAME IS NULL** · 2020/02/13(木) 21:16:52.08

>>560
「業務別データベース設計のためのデータモデリング入門」渡辺幸三

**NAME IS NULL** · 2020/02/14(金) 00:46:37.23

>>563
ありがとうございます
レビュー見ると難しそうだけど読んでみます

**NAME IS NULL** · 2020/02/14(金) 00:52:53.18

分からない事があれば、ここで聞くといいよ
賑わいはないけど真面目にレスが返る板だから

**NAME IS NULL** · 2020/02/19(水) 21:02:42.95

>>565
おまえが気持ち悪い事ゆうから誰も居らんくなったやないか

**NAME IS NULL** · 2020/02/19(水) 22:45:15.97

褒めないでくださいよ、照れるな

**NAME IS NULL** · 2020/02/20(木) 02:03:55.39

連番管理する必要がある場合、以下のどちらのほうほうがよいでしょうか？
https://ideone.com/oOlh4z

中間にINSERTされる場合があります。
SELECTする時は漏れなく連番の先頭から最後まで一括で取得することになります。

**NAME IS NULL** · 2020/02/20(木) 03:27:31.79

前後の関係を知りたいのが主なら1だけど、汎用的には2

**NAME IS NULL** · 2020/02/20(木) 04:23:11.02

>>568
件数や更新頻度、データの使われ方による

一括SELECT時のパフォーマンスが重要なら連番順のインデックスを作れるようにする
例えば有理数で管理して1/5, 2/5, 3/5と並んでるところに
データを挿入したければ3/10, 5/10
それで2/10, 3/10, 4/10, 5/10, 6/10の並びになる
他には101000, 102000, 103000のような飛び番で管理して
番号が埋まってきたら番号を振り直す方法もある

挿入時のパフォーマンスが重要なら書いてるようなLinked List的な方法で良いと思う
previousを知る必要がなければ2の方法で十分だがrootが一発でわかるデータは必要

**NAME IS NULL** · 2020/02/20(木) 18:03:03.56

INSERTする頻度がそれほどでないなら
順番を決められるような非整数の項目用意して
通常は整数値を入れておき、
挿入時に前後の項目の中間値を入れるなんてどうかな

**NAME IS NULL** · 2020/02/20(木) 19:50:02.82

>SELECTする時は漏れなく連番の先頭から最後まで一括で取得
取得する順番はどうでもいいのか？

**NAME IS NULL** · 2020/02/20(木) 20:55:47.42

どう考えても２だろ１とかいみふ
>>570
振り直しとかｗ

**NAME IS NULL** · 2020/02/20(木) 21:26:21.35

>>572
再帰クエリを使う前提やろ

>>573
>振り直しとかｗ
RDBのページ分割と同じだぞ

**NAME IS NULL** · 2020/02/20(木) 21:53:23.57

用途によるわな。
二項関係を全部保持する設計だと参照は爆速。

**NAME IS NULL** · 2020/02/20(木) 22:07:16.22

あとnullはやめて-1や0にしといたほうが吉

**NAME IS NULL** · 2020/02/21(金) 05:29:35.02

>>568
入れ子集合
閉包テーブル
なんて方法もあります

**NAME IS NULL** · 2020/02/21(金) 20:03:46.42

>>573
振り直しは実は結構現実的なソリューション

>>574
まあ、再帰前提になるわな

再帰クエリってパフォーマンスどうなんだ
あと再帰のネスト深さとかけっこう制限あったような

**NAME IS NULL** · 2020/04/28(火) 18:41:13.11

フラグ系のカラム名付け質問

例えば商品マスタ（ID,JANコード、名称、・・・）があって
こいつらにセール対象、まとめ買い対象、みたいなフラグカラム追加したいときってどういうカラム名がいいんでしょ？

セール対象テーブル追加してそっちみろは無しでお願いします
is_Bargain、is_MatomeGay(英語わからんので適当)とかにする？

**NAME IS NULL** · 2020/04/28(火) 21:37:21.40

まとめゲイw

命名規約次第だけど個人的にはon_saleやfor_bulkみたいな名前をつける
is/has縛りなら商品に対応する単語をくっつけたほうがいいかも
セール対象商品 => is_bargain_item
まとめ買い対象商品 => is_matomegai_item

item.is_bargainだと英語的には超微妙
item.is_for_bargainならわりと自然だけどis_for_bargainというカラム名は微妙
item.is_bargain_itemも冗長だけど冠詞がないだけでまあ自然でis_for_bargainに比べるとカラム名としてはマシ

**NAME IS NULL** · 2020/04/28(火) 21:42:09.42

ただ現実問題としてis_bargainみたいなboolフラグで管理可能なの？

アフィサイトみたいに表示管理だけでいいなら
それでも問題ないかもしれないけど、実際にキャンペーンやる会社なら
どの期間、どのキャンペーンの対象で、どういう適用条件かみたいなのが最低限必要だからboolじゃ破綻しそう

**NAME IS NULL** · 2020/04/28(火) 23:30:35.91

ありがとうございます
そうなんですよね。英語的にはマシかもだけどカラム名として何だか微妙になるんですよね
現状はフラグ1、フラグ2、..みたいな暗黒状態かつ命名規約何それなので、それよりはマシなのですが

実際は簡単なフラグ管理だけで良いので、バーゲン期間とかは考慮しなくて大丈夫です
良かろうと思って一般的なサンプルでっち上げると余計な検討点が出てきてダメですね

私の悩みを10年前に通過している列海王的な方がいたら、引き続きナイスな命名案をよろしくお願いします

**NAME IS NULL** · 2020/04/29(水) 00:45:02.07

github検索してみたが
on_saleやis_on_saleで命名してるのはそこそこ見つかる

**NAME IS NULL** · 2020/05/02(土) 23:39:27.57

>>583
遅くなりました。ありがとうございます
githubも見てみます
こういう時ネイティブ並の語彙力がほしくなる

**NAME IS NULL** · 2020/05/03(日) 04:57:59.36

どうせそれを見るのも日本人だろ
ネイティブが違和感を感じるかどうかより、日本人が納得するかどうかだと思うぞ

DBMSにもよるだろうが、日本語環境以外での動作を考えないなら日本語カラム名でもいいと思う

**NAME IS NULL** · 2020/05/04(月) 17:11:14.86

以前はfoo_flag, bar_flagみたいな命名はダサいから可能な限り避けようとしてたが
最近は一貫性が取れてるならis_fooやis_barよりもベターなケースが多いと思うようになってきた
組織の英語力やDBリテラシー次第

**NAME IS NULL** · 2020/05/04(月) 22:00:17.67

うちのアカンDB
boo(0,1)とるカラムがxx_kbn
int(0~9)とるカラムがxx_flag
せめて逆じゃね？

**NAME IS NULL** · 2020/05/04(月) 23:04:59.53

逆ならよかったね～

**NAME IS NULL** · 2020/05/10(日) 15:13:42.60

普通はデータベースって蓄積するもので、
普通は削除フラグにとどめて、よほどのことがないとdeleteするようなことってないと思いますが、
deleteしまくることによって何か問題が起きたりするのでしょうか？
あと消したあとも、ゴミ箱にいれたHDDの中身みたいに実は復旧可能だったりしますか？
問い合わせのログみたいなのを一定期間後に完全削除するのを考えてます。

**NAME IS NULL** · 2020/05/10(日) 15:37:54.86

>>589
削除するかどうかは要件次第

不要になったら一旦アーカイブに移動させて
その後、事前に決めた一定期間を過ぎたらメディアにバックアップとって削除する
メディアも事前に決めたメディア用の一定期間を過ぎたら廃棄する
そういうデータライフサイクルを要件定義時に決めて運用にのせるのが普通

復元できるかどうかはバックアップやトランザクションログの残し方による

**NAME IS NULL** · 2020/05/19(火) 13:31:17.65

同じ設計で別の用途に使用したいテーブルがある場合、テーブル名をどうしていますか？

例えばブログの場合、
article 　　→　記事テーブル
category　→　カテゴリーテーブル
article_cateogry　→記事のカテゴリーテーブル

と設計することがあると思います。
ここに「特集」という別のコンテンツを追加したい場合、

special 　　→　特集テーブル
special_category　→　特集カテゴリーテーブル
special_special__cateogry　→特集の特集カテゴリーテーブル

とするのは変です。

記事と特集はテーブル設計が異なるので、同じテーブルでまとめられません。
しかし、「カテゴリー」テーブルの設計は同じです。同名でも意味は通じます。

categoryではなく、type（種類）とかclass（クラス）とか別名にして対応するのでしょうか？

**NAME IS NULL** · 2020/05/19(火) 15:41:38.69

>>591
「特集」は特集記事であって記事の特化したものではないの？

ある一つのカテゴリーを選択した場合に
それに合致する記事も特集も拾いたいケースがあるなら
カテゴリーテーブルは一つにしたほうがよくて
特集テーブルも記事テーブルと1 ― 0..1 の関係で作るか
特集テーブルと記事テーブルを汎化したテーブルを検討する

**NAME IS NULL** · 2020/05/19(火) 16:47:06.21

>>592
「特集」という例がわかりづらいなら、掲示板（bbs）でもいいです。
掲示板でも「カテゴリー」って分類は必要ですよね？
でも、記事のカテゴリーと掲示板のカテゴリーは内容そのものが違います。

たとえカラムが同じであっても、用途が異なるテーブルを共有し使うのはよくありません。
だからcategoryではない別名が必要なのですが、その命名が難しいという相談です。

**NAME IS NULL** · 2020/05/19(火) 20:13:30.72

この程度のことを聞ける人が会社にいないんだろうかw

**NAME IS NULL** · 2020/05/19(火) 20:32:01.95

記事カテゴリーと掲示板カテゴリーでなんの不都合がある？

**NAME IS NULL** · 2020/05/19(火) 20:45:57.38

>>594
この程度のことがググっても見つからないんです。

>>595
日本語だとそれでOKなのですが、>>591の命名に合わせるとおかしいと思う次第です。

そもそもですが、最初は単純に「category」というテーブル名にしてて、
あとから別の用途のカテゴリーがでてくる事ってありませんか？
最初から記事カテゴリーを作る想定をしていないと思うんです。
規模を拡張する時に命名が被る、だから困るってそんなおかしい悩みですかね・・・

**NAME IS NULL** · 2020/05/19(火) 21:13:48.53

命名がうまくいかないケースの7~8割は
モデリングがうまくできてないケース

**NAME IS NULL** · 2020/05/19(火) 21:52:13.20

悩みは理解できるがmany-to-manyで管理が必要なカテゴリーテーブルが
1つのスキーマに複数必要になるケースってそうそうないよね

**NAME IS NULL** · 2020/05/19(火) 21:58:57.66

そもそもそんな場合はDB分けるし

**NAME IS NULL** · 2020/05/19(火) 22:14:36.92

>>591
そもそも special_category という名称が意味不明

**NAME IS NULL** · 2020/05/19(火) 23:39:26.48

>>598
確かにただアプリとしてブログとか掲示板を作ってるだけなら無いですが、
サイト作ってる場合、要件の追加・カスタマイズってあると思うんですよね
カテゴリーみたいな分類が必要なコンテンツって、
記事、掲示板、お知らせ、特集、クチコミ、求人など様々思いつきますし。
それをWordpressのように単一参照テーブルで管理しろってのもちょっと・・。

>>599
それも考えたのですが、ひとつのDBに数テーブルしかない状態でわけるってのも
どうかと思うんです。JOINの効率も悪そうだし。

>>600
すみません。単に例題として出しただけです。

**NAME IS NULL** · 2020/05/19(火) 23:45:42.87

とにかく的確な答えがない＝よくある設計の悩みじゃないってことですかね
categoryじゃなくても、menuとかclassとかgenreとか似たような用途に使える
名前があるし、わざわざカテゴリーって呼び方にこだわらなくてもいいかもしれません

一般的な質問でない場合、上記のように解釈して妥協します。

**NAME IS NULL** · 2020/05/20(水) 02:26:52.88

力技で命名するより先に設計見直したほうがいいって言われてるのが理解できないのかな

記事カテゴリー
掲示板カテゴリー
お知らせカテゴリー
特集カテゴリー
クチコミカテゴリー
求人カテゴリー

普通のお客さんならキレるよ

**NAME IS NULL** · 2020/05/20(水) 09:07:47.41

>>603
お客さんに提供してないのでキレられることはないですが、
設計を見直すということは、既存のテーブルの名前を変えろということですか？

何度も記載していますが、最初はただの「カテゴリー」として作っていたものを
後から「記事カテゴリー」と別名にするのはリスク高いと思います。
だから力技で命名するしかないのではないか？と思う次第です。

「いや、後から用途が増えるなら変えるべきだろ」
というなら私の認識が間違っているので変更しますが、
確信的なレスがないので納得できないでいます。

**NAME IS NULL** · 2020/05/20(水) 09:15:02.49

自分の説明の仕方が悪いと思うので、もう一度整理します。

（１）初期運用段階
article 　　→　記事テーブル
category　→　カテゴリーテーブル
article_cateogry　→記事のカテゴリーテーブル

（２）「カテゴリー付きの掲示板が必要」という要件が発生した
bbs　　→　掲示板テーブル
bbs_category　→　掲示板カテゴリーテーブル
bbs_bbs__cateogry　→掲示板の掲示板カテゴリーテーブル

[悩み]こういうテーブル設計を追加するのはおかしいと思う。
　　　　一般的にはどうするべきですか？

（補足）>>603さんの案：既存のテーブル名を変更
article_category　→　記事カテゴリーテーブルに変更
article_article_cateogry　→記事の記事カテゴリーテーブル

[悩み]途中で既存のテーブル名を変更するのはリスクが高くないか

**NAME IS NULL** · 2020/05/20(水) 12:39:47.56

いやいやw
>>603のは普通は全部一つのカテゴリーテーブルでまとめられるだとって話なんだけど・・・

CMSで管理するサイトコンテンツのカテゴリーでしょ？
記事に付けるタグと求人に付けるタグが共通でも問題ないし
どちらか一方にしか使えないタグが必要でも
いちいち別テーブルにしなくてもまとめて管理できるでしょ

力技の命名ってのは関連テーブルを示すprefix/infix/suffixを決めて
それを該当スキーマ内で一貫して使うみたいな規約で逃げるという意味
既存のテーブル名を変更するのがリスクが高いかどうかはアプリの作り次第だが
CMSならリスクは知れてる

**NAME IS NULL** · 2020/05/20(水) 17:44:51.41

>>606
もしかしてCMS＝既存のCMSを指してますか？
そうでなくて、自作の話なのですが・・。

それにひとつのカテゴリーテーブルで、>>603みたいなのをまとめるのは無理です。

例えば以下のようなカテゴリーが必要だとします。
記事　｜全般、Web制作、システム開発、データベス
掲示板｜パソコン、ニュース、エンタメ
お知らせ｜サービス、イベント、運営会社

記事コンテンツで、掲示板で使用する「パソコン」というカテゴリーはいらないし、
お知らせコンテンツにある、運営会社というカテゴリーもおかしいです。

カテゴリーテーブル（category）を以下のカラム構成にして
id（pk）｜target｜name｜
1　　　｜article｜全般
2　　　｜bbs　｜パソコン

SELECT * FROM category WHERE target='article'

というSQLを実行すれば、「記事だけのカテゴリーを抽出」することは可能です。
しかし、こんな設計は明らかにアンチパターンですよね？
JOINするときはWHEREとセットになるし、SQLコストも増大します。
通常は要件に伴ったテーブルを用意するはずです。

それともアンチパターンとか関係なく、上記のようにするのが普通なのでしょうか？
あるいは、カラム設計自体も違うというのであれば、正しい設計を教えていただきたいです。

**NAME IS NULL** · 2020/05/20(水) 18:55:01.20

>>607
細かいところを置いておくとそのテーブルイメージの考え方はアンチパターンではないよ
同じ情報を管理するのに全部別テーブルにするほうがアンチパターン

JOINするときWHEREとセットになるんじゃなく
記事/掲示板/お知らせみたいな要素を指すIDが結合条件になる
仮にWHEREで指定することになったところで
カテゴリーテーブルの件数なんてめちゃくちゃ少ないし
きちんとインデックス付けてればSQLコストが増大とかしないから

**NAME IS NULL** · 2020/05/20(水) 18:57:14.65

はじめからそういう要件を想定できなかった以上、きれいな設計にしたいなら作り直せ

**NAME IS NULL** · 2020/05/20(水) 19:00:20.45

>>607
それとそのカテゴリーの例を見ると
1つの記事や掲示板は1つのカテゴリーにしか属さない風にも見えるけど
複数カテゴリーに属する前提であってる？

**NAME IS NULL** · 2020/05/20(水) 19:04:47.61

この態度で回答するやついたら神だな
俺は絶対スルー案件だわw

**NAME IS NULL** · 2020/05/20(水) 19:28:50.40

>>607
上でもそうだったけど、命名がおかしい気がする

掲示板のところにある「パソコン」「ニュース」「エンタメ」というのは
5ちゃんねるで言う板のこと？ (たとえばこのスレはデータベース板だけど)

記事・掲示板・お知らせの関係がわかると答えやすくなると思う
(例えば掲示板と記事は一対多の関係など)

**NAME IS NULL** · 2020/05/20(水) 19:48:43.41

なにがどうアンチパターンなのかも判断できないのに
こいつのアンチパターンだからダメって脅迫概念はどっからきてるんだ

**NAME IS NULL** · 2020/05/20(水) 20:15:27.77

>>607
> 正しい設計を教えていただきたいです。
そもそも絶対的に正しい設計なんてない
例えばカテゴリーテーブルを>>603の各項目毎に作るのか１つにまとめるのかも双方にメリット・デメリットあるからケースバイケースで常にどっちかが良いというわけじゃない
算数の答えみたいに正解が１つと思うのはやめた方がいい

**NAME IS NULL** · 2020/05/20(水) 20:25:38.47

レス前後しますが、

>>613
何がどうアンチパターンか＝正規化ができてない
って判断はおかしいですかね？怒られる程なのでしょうか・・・

>>608
既存テーブルのカテゴリーを使用する箇所すべてで、SQLを組み直すんですよ？
単純にリスクが増大すると思うんですよね。手間云々だけじゃなくて。

>>609
煽り抜きで教えてほしいのですが、
普通に「思ったより反響があって増築の必要が出た」
って要件、くさるほどあると思うんです。
1か100かじゃなくて、1・2・3って成長していくものだと思うんです。

**NAME IS NULL** · 2020/05/20(水) 20:26:36.28

>>610
591や605の例で中間テーブルを想定していますが、
>>607の例でも中間テーブルを用意すれば、多対多は可能だと思います。

>>611
真摯に議論したいし、間違っていたら教えてもらいたいだけです。

>>614
おしゃるとおりですが、そもそも私の質問自体「こいつ馬鹿じゃね？」
って感じのレスを頂くものですから、ベストプラクティスがあると思うんです。
それにみなさんはどうしているのかを聞きたいのが、希望ですし・・。

**NAME IS NULL** · 2020/05/20(水) 21:04:01.67

>>616
>中間テーブルを用意すれば、多対多は可能だと思います。

実現可能かどうかじゃなく要件として多対多が要求されてるの？

**NAME IS NULL** · 2020/05/20(水) 21:17:12.37

>>615
>既存テーブルのカテゴリーを使用する箇所すべてで、SQLを組み直すんですよ？
>単純にリスクが増大すると思うんですよね。手間云々だけじゃなくて。

自分のまずい設計を正当化するためにリスクが増大するんですって言ってるんじゃなく
微妙な設計になることのデメリットと既存の部分を触ることによるデメリットを
天秤に掛けた上の判断なら別にいいと思うよ

CMSでカテゴリーテーブルを使用する箇所が
あっちこっちに散在してるようならそもそもの設計がまずいとは思うけどね

**NAME IS NULL** · 2020/05/20(水) 21:26:58.14

>>617
要求されています。

>>618
618さんの解釈では、
「すでにカテゴリーテーブルが有るのに同じようなものを用意する必要はない」
ということですよね？それがまずい設計だと、

私は「ひとつのテーブルですべてのカテゴリーを管理する」
ことがまずい設計だと思っているんです。

なぜまずいと思うかというと、アンチパターンだったり、正規化できていなかったりと
一般的に悪いと言われるテーブル設計を採用しろと言われているからです。

618さんの言う「カテゴリーはカテゴリーなんだから、複数あるのはおかしい」
という主張は理解できます。
しかし、ひとつのテーブルに用途違いのデータが入ることの正当性が
私には理解できないので、618さんの主張が正しいと思えないんです。
煽っているのではなく、主張を正しいとする論拠がわからないんです。

**NAME IS NULL** · 2020/05/20(水) 21:32:41.33

意識低い系の自分はその場合カテゴリのテーブルは一つのままカテゴリの種類ごとにidの範囲を変えて運用してしまうな
記事カテゴリは10000～19999、特集カテゴリは20000～29999みたいな

**NAME IS NULL** · 2020/05/20(水) 21:34:11.67

>>612 は？

**NAME IS NULL** · 2020/05/20(水) 21:49:45.25

>>620
それで記事テーブルと結合する時はどうするんですか？
全てのSQLにWHERE id BETWEEN '10000' AND '19999'
を追加するのでしょうか？

>>621
5ちゃんねるでいうと板になるんですかね。
記事とか掲示板とかお知らせは1つのテーブル（1つのコンテンツが入る）であり、
カテゴリーというのは、そのテーブル内のデータを分類するために必要です。
1つの投稿に対して複数のカテゴリーを割り当てられることから、多対多ですね。
5ちゃんねるの場合、1つの投稿に複数カテゴリーを割り当てないと思いますが。

**NAME IS NULL** · 2020/05/20(水) 22:07:40.68

>>622
掲示板と記事は一対多なの？

**NAME IS NULL** · 2020/05/20(水) 22:25:53.64

>>619
>「すでにカテゴリーテーブルが有るのに同じようなものを用意する必要はない」ということですよね？
違う、そういう考え方じゃない
既存のしがらみは一旦忘れて同じエンティティなのか異なるエンティティなのかを考える
その答えは要件によって変わるんだが
今のところ異なるエンティティとして管理すべき要件は見当たらない

正規化できないというのは君の思い込み

コンテンツの種別ごとにカテゴリーテーブルとその中間テーブルを作らなきゃいけないのは
SQLアンチパターンの9章にある”Antipattern: Clone Tables or Columns”

**NAME IS NULL** · 2020/05/20(水) 22:39:11.58

CMSならコンテンツを管理する単位が記事だろうと掲示板だろうと
共通に扱える仕組みを用意した上で個別に必要な拡張が施せるようにする

記事に特化した記事管理システムなら
そこに掲示板管理システムをそのまま増設するのは悪手で
DB含めてシステムを分けるか再構築してまともなCMSにする

**NAME IS NULL** · 2020/05/20(水) 23:15:00.78

>>624-625
自分のスキルが低いと思うんですが、理解できずに申し訳ないです。

それでは私が最初に構想していた>>591という
要件毎にテーブルを作るやり方ではなく、
>>607のような、ひとつのテーブルでまとめるやり方が正しい
（今回の相談ケースではこうするべき）という解釈で良いのでしょうか？

AでもBでも良いとか、AもBもよくないという結論では
モヤッとしてしまうので、どちらがベターか指摘してほしいです。

**NAME IS NULL** · 2020/05/20(水) 23:35:03.93

>>616
> ベストプラクティスがあると思うんです。
だからケースバイケースだっていう話

>>611
お前が正しかったわ

**NAME IS NULL** · 2020/05/20(水) 23:41:09.52

突然伸びててビビったズラ

テレワークは終わりですよ

**NAME IS NULL** · 2020/05/21(木) 01:00:34.53

お前の言うカテゴリーとは何なのかを詳細に詰めないとベストな答えなんか出ないわ

テーブル名とかまあどうでもいいわな
掲示板カテゴリーと記事カテゴリーが別だとするなら別テーブル作ればいいし
同じだが使用箇所が違うだけだと思えば一つで良い

**NAME IS NULL** · 2020/05/21(木) 06:52:31.63

命名規約があるなら結果変なテーブル名になっても仕方ない
それがいやならテーブル名を連番にでもすればいい

**NAME IS NULL** · 2020/05/21(木) 11:31:44.45

>要件毎にテーブルを作るやり方ではなく

要件という言葉を理解してないw
無知なのにイキってる感じがQiitaっぽいな

**NAME IS NULL** · 2020/05/21(木) 17:40:13.28

カテゴリと内容の関係ならカテゴリに記事と特集を示すフィールド入れれば解決ずら
その程度の変更もできないプログラムだったらプログラム側の設計も見直したほうがいいら

**NAME IS NULL** · 2020/05/21(木) 18:10:57.18

話題変わるけど10万円給付のオンライン申請で多重申請とかで問題出て停止しているようだけど
これってDB設計が糞だと思うんだけどどうだと思いますか？

**NAME IS NULL** · 2020/05/21(木) 18:20:21.15

システム設計の根本から間違えている

**NAME IS NULL** · 2020/05/21(木) 18:57:20.13

多重申請を許容するかどうかは要件次第なので
多重申請ができるからといってDB設計が糞とは言い切れない

DV被害者対策や郵送申請もあるので
後続の業務はもともと多重申請がある前提で設計しておく必要がある

実際のところは短期間での開発を要求されたから
普通なら必要になる画面や機能を削った結果
多重申請を許容する仕様にせざるを得なかったんだろうな

**NAME IS NULL** · 2020/05/21(木) 19:02:38.66

ググったら10人以上の世帯は複数回申請しないといけないからってのと
間違った内容で申請した場合に後から正しい内容で申請できるようにするために
多重申請ができる仕様にしてるらしい

付け焼き刃だし仕方ないかもね
郵送に一本化しといたほうが効率的だった可能性もある

**NAME IS NULL** · 2020/05/21(木) 19:29:00.39

今回の目的はｷﾞｮｳﾑｶｲｾﾞﾝじゃなくて感染防止だから……

単に用紙の持ち込みをオンライン化しただけで
持ち込まれたデータのチェック・管理はすべて人力
分かりやすいシンプルな良いシステム

**NAME IS NULL** · 2020/05/21(木) 19:49:25.34

＞新型コロナウイルスの感染拡大に伴う現金10万円の一律給付を受けるためのオンライン申請について、
＞東京調布市と福生市は入力された情報の確認に時間がかかり給付が遅れるおそれがあるとして、受け
＞付けや手続きを停止しました。オンライン申請を巡っては、同じような対応をとる自治体が各地で相次い
＞でいます。

https://www3.nhk.or.jp/news/html/20200521/k10012439151000.html

**NAME IS NULL** · 2020/05/21(木) 21:19:53.32

オンラインで申請すると郵送よりも処理に時間がかかる上、
郵送分の処理も妨害して遅くするのでやめてほしいそうだ。

**NAME IS NULL** · 2020/05/22(金) 15:56:07.78

>>607
自分が俄で視点が近いからか微妙に解る気がするんだけどこの設計がEAVじゃないかって気になるって事であってる？

けどこれって>624の「同じエンティティなのか異なるエンティティなのかを考える」が全てで、
カテゴリーっていう同じエンティティなんだから同じテーブルに纏めたってEAVにはならないのではって事だと思うが

このテーブルに[targer:person_name, name:田中]みたいなレコード登録したらEAVだと思うけど

**NAME IS NULL** · 2020/05/22(金) 23:25:58.05

EAVかどうかなんて考え方次第
カテゴリーテーブルがサブカテゴリーにたいするEAVだって考え方もある

EAVだからアンチパターンでダメだって考えが間違ってる
アンチパターンと言われているものの、何がどうダメなのかちゃんと考えないと

**NAME IS NULL** · 2020/05/23(土) 00:18:19.59

AmazonみたいなECサイトで商品カテゴリと顧客カテゴリを管理するとしたらほぼ確実に別エンティティ

Youtubeの動画に付けるタグとGmailのメールにつけるタグも1テーブルで管理することはまずない
(RDB使ってない可能性のほうが高いけど)

QiitaがもしQ&A掲示板を始めたり技術イベントの告知・集客サービスを始めて
各スレッドや各イベントにタグ付けできる機能を実装するようなケースは
既存の記事向けのタグと同じエンティティとして管理する可能性が高い

**NAME IS NULL** · 2020/05/23(土) 09:51:07.58

あきらかに回答でもなく雑談（笑）

**NAME IS NULL** · 2020/05/23(土) 11:30:26.74

雑談と言うより単なる妄想

**NAME IS NULL** · 2020/05/23(土) 12:34:48.23

雑談っちゃ雑談だけど抽象化思考が苦手なやつが多いみたいだから具体的なインスタンスを示してみたんだよ

ケースバイケースとか考え方次第で済ませてその判断基準を何も提示しないのはゼロ回答に等しいからさ

**NAME IS NULL** · 2020/05/23(土) 12:59:28.25

ここは、モノローグスレ

**NAME IS NULL** · 2020/05/23(土) 14:37:43.95

適当な妄想垂れ流すぐらいならゼロ回答のほうがマシ

**NAME IS NULL** · 2020/05/23(土) 16:07:15.63

事例に対する個人の判断結果を示してるだけで、肝心の判断基準を示してない件

**NAME IS NULL** · 2020/05/23(土) 18:14:02.96

>>648
それは「考え方次第」

**NAME IS NULL** · 2020/05/23(土) 20:48:19.09

でも語るスレだからいいのか

**NAME IS NULL** · 2020/05/23(土) 21:52:49.37

>>650
それは「ケースバイケース」

**NAME IS NULL** · 2020/05/27(水) 07:37:48.25

質問です
csv ファイルを提供されて
数量データが4000なのですが
少数第二位までという4000.00の意味の
400000というデータで提供されます
毎回エクセルで100で割ってからインポートします
また、顧客コードが10桁で
数字の羅列が醜いので
12-3456-7890とハイフンの追加も行ってから
インポートします
毎月の事なのですが
この数量データ割算と、顧客データハイフンを
いちいちExcelで処理せずに
インポート時やインポート後にうまく処理する方法は無いでしょうか？