2009-01-21 39 views
1

想象一下,一个可以处理随时间变化的数据的系统。例如,今天你的User对象包含Name:String和Email:String,但是明天你需要添加Age:Integer和Address,它由国家,邮政编码等组成。然后你可能想创建新的字段User.Contacts并将电子邮件和地址移动到该字段,如重构。 它应该在运行时完成,无需编码和重新部署,因为它将由客户或管理员完成,而不是由开发人员完成。使用变量结构的数据

你会考虑存储这些数据的方法和工具吗?它是每个对象类别的单独表格,每次更改结构时都会改变表格,或者是对象与其属性值之间的一对多关系(如具有字段ObjectID,PropertyID,StringValue的表格StringProperties);或所有对象的一个​​大表(具有通用字段StringField1,NumericField2等)

如何编制索引工作?

你会考虑使用像CouchDB这样的主流工具吗?还有其他工具我应该知道吗?

是否有任何具有类似想法的应用程序示例 - 允许用户定义和扩充自己的数据结构?

编辑:我不指望任何人解决我的整个设计问题。粗糙的想法或链接到像CouchDB或Prevayler这样的工具是非常值得欢迎的。任何文章链接也欢迎。

回答

1

我认为这将在很大程度上依赖于数据的寿命和你所在的语言。

对于一个短暂的结构,动态语言,那么我会被诱惑去低俗和使用一个列表哈希。

在规模的另一端 - 您需要坚持并且您确实需要关系数据库,那么我可能会转向更模块化的体系结构,即客户端代码负责数据的整个生命周期 - 直至并包括create table声明,编组和解组以及查询数据。

对于编组/解组/查询问题,可能会使用ORM工具或使用更低技术/原始SQL方法的道路上存在另一个问题。无论哪种方式,您都需要某种阶段性的方法,这是模块化设计的一部分。

当然,当数据结构位于内存中时,如何安排数据结构可以是直接的列表映射或更多类型的安全方法,例如Eclipse的IAdaptable“模式”。

否则,你在像Prevayler这样的工具的领域,它比RDBMS更先进的序列化到磁盘工具。

在附注上,你可能会比CouchDB差很多。

+0

我正在考虑哈希和列表来存储数据在运行时确定,但它需要永久保存。 – 2009-01-21 22:25:45

+0

Prevayler看起来很有趣,谢谢。 – 2009-01-21 22:56:00

1

如果要求是,你需要随意创建名称 - 值对的能力,然后以某种形式或其他,你会的名称 - 值对一个或多个表结束:

ID  USER_ID PROPERTY_NAME   PROPERTY_VALUE 
--------------------------------------------------------------- 
1  1   Name     Chris 
2  1   Occupation   Developer 
3  2   Name     Joe 
4  2   Hair Color   Brown 

...等等。当然,这些名称 - 值表随着时间的推移而疯狂增长,因此索引和分区很重要;在可以将属性类型分类为单独表格的同时仍保留所需的灵活性的情况下,您可以将表格大小保持在相对控制下。我曾参与过使用这种方法的项目,其中表的大小可以扩展到数千万行(在SQL Server上为&) - 我无法亲自为他人担保)没有问题。

我不是DBA,但在索引方面,我的理解是,您需要一个聚簇索引,以保持磁盘上相对接近的相关记录,并且在我的示例中,您可能需要非在USER_ID上也是非唯一索引,因为您会直接查询它,但除此之外,我没有具体的建议 - 除了阅读Stephane Faroult的优秀书The Art of SQL,它可以提供更多见解比我在这个复杂的话题上所能达到的要高祝你好运!

1

如果你想最终用户/管理员正在进行更改,你真的不能让他们访问架构和添加/删除关系和表等,他们打破了一些东西。

此前我使用过基于XML的通用架构来存储这样的信息。你最终像这样的东西(psydo-XML):

<数据>
<名称>东西< /名称>
< DOB> 2008-01-01 </DOB >
<地址>
<Street> 1a Foo St </Street >
...
< /地址>
< /数据>

为了能够使这个以HTML(或别的)的元数据文件来指定哪些每一种类型是,(即DOB =日期,地址/街道=字符串)和正确的渲染器,用于将输出渲染为与XML相同的heirachal外观。不确定这是否适合您的需求,因为它是如此通用,您指定布局和各种事物的能力有限。上述方法用于呈现通用配置文件。