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/25(金) 21:13:08.94

論理削除否定派のヤツが設計したシステム
取引先からの依頼データなど大事なデータ平気でdeleteしてるんだが、そもそも他人が作ったデータを跡形もなく消せて、その消した証拠すら残さないとかシステムとして間違ってる。

**NAME IS NULL** · 2018/05/25(金) 21:15:53.50

削除データの扱い方、議論始めると荒れるんだけど

**NAME IS NULL** · 2018/05/25(金) 21:21:20.27

だけどその議論はいつも、ユーザーデータはみんなで使ってる共有資産であるという重要な視点が抜けてる。

**NAME IS NULL** · 2018/05/25(金) 21:24:01.69

君の個人情報もみんなで共有しよう

**NAME IS NULL** · 2018/05/25(金) 21:26:30.82

そんなゴミはいらん
おまえ一人で共有しとけ

**NAME IS NULL** · 2018/05/25(金) 21:34:37.41

>>273
必要ないからdeleteしてるんでしょ？

**NAME IS NULL** · 2018/05/25(金) 21:54:12.06

>>278
それが必要だったから大トラブル

**NAME IS NULL** · 2018/05/25(金) 22:01:35.26

つまり必要なデータを削除してしまったマヌケを論理削除の問題だと勘違いしてしまったもっとマヌケな>>273
というおはなしやな
少々笑えた

**NAME IS NULL** · 2018/05/25(金) 23:10:40.85

postgresで一切vacuumしないで運用したらいいんじゃね。time machineで任意の時点に戻れるぞ。

**NAME IS NULL** · 2018/05/25(金) 23:17:56.83

>>273
同じテーブルに残す方がわかりにくい。

**NAME IS NULL** · 2018/05/25(金) 23:20:27.43

>>281
実際はどのRDBMSでもそんな簡単な使い方をしていないから、それをやることはほぼない。

**NAME IS NULL** · 2018/05/25(金) 23:25:58.38

具体例で考えた方が良いと思う
例えば商品マスターだと、在庫切れやメーカー廃番でも削除する事はしていない
会員情報の場合だと、会員登録申請、会員情報更新、退会をそのまま反映している
退会の場合は、一定期間保留しその後物理削除している
商品販売時は、販売後にサポートが必要だったりするため、
退会とはリンクせずそのまま販売履歴として残している

**NAME IS NULL** · 2018/05/25(金) 23:47:38.82

>>284
言いたいことは理解できるが、データ量と更新・参照頻度を書かずにものを言っても意味がない。

単にリレーショナルデータベースの知識、SQLの理解が足らないことで論理削除状態にしていることがある。

**NAME IS NULL** · 2018/05/26(土) 00:50:49.12

>>280
制御が不十分で、仕掛中のデータが削除できてしまいデータ不整合となった。
どこから発生したか出元の不明なデータだけが存在する状況で、大混乱。
結局前日のバックアップから発生元のデータをサルベージしたって話・・

**NAME IS NULL** · 2018/05/26(土) 06:48:26.89

>>286
いやそれ削除フラグ云々以前のレベルやろ...

**NAME IS NULL** · 2018/05/26(土) 07:04:47.67

延々と削除フラグの話を続けるんだね w

**NAME IS NULL** · 2018/05/26(土) 08:11:25.72

>>287
削除フラグはともかく、物理削除はダメだろって話。
消しちゃいけない理由は、後付けで増えていくことが多いから、考慮漏れがあると死ねる

**NAME IS NULL** · 2018/05/26(土) 08:32:39.78

制約も知らんアホは黙ってなよ... w

**NAME IS NULL** · 2018/05/26(土) 08:41:20.21

考慮漏れで問題を起こす可能性を考えたらなんでもありだろう。
削除フラグを見落として処理するコードが混入していて大混乱、とかね。

**NAME IS NULL** · 2018/05/26(土) 09:43:20.38

>>291
それでも跡形もなく消えるよりマシ
少なくとも原因はすぐわかる。

**NAME IS NULL** · 2018/05/26(土) 10:04:04.12

面会記録は跡形もなく消します

**NAME IS NULL** · 2018/05/26(土) 19:39:28.98

レコードの削除をしても他のテーブルで保管するのが普通。

同じテーブルにためたがるのは、古めかしいデータそのものがどういう状態かを自ら示すという発想から来ているもの。

**NAME IS NULL** · 2018/05/26(土) 21:36:41.88

>>294
ソース

**NAME IS NULL** · 2018/05/26(土) 21:55:41.58

>>295
集合演算子を知らない。

**NAME IS NULL** · 2018/05/26(土) 22:16:19.76

>>296
何言ってんのこいつｗｗｗ

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

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