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，而是SELECT [ID], [COL1], [COL2] FROM TABLE在运行时发送也不用 SQL Server 验证数据库模式。因此，是否存在某个 [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 object must have a value。”）

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

只要您的新未知列可以为空，您甚至可以插入行。假设您创建了一个新的 Col4，这仍然有效！

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

但是，如果您更改列的数据类型，请注意，即使您只是传递空值，您也无法插入行。如果 Col1 是 DBML 中的字符串，但您在数据库中将其更改为 datetime，因为 Linq-To-SQL 为所有字段生成正确的插入语句，这不起作用：（'不允许隐式数据类型转换'）

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 模型和数据库相同，这样可以避免很多未来的问题。如果您向 dbml 添加了一个可空列但您没有在项目中使用它，只要您没有将它从 Linq 更新到 sql 就应该没问题，因为如果您这样做，您必须将它包含在您的模型中

于 2012-08-21T01:58:53.883 回答