itemテーブルに同じ名前で重複してかきこまれてしまいます。 0367NAME IS NULL2018/06/03(日) 18:21:59.24ID:???>>366 取引した日付と商品IDで重複しなくなるから、 その二つを使ってPrimary Keyを指定する。
PRIMARY KEY(`transaction_date`,`items_id`),
#varcharって書くと、サイズ1になるんだっけ? 0368NAME IS NULL2018/06/05(火) 01:29:12.15ID:G6hVbWAV>>367 primary key にすれば自動的にunique制約されるんですね 0369NAME IS NULL2018/06/05(火) 13:48:16.07ID:??? そういうことになるね それをキーにして何通りも取得できたら おかしいことになるだろうし 0370NAME IS NULL2018/06/09(土) 06:56:35.90ID:Icn+Lx+K 皆さんがアンケートの答えを格納するテーブルを作るとしたら 未回答は、nullを想定しますか?0を想定しますか? 理由も教えてください! 0371NAME IS NULL2018/06/09(土) 07:24:58.49ID:??? It depends on the situation. 0372NAME IS NULL2018/06/09(土) 08:20:27.48ID:??? ナイーブに考えると、行なしだろ? 0373NAME IS NULL2018/06/09(土) 10:32:23.91ID:??? 任意項目への未回答は空文字か、回答無し値(事前に決めた値)にする 0374NAME IS NULL2018/06/09(土) 17:01:40.73ID:??? 要件次第だな 事前に決めた値で問題ないならそうするかもしれんが まあnullだな 0375NAME IS NULL2018/06/09(土) 18:03:57.54ID:hcbikbxQ>>370 は未回答という状態が存在しているとしているのなら、未回答という状態のレコードが存在しないとおかしい。 0376NAME IS NULL2018/06/09(土) 18:27:03.88ID:Icn+Lx+K 説明不足でした
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のどちらを使うかです 0377NAME IS NULL2018/06/09(土) 18:44:19.45ID:??? 性別に man って... 0378NAME IS NULL2018/06/09(土) 18:55:06.75ID:??? アンケートで、「答えたくない」って選択を用意しているときがあるな 未回答を避け、こういう選択肢を用意すると言うのも方法だと思う 0379NAME IS NULL2018/06/09(土) 18:56:49.19ID:??? 適当に安価なオブジェクトストアを建ててそのまま保存かな どうせしばらく経ったら丸ごと捨てるんだろ? 0380NAME IS NULL2018/08/11(土) 20:14:14.25ID:HUdhIw+b>>332 カラムを_id, fruit_name, date, priceにして、すべての取引を記録すればいいじゃん 最高値と最安値はその都度、SQL文書いて取り出せばよくない? MaxとMinをいちいち記録する必要ある? 複雑化するだけじゃん。 0381NAME IS NULL2018/08/11(土) 20:15:06.24ID:???>>332 最大、最小しかデータ入れられないのか 糞レスしてごめん 0382NAME IS NULL2018/08/11(土) 20:48:43.90ID:??? 糞レス以前に遅レスすぎる 0383NAME IS NULL2018/08/12(日) 01:13:04.21ID:444bh0X0>>380 ものによってはレコード数が多すぎて毎回、最少値、最大値を求めるのはおかしい設計になることもある。
最少値、最大値を別のテーブルで管理していても要件次第ではこちらの方が正しい。 0384NAME IS NULL2018/08/18(土) 19:03:47.85ID:??? 一日毎のレコードで最大最小が確定するんだったら 日替わりのタイミングで取得して別テーブルに登録したいね 0385NAME IS NULL2018/08/23(木) 20:53:10.04ID:5PrJS+b6 ここまで全部アプリケーション設計の話題 0386NAME IS NULL2018/08/26(日) 10:09:20.42ID:??? 普通、設計って運用面も考えるんじゃないの? 0387NAME IS NULL2018/08/26(日) 10:12:25.44ID:l1qaluN3>>386 実際は、運用や移行無視の機能要件しか満たさないような設計も多い。 テスト工程の終盤で気付いて火を噴く 0388NAME IS NULL2018/08/27(月) 03:53:49.73ID:??? DB設計に限れば運用ってバックアップ/リストアぐらいしかないんじゃね 統計情報更新とかフラグメント対策とかの運用をちゃんと設計段階で織り込んでる? 0389NAME IS NULL2018/08/27(月) 07:07:36.29ID:??? パッチ 0390NAME IS NULL2018/08/27(月) 22:01:12.24ID:Ee+4ykO9>>388 データ容量が見積もりと、過去データ削除方式の設計など考慮すべきは山ほどある。 0391NAME IS NULL2018/08/28(火) 06:28:49.33ID:??? DBAがいないと漏れがちなこと、ってのが趣旨なんでは データ容量や保持期間の設計は費用に直結することだからやらないなんてあり得なくて、ちょっと違うと思う 0392NAME IS NULL2018/08/30(木) 23:28:39.42ID:YS+AC+kz 既存のテーブルに後から10カラムほど追加するというのはありなのでしょうか?
最初は別のテーブルにしようと思ったのですが、 1対1の関係であるため、ひとつにまとめた方が良いのではないか?と悩んでいます。 0393NAME IS NULL2018/08/30(木) 23:32:31.99ID:lHt449yM>>392 改修コスト見合いだが 将来にわたり1:1ならいいんじゃね 0394NAME IS NULL2018/08/30(木) 23:41:15.81ID:??? ありだと思います。よくやってました。 0395NAME IS NULL2018/08/30(木) 23:45:46.14ID:YS+AC+kz>>393-394 ありがとうございます。分ける方法もよくあるんですね 0396NAME IS NULL2018/09/03(月) 03:03:59.17ID:xugX4t13>>395 どちらかというと分けた方がいい。
あとから追加するものはそのカラムのまとまりに意味があるはずで、別エンティティにすべき。
カラムの追加をし始めるとどんどん追加されて、テーブルがただの入れ物になる。
コボラーさんや頭が古いひとはカラムを追加したがる。 0397NAME IS NULL2018/09/03(月) 06:44:35.34ID:???>>396 まとまりに意味があるからテーブル分けろ? 他に理由ないならバカとしか思えない 0398NAME IS NULL2018/09/03(月) 07:49:30.05ID:8k7Ekz6C ただスキルがないだけなのにバカ呼ばわりは少しかわいそうw 0399NAME IS NULL2018/09/03(月) 10:15:56.89ID:??? それぞれが巨象の一部にふれて、 象とはこういうものだと言い合っている絵を 思い浮かべる議論だな 0400NAME IS NULL2018/09/03(月) 20:46:20.70ID:xugX4t13>>399 仏教徒か。仲間だな。 0401NAME IS NULL2018/09/04(火) 19:00:44.56ID:PCCrVc8p>>396 コボラーさんはカラムを後から追加はしません。 基本的に予備領域を割り当てます。 コボラーさんがRDBで設計すると、予備1〜予備10みたいな項目が全てのテーブルに初期装備されます。 0402NAME IS NULL2018/09/04(火) 19:13:28.23ID:NpqdKDu5>>401 つまらん。コボラーが項目が追加できると知るとどんどん追加する。そしてテーブルの結合を嫌がる。 0403NAME IS NULL2018/09/04(火) 20:02:08.75ID:???>>401 JCLでレコード長の数字を弄らんといかんようになるからな w 0404NAME IS NULL2018/09/04(火) 21:09:30.08ID:??? それ以前にテープに格納されてるマスタのレコード長とか変えれんから 0405NAME IS NULL2018/09/05(水) 08:27:53.10ID:1yHvak3l なんでCOBOLの話をしているのか? 0406NAME IS NULL2018/09/05(水) 12:14:38.49ID:sxBfz2nK コボラーだもの 0407NAME IS NULL2018/09/05(水) 21:29:08.15ID:??? 小学生相手に威張る中学生、みたいな。叩ける相手がコボラーくらいしかいないんだろう。 0408NAME IS NULL2018/09/05(水) 23:49:38.89ID:w+IuU8zi ちうがくせいにいぢめられんのかコボラーてw 0409NAME IS NULL2018/09/06(木) 11:24:17.20ID:??? 列追加は構わんけど処理速度への影響も含めて検討してほしい 0410NAME IS NULL2018/09/06(木) 14:27:57.81ID:GycufIMP>>409 ? 0411NAME IS NULL2018/09/06(木) 18:52:24.46ID:???>>410 レコード長が倍違うテーブルのデータをupdateしたら、updateにかかる時間が倍になるって話 例えば主キー指定のupdate文で1項目だけ値を変更するとして、1件あたりはミリ秒以下でも何百万〜何千万件と積み上げたら明確に差が出る DBMSによって違いはあるだろうけどね 0412NAME IS NULL2018/09/06(木) 22:15:09.33ID:??? まさかレコード単位でIOかましてるとでも思ってるのか 0413NAME IS NULL2018/09/06(木) 23:46:24.34ID:??? いや ただ計測したらそうなった 0414NAME IS NULL2018/09/07(金) 19:37:22.26ID:KGOTOtzd>>411 それは追加したカラムのデータを別の物理ファイルや領域に格納するRDBMS製品の話ではないのか? 0415NAME IS NULL2018/09/07(金) 19:58:59.63ID:KGOTOtzd カラムを追加したら、明らかに処理が遅くなるのなら、同じレコードであってもカラムを飛び飛びで持っている証拠になる。
レコードのデータを連続データとして格納していないRDBMSは、SELECTもINSERTもUPDATEも当然、遅くなる。 0416NAME IS NULL2018/09/07(金) 20:01:04.05ID:??? 分からないんだけど、 連続データなら一挙にできるが 分散していると、一つ一つがバラバラに処理されるってこと? 0417NAME IS NULL2018/09/07(金) 21:15:09.98ID:cf7Dw2jW 昔SQL鯖でカラム追加した時に、クラスタインデックスが断片化して酷い目にあったなぁ 0418NAME IS NULL2018/09/09(日) 09:06:55.49ID:???>>414>>415 SQLServerなんだけどね カラムを追加したとかではなく元々レコード長が倍違うテーブルで、どっちも主キーはInteger型の一項目だけ、主キー以外のインデックスなんかは削除した状態 この2つのテーブルの一項目だけを更新するのに、これとは別に主キーと更新したい値だけを持つ2カラムのテーブルをカーソルで読み込んで、主キーをwhere条件に1件1件更新する処理を流した結果、時間が倍違った (個人的な検証なのでカーソル使わずに一括Updateすりゃいいじゃんてのは無しで)
この違いの理由を考えた結果、単純に1ページ辺りのレコード件数が倍違うのが差に出てきたのかなあと思ったわけ SQLServer特有のことかもだけど、レコード長が大きいテーブルは要注意、ひいてはカラム追加も注意が必要だと自分の中で結論を出した (もちろん、カラム追加が絶対悪というつもりは毛頭なく、処理次第だと思ってる) 0419NAME IS NULL2018/09/09(日) 11:14:36.11ID:??? 行ストアだからそんなもんでしょ