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** · 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でやるかトリップ付けた方が良いです