DB設計を語るスレ 10 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>349
あくまで苦肉の策だということ
手作業で集計値を出すまでに個々のデータは必ずあるのだから、その個々のデータを入れるのが正しいあり方だ
しかし、どうしても最安値・最高値だけ保存してそれ以外は手作業で計算したいという奇特なユーザーのためにこういう手もないことはないと提示しただけ
ちなみにこの最高値・最安値のレコードだけを登録する回避策は厳密には間違いではない
なぜなら最安値の取引実績も最高値の取引実績も実際に存在する事実だからだ
間違いがあるとすれば他にも存在したはずの事実の記録を怠った運用の仕方にある >>351
完璧に定まってる
いつ、何が、幾らで取引された、という事実を単純明快に表している
そして、それぞれの事実を識別するための最もシンプルな手段であるidを導入した
時刻はアイデンティティを示すキーの一部にはならない 速度計を持っているかどうかもわからんのに速度を入力しろとか。 >>352
それは派閥による
セルコは意味的な部分にも踏み込んで正規化としているね >>356
くだらないレスはやめよう
歩いた距離と時間を記録すれば速度を記録したようなものだ
これで速度計は不要になったね
次はなんだ?時計がないってか?
付き合いきれん >>353
> Bを記録する方法はBを直接的に記録するのとAを記録する方法がありうる
だから中途半端な>>332はバカだって言う話な
> それと果物取引実績という名前から最高値・最安値を直接的に記録するテーブルだと解釈するのは無理がある
> まっとうなテーブルじゃないからまっとうな名前をつけられない
>>332に言ってやれよ w >>357
そう?
少なくとも「プログラマのためのSQL」じゃ形式的な正規形についてしか説明していないようだけど。
曰く
「正規形は、データベースで真のデータを破壊したり、偽のデータを作成したりすることがないように
しようというのが目的です。」 >>361
> 言い返せなくなると罵倒する
> ここらで決着かな
ひょっとして「必要もないのに」って言われてる意味がわかってないとか?
てか既に決着してるだろ w 回答ありがとうございました
>>345
>>320さんを参考に
テーブル作ってみたんですが
https://ideone.com/y6urpx
itemテーブルに同じ名前で重複してかきこまれてしまいます。 >>366
取引した日付と商品IDで重複しなくなるから、
その二つを使ってPrimary Keyを指定する。
PRIMARY KEY(`transaction_date`,`items_id`),
#varcharって書くと、サイズ1になるんだっけ? >>367
primary key にすれば自動的にunique制約されるんですね そういうことになるね
それをキーにして何通りも取得できたら
おかしいことになるだろうし 皆さんがアンケートの答えを格納するテーブルを作るとしたら
未回答は、nullを想定しますか?0を想定しますか?
理由も教えてください! It depends on the situation. 任意項目への未回答は空文字か、回答無し値(事前に決めた値)にする 要件次第だな
事前に決めた値で問題ないならそうするかもしれんが
まあnullだな >>370 は未回答という状態が存在しているとしているのなら、未回答という状態のレコードが存在しないとおかしい。 説明不足でした
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のどちらを使うかです アンケートで、「答えたくない」って選択を用意しているときがあるな
未回答を避け、こういう選択肢を用意すると言うのも方法だと思う 適当に安価なオブジェクトストアを建ててそのまま保存かな
どうせしばらく経ったら丸ごと捨てるんだろ? >>332
カラムを_id, fruit_name, date, priceにして、すべての取引を記録すればいいじゃん
最高値と最安値はその都度、SQL文書いて取り出せばよくない?
MaxとMinをいちいち記録する必要ある?
複雑化するだけじゃん。 >>332
最大、最小しかデータ入れられないのか
糞レスしてごめん >>380
ものによってはレコード数が多すぎて毎回、最少値、最大値を求めるのはおかしい設計になることもある。
最少値、最大値を別のテーブルで管理していても要件次第ではこちらの方が正しい。 一日毎のレコードで最大最小が確定するんだったら
日替わりのタイミングで取得して別テーブルに登録したいね >>386
実際は、運用や移行無視の機能要件しか満たさないような設計も多い。
テスト工程の終盤で気付いて火を噴く DB設計に限れば運用ってバックアップ/リストアぐらいしかないんじゃね
統計情報更新とかフラグメント対策とかの運用をちゃんと設計段階で織り込んでる? >>388
データ容量が見積もりと、過去データ削除方式の設計など考慮すべきは山ほどある。 DBAがいないと漏れがちなこと、ってのが趣旨なんでは
データ容量や保持期間の設計は費用に直結することだからやらないなんてあり得なくて、ちょっと違うと思う 既存のテーブルに後から10カラムほど追加するというのはありなのでしょうか?
最初は別のテーブルにしようと思ったのですが、
1対1の関係であるため、ひとつにまとめた方が良いのではないか?と悩んでいます。 >>392
改修コスト見合いだが
将来にわたり1:1ならいいんじゃね >>393-394
ありがとうございます。分ける方法もよくあるんですね >>395
どちらかというと分けた方がいい。
あとから追加するものはそのカラムのまとまりに意味があるはずで、別エンティティにすべき。
カラムの追加をし始めるとどんどん追加されて、テーブルがただの入れ物になる。
コボラーさんや頭が古いひとはカラムを追加したがる。 >>396
まとまりに意味があるからテーブル分けろ?
他に理由ないならバカとしか思えない ただスキルがないだけなのにバカ呼ばわりは少しかわいそうw それぞれが巨象の一部にふれて、
象とはこういうものだと言い合っている絵を
思い浮かべる議論だな >>396
コボラーさんはカラムを後から追加はしません。
基本的に予備領域を割り当てます。
コボラーさんがRDBで設計すると、予備1〜予備10みたいな項目が全てのテーブルに初期装備されます。 >>401
つまらん。コボラーが項目が追加できると知るとどんどん追加する。そしてテーブルの結合を嫌がる。 >>401
JCLでレコード長の数字を弄らんといかんようになるからな w それ以前にテープに格納されてるマスタのレコード長とか変えれんから 小学生相手に威張る中学生、みたいな。叩ける相手がコボラーくらいしかいないんだろう。 列追加は構わんけど処理速度への影響も含めて検討してほしい >>410
レコード長が倍違うテーブルのデータをupdateしたら、updateにかかる時間が倍になるって話
例えば主キー指定のupdate文で1項目だけ値を変更するとして、1件あたりはミリ秒以下でも何百万〜何千万件と積み上げたら明確に差が出る
DBMSによって違いはあるだろうけどね まさかレコード単位でIOかましてるとでも思ってるのか >>411
それは追加したカラムのデータを別の物理ファイルや領域に格納するRDBMS製品の話ではないのか? カラムを追加したら、明らかに処理が遅くなるのなら、同じレコードであってもカラムを飛び飛びで持っている証拠になる。
レコードのデータを連続データとして格納していないRDBMSは、SELECTもINSERTもUPDATEも当然、遅くなる。 分からないんだけど、
連続データなら一挙にできるが
分散していると、一つ一つがバラバラに処理されるってこと? 昔SQL鯖でカラム追加した時に、クラスタインデックスが断片化して酷い目にあったなぁ >>414>>415
SQLServerなんだけどね
カラムを追加したとかではなく元々レコード長が倍違うテーブルで、どっちも主キーはInteger型の一項目だけ、主キー以外のインデックスなんかは削除した状態
この2つのテーブルの一項目だけを更新するのに、これとは別に主キーと更新したい値だけを持つ2カラムのテーブルをカーソルで読み込んで、主キーをwhere条件に1件1件更新する処理を流した結果、時間が倍違った
(個人的な検証なのでカーソル使わずに一括Updateすりゃいいじゃんてのは無しで)
この違いの理由を考えた結果、単純に1ページ辺りのレコード件数が倍違うのが差に出てきたのかなあと思ったわけ
SQLServer特有のことかもだけど、レコード長が大きいテーブルは要注意、ひいてはカラム追加も注意が必要だと自分の中で結論を出した
(もちろん、カラム追加が絶対悪というつもりは毛頭なく、処理次第だと思ってる) 主キーはクラスタ化なのかとか、断片化してないのとか、ページ分割が起こってないのとか
まあ不定要素多すぎて何とも言えんけど
それはそもそもレコード長が違うテーブルの更新時間が違うって話で
カラム追加するかどうかと別な話
ちゃんと比較するなら、カラム追加したときと、別テーブルにカラム持ったばあいの処理で比較しないと >>420
要は最後の1文に書いてくれたことも検討したほうがいいよって言いたかったの
まわりくどくなっちゃってごめん ・ニックネーム
・id・
・パスワード・
・最終ログイン日時
・最後にパスワードを設定した日時
・備考欄
これらのデータを管理する場合どのようなテーブル構成にしたら良いのか本を購入して学びたいのですが
良い本を教えてください。
会員サイト用のデータベースです。 >>422
趣味で作るんならともかく、仕事で作るのにやりがいもへったくれもあるか 私たち日本人の、日本国憲法を改正しましょう。
『憲法改正國民投票法』、でググってみてください。
(へいわ)は、勝ち取るものです。拡散も含め、お願い致します。 イオンみたいな巨大小売で、個人客が買い物した商品なんかの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日で日本全国で百万レコードとか行っちゃいますよね?
何かいい手があるんでしょうか?毎日テーブルを作ってるのかな? >>428
何の為にDBに登録するのか、その目的次第だと思う
小売店での現金販売だとそこまで細かくデータはとってないだろうし
そこまで細かくデータが取れるとすれば通販でクレジット決済したときくらいか >>428
例示のレコードでレコード長40byteくらいだとする
1日100万でも40Mとかだから現代ではそこまででもない 小売店で取れるデータって、POSレジの範囲だぞ
個人を特定可能なデータはとってない
特定可能なポイントカードを使わせれば良いかもだが
すべての客が使う訳じゃないからな >>428
> 1日で日本全国で百万レコードとか行っちゃいますよね?
今時そこら辺に転がってるPCでもヤ楽々処理できるレベル
1億レコード超えたら本気出す 顧客のだけでなく業者からの仕入データだって膨大になるだろうに毎日テーブル作ってたらどうなるんだよ >>428の例で、毎日テーブルを作るとしてさ、
「今年会員IDa01が購入した商品全部抽出して」って言われたらSQL文てどうやるの?テーブルを365個SQLに書かなきゃダメ? 本だと
購入日、性別、年代、書籍コード(ISBNや雑誌コード)、冊数が
届いてたなあ パーティショニングはしてるかもしれんが、テーブル毎日つくるとかないわ ようつべとか、視聴履歴をめっちゃ昔まで遡れるやん?
数億人が毎日見てるんだぜ?考えるとすごくね?しかも検索結果の抽出も早いしどうなってんだ 厚さ0.1mmの新聞紙でも42回折ったら月まで届く高さになる つまり月まで届くほどデータがあっても
検索にかかる時間は0,1mmのデータのたかだか42倍 0.1mmの42倍て4.2mmじゃね?それで月まで届くの? しかし折り方を指定してないからな
蛇腹だとたしかに月までどころか5mmにもならん よってYouTubeの検索速度を再現する事は不可能である YouTube を実際に使っているユーザーがいないんじゃ? YouTube を仮に使ってるユーザーぐらいいるんじゃね? 特殊な炭素素材で水を水素と酸素に分解 ゼビオHDのグループ企業、クロステクノロジーラボが開発 500項目超とかの巨大テーブルいい加減ヤメてほしい >>452
DBMS何使ったらそうなんの?オラコー? ■ このスレッドは過去ログ倉庫に格納されています