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/05/26(土) 23:00:10.53

削除して良い要件と、削除方法は別の話なんだが
そして削除フラグは、データの削除ではなく単なる状態変更の場合があるって話

これが理解できない奴が削除フラグの話をかきまわしてるだけ

**NAME IS NULL** · 2018/05/26(土) 23:11:28.11

継続して議論したいなら、コテハン付けるなりトリップ表示させなよ

**NAME IS NULL** · 2018/05/26(土) 23:21:53.44

削除フラグの話題にすらついてこれない人がどうしてこのスレにいるの？

**NAME IS NULL** · 2018/05/27(日) 10:01:04.63

ちゃんと削除フラグの話題で進めばいいけど>>286とか>>294みたいに頓珍漢なこと持ち出してグダグダになった過去が何回もあるからなぁ w

**NAME IS NULL** · 2018/05/27(日) 10:57:41.83

>>301
おまえの事やぞw

**NAME IS NULL** · 2018/05/27(日) 11:14:49.09

>>302
本人降臨乙w

**NAME IS NULL** · 2018/05/27(日) 15:55:32.12

>>298
ステータスならフラグという持ち方は変。

**NAME IS NULL** · 2018/05/27(日) 15:57:15.03

ひとつのレコードにたくさんフラグ項目を持っていて、それを複雑な条件で判断するようなやつは死ねよ！

**NAME IS NULL** · 2018/05/27(日) 18:20:01.00

>>304
状態がオン／オフしかないようなものならフラグでおかしくない

>>305
フラグたくさん持ってるとか条件が複雑とか、それが要件なら仕方ない
むしろ全然関係ないフラグをビットフィールドにまとめるほうが迷惑

**NAME IS NULL** · 2018/05/27(日) 21:18:51.26

>>306
>>298 は削除フラグが状態変更と言っている。単に論理削除ではないと言っている。それをただ「削除フラグ」と呼んだら普通は意味がわからない。

**NAME IS NULL** · 2018/05/27(日) 21:20:22.92

>>306
おまえ、ジジイだろ？

そんなわかりにくいデータの持ち方は、リレーショナルデータベースの考え方ではない。

**NAME IS NULL** · 2018/05/27(日) 21:25:12.75

削除フラグの泥沼スレという名前のスレを建ててそこでやれよ。

**NAME IS NULL** · 2018/05/27(日) 22:50:53.39

だいたい削除フラグなんていらないしな。

とにかく汎用機ジジイがリレーショナルデータベースを使うとこうなる。

またはExcelシートだと思っている素人が考えるとこうなる。

**NAME IS NULL** · 2018/05/28(月) 12:33:38.94

何故突然エクセルwバカってこわいwww

**NAME IS NULL** · 2018/05/28(月) 21:04:44.29

>>311
リレーショナルデータベースをExcelと同じようなものと考えている人は多いぞ。

**NAME IS NULL** · 2018/05/28(月) 22:09:34.92

>>305
一つの項目がステータスを表し、0～9の値を持ち、2と7が削除扱いという設計を見たことがある。
2が取引先からのキャンセル、7がこちら都合のキャンセル。
嫌になった。

**NAME IS NULL** · 2018/05/31(木) 21:41:41.10

毎日の果物の価格を記録するデータベースを作りたいんですがどういうテーブルをつくったらいいですか？とりあえずitemsテーブルに果物の種類とidのカラムを作ります。
毎日の価格はどういうテーブルにしたらいいですか？

**NAME IS NULL** · 2018/05/31(木) 21:59:40.22

>>314
itemテーブルはそんなものだろうと思う。

毎日の価格を登録するテーブルというのが、
実際の販売時の価格を取引単位で記録して行くのか、
それとも一定時間での平均価格等を記録して行くのか
もう少し具体的な要件を出してもらう方が良いかと思う

**NAME IS NULL** · 2018/05/31(木) 22:14:59.09

>>315
価格というのは市場で取引された価格の高値と安値で1日2つの価格に決まります。

**NAME IS NULL** · 2018/05/31(木) 22:20:51.12

その高値と安値の取得は、システム側でリアルタイムに行うのか、
それとも、一日の最後に取得するものなのか
前者の場合は、そういう記録もとっておき、更新しないとならなくなるよね

**NAME IS NULL** · 2018/05/31(木) 22:23:34.53

更新は一日に一回だけです。

**NAME IS NULL** · 2018/05/31(木) 22:26:08.06

では、難しく考える必要はない
記録したい項目をテーブルに用意して終わりでしょう

**NAME IS NULL** · 2018/05/31(木) 23:07:07.03

例えばこんな感じかな
item_id
high_price
low_price
date

他に必要な項目があれば追加

**NAME IS NULL** · 2018/06/01(金) 04:08:11.91

>>320
プライマリキーは要らないんですか？
あとテーブル名ってどんな感じに付けますか？

**NAME IS NULL** · 2018/06/01(金) 04:10:01.84

必要かどうか分からないが、
どうしてもキーを付けるなら、
一意になりそうな日付かな？
テーブル名はお好きにどうぞ

**NAME IS NULL** · 2018/06/01(金) 11:25:16.22

果物取引実績(果物取引実績ID PK, 果物ID NN, 取引年月日 NN, 取引価格 NN)
チェック(取引年月日 = 時間切捨(取引年月日))
チェック(取引価格 >= 0)
インデックス(果物ID, 取引年月日)

select 果物ID, 取引年月日, max(取引価格) 最高値, min(取引価格) 最安値
from 果物取引実績
group by 果物ID, 取引年月日

**NAME IS NULL** · 2018/06/01(金) 14:29:47.30

>>323
そうだね、一意にするためには日付だけではなく
itemIDとセットにしないといけなかった

**NAME IS NULL** · 2018/06/01(金) 21:03:43.61

しかし>>323はindex付けただけでuniqueにはしていないという

**NAME IS NULL** · 2018/06/01(金) 21:04:55.21

販売実績だからユニークにしなくていい
同じ果物が何度も売れてもいい

**NAME IS NULL** · 2018/06/01(金) 21:48:46.17

要件ガン無視ﾜﾛﾀ

**NAME IS NULL** · 2018/06/01(金) 22:16:10.56

質問者を放置して持論展開はいつもの事

**NAME IS NULL** · 2018/06/01(金) 22:30:46.29

客は要件わかってないからな
要件そのまま聞くとまあ後でおかしくなるよ
この場合だと、その日の最後に入力するので取引実績をメモしておかないといけないんだけどめんどくさい、だとか
最大最小を計算するのめんどくさいからどうにかして、といった具合

**NAME IS NULL** · 2018/06/01(金) 23:15:49.45

入手できるデータが取引単位なのか日単位なのかなんて開発者が勝手に決められるわけないわな。

**NAME IS NULL** · 2018/06/02(土) 00:24:27.89

夢見る乙女もまんぐり返る妄想力やなw

**NAME IS NULL** · 2018/06/02(土) 00:54:08.86

どうしても日単位の最大最小でしかデータを入れられないなら
insert into 果物取引実績 values
('id1', 'banana', 年月日, 最高値),
('id2', 'banana', 年月日, 最安値)
といった形にすればよろしい
最初からテーブル構造が壊れてると想定外の事態に回避策とりにくい(メモめんどくさいとか手集計めんどくさいとかね)
テーブル構造がまっとうなら回避策も容易に見つかる

**NAME IS NULL** · 2018/06/02(土) 01:03:54.25

>>332
それだと、レコード一つだけ見たときにそｒが最高値か最安値か分からないだろう

**NAME IS NULL** · 2018/06/02(土) 07:10:37.22

こういう、なにがキーかわからないテーブルを設計してしまうID厨

**NAME IS NULL** · 2018/06/02(土) 07:36:22.88

>>332
どうやったらこんなアホな発想に至るんだろう...

**NAME IS NULL** · 2018/06/02(土) 07:39:23.98

>>333
>>323

**NAME IS NULL** · 2018/06/02(土) 07:44:01.56

>>334
どう見てもidがキーとわかる
果物idと日付をキーにする派閥もあるが
後で見た人は同じ日に同じものが売れたらどうなるんだ？と疑問を感じざるをえない

**NAME IS NULL** · 2018/06/02(土) 07:44:49.55

>>335
せめて反論の形にしないと敗北宣言と同じだよ？

**NAME IS NULL** · 2018/06/02(土) 07:48:00.32

データベースは1行に1つの事実を保存する
基本中の基本
最大値や最小値を1行に保存するということはこれに反する
統計値とは複数の事実から導き出されるものだからだ

**NAME IS NULL** · 2018/06/02(土) 07:49:44.49

>>338
え゛っ、マジで言ってるの？
値を参照するだけで>>323相当のSQL要るし、既に>>320みたいなまっとうな例もでてるのに w

**NAME IS NULL** · 2018/06/02(土) 07:53:31.65

>>339
基地害ｷﾀ━(ﾟ∀ﾟ)━!

**NAME IS NULL** · 2018/06/02(土) 07:55:18.85

>>340
統計値を参照するのに集計クエリが要るのは正常

>>320はまっとうじゃないよ
手作業で出した集計値を保存するという暗黙の手続きの上にかろうじて成立しているだけ
それと試しにこのテーブルにまっとうな名前をつけてみなさい

**NAME IS NULL** · 2018/06/02(土) 07:55:39.30

>>341
>>338

**NAME IS NULL** · 2018/06/02(土) 08:01:53.58

形式だけ正規化して満足してしまう人が多すぎる
彼らは形式しかみないから>>320のような歪なテーブルを受け入れてしまうがそれはダメだ
意味的にも正しく正規化すべきだ

**NAME IS NULL** · 2018/06/02(土) 08:05:20.94

そろそろ最初の質問者である>>314が出てきて要件について後出しでも何でも良いから（というか思ってることでもいいから）
はっきりさせるべきだな。

**NAME IS NULL** · 2018/06/02(土) 08:13:57.12

>>344
「正規化」って用語を「正しいテーブル設計」の代名詞みたいに使う人は相変わらずいるねぇ。
意味的に正しい正規化ってなんだろう。

**NAME IS NULL** · 2018/06/02(土) 08:19:27.67

>>342
要件を間違えてる
「高値/安値を求める」のではなく「求められた高値/安値を記録」するってこと ⇒ >>316
統計関係ない
テーブル名？
果物取引実績とかでいいだろ w

**NAME IS NULL** · 2018/06/02(土) 08:21:54.17

休日の早朝から議論
おまいら健康的だな

**NAME IS NULL** · 2018/06/02(土) 08:22:47.57

>>346
第一正規化とかでググれ
１つの列に>>332みたいに違う意味の情報を入れるのは最悪の設計であることがわかると思う

**NAME IS NULL** · 2018/06/02(土) 08:32:59.12

>>346
例えばhoge(id, foo_1, foo_2, foo_3)のようなテーブルは形式的には正規形だが意味的にはおかしなことだ
古いエンジニアは平気でこういうテーブルを書いてしまう
集計値を格納するのも同様に形式しか見ずに設計した酷いテーブル構造だ

**NAME IS NULL** · 2018/06/02(土) 08:33:46.46

>>344が言っているのは>>320のことだが。
>>332は属性の意味が定まらんという、正規化以前の問題。

**NAME IS NULL** · 2018/06/02(土) 08:37:51.48

>>350
だから、形式的に正規形だったら正規形なんだよ。意味的におかしいというのは別の話。
それを「正しい正規形じゃない」と言うのが変なだけ。

**NAME IS NULL** · 2018/06/02(土) 08:54:32.67

>>347
記録するという行為の本質を見誤ってるな
Aという事実から直ちにBという事実が導き出される場合に
Bを記録する方法はBを直接的に記録するのとAを記録する方法がありうる
Aを記録したからといってBを記録していないということにはならない

例えば歩く速度と歩いた時間を記録すれば歩いた距離も記録したも同然だな
それと同じでここの取引価格を記録するということは同時に最安値・最高値を記録することでもある
要件には全く反していないということだな

それと果物取引実績という名前から最高値・最安値を直接的に記録するテーブルだと解釈するのは無理がある
まっとうなテーブルじゃないからまっとうな名前をつけられない

**NAME IS NULL** · 2018/06/02(土) 09:00:43.48

>>349
あくまで苦肉の策だということ
手作業で集計値を出すまでに個々のデータは必ずあるのだから、その個々のデータを入れるのが正しいあり方だ
しかし、どうしても最安値・最高値だけ保存してそれ以外は手作業で計算したいという奇特なユーザーのためにこういう手もないことはないと提示しただけ

ちなみにこの最高値・最安値のレコードだけを登録する回避策は厳密には間違いではない
なぜなら最安値の取引実績も最高値の取引実績も実際に存在する事実だからだ
間違いがあるとすれば他にも存在したはずの事実の記録を怠った運用の仕方にある

**NAME IS NULL** · 2018/06/02(土) 09:05:34.37

>>351
完璧に定まってる
いつ、何が、幾らで取引された、という事実を単純明快に表している
そして、それぞれの事実を識別するための最もシンプルな手段であるidを導入した
時刻はアイデンティティを示すキーの一部にはならない

**NAME IS NULL** · 2018/06/02(土) 09:07:03.57

速度計を持っているかどうかもわからんのに速度を入力しろとか。

**NAME IS NULL** · 2018/06/02(土) 09:07:23.66

>>352
それは派閥による
セルコは意味的な部分にも踏み込んで正規化としているね

**NAME IS NULL** · 2018/06/02(土) 09:11:43.30

>>356
くだらないレスはやめよう
歩いた距離と時間を記録すれば速度を記録したようなものだ
これで速度計は不要になったね
次はなんだ？時計がないってか？
付き合いきれん

**NAME IS NULL** · 2018/06/02(土) 09:12:48.97

>>353
> Bを記録する方法はBを直接的に記録するのとAを記録する方法がありうる
だから中途半端な>>332はバカだって言う話な

> それと果物取引実績という名前から最高値・最安値を直接的に記録するテーブルだと解釈するのは無理がある
> まっとうなテーブルじゃないからまっとうな名前をつけられない
>>332に言ってやれよ w

**NAME IS NULL** · 2018/06/02(土) 09:14:38.57

>>354
必要もないのに苦肉の策をとるバカ乙

**NAME IS NULL** · 2018/06/02(土) 09:27:03.02

言い返せなくなると罵倒する
ここらで決着かな

**NAME IS NULL** · 2018/06/02(土) 09:36:48.83

>>357
そう？
少なくとも「プログラマのためのSQL」じゃ形式的な正規形についてしか説明していないようだけど。

曰く
「正規形は、データベースで真のデータを破壊したり、偽のデータを作成したりすることがないように
しようというのが目的です。」

**NAME IS NULL** · 2018/06/02(土) 10:02:51.95

>>361
> 言い返せなくなると罵倒する
> ここらで決着かな
ひょっとして「必要もないのに」って言われてる意味がわかってないとか？
てか既に決着してるだろ w

**NAME IS NULL** · 2018/06/02(土) 19:53:26.96

意味の正規化って，数学的に言うとどういうこと?

**NAME IS NULL** · 2018/06/02(土) 20:25:43.70

バカの障り

**NAME IS NULL** · 2018/06/03(日) 17:50:56.72

回答ありがとうございました

>>345

>>320さんを参考に
テーブル作ってみたんですが

https://ideone.com/y6urpx

itemテーブルに同じ名前で重複してかきこまれてしまいます。

**NAME IS NULL** · 2018/06/03(日) 18:21:59.24

>>366
取引した日付と商品IDで重複しなくなるから、
その二つを使ってPrimary Keyを指定する。

PRIMARY KEY(`transaction_date`,`items_id`),

#varcharって書くと、サイズ1になるんだっけ？

**NAME IS NULL** · 2018/06/05(火) 01:29:12.15

>>367
primary key にすれば自動的にunique制約されるんですね

**NAME IS NULL** · 2018/06/05(火) 13:48:16.07

そういうことになるね
それをキーにして何通りも取得できたら
おかしいことになるだろうし

**NAME IS NULL** · 2018/06/09(土) 06:56:35.90

皆さんがアンケートの答えを格納するテーブルを作るとしたら
未回答は、nullを想定しますか？0を想定しますか？
理由も教えてください！

**NAME IS NULL** · 2018/06/09(土) 07:24:58.49

It depends on the situation.

**NAME IS NULL** · 2018/06/09(土) 08:20:27.48

ナイーブに考えると、行なしだろ?

**NAME IS NULL** · 2018/06/09(土) 10:32:23.91

任意項目への未回答は空文字か、回答無し値（事前に決めた値）にする

**NAME IS NULL** · 2018/06/09(土) 17:01:40.73

要件次第だな
事前に決めた値で問題ないならそうするかもしれんが
まあnullだな

**NAME IS NULL** · 2018/06/09(土) 18:03:57.54

>>370 は未回答という状態が存在しているとしているのなら、未回答という状態のレコードが存在しないとおかしい。

**NAME IS NULL** · 2018/06/09(土) 18:27:03.88

説明不足でした

Q1 性別 1.男 2.女
Q2 参加して 1.よかった 2.どちらとも 3.悪かった
Q3 よかったもの(複数回答可) 1.下着 2.靴 3.帽子
こんなアンケートの結果を
man int, ans1 int, ans2 int, ans3_1 bool, ans3_2 bool, ans3_3 bool
のカラムを持つテーブルに記録しようと思っています
manは1番から自動で割り振りのpkです
ans3_?はTRUE,FALSEで判断して未回答はFALSEと同義になります
問題はans1, ans2の未回答に0かnullのどちらを使うかです

**NAME IS NULL** · 2018/06/09(土) 18:44:19.45

性別に man って...

**NAME IS NULL** · 2018/06/09(土) 18:55:06.75

アンケートで、「答えたくない」って選択を用意しているときがあるな
未回答を避け、こういう選択肢を用意すると言うのも方法だと思う

**NAME IS NULL** · 2018/06/09(土) 18:56:49.19

適当に安価なオブジェクトストアを建ててそのまま保存かな
どうせしばらく経ったら丸ごと捨てるんだろ？

**NAME IS NULL** · 2018/08/11(土) 20:14:14.25

>>332
カラムを_id, fruit_name, date, priceにして、すべての取引を記録すればいいじゃん
最高値と最安値はその都度、SQL文書いて取り出せばよくない？
MaxとMinをいちいち記録する必要ある？
複雑化するだけじゃん。

**NAME IS NULL** · 2018/08/11(土) 20:15:06.24

>>332
最大、最小しかデータ入れられないのか
糞レスしてごめん

**NAME IS NULL** · 2018/08/11(土) 20:48:43.90

糞レス以前に遅レスすぎる

**NAME IS NULL** · 2018/08/12(日) 01:13:04.21

>>380
ものによってはレコード数が多すぎて毎回、最少値、最大値を求めるのはおかしい設計になることもある。

最少値、最大値を別のテーブルで管理していても要件次第ではこちらの方が正しい。

**NAME IS NULL** · 2018/08/18(土) 19:03:47.85

一日毎のレコードで最大最小が確定するんだったら
日替わりのタイミングで取得して別テーブルに登録したいね

**NAME IS NULL** · 2018/08/23(木) 20:53:10.04

ここまで全部アプリケーション設計の話題

**NAME IS NULL** · 2018/08/26(日) 10:09:20.42

普通、設計って運用面も考えるんじゃないの？

**NAME IS NULL** · 2018/08/26(日) 10:12:25.44

>>386
実際は、運用や移行無視の機能要件しか満たさないような設計も多い。
テスト工程の終盤で気付いて火を噴く

**NAME IS NULL** · 2018/08/27(月) 03:53:49.73

DB設計に限れば運用ってバックアップ／リストアぐらいしかないんじゃね
統計情報更新とかフラグメント対策とかの運用をちゃんと設計段階で織り込んでる？

**NAME IS NULL** · 2018/08/27(月) 07:07:36.29

パッチ

**NAME IS NULL** · 2018/08/27(月) 22:01:12.24

>>388
データ容量が見積もりと、過去データ削除方式の設計など考慮すべきは山ほどある。

**NAME IS NULL** · 2018/08/28(火) 06:28:49.33

DBAがいないと漏れがちなこと、ってのが趣旨なんでは
データ容量や保持期間の設計は費用に直結することだからやらないなんてあり得なくて、ちょっと違うと思う

**NAME IS NULL** · 2018/08/30(木) 23:28:39.42

既存のテーブルに後から10カラムほど追加するというのはありなのでしょうか？

最初は別のテーブルにしようと思ったのですが、
1対1の関係であるため、ひとつにまとめた方が良いのではないか？と悩んでいます。

**NAME IS NULL** · 2018/08/30(木) 23:32:31.99

>>392
改修コスト見合いだが
将来にわたり1:1ならいいんじゃね

**NAME IS NULL** · 2018/08/30(木) 23:41:15.81

ありだと思います。よくやってました。

**NAME IS NULL** · 2018/08/30(木) 23:45:46.14

>>393-394
ありがとうございます。分ける方法もよくあるんですね

**NAME IS NULL** · 2018/09/03(月) 03:03:59.17

>>395
どちらかというと分けた方がいい。

あとから追加するものはそのカラムのまとまりに意味があるはずで、別エンティティにすべき。

カラムの追加をし始めるとどんどん追加されて、テーブルがただの入れ物になる。

コボラーさんや頭が古いひとはカラムを追加したがる。

**NAME IS NULL** · 2018/09/03(月) 06:44:35.34

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

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

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