[過去ﾛｸﾞ] Go language part 1 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
669: デフォルトの名無しさん [sage] 2016/09/22(木) 11:24:25.38 ID:sBPmoePF(1/3) AAS
goでDB扱おうとすると動的言語のほうが楽だと痛感するけどね
単純なテーブルに対するcrudなら構造体作って対応できるけど
joinしたりとかすることも考慮するとそうも行かない。
素直にrailsでいいんじゃね
675(1): デフォルトの名無しさん [sage] 2016/09/22(木) 15:32:16.50 ID:sBPmoePF(2/3) AAS
RDBからKVSに行ってやっぱRDBがいいやと言う流れじゃないの？
mongodbとか使ってるやついるのか今
676(1): デフォルトの名無しさん [sage] 2016/09/22(木) 21:41:56.84 ID:sBPmoePF(3/3) AAS
>>670670(1): ◆SEdFBOkLSw [sage] 2016/09/22(木) 13:36:58.94 ID:3pIcfs21(1) AAS
ORM使うからじゃないの？
JOINして使う結果とJOINせず単独で使う結果はそれぞれ別の構造体になってしかるべきな気がする。
あんまRDB使わないけど。
集合検索結合集計なシステムと手続き型とオブジェクト型と関数型、どれ同士を組み合わせても、インピーダンスミスマッチは仕方ないんだから、どっちかで歩み寄らなきゃ何ともならんような。
階層型とばっかり組み合わせてるけど、言語側はわりと世代交代早いからDB側でストアド書いてるわ。
結局ビジネスロジックをどっち側に寄せるかという話になるんだろうけど
ストアドプロシージャは素朴なコードしかかけないから抽象化しづらいと思うんだけど
書いたことがないから想像でしかないけど。
でもgolangの場合は抽象化しきれないからストアドプロシージャ側にロジックを寄せて実装はありなのかもしれない
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.178s*