3

基になるテーブルを削除すると、LINQ-to-SQL で例外がスローされると想定しています。

予想される列を削除すると、その列が破損することも想定されます。その列を挿入または更新することはできません。しかし、その仮定は正しいでしょうか？その列を挿入したり更新したりしないとしたら、それSELECTがその列のデータ型のデフォルト値になるのでしょうか?

LINQ-to-SQL を破壊する基になるテーブルにどのような変更を加えることができますか? 無視されるようにするには、どのような変更を加えることができますか? 実行時にデータベース スキーマを検証しますか? 検証する場合はいつですか?

主キーや外部キーなどの制約を削除するのはどうですか? LINQ-to-SQL を壊すことなく、それらを追加、削除、または変更できますか?

基礎となるテーブルに対してできることと、できないことをいくつか知っています。私が考えている特定のケースはnullable、dbml を壊さずにテーブルに列を追加できるかどうかです。覚えていないので、ここに記録したいと思います。

4

2 に答える 2

8

LINQ-to-SQL が select ステートメントを生成し、サーバーからの応答を受信するまで、例外は発生しません。また、サーバーが予期しない応答 (フィールドの異なるデータ型など) を返した場合でも、コードでそのフィールドを積極的に使用するまで例外は発生しません。

そうです、列を問題なく追加できます。列は DBML に認識されないため、生成されたクエリは列を参照しないためです。Linq-To-SQL は を送信SELECT * FROM TABLEすることはなく、実行時に SQL Server でデータベース スキーマを送信SELECT [ID], [COL1], [COL2] FROM TABLEしたり検証したりしません。したがって、特定の [COL3] が存在するかどうかは、結果に違いはありません。

もう少し実験してみてください (お勧めできる方法ではありません)。DBML の一部である列を削除および変更して、何が機能するかを確認してみましょう。

[Col2] を削除すると、サーバーが [col2] を含む各行のすべてのフィールドを取得しようとするため、「無効な列名」エラーが生成されます。

var q = from row in table
        select row;
int id = q.First().id;

ただし、開発中に定期的に変更する予定がある場合は、必要なフィールドのみを取得することで、このようなエラーの発生を防ぐことができます。[Col2] を参照していないため、これは機能します。

var q = from row in table
        select new { row.id, row.Col1 };
int id = q.First().id;

そして少し驚くべきことに、Col2 をそのままにして、そのデータ型を完全に異なるもの (datetime など) に変更すると、これは機能することさえあります。

var q = from row in table
        select new { row.id, row.Col1, row.Col2 };
int id = q.First().id;

それが機能しないのは、フィールドを積極的に使用する場合のみです:(「Nullableオブジェクトには値が必要です。」というメッセージが表示されます)。

var q = from row in table
        select row;
var col2 = q.First().Col2;

新しい不明な列が null 可能である限り、行を挿入することもできます。新しい Col4 を作成したとしましょう。これはまだ機能します。

table.InsertOnSubmit(new table() { id = 1, col1 = 'A' };
table.SubmitChanges();

ただし、列のデータ型を変更すると、null 値を渡すだけでも行を挿入できなくなるので注意してください。Col1 が DBML の文字列であるが、データベースで datetime に変更した場合、Linq-To-SQL はすべてのフィールドに対して適切な挿入ステートメントを生成するため、これは機能しません: ('Implicit data type conversion not allowed')

table.InsertOnSubmit(new table() { id = 2 };
table.SubmitChanges();

要約すると、SQL ステートメント LINQ-To-SQL をデータベースで直接実行しても有効であり、受信したデータが DBML と矛盾しない限り、コードが壊れることはありません。

于 2012-08-21T05:30:59.063 に答える
0

LINQ TO SQL を使用していて、LINQ TO SQL モデルを更新せずにデータベース側のテーブルのみを変更した場合は、モデル オブジェクトが変更されておらず、構造も同じであるため、何も壊れることはないと思います。ただし、LINQ TO SQL を更新するか、データベースに存在しないエンティティを選択すると、内部例外がスローされる可能性が高くなります。それを行うための最も適切な方法は、LINQ TO SQL モデルとデータベースを常に同じに保つことです。これにより、将来の多くの問題を回避できます。nulable 列を dbml に追加するが、プロジェクトでそれを使用していない場合、Linq から sql に更新しない限り、モデルに含める必要があるため、問題ありません。

于 2012-08-21T01:58:53.883 に答える