[過去ﾛｸﾞ]
【本命】Blazor スレ1【真打】 (1002ﾚｽ)
【本命】Blazor スレ1【真打】 http://mevius.5ch.net/test/read.cgi/tech/1595255796/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
690: デフォルトの名無しさん [] 2020/11/08(日) 05:36:39.88 ID:t+zVbDF+ >>687 rollbackもできるというけどそれがMigrationの主要機能だし rollbackできなかったら意味ないでしょ Entity FrameworkのMigrationにもrollbackある。もちろんScaffoldもある Rubyのコマンド見てみたがEFのMigrationと似てる気がした。 ORMが履歴を持つことでrollbackできるようになる半面、長ったらしいコードが 生成されその記述を理解しないといけなくなる。 DB側のカラムに制約とかデータ型とか細かく設定するべきだが ORM使わずにpgAdmin, SQL Workbenchでやるほうが速いしわかりやすい。 さらにORM経由は操作できる範囲が限定される。 SQL使ってできる操作＞ORM使ってできる操作。 http://mevius.5ch.net/test/read.cgi/tech/1595255796/690
691: デフォルトの名無しさん [] 2020/11/08(日) 05:42:09.04 ID:t+zVbDF+ >>687 RubyおじはASP.NET Coreは使えてるのか？ ASP.NET Core使えるなら低速なRails, Rubyなんて使わなくていいだろ >>689 Sqlite以外ではMigration使ってないのか 本当にMigrationは誰得の機能かわからないわ http://mevius.5ch.net/test/read.cgi/tech/1595255796/691
701: デフォルトの名無しさん [] 2020/11/08(日) 12:54:19.78 ID:t+zVbDF+ >>692-693 逆だよ。CRUDにEF使うのは便利だから意味がある。 C#のコードが短くなるし直感的にかける だがスキーマの作成、変更でEF使うとC#のコードが長くなってしまう。 SQL側でダイレクトに変更すればすむものを履歴を持たせて C#側から操作するから手順が増える。 スキーマが自動生成のものでいいってのはDB知らない奴だな てきとうにつくるとパフォーマンス劣化する http://mevius.5ch.net/test/read.cgi/tech/1595255796/701
703: デフォルトの名無しさん [sage] 2020/11/08(日) 13:03:31.26 ID:t+zVbDF+ >>694 原始時代って履歴台帳なんて古臭い言葉つかってるおまえだろう スキーマ変更したら直後にテストしてるに決まってる あと間違いやすいのは複雑な手順をとるMigrationのほうだ http://mevius.5ch.net/test/read.cgi/tech/1595255796/703
705: デフォルトの名無しさん [sage] 2020/11/08(日) 13:11:07.00 ID:t+zVbDF+ >>695 パフォーマンスの面でDapperは昔は意味あったとおもうけど いまのEF CoreとASP.NET Coreだとかなり速いからDapper選ぶ意味がほぼないと思う。 EFで満足できない箇所だけピンポイントでダイレクトにSQL使うか、 ストアドプロシージャを使えばいいと思うわ >>697 たしかにEF Core速くなってるね あとストレージがSSDになったのも超大きい http://mevius.5ch.net/test/read.cgi/tech/1595255796/705
707: デフォルトの名無しさん [sage] 2020/11/08(日) 13:17:19.61 ID:t+zVbDF+ >>704 ORM、DBのベンチマークたまに見てるし速くなってるのは知ってるよ。 ただstringとかの最適なデータサイズは開発者じゃないとわからないから 最適なスキーマ作ろうと思うとやっぱりSQLでスキーマ作成、変更したほうが いいってのは今後も変わらないと思う http://mevius.5ch.net/test/read.cgi/tech/1595255796/707
708: デフォルトの名無しさん [sage] 2020/11/08(日) 13:25:09.54 ID:t+zVbDF+ >>706 根本的に会話になってない 俺の言ってるスキーマ変更するってのは決定事項なんだよ 既に正常に動くプログラムがあってそれをスキーマ変更するんだから スキーマ変更した後にテストしないと意味ない。 Migrationでrollbackすることもない 動くようになるまで必要ならばC#側を変更するからだ。 なんかうまく動かないからスキーマ変更やめましょうということにはならない。 http://mevius.5ch.net/test/read.cgi/tech/1595255796/708
716: デフォルトの名無しさん [sage] 2020/11/08(日) 15:20:50.04 ID:t+zVbDF+ >>714 Entity FrameworkのMigrationはそういう機能はないよ スキーマ変更の履歴を保持してロールバックとかができるだけ 俺はロールバックしたことないからめんどくさくなってMigration使ってない Managedの維持費のがSQL Serverのオンプレミス維持費より高いんでは？ SQL Serverなんてバックアップ、リカバリできれば運用かんたんでしょう DBの種類変更したらデータ型互換性なくなるから慎重にテストしないといけない。 よほど問題ない限り安定稼働してるDBはいじらんほうがいいとおもうよ http://mevius.5ch.net/test/read.cgi/tech/1595255796/716
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
1.938s*