您的胖客户端如何测试它是否与数据库模式兼容？
我开发了一个包含胖客户端和瘦客户端组件的应用程序。我们还对数据库进行版本控制，以便架构更改会产生自己的版本号，并且可以应用更改脚本。然而，数据库更改并不总是与胖客户端更改同步发生。是的，今天的数据库更改可能会在胖客户端中添加一列并需要一个列，但明天的数据库更改可能会修复不需要任何外部更改的存储过程中的错误。当有些向后兼容而有些不向后兼容时，如何对胖客户端进行编码以测试它是否与特定数据库版本兼容？
即使有人关心，我们的应用程序也是一个与 SQL Server 集成的 .NET 应用程序，但这似乎更像是版本控制问题，而不是平台问题。除非有特定于平台的解决方案......
I develop an app with both thick-client and thin-client components. We also version our database such that schema changes result in their own version number and change scripts can be applied. Database changes, however, don't always occur in step with thick-client changes. Yes, today's database change might add a column and necessitate a in the thick-client, but tomorrow's database change might fix an error in a stored procedure that does not require any external changes. How can I code the thick-client to test whether it is compatible with a specific database version when some are backwards compatible and some are not?
In the even that anyone cares, ours is a .NET app integrating with SQL Server, but this seems like more of a versioning question than a platform question. Unless there is a platform specific solution ...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以创建一个表，例如。具有两个字符串列的元数据，并在其中放置一个具有当前版本架构的条目（或多个条目）。我想你现在也会做类似的事情。
并将版本拆分为两个数字（如主要/次要方案）。当您以非向后兼容的方式更改架构时，您会增加主要版本。向后兼容更改后，您只需更新次要版本。
应用程序使用 Major 来检查它是否与当前架构兼容，major+minor 用于检查是否可以/需要更新架构。
我认为这是大多数应用程序使用的解决方案。
You can create a table, ex. metadata with two string columns, and put there an entry (or more entries) with the current version of the schema. I suppose that you do something similar now.
And split the version to two numbers (like major/minor scheme). When you change the schema in non-backwards compatibile way then you increse the major version. After backward compatible change you just update minor version.
Major is used by app to check if it is compatible with the current schema, and major+minor is used to check if you can/need to update the schema.
I think this is the solution that is used by most applications.
您能采用主/次版本号方案吗？
主编号的更改意味着客户端需要更新，而次编号的更改则不需要。
Could you adopt a major/minor version number scheme?
A change in major number implies that clients need updating, and change in minor number does not.
对于其中任何一个，版本号总是在增加。
如果数据库知道它需要的最低客户端版本，并且客户端知道它需要的最低数据库版本，则可以通过简单的检查来确定需要升级的内容（如果有的话）——现在无论您将逻辑封装在存储过程中还是封装在存储过程中代码，这是你的决定......
With any of these, version numbers are always increasing.
If the database knows the minimum client version it requires, and the client knows the minimum database version it requires, it's a simple check to determine what needs upgrading (if anything) -- now whether you encapsulate the logic in a stored procedure, or in code, that's your decision...