次世代言語14 Go Rust Swift Kotlin TypeScript ->画像>2枚

このスレへの固定リンク： http://5chb.net/r/tech/1536664054/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

ID:XOW0CkvVdのレス一覧：

428デフォルトの名無しさん (ｽﾌｯ Sdff-DAVC)2018/10/11(木) 10:12:47.40ID:XOW0CkvVd

知能が低い奴ほど正しいストアドを見たことが無いだけだろ。
正しくDBエンジニアたちが作ったストアドとViewは、いい感じに疎結合になってるし、
DBとアプリどっちの変化も吸収してくれる上に、そのへんのやつが書いたSQLよりも安定して早いぞ。
カーソル使う/使ってるようなストアドは存在自体が間違ってるとは俺も思うが、
まともなストアドは中途半端に作ったDBや、ORマッパーお任せのDB作成/クエリーよりは良いと思う。

DBエンジニアが居ないような現場だとクソなのかな。

430デフォルトの名無しさん (ｽﾌｯ Sdff-DAVC)2018/10/11(木) 10:18:33.91ID:XOW0CkvVd

Wasmの関数に整数以外を渡すときは結構手数がいるし、型付と言ってもWasm内ではただのバイト列だから死に方はWasm作るために使った言語次第だよ。
だから、単純にwasmにすれば多少パフォーマンス上がるって言い切る事もできない。むしろ遅くなるかもしれん。
Gopherjsとgo+wasmで、gopherjsの方が早かったって結果をebitenの作者が書いてたよ。
あれは画像とかも渡してるけどね。

431デフォルトの名無しさん (ｽﾌｯ Sdff-DAVC)2018/10/11(木) 10:19:00.89ID:XOW0CkvVd

>>429
使ってる側が良いと思ってるよ…？

434デフォルトの名無しさん (ｽﾌｯ Sdff-DAVC)2018/10/11(木) 11:55:00.62ID:XOW0CkvVd

>>432
デプロイは確かに悩みどころ。
migrationでストアドも載せ替えてくような感じにするしか無いな。
なので、DBの改修って扱いになる

>>433
そんなのライブラリ関数でも同じようなもんだよw
ライブラリ関数作ってるアーキチームみたいな感じ、でDB屋も集まってる感じ。

437デフォルトの名無しさん (ｽﾌｯ Sdff-DAVC)2018/10/11(木) 14:56:25.16ID:XOW0CkvVd

>>435
面目ない、wasmが早くないって事のインパクトが大きくて端折ってしまった。
まあ、今のところGoのwasmは「パフォーマンスとかおいとくよ」って言ってるし、伸びしろはあるのかもしれないし、不正確だったな。

>>436
実感的には更新はストアド、取得はView(場合によってはマテリアライズド・ビューだったり、Triggerで生成されるテーブルだったり)が多いんじゃないかな。
ぶっちゃけ後者も同じ程度だよ。ガチで運用すると。

むしろアプリ側から見たら割と純粋だし、手間は思ってるよりも無いよ。
眺めるためのviewではなくて、アプリのためのviewだし。

439デフォルトの名無しさん (ｽﾌｯ Sdff-DAVC)2018/10/11(木) 17:58:18.47ID:XOW0CkvVd

>>438
単に半角さんへの煽りだよ。
とはいえ、割と見たことあるからそこまでレアなアーキテクチャじゃないと思うけど。
医療で、そこそこの規模の開発はだいたいそういう感じでやってた。金融でも同じ作りは聞いたよ。

サンプルでミニマルだと、ストアドが鬱陶しく見えるだけだと思うわ。

レス：1-200 201-400 401-600 601-800 801-1000 ALL

TOPへ TOPへ　

		ブックマークへ

23:39:36 up 6 days, 20:48, 1 user, load average: 129.41, 124.22, 134.12

in 0.013401031494141 sec @[email protected] on 091912