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/05/27(水) 10:55:44.11

>>652
若干スレチな気もするがその内容ならCSVを変換するスクリプトを書くのが手っ取り早いと思う

どういう方法が最適かはDBMSの種類、既存のインポート方法・インポート時の処理内容、処理件数、所持スキル等による

**NAME IS NULL** · 2020/05/27(水) 11:30:33.69

ここまで回答見てきたけど、結局ケースバイケースで終わる話ばかりだな

**NAME IS NULL** · 2020/05/27(水) 12:01:00.97

経験浅いとケースバイケースが理解できないから仕方ない

**NAME IS NULL** · 2020/05/27(水) 12:29:36.22

そのケースバイケースを細かく教えて
今ここで話題にしているのはその事例なんだから

**NAME IS NULL** · 2020/05/27(水) 13:37:12.83

>>656
>そのケースバイケースを細かく教えて

これがケースバイケースが理解できてない典型例

**NAME IS NULL** · 2020/05/27(水) 13:55:21.55

理解出来るように説明して

**NAME IS NULL** · 2020/05/27(水) 14:36:27.12

>>652
この質問だけだと良くわからないんだよね
csvファイルはどういうDBにインポートされるのかとか
そもそもなぜ100で割ってからインポートするような謎な仕様になっているのかとか

ひとまずこの質問文だと, DB設計の話ではなく, DBを扱うプログラミングの話でしかない
DBにアクセスするプログラミング言語で実装すればよい

**NAME IS NULL** · 2020/05/27(水) 14:47:02.83

>>658
何を知りたいのかを他人が理解出来るようにまず説明して

**NAME IS NULL** · 2020/05/27(水) 14:55:35.18

「ケースバイケースで終わる話」って説明が必要なの？

**NAME IS NULL** · 2020/05/27(水) 15:08:38.84

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

**NAME IS NULL** · 2020/05/27(水) 15:23:40.95

客観的に見て「それケースバイケースだよね」ってレスするより
「これはこうしろ」ってレスするほうが早くないか？
質問者に喜ばれるし、自己顕示欲も満たすし、スレも荒れない。
何も損しないんだが、なぜケースバイケースってまとめるのかわからん

**NAME IS NULL** · 2020/05/27(水) 16:56:45.60

>>663
早くない
質問する側がどういうケースなのかを特定するための説明をするほうが断然早い

どういうケースなのかを相手に伝える努力を放棄してるにもかかわらず
答える側にはケースを想定した回答を求めるのは無理筋

**NAME IS NULL** · 2020/05/27(水) 17:28:19.42

何をもって
「それケースバイケース」って言えるか位は､
言えるだろう
それを聞いている

**NAME IS NULL** · 2020/05/27(水) 17:28:52.80

>>664
それならもっと詳しく聞けばいいだけじゃないか？
プログラム板とか情報足りないとそう答えてるぞ

荒れやすいニュース板でもケースバイケースとかどっちでもいいとか
クソレスするやつは少ないよ
ここぐらいだ。端からコミュニケーション放棄してるのは

**NAME IS NULL** · 2020/05/27(水) 17:29:08.26

自分の好きな例を持ってくれば良いという､簡単な事だろう

**NAME IS NULL** · 2020/05/27(水) 17:32:01.30

普通ならそうだよ。
「AまたはBですか？」
という的外れな質問でも
「Cだよ」って回答して
「いや、CじゃなくてAはこういう意味で～」
ってな感じでスレが流れる。

しかしここは「AでもBでもどっちでもいい」だもん。
まるで会話になっていない

**NAME IS NULL** · 2020/05/27(水) 17:39:29.67

>>665
「それを聞いてる」じゃわからないよ
何を聞いてるの？

**NAME IS NULL** · 2020/05/27(水) 18:00:58.87

>>666
>それならもっと詳しく聞けばいいだけじゃないか？

それは単なる甘え

自分が努力せず他人に努力させようとしてるやつに
仕事でもないのに懇切丁寧に聞き返す労力を払うやつは少ないわな

**NAME IS NULL** · 2020/05/27(水) 18:02:04.31

>>660
これに尽きるな

**NAME IS NULL** · 2020/05/27(水) 18:54:02.70

ここは、AかBかって質問で充分なケース想定ができるならもともな答がかえってくるわ

ケースバイケースっていわれた段階で説明が足りんと気づけや

**652** · 2020/05/27(水) 19:08:39.17

653
659
スレチなのにご回答ありがとうございます
とりあえずデータベースだけで出来るような仕組みを考えます

**NAME IS NULL** · 2020/05/27(水) 19:12:38.40

ちゃんと説明しないやつはコミュニケーションが足らないって言ってるやつが相手してやればいいだろ
内容がはっきりすればそれなりに回答してくれてるだろ、このスレは

**NAME IS NULL** · 2020/05/27(水) 19:14:01.98

常にケースバイケースなら、

ケース分けなどいらないぞ

**NAME IS NULL** · 2020/05/27(水) 19:15:19.35

ちゃんとやりたいことを説明しないからケースバイケースって言われるんだろ

**NAME IS NULL** · 2020/05/27(水) 20:16:10.67

ワークテーブルにいれてから
加工するsqlでインポートはどうかな

**NAME IS NULL** · 2020/05/27(水) 20:19:15.84

まちがえたインサートだ

**NAME IS NULL** · 2020/05/27(水) 21:18:28.66

ETLでやる内容だな

**NAME IS NULL** · 2020/05/27(水) 22:01:37.60

ハイフン入りの顧客コードは計算列という選択肢もある
参照整合性がどうなってんのか気になるが

**NAME IS NULL** · 2020/05/27(水) 22:20:41.40

エクセルだろ
セルに書式設定すればいいんじゃね

インポートして書式設定までVBAですぐできるだろ

**NAME IS NULL** · 2020/05/28(木) 11:27:01.61

>>677-681は想像して書いてるよな。
>>676みたいな奴は読解力がないだけ

**NAME IS NULL** · 2020/05/28(木) 12:11:39.95

>>682
想像してるんじゃなくてDBだけでやりたいという形でケースの特定化がなされたことで>>677や>>680の回答が出やすくなってるんやで

**NAME IS NULL** · 2020/05/28(木) 12:49:31.13

>>682
これに関してケースバイケースなんて言われてないだろ
お前はそれ以前に日本語が読めないのか？

**NAME IS NULL** · 2020/05/28(木) 16:48:42.27

>>684
>>654

**NAME IS NULL** · 2020/05/28(木) 17:13:38.87

カテゴリー君はよほど悔しかったんだなw

**NAME IS NULL** · 2020/10/02(金) 04:29:53.32

すみません。IDの設定について教えて下さい。
現在、id (INTEGER) と user_name (TEXT) の2カラムで、以下のデータがあるとします。
1 , 東京営業所
2 , 沖縄営業所
3 , 北海道営業所
4 , 東北営業所

データを取得時、以下のように北のほうからの並びで取得したい場合は、並び順を設定するカラムを追加するしかないでしょうか？
3 , 北海道営業所 , 1
4 , 東北営業所 , 2
1 , 東京営業所 , 3
2 , 沖縄営業所 , 4

既存のテーブルで、設計を変更するとプログラム側も変更しないといけない場所が何か所か出てくるので、
極力変更したくないのですが・・・

**NAME IS NULL** · 2020/10/02(金) 07:18:02.94

どうしても変更したくないならソートオーダーの為だけの新テーブルを追加
素直にフィールド追加した方が後の保守は楽ですよ
プログラム側はフィールド追加で影響が出ない様に作るものですけどね

**NAME IS NULL** · 2020/10/02(金) 08:33:57.24

既存テーブルへのカラム追加で既存プログラムも修正が必要になるのって
データを複製してるような処理しか思いつかない
そういう処理なら並び順もデータとして必要になるよね

**NAME IS NULL** · 2020/10/02(金) 20:23:42.56

select *

**NAME IS NULL** · 2020/10/02(金) 22:02:47.07

今どきアスタリスク指定してるくらいじゃ問題にならんよ
最終目的地までカラムを指定せず全部出力するなら別だけど

**NAME IS NULL** · 2020/10/02(金) 22:21:30.11

今order by指定していないなら、それは「たまたま」id順で出てるだけ
どっちにしてもorder by指定する必要がある

今idでorder byしてるが、それを変えたくないなら、id振りなおすしかないわな
id振りなおすのとカラム追加＆プログラム変更とid振り直しとどっちが楽か判断して決めれば良いんじゃね

**NAME IS NULL** · 2020/10/03(土) 20:16:27.73

なんで行順番の話?

**NAME IS NULL** · 2020/10/03(土) 23:37:33.72

さあ

しかしorder byがなくて
バクるアプリを引き継いだワイにはタイムリーネタやで

**NAME IS NULL** · 2020/10/03(土) 23:46:00.34

都道府県コード使うとしても、北からの並びではないからなあ
並べたい順に自分で番号付けたテーブルを用意しないと無理でしょ

**NAME IS NULL** · 2020/10/04(日) 02:18:43.41

sst

**NAME IS NULL** · 2020/10/05(月) 16:37:36.91

case でマッピングするという力業もあるけど

**NAME IS NULL** · 2020/10/05(月) 19:58:12.35

>>687
そのIDにエリアの概念を持たせなかったのが失敗なんだよ。

**NAME IS NULL** · 2020/10/05(月) 20:44:41.26

idにidentity以外の意味を持たせるのは愚策。素直に順序列を追加するのが吉。

**NAME IS NULL** · 2020/10/05(月) 20:44:48.17

あるあるアンチパターンを勧めてくるとは

さすが

**NAME IS NULL** · 2020/10/05(月) 20:45:18.74

かぶった

**NAME IS NULL** · 2020/10/06(火) 01:05:10.04

電話番号や郵便番号のコード体系を考えたこともないのかね。

**NAME IS NULL** · 2020/10/06(火) 09:23:09.69

コード体系が必要なら各意味を別々のカラムで管理してコード自体は導出項目にする

コード体系を作ったこともないのかね。

**NAME IS NULL** · 2020/10/06(火) 10:17:55.36

汎用機世代の人やRDBをよく知らないExcel屋さんは
すぐ暗黙のコードを使おうとするんだよね

昔、東大卒のマーケティング屋さんが
10個以上の意味を埋め込んだオレオレ独自コードを
自信満々のドヤ顔で説明してきた時は困り果てたよ

**NAME IS NULL** · 2020/10/06(火) 11:04:05.32

代理キーが標準のような話になってますね

**NAME IS NULL** · 2020/10/06(火) 11:47:26.23

匿名掲示板で、ID表示なし、コテハンもトリップもナシでどやられてもなあ

**NAME IS NULL** · 2020/10/06(火) 11:47:30.72

コード体系の話はプライマリキーが代理キーかナチュラルキーかは関係ないよ

複数の意味を持たせるのがアンチパターン

**NAME IS NULL** · 2020/10/06(火) 13:04:33.85

主キーの意味がわかってないのか？

**NAME IS NULL** · 2020/10/06(火) 13:25:17.40

いつもの触っちゃだめなやつ
控えめに言ってガイキチなので気をつけろ

**NAME IS NULL** · 2020/10/06(火) 14:07:09.38

>>699
identityではなくidentifier。

**NAME IS NULL** · 2020/10/06(火) 14:07:39.63

>>707
IDはユニークという意味しかない

**NAME IS NULL** · 2020/10/06(火) 14:37:54.31

>>699が言ってるのは「identifierにidentity以外の意味を持たせるのは愚策」ってことやぞ

**NAME IS NULL** · 2020/10/06(火) 14:54:07.51

あるコード(体系)を設計し導出項目となり、それをキーとしたいとなった場合
必然それは代理キーとなるだろう、とは言えるが

導出項目をつねに代理キーにするとか言ってないし
代理キーが主キーに限定されているわけでもないし

そもそもコード体系云々以前に
一つの項目に複数の意味を持たせるなって大原則があるだけ

**NAME IS NULL** · 2020/10/06(火) 16:27:35.99

実務経験のなさが露呈してますよ

**NAME IS NULL** · 2020/10/06(火) 18:02:55.53

もしかして代理キーをsurrogate keyの意味じゃなくalternate keyの意味で使ってるのか？

もしそうなら誤訳以外のなにものでもないので別の訳語なり用語を選んだほうがいいと思うぞ

**NAME IS NULL** · 2020/10/06(火) 18:11:26.80

https://ja.wikipedia.org/wiki/代理キー
代理キー（だいりキー、英: alternate key）
代替キー (サロゲートキー、surrogate key)

これはやべぇw
英語の日本語の意味が完全に逆

**NAME IS NULL** · 2020/10/06(火) 18:14:46.93

いまになって調べてるのか？

**NAME IS NULL** · 2020/10/06(火) 18:24:08.59

>>716
その代替キーはIPAでは代用キーと呼んでいる。

サロゲートキーのことを「代理キー」と呼ぶのは日本の慣習です。

英語の翻訳語は使われ方が反対になることがあるので注意してください。

**NAME IS NULL** · 2020/10/06(火) 22:06:20.96

>>716
wikipediaの記事ができるより前の時期で検索してみたが
surrogate keyは代理キーは、alternate keyは代替キーと正しく訳してるものしか見つからない
オラクル、富士通、ユニシス、@IT、オージス総研などなど

古いDBマガジンを確認しても代理キーはsurrogate keyの意味で使われてるものしかない

歴史修正主義なんかな？

**NAME IS NULL** · 2020/10/06(火) 22:15:47.94

alternate keyは二次識別子と言っておけばだいたいOK

**NAME IS NULL** · 2020/10/20(火) 07:31:35.62

テーブル設計であえて正規化しないで置くべき理由ってなにがあるでしょうか？
ちょろっとググった感じだと、パフォーマンスが重要な要件だとテーブル結合をなるべく避けたい
とかが見つかりましたが

**NAME IS NULL** · 2020/10/20(火) 07:34:17.42

逆に正規化する「べき」理由ってあるの？

**NAME IS NULL** · 2020/10/20(火) 07:40:17.35

素人なので断言できませんがパッと思いつくのは
多重管理を避けることができ、それに付随して
・テーブルの意図が明確になる
・データ不整合の発生を防げる
などです

**NAME IS NULL** · 2020/10/20(火) 10:09:11.35

>>721
トランザクション処理中心の業務系データベースの場合は基本的に正規化する
更新異常を防いで整合性を維持するため

ただしパフォーマンス最適化のために正規化されたものを非正規化することはある
その場合でも設計時には正規化された場合の構造を明確にした上で非正規化する
そうしないと非正規化したことでどういう更新異常が発生しうるのかや
アプリ側で担保しなくてはいけないデータ整合性が明文化されないから

データウェアハウスのようにデータの追加はあっても更新のない情報系データベースの場合は
全く正規化しないわけではないけど最初から分析しやすい形を念頭に設計する

**NAME IS NULL** · 2020/10/20(火) 14:09:08.77

>>724
やはり特殊な用途を除き正規化するのが基本なのですね
ありがとうございます

身近で詳しそうな人に正規化した設計を提出したところ
フラットに作り直すよう指摘され、明確な理由がわからず
もやもやしておりました

開発観点の他に運用・保守観点（項目の追加/削除、データの追跡可能性）
を想像してみても特に正規化を避けるべき理由が思い当たりませんでした

**NAME IS NULL** · 2020/10/20(火) 14:56:58.07

なぜ指摘した本人に理由を聞かないのか

そもそもそれほんとにちゃんとした正規化が出来てるのか？
正規化を避けるべき理由はないのか？

そもそも設計を提出ってなんだよ。業務なのか？
だったらなぜ上司ではなく詳しそうな人なんだ

**NAME IS NULL** · 2020/10/20(火) 15:05:03.53

もしかしてRDBじゃなくMongoみたいの使う前提なのかな？

まあ指摘した本人に理由を聞くべきなのは間違いない

**NAME IS NULL** · 2020/10/20(火) 15:31:38.20

理由ははぐらかされてしまいました
そっちのほうがいい気がする
というようなことを言っていました

> もしかしてRDBじゃなくMongoみたいの使う前提なのかな？
RDBです

**NAME IS NULL** · 2020/10/20(火) 16:12:36.27

技術的な面じゃなくサーバーが年代物で貧弱とか
開発予算がないから手抜きで作るとか政治的な事だったり

**NAME IS NULL** · 2020/10/20(火) 17:39:35.83

正規化した設計とかフラットにした設計の中身が
もう少し具体的にわからんとなんとも言えないね

フラットにすることで更新異常が発生しうるんなら
メリットデメリット理解して選択するしかない

**NAME IS NULL** · 2020/10/20(火) 19:58:51.65

>>725
世の中には自分の理解できないものは使うな
って言う上司とか先輩はいっぱいいる
その人に従わないとダメなら言質を押さえて従うがよろし
単に詳しそうな身近な人と言うだけならもう変更の工数ないからとか言って無視しとけばいい

**NAME IS NULL** · 2020/10/21(水) 00:08:11.04

原則は教科書通りにるすのが一番ですが

場数踏んだ熟練のPGさんとか
製造工数おさえてギリokみたいな
絶妙な作りしてくる人もいる
理由は経験とカンみたいな

気にやまないことだと思います

**NAME IS NULL** · 2020/10/21(水) 01:41:41.26

すぐに言語化できなくても直感的にモヤッとする設計ってのはある
必ずしもその直感が妥当というわけではないんだけど
熟練になればなるほど感覚的なものも大事にしたほうがいい

**NAME IS NULL** · 2020/10/21(水) 01:49:04.44

なんとなく分かる
気持ち悪い設計って確かにある

**NAME IS NULL** · 2020/10/21(水) 13:04:54.08

第4や第5とかボイス何たらとかを第3に戻されたとか？

**NAME IS NULL** · 2020/10/21(水) 13:07:36.31

第5はともかくボイスコッドで設計できる人の質問ではない気がする

**NAME IS NULL** · 2020/10/21(水) 17:30:47.48

詳しそうで素人な人もいるぜ
クソ設計なテーブルで、プログラム書かされて死にそうになったことある

**NAME IS NULL** · 2020/10/23(金) 14:20:38.63

>>736
ボイスコッドの方が難易上なの？
自分が理解し切れてないのだけど、ボイスコッド正規形は条件満たすだけならまあ簡単だけど実務とか現実世界の関係的に違和感のある設計になるよくわからんもの、みたいなイメージがある……

**NAME IS NULL** · 2020/10/23(金) 23:40:51.85

実務のボイスコッド正規形は理論のそれと違って
導出属性を使った制約を追加することで第三正規形から関数従属性を失わずに
ある種のビジネスルールをデータモデルに埋め込むことができる

第3や第5よりもBC正規形使った設計ができる人のほうが
DB設計に対して深い理解があると思うよ

**NAME IS NULL** · 2020/11/30(月) 22:31:04.06

とりあえずサロゲートキー持たせたいとき（持たせるって表現で良いのか解らないけど）って、
数字のみの連番にする？　何か文字列も付与する？　ケースバイケース？

数字のみで良いのかなと思ってたんだけど、文字列付けた方が良い時ってあるんじゃろか

**NAME IS NULL** · 2020/11/30(月) 23:55:06.66

サロゲートキーという範疇に入らないかもしれないがUUIDを使ったほうがいいケースは自然と文字列も入る
分散データベース間でも一意に識別したいとかDBにアクセスせずに一意なIDを生成したい場合

でもそういうのはDBのプライマリキーには使わないから
1つのテーブル内の一意性で十分で、数字の連番を使い切る可能性がなければ文字列を入れる理由はないかな

他には人間に読みやすくかつ間違いにくくするために文字を入れるケースもあるけど
その場合は生成した数字とは別のカラムで文字列込みの値を管理する

**NAME IS NULL** · 2020/12/01(火) 00:00:33.65

最初に文字を入れると全部桁数は揃うだろうから見た目は気持ちはいいかもな

**NAME IS NULL** · 2020/12/02(水) 02:52:19.08

>>741
なるほど。こういうのもあるのか
> その場合は生成した数字とは別のカラムで文字列込みの値を管理する

これはこれで、それぞれのカラム名どうしようとか悩みます
文字列込みにした方が人間に読みやすいのは確かなんだけど、２つ管理するのも不慣れなせいかしっくりこない
選択肢が増えてますます混乱したｗ

**NAME IS NULL** · 2020/12/02(水) 09:55:10.43

そもそも代理キーに文字を入れたいとか、代理キーになんらかの意味を持たせたいってことだろ
それすでに代理キーじゃなくね

**NAME IS NULL** · 2020/12/04(金) 10:49:18.51

>>744
代理キーならあるでしょ
サロゲートキーの話をしてるなら同意するけど

**NAME IS NULL** · 2020/12/04(金) 11:41:14.98

>>745

>>715

**NAME IS NULL** · 2021/01/04(月) 11:20:12.25

商品に、表示フラグ、新着フラグ、18禁フラグや、表示優先順位などWeb上の表示だけに特化した値を持つ場合、商品マスタに書いてしまっていいのでしょうか？それとも別に持ったほうがいいのでしょうか？

**NAME IS NULL** · 2021/01/04(月) 12:28:55.25

表示フラグと18金ｗはいるだろうな
他は、コロコロ変わるものだから
別にして良いと思う

**NAME IS NULL** · 2021/01/04(月) 18:53:45.42

>>747
商品マスタの構成や商品マスタをどう使う前提なのかによる

一般論で言えば商品IDが決まれば値が確実に決まるような属性なら商品マスタに書く
商品すべてがWeb上で扱う前提ならWebに特化した値も商品マスタに書いてもいい
Webに特化した属性のCRUDのタイミングが商品マスタの基本属性と異なるなら
別テーブルにしたほうがいい可能性が高い

18禁フラグ以外は商品ID+日時の組み合わせで管理できるようにしておいたほうが運用は楽
(商品マスタ自体が商品ID+日時の組み合わせで一意になるようなら更新頻度/更新タイミングなどから別テーブルにするかどうか検討)

あと新着かどうかは販売開始日付みたいなのからアプリで判断するほうが普通

**NAME IS NULL** · 2021/01/04(月) 21:39:09.85

サロゲートキーにulid 使うのは異端？
スレ検索してもulid 出てこないね。

**NAME IS NULL** · 2021/01/04(月) 22:01:16.35

サロゲートキーにUUIDを必要とするユースケース自体がかなり稀だからね

**NAME IS NULL** · 2021/01/04(月) 23:04:35.94

ごめん、ちゃんと注意して書けば良かった。
128bitのUUID(Universally Unique Identifier)ではなくて、
同じく128bit(Timestamp 48 bit + Randomness 80 bit)のULID(Universally unique Lexicographically sortable IDentifier)。

日時でソートできるUUID的なヤツなんだけど、あんま使われてないんかな？