标签: data-modeling

每个人Customer都有一个实际地址和一个可选的邮寄地址.你最喜欢的模型是什么？

选项1. Customer具有外键Address

   Customer   (id, phys_address_id, mail_address_id)
   Address    (id, street, city, etc.)

选项2. Customer具有一对多关系Address,其中包含用于描述地址类型的字段

   Customer   (id)
   Address    (id, customer_id, address_type, street, city, etc.)

选项3.地址信息被去规范化并存储在 Customer

   Customer   (id, phys_street, phys_city, etc. mail_street, mail_city, etc.)

我最重要的目标之一是简化对象关系映射,所以我倾向于第一种方法.你的想法是什么？

如果我在两个表之间有关系(两个表都有自己的主键),那么应该指导我决定哪个表应该存储外键？我知道这种关系的本质可能很重要(一对一,一对多,多对多,单向,双向),而且访问模式也很重要.虽然做出决定的系统方法是什么？

我是数据库的新手,我从未使用过任何RDBMS.但是我得到了关系数据库的基本概念.至少我想我做;-)

假设我有一个用户数据库,每个用户都有以下属性:

• 用户
  • ID
  • 名称
  • 压缩
  • 市

在关系数据库中,我将在一个名为的表中对其进行建模user

• 用户
  • ID
  • 名称
  • LOCATION_ID

并有一个名为的第二个表 location

• 地点
  • ID
  • 压缩
  • 市

并且location_id是location表中条目的外键(引用).如果我理解正确的优势就在这里,如果某个城市的邮政编码发生变化,我只需要改变一个条目.

那么,让我们去非关系型数据库,在那里我开始使用Google App Engine.在这里,我真的会对它进行建模,就像它在规范中首先写下来一样.我有一种user:

class User(db.Model):
    name = db.StringProperty()
    zip = db.StringProperty()
    city = db.StringProperty()

优点是我不需要加入两个"表",但缺点是,如果邮政编码改变,我必须运行一个遍历所有用户条目并更新邮政编码的脚本,对吗？

因此,现在Google App Engine中还有另一个选项可供使用ReferenceProperties.我可以有两种:user和location

class Location(db.Model):
    zip = db.StringProperty()
    city = db.StringProperty()

class User(db.Model):
    name = db.StringProperty()
    location = db.ReferenceProperty(Location)

如果我没错,我现在拥有与上述关系数据库完全相同的模型.我现在想知道的是,首先,我所做的是错误的,这会破坏非关系型数据库的所有优点.我明白,为了获得zip和城市的价值,我必须运行第二个查询.但在另一种情况下,要对邮政编码进行更改,我必须运行所有现有用户.

那么这两种建模可能性在Google数据存储区等非关系数据库中的含义是什么呢？它们的典型用例是什么,这意味着何时我应该使用一个,另一个使用何时.

另外作为一个额外的问题,如果在非关系数据库中我可以建模与关系数据库中的模型完全相同的模型,为什么我应该使用关系数据库呢？

很抱歉,如果其中一些问题听起来很幼稚,但我相信他们会帮助一些对数据库系统不熟悉的人,以便更好地理解.

考虑这种情况,我正在尝试为公司建模数据库:

• 实体:Employees,Managers,Departments.
• 一个Employee只有1作品Department而Department可能有许多Employees在它的工作.
• A Manager可以只管理1个Department,类似的Department可能只有1个Manager.
• 一个Manager监督很多Employees,但一个Employee只由一个监督Manager.

现在我有两种方法来模拟这个:

第一解决方案

我会考虑Manager实体继承Employee实体,考虑到我将保留管理者独有的数据(例如奖金和状态).

• 由于之间的关系Department,并Employee为1:N后来我就把这 Department Id作为一个外键Employee表的Works 关系.

• 由于之间的关系Department,并Manager为1:1后来我就把这 Department Id作为一个外键Manager表的Manages 关系.

问题:我如何表示Manager和之间的递归关系Employee？

二解决方案:

我认为Manager不需要实体其他Employees …

当我在大学学习时,他们教我们数据库的基础知识,基础知识和规则,其中一个最重要的规则是约束(主键,外键),以及如何建立1-m,1-1,mn关系.

现在,当我转向真实的商业环境时,他们告诉我:你应该忘记你所教过的一切; 没有约束,所有这些关系都是逻辑的,没有主键,没有外键,你可以通过代码制定约束.

我不知道谁是对的:我在学术生活中学到了什么,或者在新的现实生活中学到了什么.你怎么看？

寻找工具(windows平台)从现有的Oracle数据库中生成ER图(或类似的).
有哪些好的工具可以免费使用或成本低廉？

我正在寻找一个模式,算法或库,它将采用一组日期并返回一个退出的描述,如果一个退出,即集[11-01-2010,11-08-2010,11-15-2010 ,11-22-2010,11-29-2010]会产生类似"11月的每个星期一".

有没有人见过这样的事情,或者对实施它的最佳方法有任何建议？

在Xcode中创建数据模型后,它会为每个对象关系抛出以下错误:

Consistency Error:
Setting the No Action Delete Rule on [object relationship] is an advanced setting

什么是Xcode试图告诉我,我该如何回应？

我正在尝试使用DynamoDB和NoSQL.

对于我需要建立学生与班级关系这一事实,对学生表和班级表进行建模的最佳(对吗？)方法是什么？我考虑到DynamoDB中没有第二个索引可用.

该模型需要回答以下问题:

哪个学生在特定班级？

学生参加哪些课程？

谢谢

在我作为开发人员的工作中我必须解决的大多数问题都与数据建模有关.例如,在OOP Web应用程序世界中,我经常需要更改对象中的数据属性以满足新的要求.

如果我很幸运,我甚至不需要以编程方式添加新的"行为"代码(函数,方法).相反,我可以通过注释属性(Java)来声明添加验证甚至UI选项.

在函数式编程中,由于模式匹配和数据构造函数(Haskell,ML),添加新数据属性似乎需要大量代码更改.

如何最大限度地减少此问题？

这似乎是一个公认的问题,因为Xavier Leroy在"对象和类与模块"的第24页很好地说明 - 总结那些没有PostScript查看器的人,它基本上说FP语言比OOP语言更好地添加新的对数据对象的行为,但OOP语言更适合添加新的数据对象/属性.

FP语言中是否有任何设计模式可以帮助缓解此问题？

我已经阅读了Phillip Wadler 建议使用Monads来帮助解决这个模块化问题,但我不确定我是怎么理解的？