回答編集履歴
1
ミスタイプ修正
test
CHANGED
|
@@ -1,5 +1,6 @@
|
|
|
1
|
+
多くのGoバックエンドはDBをシンプルに設計しつつゴリゴリ実装を書いているプロダクトが多いように見えます。
|
|
2
|
+
|
|
1
|
-
One-to-ManyやMany-to-Manyが必要ならそれに対応したORMを利用するとよいと思いますよ。
|
|
3
|
+
One-to-ManyやMany-to-Manyが必要ならそれに対応したORMを利用するとよいと思いますよ。特にサンプルコードが例示されているものが良いのではないでしょうか。
|
|
2
|
-
特にサンプルコードが例示されているものが良いのではないでしょうか。
|
|
3
4
|
|
|
4
5
|
https://entgo.io や https://gobuffalo.io などは対応しているようですよ。
|
|
5
6
|
|
|
@@ -9,9 +10,7 @@
|
|
|
9
10
|
|
|
10
11
|
「NGポイントを発見」ー＞「複雑なORMのコードを追うコストの高さ」ー＞「生SQL書いたほうが早く目的の実装が出来上がる」という流れは多く観測されてきました。
|
|
11
12
|
|
|
12
|
-
Goの場合、Goを選択したという時点で応答性能の高いバックエンドが求められているのかなと思いますが、その場合、DBテーブルの構成をシンプルに保ちつつ参照範囲をできるだけ狭くなるように設計することが重要になります。
|
|
13
|
-
あまり賢くないORMを利用した場合、このあたり貪欲に広範囲のデータを参照しようとしまう傾向があります。
|
|
14
|
-
そうなってくると、RubyやPython、Nodeのような賢いORMのある環境のほうが平均的に応答性能が高いという結果もあり得るわけです。
|
|
13
|
+
Goの場合、Goを選択したという時点で応答性能の高いバックエンドが求められているのかなと思いますが、その場合、DBテーブルの構成をシンプルに保ちつつ参照範囲をできるだけ狭くなるように設計することが重要になります。あまり賢くないORMを利用した場合、このあたり貪欲に広範囲のデータを参照しようとしてしまう傾向があります。そうなってくると、RubyやPython、Nodeのような賢いORMのある環境のほうが平均的に応答性能が高いという結果もあり得るわけです。
|
|
15
14
|
|
|
16
15
|
そういう意味でGoをチョイスした理由とGo古参のORMとは若干ミスマッチだなぁとは思っています。
|
|
17
16
|
Goを選んだ場合、「シンプルなDBテーブル構成で手書きコードまたはコード生成でマッピング」とする傾向が強いというのはありそうです。
|