为动态逻辑数据库模式提供存储的推荐架构是什么？
澄清一下:如果系统需要为模型提供存储,模型的架构可能会在生产中被用户扩展或更改,那么有哪些优秀的技术,数据库模型或存储引擎可以实现这一点？
一些可能的说明:
通过动态生成的DML创建/更改数据库对象
创建具有大量稀疏物理列的表,并仅使用"重叠"逻辑模式所需的表
创建一个"长而窄"的表,该表将动态列值存储为行,然后需要进行旋转以创建包含特定实体的所有值的"短,宽"行集
使用BigTable/SimpleDB PropertyBag类型系统
任何基于现实世界经验的答案都将不胜感激
你提出的建议并不新鲜.很多人都尝试过......大多数人都发现他们追求的是"无限"的灵活性,而不是最终的结果.这是数据库设计的"蟑螂汽车旅馆" - 数据进入,但几乎不可能把它拿出来.尝试并概念化为任何类型的约束编写代码,你会明白我的意思.
最终结果通常是一个更难以调试,维护和充满数据一致性问题的系统.情况并非总是如此,但往往是这样的结果.主要是因为程序员没有看到这个火车残骸即将到来并且未能防御性地编码.此外,通常最终会出现"无限"灵活性并非必要的情况; 这是一个非常糟糕的"气味",当开发团队得到一个说"Gosh我不知道他们将在这里放置什么样的数据,所以让他们把它放在任何地方"......并且最终用户很好拥有他们可以使用的预定义属性类型(编写通用手机#,
如果您有一个非常优秀的开发团队并且非常了解这个设计必须克服的问题,那么您可以成功编写一个设计良好,而不是非常错误的系统.大多数时候.
不过,为什么要开始考虑那么多的赔率呢？
不相信我？谷歌"One True Lookup Table"或"单桌设计".一些好的结果:http://asktom.oracle.com/pls/asktom/f？p = 100:11:0 ::::P11_QUESTION_ID: 10678084117056
http://thedailywtf.com/Comments/Tom_Kyte_on_The_Ultimate_Extensibility.aspx?pg=3
http://www.dbazine.com/ofinterest/oi-articles/celko22
http://thedailywtf.com/Comments/The_Inner-Platform_Effect.aspx?pg=2
MSSQL中的强类型xml字段对我们有用.
像其他人所说的那样,除非你别无选择,否则不要这样做.需要这种情况的一种情况是,如果您要销售必须允许用户记录自定义数据的现成产品.我公司的产品属于这一类.
如果您确实需要允许客户执行此操作,请参考以下提示:
- 创建强大的管理工具以执行架构更改,并且不允许以任何其他方式进行这些更改.
- 使其成为一种管理功能; 不允许普通用户访问它.
- 记录每个架构更改的每个细节.这将帮助您调试问题,如果客户做了一些愚蠢的事情,它也会为您提供CYA数据.
如果你能成功完成这些事情(特别是第一个),那么你提到的任何架构都可以工作.我的首选是动态更改数据库对象,因为这样可以在访问存储在自定义字段中的数据时利用DBMS的查询功能.其他三个选项要求您加载大块数据,然后在代码中执行大部分数据处理.
我有类似的要求,并决定使用无架构的MongoDB.
MongoDB(来自"humongous")是一个用C++编程语言编写的开源,可扩展,高性能,无架构,面向文档的数据库.(维基百科)
强调:
具有丰富的查询功能(可能最接近SQL DB)
生产就绪(foursquare,sourceforge使用它)
Lowdarks(你需要了解的东西,所以你可以正确使用mongo):
没有交易(实际上它有交易但只有原子操作)
这个东西在这里:http://ethangunderson.com/blog/two-reasons-to-not-use-mongodb/
耐久性..主要是ACID相关的东西
我在一个真实的项目中做到了:
数据库由一个表组成,其中一个字段是一个50的数组.它上面有一个'word'索引.所有数据都是无类型的,因此'word index'按预期工作.数字字段表示为字符,实际排序已在客户端完成.(如果需要,仍然可以为每种数据类型提供多个数组字段).
逻辑表的逻辑数据模式保存在具有不同表行"类型"(第一个数组元素)的同一数据库中.它还支持使用相同"类型"字段的写时复制样式的简单版本控制.
好处:
您可以动态重新排列和添加/删除列,无需转储/重新加载数据库.任何新的列数据都可以在零时间内(虚拟地)设置为初始值.
碎片是最小的,因为所有记录和表都是相同的大小,有时它会提供更好的性能.
所有表模式都是虚拟的.任何逻辑模式结构都是可能的(甚至是递归的,或面向对象的).
它适用于"一次写入,大多数读取,不删除/删除标记"数据(大多数Web应用程序实际上就是这样).
缺点:
仅使用完整单词索引,无缩写,
复杂查询是可能的,但性能略有下降.
取决于您的首选数据库系统是否支持数组和单词索引(它是在PROGRESS RDBMS中添加的).
关系模型仅在程序员的脑海中(即仅在运行时).
而现在我认为下一步可能是 - 在文件系统级别实现这样的数据库.这可能相对容易.
拥有关系数据库的关键在于保持数据的安全性和一致性.在您允许用户更改架构的那一刻,您的数据完整性就会出现......
如果您需要存储异构数据,例如CMS场景,我建议将XSD验证的XML存储在一行中.当然,你会失去性能和简单的搜索功能,但这是一个很好的权衡恕我直言.
从2016年开始,忘记XML了!使用JSON存储非关系数据包,并使用适当类型的列作为后端.您通常不需要通过包内的值进行查询,即使许多当代SQL数据库本身都了解JSON,这也会很慢.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
