标签: schema-design

一对一的关系通常可以存储在同一个表中.有没有理由不把它们存放在同一张桌子上？

在Solr中,如果我们在架构中有一个带有stored ="true"的字段,并且我们更改了与该字段关联的分析器,是否可以仅更新此字段而无需重新索引所有文档？这可以使用新分析仪使用字段的"存储"值而不返回原始数据源吗？

由于SQLite引擎不会截断您存储在文本列中的数据,因此在定义架构时特定于列大小是否有任何优势？有人会更喜欢这个:

CREATE TABLE contact(
 id    INTEGER PRIMARY KEY, 
 name  VARCHAR(45),
 title VARCHAR(10)
);

对此:

CREATE TABLE contact(
 id    INTEGER PRIMARY KEY, 
 name  TEXT,
 title TEXT
);

为什么？

不具体是否有优势？

我正在尝试为MongoDB设计数据库模式,但希望能够直观地表示嵌入式文档.有点像这样:

http://www.mongodb.org/download/attachments/131465/reference.jpg?version=1&modificationDate=1253899724083

有谁知道一些让我这样做的软件？我知道我可以在纸上做,但我希望能够与同事分享架构并让他们编辑小东西.

我一直givenName+" "+surname在CN领域使用,昨晚我醒来时尖叫着'John Smith'怎么样？我可以想象任何一个雇用多个同名人士的大型组织.所以当然这不会起作用.人们用什么代替？

编辑注意:在inetOrgPersonCN中是DN的一部分.

编辑注意:在这种情况下,我期望成长为数十万用户条目.

从RDMBS背景来看,很难不考虑像连接这样的思想,特别是在使用无模式的MongoDB环境时.

我在博客上看到DBRefs仅在您知道您引用的对象类型时才有用.

为什么会这样？当然,他们有更多的用途.

假设我有一个用户集合和一个雇主集合.许多用户可以引用同一个雇主.对我来说,这是DBRef的完美使用.但是,这与我在博客上看到的内容相矛盾.

当然,我可以将雇主嵌入到每个用户集合中,但是当雇主改变时会发生什么？也许他们雇主改变地址或电话号码或其他东西.如果雇主嵌入在每个用户中,那么我必须更新每个用户的嵌入式文档.

那不可能有效.或者可以吗？

我们正在考虑使用HBase进行实时分析.

在HBase之前,我们将在日志文件上运行Hadoop Map Reduce作业并聚合数据,并将细粒度聚合结果存储在HBase中,以实现对聚合数据的实时分析和查询.因此HBase表将具有预聚合数据(按日​​期).

我的问题是:如何最好地设计HBase数据库的模式和主键设计,以实现快速但灵活的查询.

例如,假设我们将以下行存储在数据库中:

timestamp, client_ip, url, referrer, useragent

并说我们的map-reduce作业产生三个不同的输出字段,每个字段我们要存储在一个单独的"表"(HBase列族)中:

• date,operating_system,browser
• 日期,网址,推荐人
• 日期,网址,国家/地区

(我们的map-reduce作业从用户代理和client_ip数据中获取operating_system,browser和country字段.)

我的问题是:我们如何构建HBase模式以允许对这些字段或组合中的任何字段进行快速,接近实时和灵活的查找？例如,用户必须能够指定:

• 按日期操作系统("此日期范围内有多少iPad用户？")
• 按国家/地区和日期划分的网址("上个月来自此国家/地区的网址数量是多少？")

基本上任何其他自定义查询？

我们应该使用这样的键:

• date_os_browser
• date_url_referrer
• date_url_country

如果是的话,我们可以完成上面指定的那种查询吗？

我有一个动态问答的当前关系模型。我正在尝试查看是否可以将架构转换为 MongoDB 以提高性能和灵活性。

我们基本上有一系列问题和问题类型。这些问题被放在一个问题集中。

问题按特定顺序提出，但对于某些问题，根据答案，下一个问题可能会有所不同。

例如，如果 Q1=YES 那么问问题 Q9 否则问问题 Q2

关于如何在没有我目前使用的各种关系 tavles 的情况下设计这种模式的任何想法？

我需要将每日收盘价以及报价数据存储在MongoDB中。您将如何设计这样的模式？对于每日价格，我很想为每个股票代号准备一份文件，例如

{
    symbol: "AAPL",
    quotes: {
        {
           date: '2014-01-01',
           values: { open: 1, high: 1, low: 1, close: 1, volume: 100 }
        },
        {
           date: '2014-01-02',
           values: { open: 1, high: 1, low: 1, close: 1, volume: 100 }
        }, ...
    }
}

对于滴答数据，我可以每小时对一个子文档进行一系列类似的操作，完成上述操作。

但是，考虑到最大文档大小只有16MB，我相信可以很快达到限制，尤其是对于滴答数据。

我知道这种方法http://blog.mongodb.org/post/65517193370/schema-design-for-time-series-data-in-mongodb。那会是个好方法吗？即每天每个符号一个文档？

因此，您将如何分别设计每日价格和报价数据的架构？

假设您有一个"用户"记录的概念,您希望将其存储在数据存储中.

class User (db.Model):
  first_name = db.StringProperty()
  last_name = db.StringProperty()
  created = db.DateTimeProperty(auto_now_add=True)
  twitter_oauth_token = db.StringProperty()
  twitter_oauth_secret = db.StringProperty()

几乎在您使用用户对象时都会使用某些字段,例如first_name和last_name.

但是,有些字段只有一个用例,例如,twitter_oauth_token和twitter_oauth_secret,当95%的时间不需要它们时,打扰序列化和反序列化效率会有些低效.

所以,如果你拆分你的模型:

class User (db.Model):
  first_name = db.StringProperty()
  last_name = db.StringProperty()
  created = db.DateTimeProperty(auto_now_add=True)

class UserTwitterOauth(db.Model):
  oauth_token = db.StringProperty(required=True)
  oauth_secret = db.StringProperty(required=True)
  created = db.DateTimeProperty(auto_now_add=True)

你可以在UserTwitterOauth中为User提供一个ReferenceProperty,但这实际上是一对多的,因为没有什么能阻止每个用户使用多个UserTwitterOauth对象.您希望最多只有一个UserTwitterOauth与任何用户相关.您如何一对一地联系这些模型？