data-4404730_640

1: 風吹けば名無し 2023/12/01(金) 18:09:43.35 ID:ycM5zF8m0
例えば営業部門、製菓部門があったとするやろ？んで今後も増える可能性があるとする
この時、部門事に扱う情報が同じなら多少汚くなっても同じデータベースに入れるべきなんか？それとも分けるべきなんか？
分ける場合は新たな部門を作成する時に動的に増やせるようにする方法を教えてくれや


2: 風吹けば名無し 2023/12/01(金) 18:12:35.36 ID:ycM5zF8m0
飲料と製菓のがええか

商品番号,値段,販売日時,部門

こういうのをまとめて管理するんでええんか？ワイ初心者でよぅわからんのや

4: 風吹けば名無し 2023/12/01(金) 18:14:47.33 ID:iL4GQPMg0
おなじのにまとめて部門の情報がある別のテーブルつくれ

8: 風吹けば名無し 2023/12/01(金) 18:16:59.75 ID:ycM5zF8m0
>>4
なるほど
商品のデータベースで製菓部門をカラムに入れといて
↓
製菓データベースで製菓部門の情報を書くってことやな？

3: 風吹けば名無し 2023/12/01(金) 18:14:33.93 ID:Lw1h9YCn0
正規化しない場面があるかって質問でええ？

5: 風吹けば名無し 2023/12/01(金) 18:15:02.11 ID:ycM5zF8m0
>>3
多分そういう事かもしれん

7: 風吹けば名無し 2023/12/01(金) 18:16:45.16 ID:Lw1h9YCn0
>>5
アプリ次第やな
正規化すると開発工数や増える場合もあるからやらない運用もある
例えばソシャゲみたいな速度重視の業界だと基本的に正規化しない

6: 風吹けば名無し 2023/12/01(金) 18:15:50.99 ID:wGsY17pm0
そら絶対一つにまとめるべきや
部門ごとに特殊なデータはその部分だけを切り出して別テーブルにして、使うときにJOINするんや

10: 風吹けば名無し 2023/12/01(金) 18:18:38.00 ID:ycM5zF8m0
>>6
>>7
なるほど
工数とか速度重視の場合はまとめて置いとくだけでええ時もあると...
若干分かってきたで

9: 風吹けば名無し 2023/12/01(金) 18:17:14.39 ID:M5PYKgbd0
「データベースエンジニアさん来てくれんか？」でスレ立ててくれんか？
ワイ組み込みエンジニアには分からん

11: 風吹けば名無し 2023/12/01(金) 18:18:57.22 ID:ycM5zF8m0
>>9
すまん我慢してや🥺

12: 風吹けば名無し 2023/12/01(金) 18:20:49.70 ID:ycM5zF8m0
じゃあレトルト部門増えますよー！！となった時はどうすりゃええんや？新しいレトルトデータベースが必要になるんやろ？
それってエンジニア側で内部を修正するん？
クライアント側で修正する場合レトルト部門ポチッ！でレトルトデータベース作成する時はどうしたらええんや

13: 風吹けば名無し 2023/12/01(金) 18:20:52.27 ID:oi5nnBNO0
分けるべきやろ

14: 風吹けば名無し 2023/12/01(金) 18:21:17.44 ID:ycM5zF8m0
>>12
一応これが本題や！
分け方何となく理解してきたでありがとう

20: 風吹けば名無し 2023/12/01(金) 18:25:36.95 ID:wGsY17pm0
>>12
部門マスタというテーブルを用意するんや
部門をユーザーが登録できるようにして部門番号001は営業部門、002は製菓部門としておくンゴ
ユーザーが新たに003にレトルト部門を追加したらみっつめの部門ができるンゴ
他のテーブルはすべて部門名やなくて「部門番号」で串刺しにして管理するんやで

23: 風吹けば名無し 2023/12/01(金) 18:30:29.21 ID:ycM5zF8m0
>>20
あぁ！完全に理解したで
部門のテーブルの部門番号(部門テーブル)

商品の部門番号(商品テーブル)

ということか！！
ほんならデータベースって沢山作らんでええものなんやな
テーブルとごちゃ混ぜになっとった

15: 風吹けば名無し 2023/12/01(金) 18:24:09.80 ID:e2oIP2uP0
もしやテーブルとデータベースをごっちゃにしているのか？

17: 風吹けば名無し 2023/12/01(金) 18:24:49.72 ID:ycM5zF8m0
>>15
それや！！！
正に今勘違いしとった

16: 風吹けば名無し 2023/12/01(金) 18:24:29.17 ID:Itcv/i7fd
RDBMSなら分ける、ODBMSならどうでもええんでね？
ワイODBMS使ったことないからようわからんけど

18: 風吹けば名無し 2023/12/01(金) 18:25:09.71 ID:ycM5zF8m0
>>16
なんや管理システムで変わるんか

22: 風吹けば名無し 2023/12/01(金) 18:30:13.87 ID:Itcv/i7fd
>>18
何のDBMS採用してるのか知らんけど、リレーショナルならわけない意味は全くない

19: 風吹けば名無し 2023/12/01(金) 18:25:31.37 ID:+yq7oDIw0
普通[部門id][部門名]……みたいな部門テーブル作って、
商品テーブルは[商品id][商品名][JANコード][値段][販売日時][部門id]……みたいにするもんちゃう

21: 風吹けば名無し 2023/12/01(金) 18:28:30.38 ID:ycM5zF8m0
>>19
そういう事か

24: 風吹けば名無し 2023/12/01(金) 18:31:31.71 ID:cwCrSvAC0
部門マスタと情報テーブルをユニークキーで紐付けるんが一般的やけど特定の部門だけバカみたいにデータ多いとかなら分けるのもありやね

25: 風吹けば名無し 2023/12/01(金) 18:33:07.01 ID:ycM5zF8m0
早速ワイ自作のお買い物アプリに取り掛かろうと思うわ
みんなホンマにありがとう🥺
>>24
ほー
確かに情報多いと全部アクセスして確かめなアカンもんな
多い時は分けて商品情報テーブル2に置くみたいなことなんやろか

引用元: https://eagle.5ch.net/test/read.cgi/livejupiter/1701421783/


達人に学ぶDB設計 徹底指南書
達人に学ぶDB設計 徹底指南書
posted with AmaQuick at 2023.12.02
ミック(著)
(2012-03-15T00:00:00.000Z)
5つ星のうち4.4
Amazon.co.jpで詳細を見る
タグ ：
#システム開発
#ITエンジニア
#データベース