标签: data-modeling

我的问题是关系数据库系统中的继承建模.我有规范的数据模型,并且我有一些与产品定价相关的字段,从产品表继承某些属性,我想在MySQL关系数据库中建模这种继承,所以,

"我们如何在关系数据库中进行继承建模？"

谢谢.

对于我的应用程序来说,能够从firebase中的集合中随机选择多个文档至关重要.

由于Firebase(我知道)没有内置本机函数来实现这样做的查询,我首先想到的是使用查询游标来选择随机的开始和结束索引,前提是我有多少文档集合.

这种方法只能以有限的方式起作用,因为每个文件都会按照其相邻文件的顺序提供; 但是,如果我能够通过其父集合中的索引选择文档,我可以实现随机文档查询,但问题是我找不到任何描述如何执行此操作的文档,即使您可以执行此操作.

这是我想要做的,考虑以下firestore架构:

root/
  posts/
     docA
     docB
     docC
     docD

然后在我的客户端(我在Swift环境中)我想编写一个可以执行此操作的查询:

db.collection("posts")[0, 1, 3] // would return: docA, docB, docD

无论如何我能做到这一点吗？或者,有不同的方式我可以以类似的方式选择随机文档吗？

请帮忙.

顺便说一下 - 参考数据建模,我指的是逻辑或概念数据模型 - 而不是物理模型.

工作中的讨论提出了这个问题; 我自然而然地跳到维基百科以获得一些基本的定义 - 希望他们可以澄清差异 - 但他们没有......

概念模式或概念数据模型是概念及其关系的映射.

逻辑数据模型看起来非常相似(根据此定义):

一个逻辑数据模型的系统工程(LDM)是一个组织的数据,在术语实体和关系来组织的代表和独立于任何特定的数据管理技术.

其中,作为...

解决问题和软件工程中的域模型或域对象模型(DOM)可以被认为是描述该系统中涉及的各种实体及其关系的系统的概念模型.

领域模型与概念数据模型之间的差异似乎特别模糊.

增加这种混淆的一个原因是(从我所看到的)域模型通常使用UML类图建模 - UML类图中的类实体支持方法 - 我们的同事坚持认为域模型必须不包含"操作".我可以使用UML类图的子集来理解域建模器 - 但假设人们在使用它们所使用的工具支持它时不会包含"操作"并不危险吗？

在SQL和关系理论(CJ Date,2009)中,第4章主张避免重复行,并避免NULL存储数据中的属性.虽然我没有避免重复行的麻烦,但我很难看到如何在不使用的情况下对数据进行建模NULL.举个例子来说 - 这有点像下班.

我们有一个artist表,其中包含一gender列.这是gender表的外键.然而,对于一些艺术家来说,我们并不知道他们的性别 - 例如,我们已经获得了一个没有艺术家描述的新音乐列表.如何在不使用的NULL情况下表示这些数据？我看到的唯一解决方案是在gender表格中添加一个新的性别"未知" .

虽然我非常喜欢这本书,但在本章结束时我真的很失望:

当然,如果禁止空值,则必须通过其他方式处理丢失的信息.不幸的是,那些其他手段太复杂了,不能在这里详细讨论.

这是一个真正的耻辱 - 因为这是我等待阅读的解决方案!有一篇参考资料来阅读有很多出版物要阅读的附录,但在我潜入阅读这些内容之前,我希望能有更多的实际总结.

我有几个人评论说他们不明白我为什么要避免'NULL'所以我会再次引用这本书.请执行以下查询:

SELECT s.sno, p.pno
  FROM s, p
 WHERE s.city <> p.city
    OR p.city <> 'Paris'

现在,以s.city为伦敦为例,p.city为Paris.在这种情况下,伦敦<>巴黎,所以查询是真的.现在假设p.city不是Paris,并且实际上是xyz.在这种情况下,(London <> xyz)OR(xyz <> Paris)也是True.所以,给定任何数据 - 这个查询都是真的.但是,如果xyz为"NULL",则场景会发生变化.在这种情况下,这两个表达式既不是True 也不是 False,它们实际上是Unknown.在这种情况下,因为结果未知,您将不会返回任何行.

从2值逻辑到3值逻辑的转变很容易引入这样的错误.事实上,我刚刚在工作中介绍了一个激励这篇文章的内容.我想要所有的行,type != 0然而,这实际上最终匹配type == 0 OR type IS NULL- 令人困惑的行为.

我是否NULL在未来对数据进行建模尚不清楚,但我很好奇其他解决方案是什么.(我也一直认为,如果你不知道,你应该使用NULL).

代理键,合成键和人工键之间是否有任何差异？

我不清楚确切的区别.

我想知道你是否有一个网站上有十几种不同类型的列表(商店,餐馆,俱乐部,酒店,活动)需要不同的字段,是否有一个好处,创建一个表定义如下所示的列
示例:

shop_id | name | X | Y | city | district | area | metro | station | address | phone | email | website | opening_hours

或者更类似于此的抽象方法:

object_id | name        
---------------
1         | Messy Joe's  
2         | Bate's Motel 

type_id | name
---------------
1       | hotel
2       | restaurant


object_id | type_id
---------------
1         | 2
2         | 1

field_id | name           | field_type
---------------
1        | address        | text
2        | opening_hours  | date 
3        | …

最近我将我的数据模型从Firebase移到了Firestore.我的所有代码都正常工作,但是我的嵌套查询有一些丑陋的问题需要检索一些数据.这是重点:

现在我的这个部分的数据模型看起来像这样(是的!另一个粉丝/饲料示例):

{
  "Users": { //Collection
    "UserId1" : { //Document
      "Feed" : { //Subcollection of Id of posts from users this user Follow
        "PostId1" : { //Document
          "timeStamp" : "SomeDate"
        },
        "PostId2" : {
          "timeStamp" : "SomeDate"
        },
        "PostId3" : {
          "timeStamp" : "SomeDate"
        }
      }
      //Some data
    }
  },
  "Posts":{ //Collection
    "PostId1":{ //Document
      "Comments" :{ //Subcollection
        "commentId" : { //Document
          "authorId": "UserId1"
          //comentsData
        }
      },
      "Likes" : { //Subcollection
        "UserId1" : { //Document
          "liked" : true
        }       
      }
    } …

我被赋予了设计数据库的任务,以便为我们公司存储大量信息.因为任务相当大并且包含用户应该能够做的事情的多个模块,所以我担心为此设计一个好的数据模型.我只是不想最终得到一个设计糟糕的数据库.

我希望有一些合适的数据库结构示例,用于合同/计费/订单等,以便将它们组合在一个漂亮的关系数据库中.有没有资源可以帮我提供一些相关的例子？

我经常遇到通过选择框等形式公开内部数据库主键的Web应用程序.偶尔我会看到javascript匹配一个切换逻辑的int或guid魔术值.

最佳做法是避免泄露Web应用程序中行的所有内部标识符,以防止外人了解您的系统太多,并可能使用它来利用您的系统.如果是这样,解决这个问题的最佳方法是什么？

您是否应该向Web应用程序公开可以转换回主键的其他值？

谢谢

编辑

在一个完美的世界中,您的应用程序将是100%安全的,因此如果您遮挡了一些东西并不重要.显然情况并非如此,所以我们是否应该谨慎对待并且不公开这些信息？

有人指出Stackoverflow可能暴露了Url中的一个密钥,这可能很好.但企业应用程序的注意事项有何不同

我想一劳永逸地知道如何编写UML基数,因为我经常不得不对它们进行辩论(因此非常欢迎证明和来源:)

如果我想解释一个Mother可以有几个Child人,但一个Child只有一个Mother,我应该写:

Mother * ---------- 1 Child

要么

Mother 1 ---------- * Child

？