回答編集履歴
4
あ
answer
CHANGED
File without changes
|
3
あ
answer
CHANGED
@@ -24,9 +24,8 @@
|
|
24
24
|
などです。
|
25
25
|
|
26
26
|
2つ目は
|
27
|
-
画像の差し替え、更新、取得に際して、active_recordだけでは不可能で、ハードコーディング(SQLを直打ち)する必要がある。
|
27
|
+
- 画像の差し替え、更新、取得に際して、active_recordだけでは不可能で、ハードコーディング(SQLを直打ち)する必要がある。
|
28
|
-
そもそも、active_recordは構造上モデルのDataBaseのfieldを一旦、全て取得するので
|
29
|
-
|
28
|
+
- そもそも、active_recordは構造上モデルのDataBaseのfieldを一旦、全て取得するので毎回、取得時にそれをメモリ上に展開して、処理を行うと、userに関わる全てのactive_recordでとんでもない遅延が発生する。
|
30
29
|
|
31
30
|
ですかね
|
32
31
|
特に最後は重要です。
|
2
説明追加
answer
CHANGED
@@ -14,4 +14,20 @@
|
|
14
14
|
です。
|
15
15
|
特に2つ目は狂気の沙汰としか思えません
|
16
16
|
|
17
|
-
理由を説明し
|
17
|
+
理由を説明しますと
|
18
|
+
|
19
|
+
1つ目に関しては
|
20
|
+
- 画像のバイナリデータの内部を検索することはないので、DBに入れる意味は薄い
|
21
|
+
- OSのファイル管理自体が、かなり効率のいいファイルDBになっておりfilepathだけ格納しても遅延はそこまで発生しない。
|
22
|
+
- DBをバックアップするときに、画像データのバイナリをいちいち保存しなくてはいけないのでバックアップファイルが巨大になりかつ時間もかかる。
|
23
|
+
- バイナリデータは拡張子を保存しないので、拡張子を別に保存するか、画像に変換時に、推定しなくてはいけない。
|
24
|
+
などです。
|
25
|
+
|
26
|
+
2つ目は
|
27
|
+
画像の差し替え、更新、取得に際して、active_recordだけでは不可能で、ハードコーディング(SQLを直打ち)する必要がある。
|
28
|
+
そもそも、active_recordは構造上モデルのDataBaseのfieldを一旦、全て取得するので
|
29
|
+
枚取得時にそれをメモリ上に展開して、処理を行うと、userに関わる全てのactive_recordでとんでもない遅延が発生する。
|
30
|
+
|
31
|
+
ですかね
|
32
|
+
特に最後は重要です。
|
33
|
+
|
1
説明追加
answer
CHANGED
File without changes
|