[過去ﾛｸﾞ]
【本命】Blazor スレ1【真打】 (1002ﾚｽ)
【本命】Blazor スレ1【真打】 http://mevius.5ch.net/test/read.cgi/tech/1595255796/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
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
709: デフォルトの名無しさん [sage] 2020/11/08(日) 13:33:40.14 ID:QCCK7Xg4 >>707 EFモデルファーストは文字列の長さなど細かいコントロールも当然可能だ より詳細な調整をしたい場合はMigrationを手書きしてMigrationBuilderに生えてるDDLラッパーを呼び出せば良い DDLラッパーはCreateTableメソッド、DropTableメソッドなど.NETのメソッドではあるがDLLを書くのと非常に近い感覚で使うことができる これはラッパーなので複数ベンダに対応することができる 代わりに最大公約数的な機能に制限されるが十分な機能揃っている 完全にMigrationをコントロールしたい場合には生のSQLを書いてもいい EFはもちろん生のSQLもサポートしている 原始時代や産業革命時代に行っていたような作業はすべてEFでできる ただし生のSQLを使うとベンダ依存が発生するのでそこはトレードオフだ 更に加えてMigrationとして.NETのカスタムコードを実行することが可能だ 例えば今まで保護されていなかった個人情報をC#で暗号化して保存し直すといったことも可能だ 手作業でSQLを実行する http://mevius.5ch.net/test/read.cgi/tech/1595255796/709
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.029s