回答編集履歴
1
あ
test
CHANGED
@@ -8,9 +8,9 @@
|
|
8
8
|
|
9
9
|
|
10
10
|
|
11
|
-
会社と部署という、
|
11
|
+
会社と部署という、包含関係はありそうだけれど全く違う構造になりそうなmodelを例に出し
|
12
12
|
|
13
|
-
|
13
|
+
包含関係がさらに追加された場合と言われてもOrlofsky様の回答しか引き出されないと思います。
|
14
14
|
|
15
15
|
|
16
16
|
|
@@ -22,7 +22,7 @@
|
|
22
22
|
|
23
23
|
また、Railsはしっかりとレールに乗った構築をしていれば
|
24
24
|
|
25
|
-
テーブル構造
|
25
|
+
テーブルの構造に変更があっても、Railsの変更は最小限で済みます。
|
26
26
|
|
27
27
|
なので、設計はベターで行って、運用しながらベストを探る(案ずるより生むが易し)がRailsの基本となります。
|
28
28
|
|
@@ -32,12 +32,14 @@
|
|
32
32
|
|
33
33
|
もしその親子関係があるモデルというのが大グループ中グループ小グループみたいな感じでmodel(class)としての
|
34
34
|
|
35
|
-
|
35
|
+
機能がほぼ同じで、さらに細目グループが追加される可能性や小グループと中グループが入れ替わったり
|
36
36
|
|
37
37
|
中グループが消え小グループが大グループ直下になるとかいうことが起こり得るモデルなら
|
38
38
|
|
39
39
|
[ancestry](http://qiita.com/NAKANO_Akihito/items/d42a6ceae40933af2352)なるgem
|
40
40
|
|
41
|
-
をお勧めします。これはSQLアンチパターンを利用して、activerecordに組み込んであるので
|
41
|
+
をお勧めします。これはSQLアンチパターンを利用して包含関係を、activerecordに組み込んであるので
|
42
42
|
|
43
43
|
非常に使いやすいです。
|
44
|
+
|
45
|
+
|