回答編集履歴
3
サンプルデータ追記
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 |
|
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
|
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
|
-
|
89
|
+
さらに開発が進むと「田中氏と田村氏の対戦を検索するとき、先攻:田中/後攻:田村 と 先攻:田村/後攻:田中 と2回検索するのが大変だな…」と感じ、じゃあそこを抜き出して別テーブルにするか…と改善を進めていく感じです。(これも正規化の一種です)
|
68
90
|
|
69
91
|
|
70
92
|
|
2
データベース設計について追記
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設計につい
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
|
+
|