标签: relational-database

我发现想要在我的功能程序中建模关系数据是很常见的.例如,在开发网站时,我可能希望使用以下数据结构来存储有关我的用户的信息:

data User = User 
  { name :: String
  , birthDate :: Date
  }

接下来,我想存储有关用户在我的网站上发布的消息的数据:

data Message = Message
  { user :: User
  , timestamp :: Date
  , content :: String
  }

此数据结构存在多个问题:

• 我们无法区分具有相似姓名和出生日期的用户.
• 用户数据将在序列化/反序列化时重复
• 比较用户需要比较他们的数据,这可能是昂贵的操作.
• 对字段的更新User是脆弱的 - 您可能忘记更新User数据结构中的所有事件.

这些问题是可管理的,而我们的数据可以表示为树.例如,您可以像这样重构:

data User = User
  { name :: String
  , birthDate :: Date
  , messages :: [(String, Date)] -- you get the idea
  }

但是,可以将数据整形为DAG(想象任何多对多关系),甚至可以作为一般图形(好的,也许不是).在这种情况下,我倾向于通过在Maps中存储我的数据来模拟关系数据库:

newtype Id a = Id Integer
type Table a = …

在一个新项目中,我需要努力使用lucene来实现搜索器.这个搜索者将是该项目的一个非常重要(和大)的部分.用MongoDb替换Relational Database + Lucene是有效还是方便？

编辑:好的,我会澄清:我不是在询问风险,我可以在这个项目中支付这个价格.我的观点是:MongoDB是否面向这种事情？我可以制作一个完整的搜索引擎,具有与Lucene相同的性能吗？一位朋友指出MongoDB是另一种选择,但我不知道Lucene性能是否带有文档备选(然后,我也会在MongoDB中看到它),或者,另一方面,反向索引和优化是完全的独立的文件导向.

有人可以向我解释3NF和BCNF之间的区别吗？如果您还可以提供一些示例,那就太棒了.谢谢.

我正在尝试学习OLAP和数据仓库,我对关系和维度建模之间的区别感到困惑.维度建模基本上是关系建模,但允许冗余/非标准化数据？

例如,假设我有(产品,城市,#销售)的历史销售数据.我理解以下是关系的观点:

Product | City | # Sales
Apples, San Francisco, 400
Apples, Boston, 700
Apples, Seattle, 600
Oranges, San Francisco, 550
Oranges, Boston, 500
Oranges, Seattle, 600

虽然以下是更具维度的观点:

Product | San Francisco | Boston | Seattle
Apples, 400, 700, 600
Oranges, 550, 500, 600

但似乎两种观点仍然可以在相同的星型模式中实现:

Fact table: Product ID, Region ID, # Sales
Product dimension: Product ID, Product Name
City dimension: City ID, City Name

直到你开始向每个维度添加一些额外的细节,差异才会开始出现.例如,如果您也想跟踪区域,关系数据库往往会有一个单独的区域表,以便保持所有规范化:

City dimension: City ID, City Name, Region ID
Region dimension: Region ID, Region …

我正在探索一个遗留数据库系统,对其内部知识知之甚少.我想找到调用另一个存储过程的所有存储过程A.

怎么做到最好？

我可以写这样的伪代码:

select name from AllStoredProcedures as Asp where Asp.TextualContent contains 'A'

Asp.TextualContent 表示SP中包含的实际SQL.

使用处理关系的MVC框架时定义外键有什么好处？

我正在使用一个关系数据库,其框架允许模型定义与关系.因为外键是通过模型定义的,所以外键似乎是多余的.在开发中管理应用程序的数据库时,编辑/删除使用外键的表是一件麻烦事.

通过完全放弃使用外键,使用外键是否有任何优势？

最近我和MongoDB一直在合作,我不得不说我非常喜欢它.然而,它是一个完全不同类型的数据库然后我被使用.我注意到它对于某些类型的数据肯定更好,但是对于高度规范化的数据库,它可能不是最佳选择.

然而,在我看来,它可以完全取代你可能拥有的任何关系数据库,并且在大多数情况下表现更好,这令人难以置信.这让我想问几个问题:

1. 面向文档的数据库是否正在开发为下一代数据库,并且基本上完全取代了关系数据库？
2. 是否可能更好地使用面向文档的数据库和关系数据库,以获得更适合其中一种的各种数据？
3. 如果面向文档的数据库不是要替换关系数据库,那么有没有人有一个数据库结构的例子,在关系数据库中绝对会更好(反之亦然)？

所以我试图设计一个数据库,允许我将一个产品与多个类别连接起来.这部分我想通了.但我无法解决的问题是持有不同类型的产品细节.

例如,产品可能是一本书(在这种情况下,我需要像isbn,作者等那样引用该书的元数据),或者它可能是商业列表(具有不同的元数据).

我应该怎么解决这个问题？

Daft SQL问题.我有一个像这样的表('pid'是自动增量主col)

CREATE TABLE theTable (
    `pid` INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
    `timestamp` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    `cost` INT UNSIGNED NOT NULL,
    `rid` INT NOT NULL,
) Engine=InnoDB;

实际表格数据:

INSERT INTO theTable (`pid`, `timestamp`, `cost`, `rid`)
VALUES
  (1, '2011-04-14 01:05:07', 1122, 1),
  (2, '2011-04-14 00:05:07', 2233, 1),
  (3, '2011-04-14 01:05:41', 4455, 2),
  (4, '2011-04-14 01:01:11', 5566, 2),
  (5, '2011-04-14 01:06:06', 345, 1),
  (6, '2011-04-13 22:06:06', 543, 2),
  (7, '2011-04-14 01:14:14', 5435, 3),
  (8, '2011-04-14 01:10:13', 6767, 3)
;

我想得到每个rid的最新行的PID(每个唯一RID 1个结果).对于样本数据,我想:

pid …

我将使用MongoDB创建一个学生管理系统.我将为学生提供一张桌子,为出勤记录提供另一张桌子.我可以在考勤表中找到一张钥匙到达学生桌,如下图所示吗？怎么样？