我应该使用并添加到现有的非规范化数据库结构，还是创建自己的？
我们有一个第三方软件，我被要求为其创建一个扩展。该扩展将处理当前软件中存在的数据，并包括一些附加数据。
现有数据是极度非规范化的。我将使用的大部分数据（大约 4-5 个不同的实体）都存在于一个表中。我需要向其中大多数实体添加其他字段。
我看到有两种方法可以做到这一点：
为新字段创建一个新表，与现有表 1:1 匹配并使用它们使用的相同非规范化样式
优点：它适合现有的非规范化数据库结构，并且易于创建
缺点：非常非规范化，而且我有点痴迷于规范化我的数据库。当前表已经有超过 50 列，它实际上应该分为 4-5 个不同的表。
我也不认为我可以轻松地将 EF 与当前的数据库结构（我使用数据库的首选方式）结合使用，并且必须在代码中手动创建数据模型，而不是使用 EF 生成它们
创建一个整体新建一组表并使用触发器同步表间数据
优点：可以按照我想要的方式创建表，并且可以使用 EF 处理数据库操作，并为我生成数据模型
缺点：需要使用触发器来与现有表同步数据
您认为哪个是更好的主意？
We have a 3rd party software, and I have been asked to create an extension for it. The extension will deal with data that exists in the current software, and include some additional data.
The existing data is extremely denormalized. Most of the data I will be working with, which is for about 4-5 different entities, exists in a single table. I will need to add additional fields to most of these entities.
I see 2 ways of doing this:
Create a new table for the new fields, that matches the existing table 1:1 and uses the same denormalized style they use
Pros: It would fit in with the existing denormalized database structure, and be easy to create
Cons: Very denormalized, and I'm a bit obsessed about normalizing my databases. The current table already has over 50 columns, and it should really be split up into 4-5 different tables.
I also don't think I can use EF easily with the current database structure (my preferred way of working with the database) and would have to manually create data models in the code instead of using EF to generate them
Create a whole new set of tables and use triggers to synchronize the data between the tables
Pros: Can create the tables the way I want, and can use EF to handle database operations, and to generate the data models for me
Cons: Need to use Triggers to synchronize data with existing table
Which do you think is the better idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为这取决于您正在考虑的扩展程度。如果您要向现有界面添加一些花哨的功能，特别是如果您不需要包装现有界面，那么您最好保持警惕并接受丑陋的基础数据结构。
这一切都归结为要构建和维护的代码量较小：
由于非规范化基础 + 扩展属性而变得丑陋的扩展代码 - 或 -
干净的扩展代码 + 所有丑陋的表同步触发代码。
在我看来，如果扩展确实很大，那么 2 可能会比 1 小。但是，如果你只考虑那些花里胡哨的东西，那么 1 可能会比 2 小很多。
I think it depends on how much of an extension you're looking at. If you are adding a couple of bells and whistles to the existing interface, and especially if you aren't going to have to wrap the existing interface, then you might be better off to hold your nose and live with the ugly base data structure.
It all comes down to which is a smaller pile of code to build and maintain:
Extension code that is made ugly by the denormalized base + extended attributes - or -
Clean extension code + all of the ugly table synchronization trigger code.
It seems to me that if the extension is really substantial, then 2 could turn out to be smaller than 1. However, if you're looking at just those few bells and whistles, then 1 is probably going to be a lot smaller than 2.
我认为答案是如何最好地利用你的时间以及你现在和将来对牌桌的控制程度。就我个人而言，我会创建一个具有某种关系的备用表。如果您选择修改现有表，您现在不仅必须对应用程序进行回归测试并测试新应用程序，而且还面临着未来更新破坏这两个应用程序的风险。所以我说，做你能控制的事情。您的时间将得到更有效的利用，并且您今后的风险也会更小。为您提供智能，为企业提供智能。希望有帮助。
I think the answer is how to best utilize your time combined with how much control you have over the tables for now and in the future. Personally I would create an alternate table with some relationship. If you choose to modify the existing table you not only now have to regression test the app and test your new app but you stand the risk of future updates breaking both apps. So I say, work with what you can control. You're time will be more effectively used and you position yourself with less risk down the road. Smart for you and smart for business. Hope that helps.