问题标签 [data-modeling]

我的要求是为每个对象的每个属性的更改保留完整的审计跟踪的数据模型。对象定义也是流动的：新属性会随着时间的推移出现或消失。此审计跟踪将与原始数据库分开存在，因此基于触发器的审计模型将不起作用。

在关系数据库中，我可以使用一个大型 ATTRIBUTE_HISTORY 表来实现这一点，该表记录每个属性的每个单独更改，并带有适当的时间戳和责任字段。

我的问题：是否有任何较新的存储模型（BigTable、HBase、CouchDB、RDF 存储等）优于 RDBMS？

我正在编写一个需要可搜索版本控制的 wiki 应用程序。什么是最好的数据模型？

我正在用 Django 编写它，这并不重要。

是否有适合所有号码的电话号码格式？（比区号 3 个数字和其余 7 个数字更灵活的东西）

我想记录各种来源对历史人物的看法。IE

• 维基百科网站说苏珊·B·安东尼出生于 1820 年 2 月 15 日，她最喜欢的颜色是蓝色
• 《奋斗的世纪》一书中说，苏珊·B·安东尼出生于 1820 年 2 月 12 日，她最喜欢的颜色是红色
• 《妇女选举权史》一书中说，苏珊·B·安东尼生于 1820 年 2 月 15 日，她最喜欢的颜色是红色，是亚伯拉罕·林肯的第二代堂兄。

我还希望研究人员能够表达他们对这些来源提出的个人主张的信心，例如以百分比表示。IE

• 用户 A 有 90% 的把握认为苏珊 B.安东尼出生于 1820 年 2 月 15 日；75% 的人相信她最喜欢的颜色是蓝色，30% 的人相信她是亚伯拉罕·林肯的第二表亲
• 用户 B 有 30% 的把握认为苏珊 B.安东尼出生于 1820 年 2 月 12 日；60% 相信她最喜欢的颜色是蓝色，10% 相信她是亚伯拉罕·林肯的第二代表亲

然后，我希望每个用户都能看到 Susan B. Anthony 的视图，其中显示了她的生日、最喜欢的颜色以及用户认为最有可能真实的关系。

我还想使用关系数据库数据存储，我认为这样做的方式是为我希望用户能够表达他们的信心的每一种原子事实创建一个单独的表。所以对于此示例，总共将有八个表，三个单独的表用于三个单独的原子事实。

这感觉它很快变得非常复杂，因为实际上想要记录很多类型的原子事实。有没有更好的方法来做到这一点？

我认为，这与 Martin Fowler 所说的矛盾观察相同的问题。

我正在使用 MVC 范例（在 CakePHP 中）为一个项目创建一个简单的社交网站设计，我有一个名为 Users 的表，它存储所有用户详细信息，我有一个存储所有组详细信息的组表，这两个模型之间的关系是有并且属于很多，然后我有一个 group_portfolios 表，它存储属于一个组的所有投资组合和一个 user_portfolio 表，它存储与用户相关的所有投资组合信息。一个用户可以有多个投资组合 一个组可以有多个投资组合 一个用户可以有很多媒体 一个组可以有很多媒体

我已经分离了与用户和组关联的媒体的功能，我的问题是，

1) 在建模 MVC 应用程序方面，我是否以正确的方式思考？
2）由于我将用户和组的功能分开，因此我最终得到了 2 个表，其中包含与他们相关的所有信息，例如媒体和投资组合。这是否会导致任何冗余和性能相关问题，尤其是在搜索投资组合等时？
3) 当我以后想添加更多功能时，这是否能够扩展？
4）有没有更好的方法来模拟系统？

谢谢你

I'm evaluating the idea of building a set of generic database tables that will persist user input. There will then be a secondary process to kick off a workflow and process the input.

The idea is that the notion of saving the initial user input is separate from processing and putting it into the structured schema for a particular application.

An example might be some sort of job application or quiz with open-ended questions. The raw answers will not be super valuable to us for aggregate reporting without some human classification. But, we do want to store the raw input as a historical record.

We may also want the user to be able to partially fill out some information and have it persisted until he returns.

Processing all the input to the point where we can put it into our application-specific data schema may not be possible until we have ALL the data.

Two initial questions:

1. Assuming this concept has a name, what is it?
2. Is this a reasonable approach? Why or why not?

Update:

Here's another way to state the idea. The user is sequentially populating fields in a DTO. I (think I) want to save the DTO to disk even in a partially-complete state. Once the user has completed populating the fields, I want to pull out the DTO and process it for structured saving into a table which represents the specific DTO. I can't, however, save a partially complete or (worse) a temporarily incorrect set of input since some of the input really shouldn't be stored as part of the structured record.

My idea is to create some generic way to save any type of DTO and then pull them out for processing in a specific app as needed. So maybe this generic DTO table stores data relating to customer satisfaction surveys right next to questions answered in a new account setup wizard.

我正在寻找一款软件，让我可以轻松地为现有 MySQL 数据库创建数据库模式

我正在寻找资源来帮助将我的设计技能从传统的 RDBMS 数据存储迁移到 AppEngine DataStore（即：“软模式”风格）。我看过几个演示文稿，都涉及到总体主题和一些特定技术。

我想知道是否有一个地方我们可以从经验（“来自战壕”）中汇集知识，以重新思考数据的结构，特别是移植现有应用程序。我们在很大程度上是基于 Hibernate 的，并且可能已经在我们的数据模型上走错了路，产生了一些我们的数据库正在努力解决的粗糙查询。

如果出现以下情况请回复：

1. 您已将一个重要的应用程序移植到 AppEngine
2. 您已经在 AppEngine 中从头开始创建了一种通用类型的应用程序
3. 您没有完成 1 或 2，但正在考虑并希望分享您迄今为止的发现。

我最近阅读了一些关于数据建模的文章，并且对实体可能扮演的角色有疑问。

考虑一个简单的案例，您有一家公司，一家公司可以是供应商、客户、分销商等，也可以是这些角色的组合。因此，X 公司可能既是供应商又是客户。

在数据级别下，您可能有一个 CompanyS 表，然后是 SupplierS、CustomerS 等引用 Company 表的表。至少我认为这就是它的表现方式。

好的，所以在应用程序领域的某个地方，您有 CustomerS 和 SupplierS 等的类。每个都由一个公司组成，然后是该特定类别的其他任何特殊之处。

只要我们一次只使用一个实体类，这一切都很好，对我来说很有意义。如果我们想从一家公司开始，看看它扮演什么角色怎么办？所以在一个应用程序中，我可能会拉出一个公司，然后看到它是供应商和分销商。

现在我可以想到几种不同的方法来做到这一点，但我觉得因为这个问题域太老了，所以必须有一些经过验证的真实模式来对这些概念进行建模。

因此，我在这里寻找的是在应用程序级别对实体角色进行建模的常用策略或模式。关于这个特定主题的具体参考资料将不胜感激（无论是博客、书籍还是其他）。

我正在查看我提出的这个数据模型并且感觉不舒服。我已经更改了实体名称，所以它（希望）更有意义。无论如何，您将如何建模以下内容？

我有 3 个实体。政府客户、私人客户、公共客户。私人客户和公共客户都是公司客户。企业和政府客户是账户。所有帐户共享相同的密钥空间（因此，如果 PrivateCustomer 的 PK 为 1，那么 Public 或 GovernmentCustomer 的 PK 不应该为 1）。CorporateCustomer 有一些GovernmentCustomer 没有的1:M 关系。PublicCustomers 有一些 PrivateCustomers 没有的 1:M 关系。

传承：

现在我的模型有 5 张桌子。“Account”表是这个层次结构的根，每个子表的 PK 是其父 PK 的 FK。所以所有的表都有相同的PK。

所以，是的，你将如何建模？我希望这里没有出现严重错误:)。

编辑：

另外： - 我希望数据库负责参考完整性而不是应用程序。- 如果没有私人或公共客户，CorporateCustomer 就不可能存在。它的抽象。