.Net体系结构挑战：易于更改的模型

早上好

在办公室里，我们一直在为这个有趣的场景挠头，我们渴望听到您的想法和方法：

我们有一个数据库，它的模式是 容易发生变化-让我们称之为 Prony-。（用于存储的配置参数） 嵌入式设备。那么如果嵌入式设备 我需要一张新桌子， 财产或关系 作为一个榜样，他应该能够适应 模式以一种简单的方式出现——就是这样 经常-

Prony需要一个web界面来 创建/编辑其数据（一组简单的积垢就足够了）

我们有另一个数据库包含 还需要加载到的数据 在制作了一些 转换-让我们称之为 Oddy-（此数据由已存在的 管理web应用程序）

最后，我们有了Tracy，一台服务器，用于与我们的DBs和嵌入式设备进行通信。 她应该能够自动适应我们的dbs模式更改，并将数据序列化到设备

很好的拼图，你不这么认为吗？：）

---

我们当前的候选人：

• 拉迪：快
  让我们在中创建一些视图 Prony从Oddy进行数据转换。然后 使用动态CDATA（或某些RAD） 工具）来创建/更新简单的web Prony的接口（这样他就可以 甚至可以查阅转换后的数据 来自Prony：）。关于 Tracy，她需要重新编译 更新她的DB模式（实体框架应该可以工作），并使用反射递归地探索模式并序列化数据
  缺点：
  • 我们必须重新编译Tracy和Prony的web界面

你觉得候选人怎么样？

---

有什么想法吗？

处理产品发布后不断变化的数据模型的一种方法是全部或部分使用数据库设计。EAV结构添加行而不是列或表，并且允许更少的模式更改（或者根本不更改）

当然，它也有自己的一套警告，例如需要经常以数据为中心，但它们是可以管理的。有大量的EAV DB正在生产中

---

性能说明：人们经常担心EAV的性能。我有很多EAV，EAV表运行的记录超过1000万条。读取、插入、更新和删除都可以。当您开始对这样的数据结构进行大量报告时，麻烦就来了。在您的情况下，您正在存储设备的配置信息。这不是无伤大雅的，也不是微不足道的，但我要说的是，db的这一部分听起来像是EAV的一个很好的候选者，因为您的读写将受到限制，我猜您的报告需要简单。

嗨，Paul，嘿，这是一个好主意，所以模式更改可以在不重新编译的情况下完成：）+1绝对正确。您只需确保您的代码与持久性模型一样灵活。例如，您是否需要处理新实体，还是只添加/修改一组已知实体的属性？嗨，Paul，在这种情况下，是的，我们还需要创建新实体。很好的一点是+1:）。我正在考虑使用Umbraco（它已经是EAV，并且也有一个很好的web界面：）。我们只需要找到一种将翁布拉科与外部星展银行（Oddy）整合的方法。你觉得呢？Oddy需要一个数据库吗？似乎这就是您要放置一个web服务的地方，它提供一个配置API并从Prony中提取数据？或者Oddy是运行在移动设备上的紧凑型db的一种风格？顺便说一句，EAV对于小型dbs也很好。我只是不想尝试OLAP风格的报告。嗨，保罗，Oddy已经是一个DB了，但我们可以公开一个web服务API。好主意：）-我们羞于发现团队中有人从一开始就提出了这个建议，我们怎么能忽视它？哈哈。EAV可以，这只是一个配置参数数据库。再次感谢：）+1