DB設計を語るスレ 10 [無断転載禁止]©2ch.net

1NAME IS NULL2017/05/22(月) 16:38:31.52ID:???
語れ

前スレ
DB設計を語るスレ 9
http://echo.2ch.net/test/read.cgi/db/1444733172/

399NAME IS NULL2018/09/03(月) 10:15:56.89ID:???
それぞれが巨象の一部にふれて、
象とはこういうものだと言い合っている絵を
思い浮かべる議論だな

400NAME IS NULL2018/09/03(月) 20:46:20.70ID:xugX4t13
>>399
仏教徒か。仲間だな。

401NAME IS NULL2018/09/04(火) 19:00:44.56ID:PCCrVc8p
>>396
コボラーさんはカラムを後から追加はしません。
基本的に予備領域を割り当てます。
コボラーさんがRDBで設計すると、予備1〜予備10みたいな項目が全てのテーブルに初期装備されます。

402NAME IS NULL2018/09/04(火) 19:13:28.23ID:NpqdKDu5
>>401
つまらん。コボラーが項目が追加できると知るとどんどん追加する。そしてテーブルの結合を嫌がる。

403NAME IS NULL2018/09/04(火) 20:02:08.75ID:???
>>401
JCLでレコード長の数字を弄らんといかんようになるからな w

404NAME IS NULL2018/09/04(火) 21:09:30.08ID:???
それ以前にテープに格納されてるマスタのレコード長とか変えれんから

405NAME IS NULL2018/09/05(水) 08:27:53.10ID:1yHvak3l
なんでCOBOLの話をしているのか?

406NAME IS NULL2018/09/05(水) 12:14:38.49ID:sxBfz2nK
コボラーだもの

407NAME IS NULL2018/09/05(水) 21:29:08.15ID:???
小学生相手に威張る中学生、みたいな。叩ける相手がコボラーくらいしかいないんだろう。

408NAME IS NULL2018/09/05(水) 23:49:38.89ID:w+IuU8zi
ちうがくせいにいぢめられんのかコボラーてw

409NAME IS NULL2018/09/06(木) 11:24:17.20ID:???
列追加は構わんけど処理速度への影響も含めて検討してほしい

410NAME IS NULL2018/09/06(木) 14:27:57.81ID:GycufIMP
>>409

411NAME IS NULL2018/09/06(木) 18:52:24.46ID:???
>>410
レコード長が倍違うテーブルのデータをupdateしたら、updateにかかる時間が倍になるって話
例えば主キー指定のupdate文で1項目だけ値を変更するとして、1件あたりはミリ秒以下でも何百万〜何千万件と積み上げたら明確に差が出る
DBMSによって違いはあるだろうけどね

412NAME IS NULL2018/09/06(木) 22:15:09.33ID:???
まさかレコード単位でIOかましてるとでも思ってるのか

413NAME IS NULL2018/09/06(木) 23:46:24.34ID:???
いや
ただ計測したらそうなった

414NAME IS NULL2018/09/07(金) 19:37:22.26ID:KGOTOtzd
>>411
それは追加したカラムのデータを別の物理ファイルや領域に格納するRDBMS製品の話ではないのか?

415NAME IS NULL2018/09/07(金) 19:58:59.63ID:KGOTOtzd
カラムを追加したら、明らかに処理が遅くなるのなら、同じレコードであってもカラムを飛び飛びで持っている証拠になる。

レコードのデータを連続データとして格納していないRDBMSは、SELECTもINSERTもUPDATEも当然、遅くなる。

416NAME IS NULL2018/09/07(金) 20:01:04.05ID:???
分からないんだけど、
連続データなら一挙にできるが
分散していると、一つ一つがバラバラに処理されるってこと?

417NAME IS NULL2018/09/07(金) 21:15:09.98ID:cf7Dw2jW
昔SQL鯖でカラム追加した時に、クラスタインデックスが断片化して酷い目にあったなぁ

418NAME IS NULL2018/09/09(日) 09:06:55.49ID:???
>>414>>415
SQLServerなんだけどね
カラムを追加したとかではなく元々レコード長が倍違うテーブルで、どっちも主キーはInteger型の一項目だけ、主キー以外のインデックスなんかは削除した状態
この2つのテーブルの一項目だけを更新するのに、これとは別に主キーと更新したい値だけを持つ2カラムのテーブルをカーソルで読み込んで、主キーをwhere条件に1件1件更新する処理を流した結果、時間が倍違った
(個人的な検証なのでカーソル使わずに一括Updateすりゃいいじゃんてのは無しで)

この違いの理由を考えた結果、単純に1ページ辺りのレコード件数が倍違うのが差に出てきたのかなあと思ったわけ
SQLServer特有のことかもだけど、レコード長が大きいテーブルは要注意、ひいてはカラム追加も注意が必要だと自分の中で結論を出した
(もちろん、カラム追加が絶対悪というつもりは毛頭なく、処理次第だと思ってる)

419NAME IS NULL2018/09/09(日) 11:14:36.11ID:???
行ストアだからそんなもんでしょ

420NAME IS NULL2018/09/09(日) 12:57:35.94ID:???
主キーはクラスタ化なのかとか、断片化してないのとか、ページ分割が起こってないのとか
まあ不定要素多すぎて何とも言えんけど

それはそもそもレコード長が違うテーブルの更新時間が違うって話で
カラム追加するかどうかと別な話

ちゃんと比較するなら、カラム追加したときと、別テーブルにカラム持ったばあいの処理で比較しないと

421NAME IS NULL2018/09/10(月) 14:21:33.58ID:???
>>420
要は最後の1文に書いてくれたことも検討したほうがいいよって言いたかったの
まわりくどくなっちゃってごめん

422NAME IS NULL2018/10/06(土) 14:35:50.55ID:Kml7Tt+s
皆さんデータベースを作るやりがいってなんですか?

423NAME IS NULL2018/10/06(土) 16:33:44.55ID:i1VqU+gz
・ニックネーム
・id・
・パスワード・
・最終ログイン日時
・最後にパスワードを設定した日時
・備考欄

これらのデータを管理する場合どのようなテーブル構成にしたら良いのか本を購入して学びたいのですが
良い本を教えてください。
会員サイト用のデータベースです。

424NAME IS NULL2018/10/06(土) 18:20:10.06ID:???
>>422
趣味で作るんならともかく、仕事で作るのにやりがいもへったくれもあるか

425NAME IS NULL2018/10/13(土) 19:44:09.60ID:???

426NAME IS NULL2018/10/14(日) 20:23:24.26ID:???
 私たち日本人の、日本国憲法を改正しましょう。
『憲法改正國民投票法』、でググってみてください。
(へいわ)は、勝ち取るものです。拡散も含め、お願い致します。

427NAME IS NULL2018/10/14(日) 20:53:15.89ID:XnVgDh+Y
>>426
戦争反対!

428NAME IS NULL2018/10/17(水) 23:43:26.92ID:???
イオンみたいな巨大小売で、個人客が買い物した商品なんかの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日で日本全国で百万レコードとか行っちゃいますよね?
何かいい手があるんでしょうか?毎日テーブルを作ってるのかな?

429NAME IS NULL2018/10/17(水) 23:52:23.40ID:???
>>428
何の為にDBに登録するのか、その目的次第だと思う

小売店での現金販売だとそこまで細かくデータはとってないだろうし
そこまで細かくデータが取れるとすれば通販でクレジット決済したときくらいか

430NAME IS NULL2018/10/18(木) 00:21:22.13ID:tCAmet/Z
>>428
例示のレコードでレコード長40byteくらいだとする
1日100万でも40Mとかだから現代ではそこまででもない

431NAME IS NULL2018/10/18(木) 01:28:56.96ID:NAGDWV1s
>>429
取る取る、もっと細かく取るよ。

432NAME IS NULL2018/10/18(木) 01:47:15.31ID:???
小売店で取れるデータって、POSレジの範囲だぞ
個人を特定可能なデータはとってない
特定可能なポイントカードを使わせれば良いかもだが
すべての客が使う訳じゃないからな

433NAME IS NULL2018/10/18(木) 06:59:59.61ID:???
>>428
> 1日で日本全国で百万レコードとか行っちゃいますよね?
今時そこら辺に転がってるPCでもヤ楽々処理できるレベル
1億レコード超えたら本気出す

434NAME IS NULL2018/10/18(木) 07:03:00.50ID:???
顧客のだけでなく業者からの仕入データだって膨大になるだろうに毎日テーブル作ってたらどうなるんだよ

435NAME IS NULL2018/10/18(木) 07:33:05.12ID:???
>>428の例で、毎日テーブルを作るとしてさ、
「今年会員IDa01が購入した商品全部抽出して」って言われたらSQL文てどうやるの?テーブルを365個SQLに書かなきゃダメ?

436NAME IS NULL2018/10/18(木) 16:22:23.06ID:???
本だと
購入日、性別、年代、書籍コード(ISBNや雑誌コード)、冊数が
届いてたなあ

437NAME IS NULL2018/10/18(木) 23:03:46.70ID:???
パーティショニングはしてるかもしれんが、テーブル毎日つくるとかないわ

438NAME IS NULL2018/10/18(木) 23:29:31.96ID:???
ようつべとか、視聴履歴をめっちゃ昔まで遡れるやん?
数億人が毎日見てるんだぜ?考えるとすごくね?しかも検索結果の抽出も早いしどうなってんだ

439NAME IS NULL2018/10/19(金) 03:14:59.08ID:???
超並列とか言ってみる

440NAME IS NULL2018/10/20(土) 17:50:10.77ID:???
厚さ0.1mmの新聞紙でも42回折ったら月まで届く高さになる

441NAME IS NULL2018/10/20(土) 17:51:48.84ID:???
やってみてくれ

442NAME IS NULL2018/10/23(火) 20:01:35.00ID:???
つまり月まで届くほどデータがあっても
検索にかかる時間は0,1mmのデータのたかだか42倍

443NAME IS NULL2018/10/23(火) 22:33:49.87ID:hntOGwbv
0.1mmの42倍て4.2mmじゃね?それで月まで届くの?

444NAME IS NULL2018/10/23(火) 22:45:12.23ID:???
いやそれはおかしい

445NAME IS NULL2018/10/23(火) 22:45:58.51ID:???
0.1mm×2^42

446NAME IS NULL2018/10/24(水) 01:29:31.23ID:???
しかし折り方を指定してないからな
蛇腹だとたしかに月までどころか5mmにもならん

447NAME IS NULL2018/10/24(水) 01:45:22.86ID:???
どういう折り方しても、無理

448NAME IS NULL2018/10/25(木) 03:15:40.01ID:???
よってYouTubeの検索速度を再現する事は不可能である

449NAME IS NULL2018/10/25(木) 09:51:00.34ID:???
YouTube を実際に使っているユーザーがいないんじゃ?

新着レスの表示
レスを投稿する