回答編集履歴

3

サンプルデータ追記

2017/07/28 12:40

投稿

miyahan
miyahan

スコア3095

test CHANGED
@@ -44,7 +44,7 @@
44
44
 
45
45
 
46
46
 
47
- 次に必要なデータを正規化によって各テーブルに分割していきます。たとえば「2017/7/28、渋谷将棋会館で行われた、鈴木氏と佐々木氏の対戦:虎王戦決勝トーナメント1回戦で、1手目、先手の鈴木氏は、7六歩」という情報を記録したいとすると、対戦の情報と手の情報でテーブルを分けられそうです。
47
+ 次に必要なデータを正規化によって各テーブルに分割していきます。たとえば「2017/7/28、渋谷将棋会館で行われた、鈴木氏と佐々木氏の対戦:虎王戦決勝トーナメント1回戦で、1手目、先手の鈴木氏は、7六歩」という情報を記録したいとすると、とりあえず対戦の情報と手の情報でテーブルを分けるのがよさそうです。
48
48
 
49
49
 
50
50
 
@@ -56,15 +56,37 @@
56
56
 
57
57
 
58
58
 
59
- | gameid | moveid | player | x | y | piece | action |
59
+ | gameid | moveid | x | y | piece-player | piece-type |
60
60
 
61
- |:-------|:-------|:-------|:--|:--|:------|:-------|
61
+ |:-------|:-------|:--|:--|:-------------|:-----------|
62
62
 
63
+ | 1234 | 1 | 1 | 1 | white | 香車 |
64
+
65
+ | 1234 | 1 | 1 | 3 | white | 歩兵 |
66
+
63
- | 1234 | 1 | black | 7 | 6 | 歩 | 置く |
67
+ | 1234 | 1 | 1 | 7 | black | 歩 |
68
+
69
+ | 1234 | 1 | 1 | 9 | black | 香車 |
70
+
71
+ | ... | ... | . | . | ... | ... |
72
+
73
+ | 1234 | 1 | 9 | 9 | black | 香車 |
64
74
 
65
75
 
66
76
 
77
+ という感じになります。手を記録するパターンなら次のようになりますね。
78
+
79
+
80
+
81
+ | gameid | moveid | player | x-before | y-before | x-after | y-after | piece | action | narite |
82
+
83
+ |:-------|:-------|:-------|:--|:--|:--|:--|:------|:-------|:--------|
84
+
85
+ | 1234 | 1 | black | 7 | 7 | 7 | 6 | 歩兵 | 移動 | no |
86
+
87
+
88
+
67
- という感じになります。さらに開発が進むと「田中氏と田村氏の対戦を検索するとき、先攻:田中/後攻:田村 と 先攻:田村/後攻:田中 と2回検索するのが大変だな…」と感じ、じゃあそこを抜き出して別テーブルにするか…と改善を進めていく感じです。(これも正規化の一種です)
89
+ さらに開発が進むと「田中氏と田村氏の対戦を検索するとき、先攻:田中/後攻:田村 と 先攻:田村/後攻:田中 と2回検索するのが大変だな…」と感じ、じゃあそこを抜き出して別テーブルにするか…と改善を進めていく感じです。(これも正規化の一種です)
68
90
 
69
91
 
70
92
 

2

データベース設計について追記

2017/07/28 12:39

投稿

miyahan
miyahan

スコア3095

test CHANGED
@@ -21,6 +21,14 @@
21
21
 
22
22
 
23
23
  うすうす感じているとは思いますが、これだけ莫大なカラムが必要になるということは**データベースの設計に問題がある**ことを意味します。データベースの不備は後々辛い思いをすることになるので、無理のない設計を心がけたいところです。
24
+
25
+
26
+
27
+ ---
28
+
29
+
30
+
31
+ (追記)
24
32
 
25
33
 
26
34
 
@@ -48,8 +56,6 @@
48
56
 
49
57
 
50
58
 
51
-
52
-
53
59
  | gameid | moveid | player | x | y | piece | action |
54
60
 
55
61
  |:-------|:-------|:-------|:--|:--|:------|:-------|
@@ -58,6 +64,8 @@
58
64
 
59
65
 
60
66
 
67
+ という感じになります。さらに開発が進むと「田中氏と田村氏の対戦を検索するとき、先攻:田中/後攻:田村 と 先攻:田村/後攻:田中 と2回検索するのが大変だな…」と感じ、じゃあそこを抜き出して別テーブルにするか…と改善を進めていく感じです。(これも正規化の一種です)
61
68
 
62
69
 
63
70
 
71
+ がんばってくださいね。

1

DB設計につい

2017/07/28 12:25

投稿

miyahan
miyahan

スコア3095

test CHANGED
@@ -20,4 +20,44 @@
20
20
 
21
21
 
22
22
 
23
- うすうす感じているとは思いますが、これだけ莫大なカラムが必要になるということは**データベースの設計に問題がある**ことを意味します。データベースの不備は後々辛い思いをすることになるので、いまのうちにきちんと勉強し設計を見直すとをおすめします
23
+ うすうす感じているとは思いますが、これだけ莫大なカラムが必要になるということは**データベースの設計に問題がある**ことを意味します。データベースの不備は後々辛い思いをすることになるので、無理のない設計を心がけたいとろです。
24
+
25
+
26
+
27
+ データベースの設計はシステム設計・開発とは別に専門家(DBA: Data Base Administrator)が存在するほど難しく奥深い世界です。「達人に学ぶDB設計 徹底指南書」などの技術本もありますが、最終的には経験や勘が重要になってきます。
28
+
29
+
30
+
31
+ まずはQiitaなどで関連するエントリーを読んで基礎知識を軽くおさえておきましょう。「**正規化**」がキーワードです。そのあとはソフトを作ってみて「あー、こうなってると検索がめんどくさいなー。結果を表示させるときにデータの加工が大変だな。なんかSQL実行が遅いな…」などと感じてきたら、テーブルやカラム(スキーマ)の設計を見直す、といった作業を繰り返していくしかないと思います。
32
+
33
+
34
+
35
+ たとえば今回のテーブルが将棋を扱うものであれば(すいません、知識がないです)、各手を記録するために手ごとに盤面の状態(すべての駒の絶対位置)を記録するのか、生じた事実(どこの位置に何の駒を置いた/取った)を記録するのか、もしくは両方やるのか…によってその後のデータベース設計や、プログラムの作り方が大きく左右されますよね。
36
+
37
+
38
+
39
+ 次に必要なデータを正規化によって各テーブルに分割していきます。たとえば「2017/7/28、渋谷将棋会館で行われた、鈴木氏と佐々木氏の対戦:虎王戦決勝トーナメント1回戦で、1手目、先手の鈴木氏は、7六歩」という情報を記録したいとすると、対戦の情報と手の情報でテーブルを分けられそうです。
40
+
41
+
42
+
43
+ | gameid | date | location | player-black | player-white | game-name |
44
+
45
+ |:-------|:-----------|:------------|:-------------|:-------------|:----------|
46
+
47
+ | 1234 | 2017-07-28 | 渋谷将棋会館 | 鈴木 | 佐々木 | 虎王戦決勝トーナメント1回戦 |
48
+
49
+
50
+
51
+
52
+
53
+ | gameid | moveid | player | x | y | piece | action |
54
+
55
+ |:-------|:-------|:-------|:--|:--|:------|:-------|
56
+
57
+ | 1234 | 1 | black | 7 | 6 | 歩 | 置く |
58
+
59
+
60
+
61
+
62
+
63
+