回答編集履歴
2
注意書きを追加
test
CHANGED
|
@@ -1,3 +1,13 @@
|
|
|
1
|
+
**回答通りに行って問題が起こったとしても責任は持てません。
|
|
2
|
+
|
|
3
|
+
あくまでも一参考程度に収め、何かあった時に復旧ができるように
|
|
4
|
+
|
|
5
|
+
準備を欠かさないようにしてください。
|
|
6
|
+
|
|
7
|
+
大きな損失が出るのであればその手のプロフェッショナルを雇うべきです。**
|
|
8
|
+
|
|
9
|
+
|
|
10
|
+
|
|
1
11
|
追記された情報を見ていたら案外単純なことなんじゃないかと思ったのですが、
|
|
2
12
|
|
|
3
13
|
もし解釈が間違っていたらご指摘ください。
|
1
用語について追記
test
CHANGED
|
@@ -21,3 +21,107 @@
|
|
|
21
21
|
|
|
22
22
|
|
|
23
23
|
初期レコードを挿入したいのであれば`db:seed`を使えばよいでしょう。
|
|
24
|
+
|
|
25
|
+
|
|
26
|
+
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
[用語について追記]
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
用語による齟齬が発生しそうなのでそのあたりを踏まえて追記します。
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
|
|
39
|
+
### RailsにおけるDB操作について
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
DBの作成や構造など、テーブル操作含めDBにおける操作は基本的にmigrationファイルで行うべきです。
|
|
44
|
+
|
|
45
|
+
ある処理はmigrationファイルでやってある処理はSQLコマンドでやって、のように複数の実行形式があると
|
|
46
|
+
|
|
47
|
+
どれか実行し忘れるだけでバグの原因になります。
|
|
48
|
+
|
|
49
|
+
Railsでは`rails db:migrate`でファイルにある処理を一括して行ってくれるので
|
|
50
|
+
|
|
51
|
+
実行し忘れるというリスクは低いです。
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
|
|
55
|
+
また、Railsには他に初期化データを格納するseedsファイルがあるので、
|
|
56
|
+
|
|
57
|
+
最初のDB構築時に初期化データを`rails db:seed`で実行することができます。
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
|
|
61
|
+
今新規サーバで新しくDB環境を構築し、migrationファイルではなくSQLコマンドでなにか必要な処理したとします。
|
|
62
|
+
|
|
63
|
+
いずれ（新規サーバが壊れたとかで）また別な新規サーバで環境構築をするとまたSQLコマンドを打つことになりますが、
|
|
64
|
+
|
|
65
|
+
そのコマンドは確実に実行されると思いますか？
|
|
66
|
+
|
|
67
|
+
SQLコマンドを打ったが何を打ったかわからない、メモしたファイルが見つからない、そもそも担当者が変わってわからないとか
|
|
68
|
+
|
|
69
|
+
そういった面で実行されないリスクが高まります。
|
|
70
|
+
|
|
71
|
+
|
|
72
|
+
|
|
73
|
+
### 環境によるDB周りについて
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
|
|
77
|
+
一般的にデータベースというとデータベース関連全体を含む広義の言葉を使用していますが、
|
|
78
|
+
|
|
79
|
+
構造は「レコード∈テーブル∈データベース」というようになっていて
|
|
80
|
+
|
|
81
|
+
この構造でいうデータベースはデータの集合を意味する狭義の表現となります。
|
|
82
|
+
|
|
83
|
+
便宜上、この回答内では「DB：広義の意味」、「データベース：狭義の意味」で区別して記載します。
|
|
84
|
+
|
|
85
|
+
|
|
86
|
+
|
|
87
|
+
Railsでは`rails db:create`でデータベースの作成が行われ、環境毎に指定された名前の
|
|
88
|
+
|
|
89
|
+
データベースが作成されます。
|
|
90
|
+
|
|
91
|
+
そして、`rails db:migrate`でテーブル関連の処理が記載されたファイルに従って行われます。
|
|
92
|
+
|
|
93
|
+
このmigrationファイルに記載された内容はどの環境でも同じように実行されますが、
|
|
94
|
+
|
|
95
|
+
それ以外のもの、たとえば運用中のデータ挿入、削除、更新などは環境によって変わります。
|
|
96
|
+
|
|
97
|
+
|
|
98
|
+
|
|
99
|
+
例えばAサーバで作成されたhogeデータベースにhugaというテーブルを作成したとします。
|
|
100
|
+
|
|
101
|
+
これを運用し、ユーザ登録等でデータがどんどん増えていくとしましょう。
|
|
102
|
+
|
|
103
|
+
Bサーバに同じ環境を整えようとしたとき、
|
|
104
|
+
|
|
105
|
+
Bサーバ上にもhogeデータベースが作成され、hugaテーブルがその中に作成されます。
|
|
106
|
+
|
|
107
|
+
AサーバとBサーバでは名前こそ同じデータベースですが、別々の場所にあるものなので
|
|
108
|
+
|
|
109
|
+
AサーバのデータがBサーバのDBの中に入るわけではありません。
|
|
110
|
+
|
|
111
|
+
|
|
112
|
+
|
|
113
|
+
migrationファイルはあくまでも構築するための手順書で、
|
|
114
|
+
|
|
115
|
+
`rails db:migrate`は手順書を元に作り上げるだけなのです。
|
|
116
|
+
|
|
117
|
+
|
|
118
|
+
|
|
119
|
+
### gemについて
|
|
120
|
+
|
|
121
|
+
|
|
122
|
+
|
|
123
|
+
gemはRubyにおけるライブラリです。
|
|
124
|
+
|
|
125
|
+
複雑な機能を使いやすいようまとめたものだと思ってください。
|
|
126
|
+
|
|
127
|
+
コメント中に「Gemを作る」という言葉がありますが、意味合いがおかしくなってしまいますね。
|