トップページ⇒DB＠2ch掲示板
1002コメント323KB
DB設計を語るスレ 10 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
0429NAME IS NULL
垢版 |
2018/10/17(水) 23:52:23.40ID:???
>>428
何の為にDBに登録するのか、その目的次第だと思う

小売店での現金販売だとそこまで細かくデータはとってないだろうし
そこまで細かくデータが取れるとすれば通販でクレジット決済したときくらいか
0430NAME IS NULL
垢版 |
2018/10/18(木) 00:21:22.13ID:tCAmet/Z
>>428
例示のレコードでレコード長40byteくらいだとする
1日100万でも40Mとかだから現代ではそこまででもない
0431NAME IS NULL
垢版 |
2018/10/18(木) 01:28:56.96ID:NAGDWV1s
>>429
取る取る、もっと細かく取るよ。
0432NAME IS NULL
垢版 |
2018/10/18(木) 01:47:15.31ID:???
小売店で取れるデータって、POSレジの範囲だぞ
個人を特定可能なデータはとってない
特定可能なポイントカードを使わせれば良いかもだが
すべての客が使う訳じゃないからな
0433NAME IS NULL
垢版 |
2018/10/18(木) 06:59:59.61ID:???
>>428
> 1日で日本全国で百万レコードとか行っちゃいますよね？
今時そこら辺に転がってるPCでもヤ楽々処理できるレベル
１億レコード超えたら本気出す
0434NAME IS NULL
垢版 |
2018/10/18(木) 07:03:00.50ID:???
顧客のだけでなく業者からの仕入データだって膨大になるだろうに毎日テーブル作ってたらどうなるんだよ
0435NAME IS NULL
垢版 |
2018/10/18(木) 07:33:05.12ID:???
>>428の例で、毎日テーブルを作るとしてさ、
「今年会員IDa01が購入した商品全部抽出して」って言われたらSQL文てどうやるの？テーブルを365個SQLに書かなきゃダメ？
0436NAME IS NULL
垢版 |
2018/10/18(木) 16:22:23.06ID:???
本だと
購入日、性別、年代、書籍コード(ISBNや雑誌コード)、冊数が
届いてたなあ
0437NAME IS NULL
垢版 |
2018/10/18(木) 23:03:46.70ID:???
パーティショニングはしてるかもしれんが、テーブル毎日つくるとかないわ
0438NAME IS NULL
垢版 |
2018/10/18(木) 23:29:31.96ID:???
ようつべとか、視聴履歴をめっちゃ昔まで遡れるやん？
数億人が毎日見てるんだぜ？考えるとすごくね？しかも検索結果の抽出も早いしどうなってんだ
0439NAME IS NULL
垢版 |
2018/10/19(金) 03:14:59.08ID:???
超並列とか言ってみる
0440NAME IS NULL
垢版 |
2018/10/20(土) 17:50:10.77ID:???
厚さ0.1mmの新聞紙でも42回折ったら月まで届く高さになる
0442NAME IS NULL
垢版 |
2018/10/23(火) 20:01:35.00ID:???
つまり月まで届くほどデータがあっても
検索にかかる時間は0,1mmのデータのたかだか４２倍
0443NAME IS NULL
垢版 |
2018/10/23(火) 22:33:49.87ID:hntOGwbv
0.1mmの42倍て4.2mmじゃね？それで月まで届くの？
0444NAME IS NULL
垢版 |
2018/10/23(火) 22:45:12.23ID:???
いやそれはおかしい
0446NAME IS NULL
垢版 |
2018/10/24(水) 01:29:31.23ID:???
しかし折り方を指定してないからな
蛇腹だとたしかに月までどころか5mmにもならん
0447NAME IS NULL
垢版 |
2018/10/24(水) 01:45:22.86ID:???
どういう折り方しても、無理
0448NAME IS NULL
垢版 |
2018/10/25(木) 03:15:40.01ID:???
よってYouTubeの検索速度を再現する事は不可能である
0449NAME IS NULL
垢版 |
2018/10/25(木) 09:51:00.34ID:???
YouTube を実際に使っているユーザーがいないんじゃ？
0450NAME IS NULL
垢版 |
2018/12/13(木) 23:16:46.44ID:Ht+aqMlR
YouTube を仮に使ってるユーザーぐらいいるんじゃね？
0451NAME IS NULL
垢版 |
2018/12/26(水) 10:07:27.12ID:IDBXTEXd
特殊な炭素素材で水を水素と酸素に分解　ゼビオＨＤのグループ企業、クロステクノロジーラボが開発
0452NAME IS NULL
垢版 |
2019/03/20(水) 08:24:10.88ID:???
500項目超とかの巨大テーブルいい加減ヤメてほしい
0453NAME IS NULL
垢版 |
2019/03/30(土) 17:46:10.62ID:???
>>452
DBMS何使ったらそうなんの？オラコー？
0454NAME IS NULL
垢版 |
2019/03/30(土) 17:52:56.67ID:klkn0vtv
紙の業務の置き換えで
10明細x50の伝票！あと10年は変更ありません！
とかだとよくやる。官公庁だあとありがち。
正規化するといちいちJOIN書かないといかんし
0455NAME IS NULL
垢版 |
2019/03/30(土) 19:41:39.53ID:???
>>452
見たのは確かOracle
項目多過ぎでSQLが実行できない
0456NAME IS NULL
垢版 |
2019/03/30(土) 22:37:17.45ID:???
COBOLで書かれたような奴の移植ならよくある
0457NAME IS NULL
垢版 |
2019/05/31(金) 20:09:56.83ID:h9fg3gjJ
主キーをサロゲートキー(serial)にするか、複合カラムの組み合わせでUNIQUE制約をつけて主キーっぽく使うかで悩んでいます。
問題なのが、このテーブルはレコードを削除した後、復活(再度、新規登録)させる必要が出てくる可能性があることです。
その場合、復活させた時に番号が変わるserialを主キーにするのは、ありえないですよね？
0458NAME IS NULL
垢版 |
2019/05/31(金) 20:48:12.74ID:???
そのDBがserial値の明示的挿入を許して、それが滅多に起きないんならなくはないんじゃね

それ以前におれなら復活必要なら論理削除にしとくが
0459NAME IS NULL
垢版 |
2019/05/31(金) 23:33:17.50ID:???
データレコード削除してもサロゲートキーのマスター残しておけば問題ないんでないの。
0460NAME IS NULL
垢版 |
2019/06/04(火) 20:14:47.94ID:???
サロゲートキーのマスターとは？

ここで言ってるserialってのは、システム側で管理して勝手に数値入れてくれるものだと思うが
0461NAME IS NULL
垢版 |
2019/06/04(火) 20:52:02.44ID:???
単なるserial;はふつうサロゲートキーとは言わんだろう。
>>457のように一意性を保証する複合主キーが存在したうえでその代理とするのがサロゲートキー。
んだから元の複合主キーとserialからなるのがマスターだしそれが自動採番されることは矛盾しない。
0462NAME IS NULL
垢版 |
2019/06/04(火) 21:03:46.49ID:???
で、データレコード削除しても残るサロゲートキーのマスターって何？って話だが

自動採番（システム管理）される値をサロゲートキーにするって前提じゃないの？
0463NAME IS NULL
垢版 |
2019/06/04(火) 21:33:06.85ID:???
だから複合主キーとサロゲートキーの対応表だよ。そう書いたつもりだったが。
>>457のようにデータ再投入時にサロゲートキーの値が変わるのを防ぎたいなら
そういうマスターを残しておけばいいという話。
採番が自動か手動かはこの際関係ない。
0464NAME IS NULL
垢版 |
2019/06/05(水) 00:34:03.47ID:???
>>463
そういうマスターを残すには手動でそういうマスターを作らないとダメなわけで
前提を合わす気がないならちゃんとそういっとかないと議論にならん
0465NAME IS NULL
垢版 |
2019/06/05(水) 00:38:31.46ID:???
serialを変えたくないってことは、
その様な使い方を別なところでしているんじゃないかな
ログとか履歴とか
0466NAME IS NULL
垢版 |
2019/06/05(水) 08:10:00.40ID:???
>>464
既に何度も書いているが、そのマスターのサロゲートキーはserialで自動採番して全然問題ないんだが？

あるいは、もともとデータテーブルが1テーブルだったものをマスターテーブルと分離したことを言っているなら
そりゃ当たり前だ。そう提案したんだからな。
0467NAME IS NULL
垢版 |
2019/06/26(水) 12:08:55.23ID:???
大阪市は2019年6月24日、6月7日から翌8日にかけて発生した基幹系システムの障害に
ついて、原因を特定したと明らかにした。米オラクル（Oracle）のデータベース（DB）ソフト
「Oracle Database」のバグが原因だった。

https://egg.5ch.net/test/read.cgi/bizplus/1561468154/
0468NAME IS NULL
垢版 |
2019/06/26(水) 12:32:28.72ID:???
やっぱ脱Oracleだな
ろくに保守サポートされないんだから有料契約の意味がない
0469NAME IS NULL
垢版 |
2019/06/26(水) 19:39:47.63ID:???
でも金で解決してくれるサポートがなけりゃ、問題がDBMS側にあることを
突き止めることすら自前でやらなきゃならんのだぜ。
0470NAME IS NULL
垢版 |
2019/06/26(水) 19:52:43.63ID:???
突き止めることに意味がないからな

責任転嫁のための作業であって
復旧にはどのみち問い合わせじゃ間に合わん
0471NAME IS NULL
垢版 |
2019/06/26(水) 20:14:47.85ID:???
原因がわからなきゃ対策のとりようもないだろう。
「たまたまエラーになったけど原因がわからないからまた起きたらゴメンね。」で済むような仕事ならいいが。
0472NAME IS NULL
垢版 |
2019/06/27(木) 18:25:28.42ID:???
オラクルは、問題がDBMSにあることをつきとめるんじゃなくて、その問題をまず認めてもらうのにサポート窓口が必要なんだよ

あとは直ればラッキーぐらい
0473NAME IS NULL
垢版 |
2019/07/14(日) 19:52:47.78ID:???
> 大阪市で住民票などの証明書発行業務を担う基幹システムが停止。復旧まで21時間を要し、
> 8000件近い証明書発行業務に影響が及んだ。原因はOracle Databaseのクラスタ機能に潜む
> バグだった。ネットワークの不調をきっかけにシステムが停止し、再起動もできなくなった。
> 米オラクルはバグの存在を把握しながら対外開示をしていなかったとみられる。

https://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020600011/070200035/
0474NAME IS NULL
垢版 |
2019/07/14(日) 20:10:01.55ID:???
Oracleに金払う意味あるぅ？
0475NAME IS NULL
垢版 |
2019/07/15(月) 19:18:49.04ID:???
それゆえMySQLとかPostgreSQL移行が進んでる
0477NAME IS NULL
垢版 |
2019/08/21(水) 20:28:50.39ID:???
デシジョンテーブルのつくりかたがわからん
値の組み合わせ全部入れるもんなの？

null値はすべての検索値にマッチとかルール決めて行数減らしたけど
わけわかめになった
0478NAME IS NULL
垢版 |
2019/09/01(日) 05:17:00.26ID:Kcb9iNar
売上を管理するテーブルを設計したいんですが、
後になって、同じ商品コードに別の商品が割り当てられる事も想定して設計する場合、
売上テーブルには、商品コードと商品名と価格すべてを登録するのが普通でしょうか？

※売り上げに登録する商品は、商品コードと商品名と価格だけで管理すると仮定します。
0479NAME IS NULL
垢版 |
2019/09/01(日) 06:36:54.70ID:???
>>478
その意味のない商品コードとやらで何をしたいんだ？
商品名と価格だけでいいだろ
0480NAME IS NULL
垢版 |
2019/09/01(日) 09:57:23.82ID:e+zeE2vd
>>478
商品マスタに有効期間を作るのが定石かなあ
ついでに言うと当時の単価もマスタ側で
売り上げは数量かなあ
（集計用に金額持たせることはある）
あと消費税の扱いをどうするかとか考えておいたほうがいい
0481NAME IS NULL
垢版 |
2019/09/01(日) 16:19:32.45ID:???
>>478
自分ならというか自分が作ったシステムの売上データは個数、単価、価格などを保持してる
マスタから参照するのはコードと商品名ぐらい
マスタのコードは別の商品に変わる可能性があるなら売上データと商品マスタを結合するキーは
商品コードでなく商品マスタのサロゲートキー
0482NAME IS NULL
垢版 |
2019/09/01(日) 16:38:47.41ID:???
>同じ商品コードに別の商品が割り当てられる事も想定して

これがどういう状況を表しているのかはっきりさせないと設計も決められないだろ。
少なくとも「商品コード」で「商品」を特定できないことは読み取れるが、じゃあ
「商品コード」と「商品名」であれば特定できるのかそれともそうじゃないのか。
できるなら>>478のままでいいが、できないならばそれを特定できる情報を
追加しなければならない。
0483NAME IS NULL
垢版 |
2019/09/01(日) 16:51:19.34ID:???
商品名や容量が変わるなんてのはよくあること
0484NAME IS NULL
垢版 |
2019/09/01(日) 17:30:57.16ID:???
同じ商品コードを別の商品に割り当てるって言うんだから、ある商品の商品名を
変更するって話とは全然違うわな。
0485NAME IS NULL
垢版 |
2019/09/01(日) 17:43:49.61ID:???
商品コードが一意にならないって理解しにくいんだが
商品コードを仕入れ先の企業が決めてくるって事？
0486NAME IS NULL
垢版 |
2019/09/01(日) 17:54:03.12ID:???
おそらく現実の問題ではなくて、>>478が深く考えないで書いた脳内想定だと思う。
0487NAME IS NULL
垢版 |
2019/09/02(月) 04:29:38.29ID:???
現実的に、商品コードが一意にならないような要求をする客はいるぞ

もし本当に
>売り上げに登録する商品は、商品コードと商品名と価格だけで管理する
のならば、全情報コピーでいいだろ
現実的にはそんな単純な管理条件にはならんけどな
0488NAME IS NULL
垢版 |
2019/09/02(月) 12:28:21.25ID:???
>>487
> 現実的に、商品コードが一意にならないような要求をする客はいるぞ
そりゃいるだろうよ
だから外部とやり取りするためのコードと内部で処理するためのコードは別に持ったりする
0489NAME IS NULL
垢版 |
2019/09/02(月) 15:56:14.03ID:???
横着して客が提示した項目だけでまかなおうとするからコケル
0490NAME IS NULL
垢版 |
2019/09/20(金) 22:43:01.69ID:isalmAv1
>>467
ラックに限らずクラスタリングってもしもの時のバックアップとしては全く信用できない。
基本的に運が良ければダウン時間が短く済むかも程度で考えて、データのみ同期させる予備機もっとかないと。
0491NAME IS NULL
垢版 |
2019/10/13(日) 18:20:24.07ID:???
カラムに日本語使わないほうがいい
でもPHPでカラムを見ながら弄りたい
PHPやらhtmlでいちいち書くのは面倒くさい
ってんで、カラムの名前の日本語対応データだけもったtable作る
ってのは変ですか？
0492NAME IS NULL
垢版 |
2019/10/15(火) 01:36:43.91ID:???
日本語っていうか、論理名を物理名とは別に持って管理するのは珍しくない
0493NAME IS NULL
垢版 |
2019/10/15(火) 16:59:26.48ID:???
>>492
ありがとうございます
論理名 物理名というのですね
参考になる文献が結構出てきて助かりました
0494NAME IS NULL
垢版 |
2019/10/16(水) 07:52:35.26ID:???
多少長くなっても意味の通じるカラム名で管理した方が楽かな
0495NAME IS NULL
垢版 |
2019/10/16(水) 19:46:46.29ID:vHJKi6he
>>493
項目名が頻繁に変わるという仕様が本当に必要なのか考えた方がいい。
0496NAME IS NULL
垢版 |
2019/10/17(木) 01:46:16.06ID:???
どこから項目名が頻繁に変わるという仕様を導き出したんだ
0497NAME IS NULL
垢版 |
2019/10/17(木) 06:45:02.27ID:???
まあ強いて言えばわざわざ
> カラムの名前の日本語対応データだけもったtable作る
ってところじゃね？
0498NAME IS NULL
垢版 |
2019/10/17(木) 23:46:22.91ID:/2joG6dP
お腹がすいていませんか?
ウーバーイーツの利用者が初めての方は eats-5kqyfp のプロモーションコードを使うと、#Uber Eats の初回注文が ￥1,000 割引になります。https://t.co/Wxur8AeoEf 👀
Rock54: Caution(BBR-MD5:b73a9cd27f0065c395082e3925dacf01)
0499NAME IS NULL
垢版 |
2019/10/18(金) 04:25:29.95ID:???
PHPからデータを入力することを考えているのですが、初心者ゆえ取っ掛かりがわからなくて途方にくれています

例えば、
歴史的建造物のテーブルと
国のテーブルが有るとします

建造物のデータを入力する時に建造物の国カラムに、国のテーブルからオートコンプリートで入力したい
という場合、オートコンプリート用国候補のデータを"国"テーブルから取得して提示
という流れでいいのでしょうか？
この入力段階では建造物テーブルにリレーション？や結合といった処理で"国"の関連付け考えなくてもいいという感じでしょうか？
0501NAME IS NULL
垢版 |
2019/10/18(金) 19:29:58.26ID:d6MIxLxf
>>499
建造物情報と国情報が紐付いてないのに、なぜ「オートコンプリート」という言葉が出てくるのか？
0502NAME IS NULL
垢版 |
2019/10/18(金) 21:21:09.59ID:???
キー入力するんじゃねえの？
0503NAME IS NULL
垢版 |
2019/10/20(日) 20:29:56.45ID:???
つか、建物入力して、国を絞るのか？
法隆寺は日本にしかないだろうに

国を入力したら、建物のリストを候補にだすってんなら、国と建物の紐づけが必要
0504NAME IS NULL
垢版 |
2019/10/20(日) 20:53:49.69ID:???
法隆寺のデータをこれから入力しようって時に紐付けデータが先に存在しているわけなかろう。
0505NAME IS NULL
垢版 |
2019/10/20(日) 21:37:50.26ID:???
オートコンプリート用国候補のデータを"国"テーブルから取得して
0506NAME IS NULL
垢版 |
2019/10/22(火) 21:34:40.81ID:???
すでに歴史的建造物のテーブル（にレコード）があるって前提ではないのか
0507NAME IS NULL
垢版 |
2019/10/22(火) 21:43:02.01ID:???
＞オートコンプリートとは、ユーザーによるキーボード入力履歴を活用して、
＞入力操作の軽減を図る機能の一つである。

＞オートコンプリートに対応したソフトでは、ユーザーが入力したい言葉の
＞冒頭の文字を入れると、入力履歴の中から冒頭の文字が一致するものを
＞候補として一覧で表示する。候補は、文字を入力していくごとに絞り込まれ、
＞その一覧の中に入力したい言葉があれば、ユーザーは残りの文字を入力
＞することなく、一覧から選ぶだけで入力が完了する。

こういうことなんじゃ？
0508NAME IS NULL
垢版 |
2019/10/22(火) 22:57:39.65ID:???
>>501
>>503
>>506

>建造物のデータを入力する時に建造物の国カラムに、国のテーブルからオートコンプリートで入力したい
0509NAME IS NULL
垢版 |
2019/10/23(水) 09:25:30.42ID:CtOyw4yf
>>508
だからどうしてそんな変なことを言っているのか？
0510NAME IS NULL
垢版 |
2019/10/23(水) 15:59:50.08ID:???
入力者の作業が簡単になるからじゃね？
0512NAME IS NULL
垢版 |
2019/10/23(水) 19:45:44.83ID:???
変なことっていうのは違うな
誰でも考えつくことだし
0513NAME IS NULL
垢版 |
2019/10/23(水) 20:18:26.30ID:???
>>499
・国名入力欄
・建造物名入力欄

があって、「国名入力欄に入力する際に国名をオートコンプリートしたい
（“に”って入力したら“日本”が候補にでてくる）」って認識でOk？

それとも「国名を入力したら建造物名入力欄の候補が絞り込まれる」ようにしたいってことを言ってる？
0514NAME IS NULL
垢版 |
2019/10/23(水) 20:43:21.25ID:???
>国のテーブルからオートコンプリート
>オートコンプリート用国候補のデータ

こう書いてあるんだから普通わかるだろ。
0515NAME IS NULL
垢版 |
2019/10/23(水) 22:00:30.83ID:CtOyw4yf
建造物と何ら関係なかったな
0516NAME IS NULL
垢版 |
2019/11/04(月) 00:05:11.75ID:???
年取ると、書いてないことを読んだり、
書いてあることを読めなかったりします
私もそうだから、よく分かります
0517NAME IS NULL
垢版 |
2019/11/22(金) 17:14:44.84ID:kYOxBcYU
「利用回数が制限されているユーザーとされていないユーザーがいる」
という条件だとします。

このとき、finiteカラム（int）が99であれば、99回利用できるとします。
利用するごとに1ずつ減っていくイメージです。

では、「無制限に利用できる」を表現したい場合、finiteカラムでできるのでしょうか？
それとも、infiniteカラムなどを追加し、そこが1（有効）のユーザーは
無制限に利用できるというような、フラグ的な使い方をすればいいのでしょうか？

どう設計するのがベストプラクティスかわかりません。教えて下さい。
0518NAME IS NULL
垢版 |
2019/11/22(金) 17:19:37.29ID:???
制限ユーザーかどうかを識別するカラムを追加か、
finiteが -1 なら無制限ユーザーとする、とか
0519NAME IS NULL
垢版 |
2019/11/22(金) 19:58:57.97ID:???
ベストプラクティスなんて、アプリの設計方法次第で変わるわ

とりあえずfiniteにNULLでいいだろ
NULLから1引いてもNULLだからな
0521517
垢版 |
2019/11/22(金) 21:24:33.78ID:???
>>518
なるほど。-1って考えはありませんでした。
聞いたことありませんが良さそうですね。

>>519
int型のカラムにNULL入れちゃうのは抵抗があります・・・
0522NAME IS NULL
垢版 |
2019/11/22(金) 21:49:00.10ID:???
個人的には、利用上限と利用回数で項目分けたい
あとで利用回数調べたりしがちだから

基本、利用上限＞利用回数で判定して
運用上、アホみたいに利用されないなら
利用上限をintのMAX_VAlUEとかにしとけば
実質無制限になるし、同じ判定で済む
0523517
垢版 |
2019/11/22(金) 23:00:06.56ID:???
>>522
なるほど。その方が汎用性がありますね。

利用上限も制限がある場合は1〜99まで
無制限なら999とかにしておけばわかりやすいです。
-1だとorderの並び替えも難しいですが、999ならできますし
0525NAME IS NULL
垢版 |
2019/11/23(土) 21:33:05.59ID:???
finiteというカラム名がなんかアレ
0526NAME IS NULL
垢版 |
2019/11/26(火) 17:10:04.54ID:???
DB設計をどうするかと、データ取得はどういう順にしたいかは別の問題
0527NAME IS NULL
垢版 |
2019/11/28(木) 13:21:29.42ID:j6IzqXGN
モンスターマップのhtmlのデータをDB化しようとすると，
どんなスキーマにしておくと後々使えるでしょうかね．
0528NAME IS NULL
垢版 |
2019/11/28(木) 20:58:42.03ID:???
Ｃreate Ｔable MonsterMap (
HTML ｖarchar(max);
);
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況