CJ Date：经典VB向导升级还是应该重新设计？
我应该通过 VS08 中的升级向导运行经典的 VB6 应用程序，还是应该从头开始重新设计它。
数据库一片混乱。
最初在 ACCESS 中设计并导入到 MS SQL SERVER。
主要实体有 ROLLER_SKATES 和 RENTALS。如果您想租一双溜冰鞋，也可以。因此，这或多或少包括溜冰鞋的库存系统。
现在您有 2 个不同的滑冰圈。 Skate-B1 和 Skate-Z9，并且您还可以在滑冰环表中保留前面提到的实体的冗余和重复数据。
这是一场噩梦。
至少表有行 ID。但没有显式的外键，只有同名的隐式列“似乎”彼此对应。但表的其余属性都默认为 NULL。
考虑到 CJ Date 在他的《SQL 和关系模型》一书中关于类型的说法，难道不希望对属性进行检查约束吗？
而且，数据到处都是，例如，溜冰鞋序列号是G123，而在另一个实例中它是G-123。明白了吗？
我应该怎么办？
Should I run a classic VB6 app thru the upgrade wizard in VS08 or should I re-design it from scratch.
The database is a mess.
Originally designed in ACCESS and imported to MS SQL SERVER.
The main entities are e.g. ROLLER_SKATES and RENTALS. If you would like to rent a pair of roller skates you can. So this more or less comprises an Inventory system for the roller skates.
Now you have 2 different skating rings. Skate-B1 and Skate-Z9, and you keep redundant and duplicate data from the previously mentioned entities in the skating ring tables as well.
It's a nightmare.
At least the tables have row ID's. But no explicit foreign keys, just implicit columns identically named that "seem" to correspond to each other. But the rest of the table's attributes all default to NULL.
Considering what C.J Date says about Types in his book SQL and the Relation Model, isn't it desirable to have CHECK CONSTRAINTS on attributes?
And, the data is all over the place, e.g., Roller skate serial number is G123 and then in another instance it is G-123. Get the drift?
What should I do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
无需花费太多时间阅读您的问题，我就会看到两行内容：
所以，我认为我们都同意重写是最理想的课程。
但是，这必须与您的特定要求相平衡。迁移必须以多快的速度进行？当前的应用程序在重写之前是否无法使用？如果是这样，这可能是支持使用升级向导的一个非常有说服力的论据。即使考虑到它的缺陷和缺点，它也比从头开始完全重写要容易。
如果您确实决定走这条路线并使用升级向导，那么第三个“平衡”选项就会出现，我强烈推荐它。一旦您升级了项目并使用升级向导（以及您友好的邻居 Stack Overflow 作为资源）对其进行编译，您就可以分发并开始使用应用程序的新 .NET 版本。然后，慢慢地，您可以开始重新设计和重新实现应用程序当前 .NET 版本的部分内容。只要保留相同的公共接口，并且仅重新设计应用程序代码库的一小部分，您就可以缓慢地推出这些更改，本质上是分阶段重写整个应用程序。您可能需要几个月的时间才能获得正确的低级数据库访问代码，但与此同时，您的应用程序可以正常运行。然后，一旦代码正常运行并经过完善，您就可以继续将其推广到应用程序的下一个增量版本，同时在幕后处理 UI 代码。
Without spending too much time reading your question, two lines jump out at me:
So, I think we can both agree that a rewrite is the most desirable course.
However, that has to be balanced with your particular requirements. How fast does the migration have to take place? Is the current app unusuable until it is rewritten? If so, that might be a pretty compelling argument in favor of using the Upgrade Wizard. Even given its flaws and shortcomings, it's going to be easier than a total rewrite from scratch.
If you do decide to go this route and use the Upgrade Wizard, a third "balanced" option presents itself, which I highly recommend. Once you upgrade your project and get it to compile using the Upgrade Wizard (and your friendly neighborhood Stack Overflow as a resource), you can distribute and begin using the new .NET version of your app. Then, slowly, you can start redesigning and reimplementing parts of the now .NET version of the app. As long as you keep the same public interfaces, and only redesign small portions of your application's code base, you can roll out these changes slowly, essentially rewriting the entire application in stages. It might take you a few months to get the low-level database access code right, but in the meantime, your application works. Then, once you get that code working right and polished, you can go ahead and roll it out to the next incremental version of your app, while you work on the UI code behind the scenes.
如果该应用程序与您原来的帖子类似，我会建议重做和重新设计。
您有了框架，并且知道应用程序背后的想法是什么。
当我们回顾自己设计的应用程序时，很少会发现它是完美的。只有当你作为一名程序员多年来没有进步时，才会发生这种情况......
If the app is anything like you original post, I would recomend redo and redesign.
You have the skeleton, and know what the idea behind the app is.
Very seldomly when we look back at apps that we design, do we find it to be perfect. This only happens if you did not progress as a programmer over the years...
重新设计和重构固然很棒，但有时您必须意识到，您正在维护的蹩脚小项目就是这样，而且永远不会变得更好。你必须从客户的角度考虑问题。对他们来说，这只是他们用来完成工作的设备之一。如果它有效，他们可能看不到任何理由在上面花任何钱，特别是如果这是他们看不到或真正理解的某种升级。
我当时已经从 VB6 升级了几个这样的项目。也许转换器现在更好了，但我对它们的运气不太好。我发现效果很好的方法是制作看起来像旧表格的新表格。然后将旧表单中的代码复制并粘贴到新表单中并解决错误。进展得很快。我通常也会设法进行一些小改进，主要是在用户界面上，客户会看到他们花的钱得到了一些东西。
至于后端，我曾经处理过一些没有外键约束的大型数据库以及您谈到的所有其他问题。它的可维护性并不理想，但它工作得很好，而且听起来这不是那种需要大量维护的项目。不管你做什么，你都需要确保找到一种方法来为每个项目强制使用唯一的单一名称。我见过其他应用程序也犯过同样的错误，这会导致各种各样的问题。
如果奇迹般地你能够说服他们为此预算一些钱，我会从头开始。请记住，事情总是比您想象的更大、花费的时间更长。并且不要忘记您还必须编写某种数据导入器。
Redesigning and re-factoring are great, but sometimes you just have to realize that the crappy little project you're maintaining is just that, and will never be any better. You have to think about things from the customers perspective. To them it's just one of the pieces of equipment they use to get a job done. If it's working they probably don't see any reason to spend any money at all on it, especially if it's some kind of upgrade they can't see or really understand.
I've upgraded several such projects from VB6 back in the day. Maybe the converters are better now, but I didn't have a lot of luck with them. What I've found works pretty well is to make new forms that look like the old ones. Then copy and paste the code from the old form into the new form and work through the bugs. It goes pretty quick. I usually manage to slip in a few little improvements too, mostly to the UI where the customer will see that they're getting something for their money.
As for the backend I've worked with some large DBs w/o foreign key constraints and all the other problems you've talked about. It's not ideal for maintainability but it works fine, and it doesn't sound like this is the sort of project that sees much maintenance. You do need to make sure you find a way to enforce a unique single name for each item though, what ever you do. I've seen other apps make that same mistake, and it leads to all kinds of problems.
If by some miracle you are able to convince them to budget some money on it, I would start from scratch. Just remember things are always bigger and take longer than you think they will. And don't forget you'll have to write some kind of data importer as well.
项目越复杂，您就越不可能想要升级并继续按原样进行。
.Net 提供的功能比 VB6 多得多，当然，它基本上会运行 vb6 代码，但如果您实际上不打算使用 .net 及其功能，那么升级到 .net 就没有意义。
如果应用程序像您所说的那样混乱，那么转换为 .net 是重新设计以消除旧的低效率和逻辑愚蠢之处并利用 .net 中允许的新功能的好时机。即使不是完全重新设计，至少从 .net 角度考虑应用程序也会改进它。
除非应用程序的大小/复杂性很小，否则请重做。如果应用程序不大或不复杂...重做它:)
The more complicated the project, the LESS likely you'll want to just upgrade and continue as is.
.Net provides so many more features than VB6 did, and while sure, it'll basically run vb6 code, there's no point in upgrading to .net if you're not actually going to USE .net and its features.
If the app is as messy as you say, converting to .net is a great time to both redesign to remove old inefficiencies and logical goofiness, and leverage the new things you're allowed in .net. Even if it's not a TOTAL redesign, at least thinking about the app in terms of .net will improve it.
Unless the application is trivial in size/complexity, redo it. And if the app isn't large or complres... redo it :)