回答編集履歴

3

加筆修正

2019/05/21 11:39

投稿

退会済みユーザー
test CHANGED
@@ -3,6 +3,10 @@
3
3
  データ構造の正規化を検討すると良いです。
4
4
 
5
5
  [ER図 リレーションシップを正しく使い分けよう](https://products.sint.co.jp/siob/blog/relationship)
6
+
7
+ Windowsだと[A5:SQL mk-II](https://a5m2.mmatsubara.com/)でER図を描けますし、
8
+
9
+ そのままテーブルの定義(CREATE TABLE文)を起こせたりします。
6
10
 
7
11
 
8
12
 

2

見直し

2019/05/21 11:39

投稿

退会済みユーザー
test CHANGED
@@ -32,6 +32,20 @@
32
32
 
33
33
 
34
34
 
35
+ サブIDのナンバリングが、
36
+
37
+ メインID由来で1から始まる、っていうのは人に見せるためのものにしてしまって、
38
+
39
+ テーブルの中でのユニークキーを別途設けたほうが良いでしょう。
40
+
41
+ それを、別のメインIDとのリレーションのテーブルを設けて
42
+
43
+ グルーピングの助けにするのが良いかと。
44
+
45
+ ![イメージ説明](4869556f60cb02b8723654dabb49d92b.png)
46
+
47
+
48
+
35
49
  また、
36
50
 
37
51
  RDBMSの都合上、格納した順番通り順序が保持されて記録されるわけではなく、

1

見直し

2019/05/21 11:37

投稿

退会済みユーザー
test CHANGED
@@ -14,4 +14,32 @@
14
14
 
15
15
  きれいな設計になりそうな気がします。
16
16
 
17
+ 質問者さんが言うところの
18
+
19
+
20
+
21
+ > サブIDが1のレコードのみのテーブルと、サブIDが2以上のレコードのみのテーブルを個別に作ろうと考えています。
22
+
23
+
24
+
25
+ っていう分け方をしてしまうと、
26
+
27
+ そのサブIDによって参照するテーブルそのものが異なるのは悪手です。
28
+
29
+ 参照するテーブルを切り替えるのが面倒になって
30
+
31
+ すぐにビューを組むことになるんじゃないかと思います。
32
+
33
+
34
+
35
+ また、
36
+
37
+ RDBMSの都合上、格納した順番通り順序が保持されて記録されるわけではなく、
38
+
39
+ ルールを与えない限りランダムな順序で出てくる可能性もあります。
40
+
41
+ ORDER BY句できれいに並べ直した状態で抽出するから格納状態の順序は気にしないものです。
42
+
43
+
44
+
17
45
  (具体例に乏しく、質問文中の説明がアタマに全然入ってこなかったもので、ぬるい回答ですみません。)