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

[過去ﾛｸﾞ] DB設計を語るスレ 10 [無断転載禁止]©2ch.net (1002ﾚｽ)
上下前次 1-新
抽出解除ﾚｽ栞

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

33(4): 2017/12/13(水)20:21 ID:id+unZ0U(1) AAS
名簿みたいなデータではPKを何にしたら良いでしょうか？
電話番号だと電話が無い人もいるし。

101(6): 2017/12/22(金)08:14 ID:??? AAS
>>95
例えば、レコードとして実在の個人を表現したいのに氏名しかないから同姓同名の人が
区別できない、なんてのはそもそもシステム設計の失敗。
それを単に連番振れば解決するかのように言う奴はバカだし有害。

有効な自然キーがないから人工キーを振るというなら、例えば同姓同名の二人
(ここでは便宜上AさんBさんとする)に対して、Aさんは1、Bさんは2というように
個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
仕組みも必要。。

158(3): 2017/12/31(日)18:32 ID:??? AAS
例えば同姓同名の人がいたとして
その人から自分の電話番号変わったから変更してって言われても
どちらを更新して良いか分からない（＝人間）
全部書き換えようとする（＝DB）
こんなことが起こる

普通は一意性を確保するために、
社員IDやら学生IDやらマイナンバーやら
他と重ならないキー情報を用意して、
それをPKにしている。

199(3): 2018/01/25(木)17:12 ID:??? AAS
>>196
言いたいことはわかるけど、
本来リレーショナルデータベースにはそうした順序性が存在しない

203(3): 2018/01/25(木)17:25 ID:??? AAS
じゃ、テーブル設計書作ってるときとかphpMyAdminを利用してるときとかなんでも良いです。
順序がないけど順序を視覚化しているツールを使っている時に、
カラム名やデータ型が異なる順番で並んでると気になりませんか？

単に気持ちの問題ならどうでもよくても、仕様書にした場合、
順序がバラバラだとミスや勘違いの原因になりやすいのではないでしょうか？

216(3): 2018/01/25(木)18:54 ID:??? AAS
それこそ無駄じゃないですか？

MySQLに順序変更に関するコマンドがある以上、
私の質問ってそんな的外れじゃないと思うんですけどね
「DBに順序という概念はない」っていう意味はわかりますけども。

222(3): 2018/01/25(木)19:55 ID:??? AAS
返信が前後しますが、>>218さんみたいな意見があれば「やっぱり切なくなりますよね」
って思うだけです。自分も切なくなるから質問したわけですし。
かといってテーブル作り直すレベルまでもとめていません。
何度も書きますが、MySQLだとカラム同士の間に挿入できるわけですから。

ググっても「こうするべき」的な情報もないので質問したわけですが、
よくわからなくなってきました。もう半端な知識で適当に行きます。
みなさん、色々ありがとうございました。

230(3): 2018/01/26(金)13:23 ID:??? AAS
>>225
たとえば不動産のテーブル設計とか、カラム数が増えますからねぇ。
個人的に1対1の関係（必ずJOINする）ならテーブルを分ける必要ないと思います。
それは正規かと違うような。

>>226
会社で順番が重視されるとかはないかと。
ただ個人的に>>203のように思うだけなんで。

>>228
テーブル設計書に追加したカラムはどれか明記してますからね。
それでも確かに末尾に追加した方がわかりやすいとは思います。
省3

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

320(6): 2018/05/31(木)23:07 ID:??? AAS
例えばこんな感じかな
item_id
high_price
low_price
date

他に必要な項目があれば追加

323(4): 2018/06/01(金)11:25 ID:??? AAS
果物取引実績(果物取引実績ID PK, 果物ID NN, 取引年月日 NN, 取引価格 NN)
チェック(取引年月日 = 時間切捨(取引年月日))
チェック(取引価格 >= 0)
インデックス(果物ID, 取引年月日)

select 果物ID, 取引年月日, max(取引価格) 最高値, min(取引価格) 最安値
from 果物取引実績
group by 果物ID, 取引年月日

332(7): 2018/06/02(土)00:54 ID:??? AAS
どうしても日単位の最大最小でしかデータを入れられないなら
insert into 果物取引実績 values
('id1', 'banana', 年月日, 最高値),
('id2', 'banana', 年月日, 最安値)
といった形にすればよろしい
最初からテーブル構造が壊れてると想定外の事態に回避策とりにくい(メモめんどくさいとか手集計めんどくさいとかね)
テーブル構造がまっとうなら回避策も容易に見つかる

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

478(5): 2019/09/01(日)05:17 ID:Kcb9iNar(1) AAS
売上を管理するテーブルを設計したいんですが、
後になって、同じ商品コードに別の商品が割り当てられる事も想定して設計する場合、
売上テーブルには、商品コードと商品名と価格すべてを登録するのが普通でしょうか？

※売り上げに登録する商品は、商品コードと商品名と価格だけで管理すると仮定します。

499(3): 2019/10/18(金)04:25 ID:??? AAS
PHPからデータを入力することを考えているのですが、初心者ゆえ取っ掛かりがわからなくて途方にくれています

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

建造物のデータを入力する時に建造物の国カラムに、国のテーブルからオートコンプリートで入力したい
という場合、オートコンプリート用国候補のデータを"国"テーブルから取得して提示
という流れでいいのでしょうか？
この入力段階では建造物テーブルにリレーション？や結合といった処理で"国"の関連付け考えなくてもいいという感じでしょうか？

591(4): 2020/05/19(火)13:31 ID:FzKBKTy1(1/2) AAS
同じ設計で別の用途に使用したいテーブルがある場合、テーブル名をどうしていますか？

例えばブログの場合、
article 　　→　記事テーブル
category　→　カテゴリーテーブル
article_cateogry　→記事のカテゴリーテーブル

と設計することがあると思います。
ここに「特集」という別のコンテンツを追加したい場合、

special 　　→　特集テーブル
special_category　→　特集カテゴリーテーブル
special_special__cateogry　→特集の特集カテゴリーテーブル
省4

603(5): 2020/05/20(水)02:26 ID:??? AAS
力技で命名するより先に設計見直したほうがいいって言われてるのが理解できないのかな

記事カテゴリー
掲示板カテゴリー
お知らせカテゴリー
特集カテゴリー
クチコミカテゴリー
求人カテゴリー

普通のお客さんならキレるよ

607(7): 2020/05/20(水)17:44 ID:??? AAS
>>606
もしかしてCMS＝既存のCMSを指してますか？
そうでなくて、自作の話なのですが・・。

それにひとつのカテゴリーテーブルで、>>603みたいなのをまとめるのは無理です。

例えば以下のようなカテゴリーが必要だとします。
記事　｜全般、Web制作、システム開発、データベス
掲示板｜パソコン、ニュース、エンタメ
お知らせ｜サービス、イベント、運営会社

記事コンテンツで、掲示板で使用する「パソコン」というカテゴリーはいらないし、
お知らせコンテンツにある、運営会社というカテゴリーもおかしいです。
省11

652(3): 2020/05/27(水)07:37 ID:??? AAS
質問です
csv ファイルを提供されて
数量データが4000なのですが
少数第二位までという4000.00の意味の
400000というデータで提供されます
毎回エクセルで100で割ってからインポートします
また、顧客コードが10桁で
数字の羅列が醜いので
12-3456-7890とハイフンの追加も行ってから
インポートします
省4

784(3): 2021/01/27(水)15:50 ID:??? AAS
QiitaのWeekly Trendで4位に入ってたから読んでみたが・・・
https://qiita.com/abe_masanori/items/1a2b9c1f1069c43237f8

扱ってる題材のレベルが低いのは初心者向けだからいいとしても
こんな問題だらけのデータモデルとユースケース書いて平気な顔してる開発者はやばいよな？

上下前次 1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.319s*