标签: data-modeling

我想创建一个产品目录,其中包含目录中每种产品类型的复杂细节.产品类型与它们有很多不同的数据; 一些只包含通用数据,一些包含一些额外的数据字段,一些包含许多特定于该产品类型的字段.我需要轻松地向系统添加新的产品类型并尊重它们的配置,我喜欢有关如何为这些产品设计数据模型以及如何处理持久性和检索的技巧.

有些产品非常通用,我打算使用通用的UI来编辑这些产品.具有与之关联的可扩展配置的产品将获得为其编辑而创建的新视图(和控制器).我希望所有自定义产品都定义了自己的模型,但是要共享一个共同的基类.基类将表示没有自定义字段的通用产品.

需要处理的示例产品:

1. 通用产品
   • 描述
2. 灯泡
   • 描述
   • 类型(带有荧光灯,白炽灯,卤素灯,led灯)
   • 瓦数
   • 风格(洪水,斑点等)
3. 冰箱
   • 描述
   • 使
   • 模型
   • 样式(在域模型中使用枚举)
   • 水过滤器信息
     • 零件号
     • 描述

我希望使用MEF来发现系统中可用的产品类型.我计划创建包含产品类型模型,视图和控制器的程序集,将这些程序集放入bin中,让应用程序发现新的产品类型,并在导航中显示它们.

1. 使用SQL Server 2008,存储这些不同类型的产品的最佳方法是什么,允许在不增加数据库模式的情况下添加新类型？

2. 从数据库中检索数据时,将这些多态实体转换为正确的域模型的最佳方法是什么？

更新和澄清

1. 为了避免内部平台效应,如果每个产品类型都有一个数据库表(用于存储该类型的产品),那么我仍然需要一种方法来检索跨越产品类型的所有产品.如何实现？

2. 我与Nikhilk更详细地讨论了他的SharePoint参考.具体来说,他正在谈论这个:http://msdn.microsoft.com/en-us/library/ms998711.aspx.它看起来很有吸引力.无需解析XML; 并且可以进行一些索引,允许对数据进行简单快速的查询.例如,我可以说"找到所有75瓦灯泡",因为当行代表灯泡时,行中的第一个int列是瓦数.应用层中的某些东西(NHibernate？)将定义从产品类型到用户数据模式的映射.

3. 投下具有属性表的架构,因为这可能导致每个产品有很多行.这可能会导致索引困难,而且所有查询都必须基本上转移数据.

我正在寻找资源来帮助将我的设计技能从传统的RDBMS数据存储迁移到AppEngine DataStore(即:'Soft Schema'风格).我已经看过几个演讲,全部涉及总体主题和一些特定技巧.

我想知道是否有一个地方我们可以将经验("来自战壕")的知识汇集到现实世界的方法上,重新思考数据的结构,特别是移植现有的应用程序.我们基于Hibernate,并且可能已经使用我们的数据模型走错了路径,产生了一些我们的数据库正在努力解决的粗略查询.

请回复:

1. 您已将一个非平凡的应用程序移植到AppEngine
2. 您已经在AppEngine中从头开始创建了一种常见的应用程序
3. 你没有做过1或2,但正在考虑它,并希望分享你自己的发现到目前为止.

编程的圣杯是一次解决问题,并永远重复使用该解决方案.然而,尽管我付出了最大的努力,但我发现我经常重新处理熟悉的问题.除了GoF设计模式之外,我曾多次设计过日历,内容管理和人/组织地址簿,仅举几例.

我想知道是否有任何好的资源(书籍,网站,等等)我可以仔细阅读常见的高级商业设计.我确实意识到我的项目和我可能发现的任何模式之间的要求会有所不同,但我确实希望事情的核心保持不变,那将会有很多来之不易的经验.此外,尽管如此,我只是喜欢阅读有关设计出现的决策背后的过程和理由.当商店,初创公司和编码员对他们的设计透明时,我喜欢它.(例如37Signals,Garret Dimon)

这篇文章涉及这个主题并将这些高级设计模式称为"功能设计模式",但我不确定这是我所描述的常用术语.对"功能设计模式"的搜索并未发生太多变化.我还搜索了"领域特定设计模式"和"数据模型设计模式",后者提供了一个有趣的结果,所以这可能更多的是目标.你知道我想用什么术语描述什么？有什么好资源吗？是否有其他商店/程序员透明地展示他们的新设计？

想象一下,你生活在一个非常简单的例子中 - 想象一下你的MySQL数据库中有一个人员表:

create table person (
    person_id int,
    name text
)

select * from person;

+-------------------------------+
|   person_id |            name |
+-------------------------------+
|           1 |           Alice |
|           2 |             Bob |
|           3 |           Carol |
+-------------------------------+

这些人需要协作/一起工作,所以你有一个链接表,将一个人的记录链接到另一个人:

create table person__person (
    person__person_id int,
    person_id int,
    other_person_id int
)

这种设置意味着人们之间的链接是单向的 - 即Alice可以链接到Bob,而Bob没有链接到Alice,更糟糕的是,Alice可以链接到Bob , Bob可以同时链接到Alice,在两个单独的链接记录中.由于这些链接代表了工作关系,在现实世界中它们都是双向的相互关系.以下是此设置中的所有内容:

select * from person__person;

+---------------------+-----------+--------------------+
|   person__person_id | person_id |    other_person_id |
+---------------------+-----------+--------------------+
|                   1 |         1 |                  2 |
|                   2 |         2 …

我不是数据库人.我对数据建模的理解并不广泛.从有限的理解来看,逻辑数据模型是物理数据模型的抽象,不包含特定存储产品/介质的任何特定内容.逻辑数据建模似乎确实涉及业务主题专家在他们的过程中,因此在我看来对冲领域模型的世界.

我认为逻辑数据模型更关注数据,而域模型更关注问题域.考虑归一化的逻辑模型,域模型较少.我只是让自己在这里感到困惑,所以如果有人可以通过例子简洁地清除两者之间的差异,我将不胜感激.

非常感谢!

您如何在MongoDB中为电子邮件应用程序(如gmail)建模？你会模特Conversation吗？Inbox/ OutBox？还是mail？

谢谢

提示这个问题的问题与创建类似于构建IR系统时使用的巨大倒置指数有关.IR社区的一般口号是关系数据库不适合构建IR系统.无论如何,在查看posgres时,行元组开销是23字节+填充(请参阅" Postgres常见问题解答 "中的"从典型文本文件存储数据需要多少数据库磁盘空间？" ).这对我的工作来说太大了(不缩放).

顺便提一下,我的数据集是17个文本,需要4-5个表,具体取决于问题的切片方式.我记得在sqlite中尝试了一个模式,db文件打破了100个演出

我很想知道Sql Server/MySql/Sqlite/Berkeley db(所有访问方法)/ Berkley Db的sqlite3接口/ Kyoto,Tokyo db和Firebird的每行开销是多少.任何一个人都无法回答我猜的问题,除非有人像我一样好奇地调查此事.

编辑

• Postgres - 23(OMG!)byte tuple header + padding.
• bdb-hash:26字节页面开销,6字节密钥/数据开销(组合).
• Bdb-btree:26字节页面开销,10字节密钥/数据开销(组合).
• MySql Innodb:这里分析(5字节标题+事务id +滚动指针=每行18个)注意到自己:为什么事务ID出现在磁盘上？什么是滚动指针？
• Sql Server:从这里开始.捕获变量元素长度,具有静态数据类型的行会产生非常适度的开销.开销估计很大程度上取决于模式和数据的性质.变量元素越大,开销越大.

我可以找到许多支持使用Canonical模型的信息,但我想知道它的一些缺点或缺点,并且可能获得一些关于创建这种模型的各种方法的知识.

我一直在使用couchdb中的图形结构(具有命名关系的属性图)建模,并想知道我会发现什么是性能的潜在瓶颈.

我使用以下原则:

• 保持文件小.
• 尝试尽可能少地嵌入.
• 将文档之间的所有关系记录为新文档(链接).

似乎所有这些原则都与CouchDB哲学相矛盾,

例如,有了这个原则,标记一个人就成了三个文件:

{ _id: '10', type: 'person', 'name': 'John Doe' }
{ _id: '20', type: 'tag', 'name': 'Important' }
{ _id: '30', type: 'link', from: 10, to: 20, name: 'tag' }

我还在一个_design名为的文档中创建了以下视图links:

{
  outgoing: {
    map: function(doc) {
      if (doc.type == 'link') {
        emit([doc.from, doc.name], {_id: doc.to});
      }
    }
  },
  incoming: {
    map: function(doc) {
      if (doc.type == 'link') {
        emit([doc.to, doc.name], { _id: doc.from });
      }
    }
  }
}

我可以通过这些网址获取文档传入或传出的所有链接: …

使用图形数据库时,最难解决的问题是选择粒度级别.让我们说我有一个图表显示在一周中的某些日子发生的事情:垃圾日,周五墨西哥比克,周五BYOB等.

• 我可以让每一天都成为一个节点(周一,周二,周三,......),这样,查询特定的日子很快.
• 我可以创建一个名为Day的节点,并使用星期几添加属性名称.这样,显示图表中的所有日子都很容易查询.

对自己思考,使节点非常具体是不好的,因为粒度没有限制.例如,星期六早上,晚上和晚上,或者更糟糕的是,每天每小时一个新节点.我还可以通过将星期六节点通过"晚上"边缘链接到垃圾日节点来使边缘成为粒度的一个组成部分.

我偶尔遇到类似的问题,例如; 我应该根据一个人的全名创建一个新节点,还是一个名为"Person"的节点,其属性为"name".然后我根据便利性制作特定或一般的节点,但我觉得可能有一些最佳实践或更高级别的原则我缺少.我不清楚如何判断哪条路更好.