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/09/03(月) 06:44:35.34

>>396
まとまりに意味があるからテーブル分けろ？
他に理由ないならバカとしか思えない

**NAME IS NULL** · 2018/09/03(月) 07:49:30.05

ただスキルがないだけなのにバカ呼ばわりは少しかわいそうw

**NAME IS NULL** · 2018/09/03(月) 10:15:56.89

それぞれが巨象の一部にふれて、
象とはこういうものだと言い合っている絵を
思い浮かべる議論だな

**NAME IS NULL** · 2018/09/03(月) 20:46:20.70

>>399
仏教徒か。仲間だな。

**NAME IS NULL** · 2018/09/04(火) 19:00:44.56

>>396
コボラーさんはカラムを後から追加はしません。
基本的に予備領域を割り当てます。
コボラーさんがRDBで設計すると、予備1～予備10みたいな項目が全てのテーブルに初期装備されます。

**NAME IS NULL** · 2018/09/04(火) 19:13:28.23

>>401
つまらん。コボラーが項目が追加できると知るとどんどん追加する。そしてテーブルの結合を嫌がる。

**NAME IS NULL** · 2018/09/04(火) 20:02:08.75

>>401
JCLでレコード長の数字を弄らんといかんようになるからな w

**NAME IS NULL** · 2018/09/04(火) 21:09:30.08

それ以前にテープに格納されてるマスタのレコード長とか変えれんから

**NAME IS NULL** · 2018/09/05(水) 08:27:53.10

なんでCOBOLの話をしているのか？

**NAME IS NULL** · 2018/09/05(水) 12:14:38.49

コボラーだもの

**NAME IS NULL** · 2018/09/05(水) 21:29:08.15

小学生相手に威張る中学生、みたいな。叩ける相手がコボラーくらいしかいないんだろう。

**NAME IS NULL** · 2018/09/05(水) 23:49:38.89

ちうがくせいにいぢめられんのかコボラーてw

**NAME IS NULL** · 2018/09/06(木) 11:24:17.20

列追加は構わんけど処理速度への影響も含めて検討してほしい

**NAME IS NULL** · 2018/09/06(木) 14:27:57.81

>>409
？

**NAME IS NULL** · 2018/09/06(木) 18:52:24.46

>>410
レコード長が倍違うテーブルのデータをupdateしたら、updateにかかる時間が倍になるって話
例えば主キー指定のupdate文で1項目だけ値を変更するとして、1件あたりはミリ秒以下でも何百万～何千万件と積み上げたら明確に差が出る
DBMSによって違いはあるだろうけどね

**NAME IS NULL** · 2018/09/06(木) 22:15:09.33

まさかレコード単位でIOかましてるとでも思ってるのか

**NAME IS NULL** · 2018/09/06(木) 23:46:24.34

いや
ただ計測したらそうなった

**NAME IS NULL** · 2018/09/07(金) 19:37:22.26

>>411
それは追加したカラムのデータを別の物理ファイルや領域に格納するRDBMS製品の話ではないのか？

**NAME IS NULL** · 2018/09/07(金) 19:58:59.63

カラムを追加したら、明らかに処理が遅くなるのなら、同じレコードであってもカラムを飛び飛びで持っている証拠になる。

レコードのデータを連続データとして格納していないRDBMSは、SELECTもINSERTもUPDATEも当然、遅くなる。

**NAME IS NULL** · 2018/09/07(金) 20:01:04.05

分からないんだけど、
連続データなら一挙にできるが
分散していると、一つ一つがバラバラに処理されるってこと？

**NAME IS NULL** · 2018/09/07(金) 21:15:09.98

昔SQL鯖でカラム追加した時に、クラスタインデックスが断片化して酷い目にあったなぁ

**NAME IS NULL** · 2018/09/09(日) 09:06:55.49

>>414>>415
SQLServerなんだけどね
カラムを追加したとかではなく元々レコード長が倍違うテーブルで、どっちも主キーはInteger型の一項目だけ、主キー以外のインデックスなんかは削除した状態
この2つのテーブルの一項目だけを更新するのに、これとは別に主キーと更新したい値だけを持つ2カラムのテーブルをカーソルで読み込んで、主キーをwhere条件に1件1件更新する処理を流した結果、時間が倍違った
（個人的な検証なのでカーソル使わずに一括Updateすりゃいいじゃんてのは無しで）

この違いの理由を考えた結果、単純に1ページ辺りのレコード件数が倍違うのが差に出てきたのかなあと思ったわけ
SQLServer特有のことかもだけど、レコード長が大きいテーブルは要注意、ひいてはカラム追加も注意が必要だと自分の中で結論を出した
（もちろん、カラム追加が絶対悪というつもりは毛頭なく、処理次第だと思ってる）

**NAME IS NULL** · 2018/09/09(日) 11:14:36.11

行ストアだからそんなもんでしょ

**NAME IS NULL** · 2018/09/09(日) 12:57:35.94

主キーはクラスタ化なのかとか、断片化してないのとか、ページ分割が起こってないのとか
まあ不定要素多すぎて何とも言えんけど

それはそもそもレコード長が違うテーブルの更新時間が違うって話で
カラム追加するかどうかと別な話

ちゃんと比較するなら、カラム追加したときと、別テーブルにカラム持ったばあいの処理で比較しないと

**NAME IS NULL** · 2018/09/10(月) 14:21:33.58

>>420
要は最後の1文に書いてくれたことも検討したほうがいいよって言いたかったの
まわりくどくなっちゃってごめん

**NAME IS NULL** · 2018/10/06(土) 14:35:50.55

皆さんデータベースを作るやりがいってなんですか？

**NAME IS NULL** · 2018/10/06(土) 16:33:44.55

・ニックネーム
・id・
・パスワード・
・最終ログイン日時
・最後にパスワードを設定した日時
・備考欄

これらのデータを管理する場合どのようなテーブル構成にしたら良いのか本を購入して学びたいのですが
良い本を教えてください。
会員サイト用のデータベースです。

**NAME IS NULL** · 2018/10/06(土) 18:20:10.06

>>422
趣味で作るんならともかく、仕事で作るのにやりがいもへったくれもあるか

**NAME IS NULL** · 2018/10/13(土) 19:44:09.60

https://imgur.com/FAF05na.jpg

**NAME IS NULL** · 2018/10/14(日) 20:23:24.26

　私たち日本人の、日本国憲法を改正しましょう。
『憲法改正國民投票法』、でググってみてください。
（へいわ）は、勝ち取るものです。拡散も含め、お願い致します。

**NAME IS NULL** · 2018/10/14(日) 20:53:15.89

>>426
戦争反対！

**NAME IS NULL** · 2018/10/17(水) 23:43:26.92

イオンみたいな巨大小売で、個人客が買い物した商品なんかのDBってどう管理してるんでしょうか？

主キー　会員ID　購入商品　品数　日付
1　a01　チロルチョコ 10　2018/10/17
2　a01　牛乳 1　2018/10/17
3　a02　牛肉 1　2018/10/17
4　a02　ポカリ 2　2018/10/17

こんな感じでテーブルに購入された商品1つ1つ登録してたら、1日で日本全国で百万レコードとか行っちゃいますよね？
何かいい手があるんでしょうか？毎日テーブルを作ってるのかな？

**NAME IS NULL** · 2018/10/17(水) 23:52:23.40

>>428
何の為にDBに登録するのか、その目的次第だと思う

小売店での現金販売だとそこまで細かくデータはとってないだろうし
そこまで細かくデータが取れるとすれば通販でクレジット決済したときくらいか

**NAME IS NULL** · 2018/10/18(木) 00:21:22.13

>>428
例示のレコードでレコード長40byteくらいだとする
1日100万でも40Mとかだから現代ではそこまででもない

**NAME IS NULL** · 2018/10/18(木) 01:28:56.96

>>429
取る取る、もっと細かく取るよ。

**NAME IS NULL** · 2018/10/18(木) 01:47:15.31

小売店で取れるデータって、POSレジの範囲だぞ
個人を特定可能なデータはとってない
特定可能なポイントカードを使わせれば良いかもだが
すべての客が使う訳じゃないからな

**NAME IS NULL** · 2018/10/18(木) 06:59:59.61

>>428
> 1日で日本全国で百万レコードとか行っちゃいますよね？
今時そこら辺に転がってるPCでもヤ楽々処理できるレベル
１億レコード超えたら本気出す

**NAME IS NULL** · 2018/10/18(木) 07:03:00.50

顧客のだけでなく業者からの仕入データだって膨大になるだろうに毎日テーブル作ってたらどうなるんだよ

**NAME IS NULL** · 2018/10/18(木) 07:33:05.12

>>428の例で、毎日テーブルを作るとしてさ、
「今年会員IDa01が購入した商品全部抽出して」って言われたらSQL文てどうやるの？テーブルを365個SQLに書かなきゃダメ？

**NAME IS NULL** · 2018/10/18(木) 16:22:23.06

本だと
購入日、性別、年代、書籍コード(ISBNや雑誌コード)、冊数が
届いてたなあ

**NAME IS NULL** · 2018/10/18(木) 23:03:46.70

パーティショニングはしてるかもしれんが、テーブル毎日つくるとかないわ

**NAME IS NULL** · 2018/10/18(木) 23:29:31.96

ようつべとか、視聴履歴をめっちゃ昔まで遡れるやん？
数億人が毎日見てるんだぜ？考えるとすごくね？しかも検索結果の抽出も早いしどうなってんだ

**NAME IS NULL** · 2018/10/19(金) 03:14:59.08

超並列とか言ってみる

**NAME IS NULL** · 2018/10/20(土) 17:50:10.77

厚さ0.1mmの新聞紙でも42回折ったら月まで届く高さになる

**NAME IS NULL** · 2018/10/20(土) 17:51:48.84

やってみてくれ

**NAME IS NULL** · 2018/10/23(火) 20:01:35.00

つまり月まで届くほどデータがあっても
検索にかかる時間は0,1mmのデータのたかだか４２倍

**NAME IS NULL** · 2018/10/23(火) 22:33:49.87

0.1mmの42倍て4.2mmじゃね？それで月まで届くの？

**NAME IS NULL** · 2018/10/23(火) 22:45:12.23

いやそれはおかしい

**NAME IS NULL** · 2018/10/23(火) 22:45:58.51

0.1mm×2＾42

**NAME IS NULL** · 2018/10/24(水) 01:29:31.23

しかし折り方を指定してないからな
蛇腹だとたしかに月までどころか5mmにもならん

**NAME IS NULL** · 2018/10/24(水) 01:45:22.86

どういう折り方しても、無理

**NAME IS NULL** · 2018/10/25(木) 03:15:40.01

よってYouTubeの検索速度を再現する事は不可能である

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

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