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

**NAME IS NULL** · 2018/10/25(木) 09:51:00.34

YouTube を実際に使っているユーザーがいないんじゃ？

**NAME IS NULL** · 2018/12/13(木) 23:16:46.44

YouTube を仮に使ってるユーザーぐらいいるんじゃね？

**NAME IS NULL** · 2018/12/26(水) 10:07:27.12

特殊な炭素素材で水を水素と酸素に分解　ゼビオＨＤのグループ企業、クロステクノロジーラボが開発

**NAME IS NULL** · 2019/03/20(水) 08:24:10.88

500項目超とかの巨大テーブルいい加減ヤメてほしい

**NAME IS NULL** · 2019/03/30(土) 17:46:10.62

>>452
DBMS何使ったらそうなんの？オラコー？

**NAME IS NULL** · 2019/03/30(土) 17:52:56.67

紙の業務の置き換えで
10明細x50の伝票！あと10年は変更ありません！
とかだとよくやる。官公庁だあとありがち。
正規化するといちいちJOIN書かないといかんし

**NAME IS NULL** · 2019/03/30(土) 19:41:39.53

>>452
見たのは確かOracle
項目多過ぎでSQLが実行できない

**NAME IS NULL** · 2019/03/30(土) 22:37:17.45

COBOLで書かれたような奴の移植ならよくある

**NAME IS NULL** · 2019/05/31(金) 20:09:56.83

主キーをサロゲートキー(serial)にするか、複合カラムの組み合わせでUNIQUE制約をつけて主キーっぽく使うかで悩んでいます。
問題なのが、このテーブルはレコードを削除した後、復活(再度、新規登録)させる必要が出てくる可能性があることです。
その場合、復活させた時に番号が変わるserialを主キーにするのは、ありえないですよね？

**NAME IS NULL** · 2019/05/31(金) 20:48:12.74

そのDBがserial値の明示的挿入を許して、それが滅多に起きないんならなくはないんじゃね

それ以前におれなら復活必要なら論理削除にしとくが

**NAME IS NULL** · 2019/05/31(金) 23:33:17.50

データレコード削除してもサロゲートキーのマスター残しておけば問題ないんでないの。

**NAME IS NULL** · 2019/06/04(火) 20:14:47.94

サロゲートキーのマスターとは？

ここで言ってるserialってのは、システム側で管理して勝手に数値入れてくれるものだと思うが

**NAME IS NULL** · 2019/06/04(火) 20:52:02.44

単なるserial;はふつうサロゲートキーとは言わんだろう。
>>457のように一意性を保証する複合主キーが存在したうえでその代理とするのがサロゲートキー。
んだから元の複合主キーとserialからなるのがマスターだしそれが自動採番されることは矛盾しない。

**NAME IS NULL** · 2019/06/04(火) 21:03:46.49

で、データレコード削除しても残るサロゲートキーのマスターって何？って話だが

自動採番（システム管理）される値をサロゲートキーにするって前提じゃないの？

**NAME IS NULL** · 2019/06/04(火) 21:33:06.85

だから複合主キーとサロゲートキーの対応表だよ。そう書いたつもりだったが。
>>457のようにデータ再投入時にサロゲートキーの値が変わるのを防ぎたいなら
そういうマスターを残しておけばいいという話。
採番が自動か手動かはこの際関係ない。

**NAME IS NULL** · 2019/06/05(水) 00:34:03.47

>>463
そういうマスターを残すには手動でそういうマスターを作らないとダメなわけで
前提を合わす気がないならちゃんとそういっとかないと議論にならん

**NAME IS NULL** · 2019/06/05(水) 00:38:31.46

serialを変えたくないってことは、
その様な使い方を別なところでしているんじゃないかな
ログとか履歴とか

**NAME IS NULL** · 2019/06/05(水) 08:10:00.40

>>464
既に何度も書いているが、そのマスターのサロゲートキーはserialで自動採番して全然問題ないんだが？

あるいは、もともとデータテーブルが1テーブルだったものをマスターテーブルと分離したことを言っているなら
そりゃ当たり前だ。そう提案したんだからな。

**NAME IS NULL** · 2019/06/26(水) 12:08:55.23

大阪市は2019年6月24日、6月7日から翌8日にかけて発生した基幹系システムの障害に
ついて、原因を特定したと明らかにした。米オラクル（Oracle）のデータベース（DB）ソフト
「Oracle Database」のバグが原因だった。

https://egg.5ch.net/test/read.cgi/bizplus/1561468154/

**NAME IS NULL** · 2019/06/26(水) 12:32:28.72

やっぱ脱Oracleだな
ろくに保守サポートされないんだから有料契約の意味がない

**NAME IS NULL** · 2019/06/26(水) 19:39:47.63

でも金で解決してくれるサポートがなけりゃ、問題がDBMS側にあることを
突き止めることすら自前でやらなきゃならんのだぜ。

**NAME IS NULL** · 2019/06/26(水) 19:52:43.63

突き止めることに意味がないからな

責任転嫁のための作業であって
復旧にはどのみち問い合わせじゃ間に合わん

**NAME IS NULL** · 2019/06/26(水) 20:14:47.85

原因がわからなきゃ対策のとりようもないだろう。
「たまたまエラーになったけど原因がわからないからまた起きたらゴメンね。」で済むような仕事ならいいが。

**NAME IS NULL** · 2019/06/27(木) 18:25:28.42

オラクルは、問題がDBMSにあることをつきとめるんじゃなくて、その問題をまず認めてもらうのにサポート窓口が必要なんだよ

あとは直ればラッキーぐらい

**NAME IS NULL** · 2019/07/14(日) 19:52:47.78

> 大阪市で住民票などの証明書発行業務を担う基幹システムが停止。復旧まで21時間を要し、
> 8000件近い証明書発行業務に影響が及んだ。原因はOracle Databaseのクラスタ機能に潜む
> バグだった。ネットワークの不調をきっかけにシステムが停止し、再起動もできなくなった。
> 米オラクルはバグの存在を把握しながら対外開示をしていなかったとみられる。

https://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020600011/070200035/

**NAME IS NULL** · 2019/07/14(日) 20:10:01.55

Oracleに金払う意味あるぅ？

**NAME IS NULL** · 2019/07/15(月) 19:18:49.04

それゆえMySQLとかPostgreSQL移行が進んでる

**NAME IS NULL** · 2019/07/28(日) 18:04:07.13

https://i.imgur.com/l91swsP.jpg

**NAME IS NULL** · 2019/08/21(水) 20:28:50.39

デシジョンテーブルのつくりかたがわからん
値の組み合わせ全部入れるもんなの？

null値はすべての検索値にマッチとかルール決めて行数減らしたけど
わけわかめになった

**NAME IS NULL** · 2019/09/01(日) 05:17:00.26

売上を管理するテーブルを設計したいんですが、
後になって、同じ商品コードに別の商品が割り当てられる事も想定して設計する場合、
売上テーブルには、商品コードと商品名と価格すべてを登録するのが普通でしょうか？

※売り上げに登録する商品は、商品コードと商品名と価格だけで管理すると仮定します。

**NAME IS NULL** · 2019/09/01(日) 06:36:54.70

>>478
その意味のない商品コードとやらで何をしたいんだ？
商品名と価格だけでいいだろ

**NAME IS NULL** · 2019/09/01(日) 09:57:23.82

>>478
商品マスタに有効期間を作るのが定石かなあ
ついでに言うと当時の単価もマスタ側で
売り上げは数量かなあ
（集計用に金額持たせることはある）
あと消費税の扱いをどうするかとか考えておいたほうがいい

**NAME IS NULL** · 2019/09/01(日) 16:19:32.45

>>478
自分ならというか自分が作ったシステムの売上データは個数、単価、価格などを保持してる
マスタから参照するのはコードと商品名ぐらい
マスタのコードは別の商品に変わる可能性があるなら売上データと商品マスタを結合するキーは
商品コードでなく商品マスタのサロゲートキー

**NAME IS NULL** · 2019/09/01(日) 16:38:47.41

>同じ商品コードに別の商品が割り当てられる事も想定して

これがどういう状況を表しているのかはっきりさせないと設計も決められないだろ。
少なくとも「商品コード」で「商品」を特定できないことは読み取れるが、じゃあ
「商品コード」と「商品名」であれば特定できるのかそれともそうじゃないのか。
できるなら>>478のままでいいが、できないならばそれを特定できる情報を
追加しなければならない。

**NAME IS NULL** · 2019/09/01(日) 16:51:19.34

商品名や容量が変わるなんてのはよくあること

**NAME IS NULL** · 2019/09/01(日) 17:30:57.16

同じ商品コードを別の商品に割り当てるって言うんだから、ある商品の商品名を
変更するって話とは全然違うわな。

**NAME IS NULL** · 2019/09/01(日) 17:43:49.61

商品コードが一意にならないって理解しにくいんだが
商品コードを仕入れ先の企業が決めてくるって事？

**NAME IS NULL** · 2019/09/01(日) 17:54:03.12

おそらく現実の問題ではなくて、>>478が深く考えないで書いた脳内想定だと思う。

**NAME IS NULL** · 2019/09/02(月) 04:29:38.29

現実的に、商品コードが一意にならないような要求をする客はいるぞ

もし本当に
>売り上げに登録する商品は、商品コードと商品名と価格だけで管理する
のならば、全情報コピーでいいだろ
現実的にはそんな単純な管理条件にはならんけどな

**NAME IS NULL** · 2019/09/02(月) 12:28:21.25

>>487
> 現実的に、商品コードが一意にならないような要求をする客はいるぞ
そりゃいるだろうよ
だから外部とやり取りするためのコードと内部で処理するためのコードは別に持ったりする

**NAME IS NULL** · 2019/09/02(月) 15:56:14.03

横着して客が提示した項目だけでまかなおうとするからコケル

**NAME IS NULL** · 2019/09/20(金) 22:43:01.69

>>467
ラックに限らずクラスタリングってもしもの時のバックアップとしては全く信用できない。
基本的に運が良ければダウン時間が短く済むかも程度で考えて、データのみ同期させる予備機もっとかないと。

**NAME IS NULL** · 2019/10/13(日) 18:20:24.07

カラムに日本語使わないほうがいい
でもPHPでカラムを見ながら弄りたい
PHPやらhtmlでいちいち書くのは面倒くさい
ってんで、カラムの名前の日本語対応データだけもったtable作る
ってのは変ですか？

**NAME IS NULL** · 2019/10/15(火) 01:36:43.91

日本語っていうか、論理名を物理名とは別に持って管理するのは珍しくない

**NAME IS NULL** · 2019/10/15(火) 16:59:26.48

>>492
ありがとうございます
論理名物理名というのですね
参考になる文献が結構出てきて助かりました

**NAME IS NULL** · 2019/10/16(水) 07:52:35.26

多少長くなっても意味の通じるカラム名で管理した方が楽かな

**NAME IS NULL** · 2019/10/16(水) 19:46:46.29

>>493
項目名が頻繁に変わるという仕様が本当に必要なのか考えた方がいい。

**NAME IS NULL** · 2019/10/17(木) 01:46:16.06

どこから項目名が頻繁に変わるという仕様を導き出したんだ

**NAME IS NULL** · 2019/10/17(木) 06:45:02.27

まあ強いて言えばわざわざ
> カラムの名前の日本語対応データだけもったtable作る
ってところじゃね？

**NAME IS NULL** · 2019/10/17(木) 23:46:22.91

お腹がすいていませんか?
ウーバーイーツの利用者が初めての方は eats-5kqyfp のプロモーションコードを使うと、#Uber Eats の初回注文が￥1,000 割引になります。https://t.co/Wxur8AeoEf 👀
Rock54: Caution(BBR-MD5:b73a9cd27f0065c395082e3925dacf01)

**NAME IS NULL** · 2019/10/18(金) 04:25:29.95

PHPからデータを入力することを考えているのですが、初心者ゆえ取っ掛かりがわからなくて途方にくれています

例えば、
歴史的建造物のテーブルと
国のテーブルが有るとします

建造物のデータを入力する時に建造物の国カラムに、国のテーブルからオートコンプリートで入力したい
という場合、オートコンプリート用国候補のデータを"国"テーブルから取得して提示
という流れでいいのでしょうか？
この入力段階では建造物テーブルにリレーション？や結合といった処理で"国"の関連付け考えなくてもいいという感じでしょうか？

**NAME IS NULL** · 2019/10/18(金) 09:22:20.96

考えなくて良い

**NAME IS NULL** · 2019/10/18(金) 19:29:58.26

>>499
建造物情報と国情報が紐付いてないのに、なぜ「オートコンプリート」という言葉が出てくるのか？

**NAME IS NULL** · 2019/10/18(金) 21:21:09.59

キー入力するんじゃねえの？

**NAME IS NULL** · 2019/10/20(日) 20:29:56.45

つか、建物入力して、国を絞るのか？
法隆寺は日本にしかないだろうに

国を入力したら、建物のリストを候補にだすってんなら、国と建物の紐づけが必要

**NAME IS NULL** · 2019/10/20(日) 20:53:49.69

法隆寺のデータをこれから入力しようって時に紐付けデータが先に存在しているわけなかろう。

**NAME IS NULL** · 2019/10/20(日) 21:37:50.26

オートコンプリート用国候補のデータを"国"テーブルから取得して

**NAME IS NULL** · 2019/10/22(火) 21:34:40.81

すでに歴史的建造物のテーブル（にレコード）があるって前提ではないのか

**NAME IS NULL** · 2019/10/22(火) 21:43:02.01

＞オートコンプリートとは、ユーザーによるキーボード入力履歴を活用して、
＞入力操作の軽減を図る機能の一つである。

＞オートコンプリートに対応したソフトでは、ユーザーが入力したい言葉の
＞冒頭の文字を入れると、入力履歴の中から冒頭の文字が一致するものを
＞候補として一覧で表示する。候補は、文字を入力していくごとに絞り込まれ、
＞その一覧の中に入力したい言葉があれば、ユーザーは残りの文字を入力
＞することなく、一覧から選ぶだけで入力が完了する。

こういうことなんじゃ？

**NAME IS NULL** · 2019/10/22(火) 22:57:39.65

>>501
>>503
>>506

>建造物のデータを入力する時に建造物の国カラムに、国のテーブルからオートコンプリートで入力したい

**NAME IS NULL** · 2019/10/23(水) 09:25:30.42

>>508
だからどうしてそんな変なことを言っているのか？

**NAME IS NULL** · 2019/10/23(水) 15:59:50.08

入力者の作業が簡単になるからじゃね？

**NAME IS NULL** · 2019/10/23(水) 19:36:46.50

>>509
おまえ読解力無さすぎだろう

**NAME IS NULL** · 2019/10/23(水) 19:45:44.83

変なことっていうのは違うな
誰でも考えつくことだし

**NAME IS NULL** · 2019/10/23(水) 20:18:26.30

>>499
・国名入力欄
・建造物名入力欄

があって、「国名入力欄に入力する際に国名をオートコンプリートしたい
（“に”って入力したら“日本”が候補にでてくる）」って認識でOk？

それとも「国名を入力したら建造物名入力欄の候補が絞り込まれる」ようにしたいってことを言ってる？

**NAME IS NULL** · 2019/10/23(水) 20:43:21.25

>国のテーブルからオートコンプリート
>オートコンプリート用国候補のデータ

こう書いてあるんだから普通わかるだろ。

**NAME IS NULL** · 2019/10/23(水) 22:00:30.83

建造物と何ら関係なかったな

**NAME IS NULL** · 2019/11/04(月) 00:05:11.75

年取ると、書いてないことを読んだり、
書いてあることを読めなかったりします
私もそうだから、よく分かります

**NAME IS NULL** · 2019/11/22(金) 17:14:44.84

「利用回数が制限されているユーザーとされていないユーザーがいる」
という条件だとします。

このとき、finiteカラム（int）が99であれば、99回利用できるとします。
利用するごとに1ずつ減っていくイメージです。

では、「無制限に利用できる」を表現したい場合、finiteカラムでできるのでしょうか？
それとも、infiniteカラムなどを追加し、そこが1（有効）のユーザーは
無制限に利用できるというような、フラグ的な使い方をすればいいのでしょうか？

どう設計するのがベストプラクティスかわかりません。教えて下さい。

**NAME IS NULL** · 2019/11/22(金) 17:19:37.29

制限ユーザーかどうかを識別するカラムを追加か、
finiteが -1 なら無制限ユーザーとする、とか

**NAME IS NULL** · 2019/11/22(金) 19:58:57.97

ベストプラクティスなんて、アプリの設計方法次第で変わるわ

とりあえずfiniteにNULLでいいだろ
NULLから1引いてもNULLだからな

**NAME IS NULL** · 2019/11/22(金) 20:52:28.55

Wow

**517** · 2019/11/22(金) 21:24:33.78

>>518
なるほど。-1って考えはありませんでした。
聞いたことありませんが良さそうですね。

>>519
int型のカラムにNULL入れちゃうのは抵抗があります・・・

**NAME IS NULL** · 2019/11/22(金) 21:49:00.10

個人的には、利用上限と利用回数で項目分けたい
あとで利用回数調べたりしがちだから

基本、利用上限＞利用回数で判定して
運用上、アホみたいに利用されないなら
利用上限をintのMAX_VAlUEとかにしとけば
実質無制限になるし、同じ判定で済む

**517** · 2019/11/22(金) 23:00:06.56

>>522
なるほど。その方が汎用性がありますね。

利用上限も制限がある場合は1～99まで
無制限なら999とかにしておけばわかりやすいです。
-1だとorderの並び替えも難しいですが、999ならできますし

**NAME IS NULL** · 2019/11/22(金) 23:21:12.77

>>523
いや、できるよ

**NAME IS NULL** · 2019/11/23(土) 21:33:05.59

finiteというカラム名がなんかアレ

**NAME IS NULL** · 2019/11/26(火) 17:10:04.54

DB設計をどうするかと、データ取得はどういう順にしたいかは別の問題

**NAME IS NULL** · 2019/11/28(木) 13:21:29.42

モンスターマップのhtmlのデータをDB化しようとすると，
どんなスキーマにしておくと後々使えるでしょうかね．

**NAME IS NULL** · 2019/11/28(木) 20:58:42.03

Ｃreate Ｔable MonsterMap (
HTML ｖarchar(max);
);

**NAME IS NULL** · 2019/11/28(木) 21:14:57.24

Wow!

**NAME IS NULL** · 2019/11/29(金) 09:41:54.28

>>528 中身をDB化したい場合．
ttps://monstermap.org/data/20191129.html
みたいなURLじゃなくて，その中身です．
名前，グーグルマップへのURL，住所　のフィクションデータが入っていて
ファイル名が日付で，中身には日本語の日付もある状態．
．

**NAME IS NULL** · 2019/12/19(木) 10:39:22.96

>>33
自分が関わったシステムではただの連番をPKにした
画面の方は検索機能で対応

**NAME IS NULL** · 2019/12/19(木) 10:51:59.59

>>499
PHPから、と言うより、WEBの入力画面で登録という解釈で良いのかな
国カラムって言い方が違和感あるけど、国項目だよね
保存ボタン押した時に国項目に入力した内容を建造物テーブルの国カラムに設定してINSERT、もしくはUPDATEするみたいな
関係云々はこの画面が建造物と国を関連を登録する機能じゃないのかな

**NAME IS NULL** · 2020/01/24(金) 22:34:18.61

>>532
国項目って言い方が違和感あるけど、国カラムだよね

**NAME IS NULL** · 2020/01/24(金) 23:19:54.20

>>533
日本語か英語の違いですw

**NAME IS NULL** · 2020/01/29(水) 14:21:05.79

運用中の既存のテーブルにカラムを一つ追加したい場合、どうするのがベストでしょうか？

普通に
ALTER TABLE `テーブル名` ADD `カラム名` TEXT NOT NULL AFTER `カラム名`

みたいなSQLを実行するだけでいいのでしょうか？
それともこれを実行するとなにか問題が起きる可能性はあるでしょうか？
運用想定までできてないので、トラブルが起きる可能性があれば教えて下さい

**NAME IS NULL** · 2020/01/29(水) 15:17:24.94

>>535
特殊な事情がない限りALTER TABLEでカラム追加するのが普通
ただDBMSの種類・バージョン、テーブルの規模、カラム追加時の指定方法などによって
どういう考慮が必要かは変わってくるので製品のマニュアルを読んだほうがよい

例えばMySQLなら↓ここを読む
https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#online-ddl-column-operations
https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-performance.html

**NAME IS NULL** · 2020/01/29(水) 16:48:38.71

>>536
ありがとうございます。MySQLを使っています。
運用中のデータ（つまり、読み書きが行われている）ものに対して
テーブルの追加変更ってまずいと思ったのですが、そうでもないみたいですね

**NAME IS NULL** · 2020/01/29(水) 19:00:39.24

>>537
もしバージョン5.x使ってるならそれなりにインパクトあるから
使ってるバージョンのマニュアル見てね

**NAME IS NULL** · 2020/01/29(水) 19:12:12.64

ロックかけて行った方が安全だろうなあとは思う

**NAME IS NULL** · 2020/01/31(金) 21:28:37.66

ロックて危険やから難しいんやで？

**NAME IS NULL** · 2020/02/01(土) 03:03:34.39

ロックなしでスキーマ変更するのが安全だと？

可能なら本番稼働中のDBでやるような処理じゃないぞ

**NAME IS NULL** · 2020/02/01(土) 18:17:36.11

ハイハイお子ちゃまはおねんねしようねえw

**NAME IS NULL** · 2020/02/01(土) 18:53:13.82

ロックンロール

**NAME IS NULL** · 2020/02/09(日) 21:54:49.46

すみません
SQL質疑応答19のスレ222でも質問した者なんですが
ブライマリキーって迷ったら全てのカラムに指定してもいいですか？

**NAME IS NULL** · 2020/02/09(日) 21:58:21.18

それはアドバイスしても理解できるかどうか疑うレベル

**NAME IS NULL** · 2020/02/09(日) 22:01:46.73

すんません冗談です

**NAME IS NULL** · 2020/02/09(日) 22:07:40.17

>>544
そーゆー時はidにしとけばええねん

**NAME IS NULL** · 2020/02/09(日) 22:08:42.02

>>544
いいんじゃね？
お前さん以外は誰も困らんし

**NAME IS NULL** · 2020/02/09(日) 22:10:54.01

こういうなりすます奴が出てくるので
質問者はageでやるかトリップ付けた方が良いです

**NAME IS NULL** · 2020/02/11(火) 21:42:03.27

ageるとid出るんですか？

**質問者** · 2020/02/11(火) 23:42:15.58

238 NAME IS NULL sage 2020/02/09(日) 18:00:13.65 ID:???
どうしてもkey を変えたくないなら元情報用カラムをついかして元情報をそこに残すしかし複数の変更履歴残したいならば、変更用トランザクションデータを残して置けば変更履歴は追える

トランザクションデータというのはsqliteでも使えるのでしょうか？
別のテーブルを作って　変更のlogを保存するという方法はどうでしょうかね

**NAME IS NULL** · 2020/02/11(火) 23:56:09.78

ここでいうトランザクションデータというのは、個別の取引レコードの事だと思う
登録するデータの内容とそれが追加か更新か（必要なら削除も）の処理内容を追記するテーブルを用意する
おそらくあなたの考えているLogと同じ事ではないかと思う。もちろんsqliteでも使える

**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

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