当我更改数据库时，我如何知道需要删除哪些内容并将其读入 Visual Studio 中的 LinqToSql O/R 设计器？
例如，我将表中的一列从 null 更改为 not null。
然后我需要删除并重新添加该表。 这部分很清楚。
访问表（尤其是表中的列）的视图、函数和存储过程又如何呢？
我尝试过对 SQLMetal 生成的文件运行差异，但取得了一些有限的成功，但即使如此，它仍然相当不清楚。
我知道至少有一个商业工具声称可以解决这个问题，但我正在寻找免费的工具。
人们如何处理这个问题？
For example, I alter a column in a table to be not null from null.
I need to then delete and readd the table. That part is pretty clear.
What about views, functions, and stored procedures that access the table, especially that column in the table?
I've tried running diffs against the files generated by SQLMetal with some limited success, but even with that it's fairly unclear.
I know there is at least one commercial tool out there that claims to address this problem, but I am looking for something free.
How are people dealing with this issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对这个问题+1。
但是，如果使用商业工具可以解决问题，那又有什么不好呢？ 毕竟，如果您每周花一个小时手动匹配更改，而不是点击一个为您完成所有操作的按钮，那么使用商业工具的许可成本将立即收回。 解决此问题的所有工具只需花费 Visual Studio 许可证的一小部分，有免费试用，而且价格对于大多数开发者来说不超过一个小时的工作时间。 只是我的2分钱。
也就是说，我同意如果这个功能免费提供那就太好了。 我曾多次尝试向 MSFT 提出这一建议，但他们似乎对此不感兴趣。 （例如：他们甚至不回复...:)）
+1 on the question.
But what's bad about using a commercial tool if it solves the problem? After all, if you spend an hour per week on manually matching up changes instead of hitting a button that does it all for you, then the license cost of using a commercial tool will pay itself back in no time at all. All tools that address this issue cost a fraction of a Visual Studio license, have free trials, and the price is not more than an hour of work for most devs. Just my 2 cents.
That said, I agree it would be neat if this functionality was available for free. I have tried suggesting that to MSFT many times but they don't seem to be interested in that. (as in: they don't even reply back... :) )
看来您将大量业务逻辑放入 SQL 数据库中，而不是将其保留在应用程序本身中。 尝试采用更DDD 方法，采用 域 模型 - 这应该将那些 SP 和视图的大部分工作从db 正在返回到它们所属的应用程序中。 那么你的数据库应该只用于持久化数据，因此更改为表应该只需要在 L2S 设计器中花费很少的时间来进行更新。
It seems you are putting a lot of business logic into your SQL DB rather than keeping it in the app itself. Try adopting a more DDD approach with a Domain Model - this should move much of the work those SPs and Views from the db are doing back into the application where they belong. Then your db should only be for persisting data and hence changed to tables should only require a very small amount of time in the L2S designer to make updates.