我参与了一个新项目，我必须从现有的关系数据库系统创建数据立方体。

我明白，现有的系统设计不当，我不知道从哪里开始。

我的问题是：

• 星型模式和数据立方体有什么区别？
• 我必须从哪里开始？从星型模式还是直接数据立方体？
• 数据立方体是从星型模式生成的吗？

我对关系数据建模的经验很少，这个问题可能看起来太基础了，我试图从很少的资源中弄清楚，仍然不清楚。请给出您的意见和建议？

如果我错过了与此问题相关的非常重要的内容，请也分享您对此的看法。

我被要求创建一些东西来跟踪每天收取的帐户成本，我正在尝试找出一个支持这一点的数据库表模式。

这是我所知道的

• 公司拥有超过 250 万个账户
• 其中，他们目前平均每月工作 200,000 人（随着人员配备水平而变化，目前处于较低水平）
• 他们有 13 种不同的成本类型要跟踪，并且警告说将来可能会增加更多
• 他们希望每天跟踪成本
• 成本不会在整个库存中分摊。它们要么分布在每月工作的帐户数量 (200,000) 中，要么用户可以输入帐户标识符以将成本应用于一组帐户，或者他们可以简单地指定将成本应用于哪些帐户。

我的第一个想法是标准化数据库：

帐户ID
日期
成本类型 ID
数量

我的问题是，做数学。这张桌子很快就会变大。假设所有 13 种成本类型都应用于当月的所有工作帐户，即每月200k * 13 * N days in month大约 75-8000 万条记录，或接近每年 10 亿条记录。

我的第二个想法是对其进行非规范化

帐户ID
日期
总消耗
成本类型 1
成本类型2
成本类型 3
成本类型 4
成本类型5
成本类型 6
成本类型7
成本类型8
成本类型9
成本类型10
成本类型11
成本类型12
成本类型13

这种方法更加非规范化，每月最多可创建 600 万条记录 ( 200k * N days in month)，或每年约 7200万条。它比第一种方法少很多，但是如果公司将来决定使用新的成本类型，则需要添加另一个数据库列。

在这两种方法中，您更喜欢哪种方法？为什么？您是否可以想到另一种替代方法可以更好地处理此问题？

我对报告绩效最感兴趣，包括总结报告和详细报告。将成本分摊到帐户的工作将在无人在场的情况下每晚运行。次要问题是数据库大小。现有的数据库已经接近300GB，我相信磁盘空间在500GB左右。

数据库是 SQL Server 2005

在 MySQL 中打开和关闭数据库连接（对于 Web 应用程序）的 CPU 密集程度如何

• ...当数据库软件在本地主机上时？
• ...当数据库软件在另一台机器上时？

我从小就受过教育——在那里我们学会了在应用程序的业务层之前设计数据库模式（或将 OOAD 用于其他一切）。我一直很擅长设计模式（恕我直言:) 并且规范化只是为了删除不必要的冗余，而不是影响速度的地方，即如果连接是性能下降，冗余就留在原地。但大多数情况并非如此。

随着一些 ORM 框架的出现，如 Ruby 的 ActiveRecord 或 ActiveJDBC（以及其他一些我不记得了，但我相信有很多）似乎他们更喜欢为每个表设置一个代理键，即使有些有主键，例如'email' - 彻底打破 2NF。好吧，我不太明白，但是当这些 ORM（或程序员）中的一些不承认 1-1 或 1-0|1（即 1 比 0 或 1）时，我（几乎）会感到紧张。他们规定，无论是否有大量nulls “今天的系统可以处理它”，最好将所有东西都放在一张大桌子上，这是我经常听到的评论。

我同意内存限制确实与规范化直接相关（还有其他好处:)但是在今天内存便宜和四核机器的时代，数据库规范化的概念是否只是留给文本？作为 DBA，您是否仍然练习标准化为 3NF（如果不是 BCNF :)？有关系吗？“脏模式”设计对生产系统有好处吗？如果它仍然相关，那么应该如何将其“用于”规范化。

（注意：我不是在谈论数据仓库的星形/雪花模式，它们具有冗余作为设计的一部分/需要，而是具有后端数据库（例如 StackExchange）的商业系统）

我有一个以这种方式创建的表：

--
-- Table: #__content
--
CREATE TABLE "jos_content" (
  "id" serial NOT NULL,
  "asset_id" bigint DEFAULT 0 NOT NULL,
   ...
  "xreference" varchar(50) DEFAULT '' NOT NULL,
  PRIMARY KEY ("id")
);

稍后插入一些行并指定 id：

INSERT INTO "jos_content" VALUES (1,36,'About',...)

稍后，一些记录被插入而没有 id 并且它们因错误而失败： Error: duplicate key value violates unique constraint。

显然，id 被定义为一个序列：

每个失败的插入都会增加序列中的指针，直到它增加到一个不再存在的值并且查询成功。

SELECT nextval('jos_content_id_seq'::regclass)

表定义有什么问题？解决这个问题的聪明方法是什么？

假设我有一个“交易”表，其中有一列“客户 ID”（外键）和一个带有“ID”（主键）的客户表。如何显示两个表之间的关系并显示“客户 ID”是“交易”表的外键，而“交易”表是“客户”表中的主键？

我在 google 上搜索了这个问题，并在这个论坛上搜索了我的查询，但找不到一个带有解决我问题的图表的确切示例。

如果可能，请用图表向我解释。

我正在阅读这篇 BBC 新闻文章和以下摘录，引起了我的注意。这听起来像是Always On Availability Groups或High Availability Mirroring，可能会自动包含安全性。

区块链是现代、高交易量应用程序的潜在可行数据库解决方案吗？

很容易看出它对个人医疗记录等小批量交易的价值，但是大批量数据库呢？

什么是区块链？

区块链依靠密码学来允许一组计算机在不需要中央参与者的情况下更改全局记录。

去除中间商可以降低几乎每个部门的成本。

区块链是一个分类帐，它按时间顺序或“链”记录一组称为“块”的数据所发生的一切。

作为一种货币，这是一项重要功能，因为它允许用户确保他们的数字货币是独一无二的，就像钱包中的每张纸币都是独一无二的一样。

“区块链技术将成为我们创造资产的方式，因为它允许你在不复制的情况下传输数字信息，”构建区块链网络的 Chain.com 的首席执行官 Adam Ludwin 说。

区块链可用于跟踪各种信息的历史并保持其价值，例如，医生可以使用它来更新医疗记录。

由于对区块链的每次更改都是在整个网络中同时进行的，因此不会丢失任何信息，并且由于更改无法撤消，系统保持其透明度。需要一个特殊的密钥来对每个块进行更改，因此个人可以通过保护该密钥来保证他们的记录安全。

我对数据库设计比较陌生，我决定制作自己的假设数据库以进行实践。但是，我无法对其进行建模和规范化，因为我认为存在许多多对多 (M:N) 关系。

一般场景描述

该数据库旨在保留有关在塞尔达系列中工作过的各种人物的数据。我想跟踪的控制台（S） ，一个游戏可以玩上，员工是曾在部分游戏的发展，乔布斯的员工有（很多员工在不同的工作职位在多个游戏等）

商业规则

• 多个员工可以在多个游戏上工作。
• 多个游戏可以在同一个控制台上。
• 多个控制台可以是同一个游戏的平台。
• 多个员工可以拥有相同的Job。
• 一个Employee可以有多个Jobs。
• 一个游戏可以有多个员工。
• 一个游戏在它的开发过程中可以有多种类型的工作
• 多个游戏可以附加相同类型的工作。
• 一个控制台可以有多个人在处理它。
• 一个人可以在多个控制台上工作。

属性名称和样本值

• Employee Name，可以分为First …

查找表（或一些人称之为代码表）通常是可以为特定列给出的可能值的集合。

例如，假设我们有一个名为party（用于存储有关政党的信息）的查找表，它有两列：

• party_code_idn，它保存系统生成的数值，并且（缺乏业务领域含义）用作真实键的代理。
• party_code, 是表的真实或“自然”键，因为它维护具有业务领域内涵的值。

让我们说这样的表保留了以下数据：

 +----------------+------------+
 | party_code_idn | party_code |
 +----------------+------------+
 |              1 | Republican |
 |              2 | Democratic |
 +----------------+------------+

在party_code列，这使价值“共和”和“民主”，在工作台的真正的关键，是建立了一个独特的约束，但我需要添加的party_code_idn，它定义为表（的PK虽然，从逻辑上说,party_code可以作为 PRIMARY KEY [PK])。

题

指向事务表中的查找值的最佳实践是什么？我应该建立外键 (FK) 引用(a)直接指向自然和有意义的值还是(b)代理值？

 +---------------+------------+---------+
 | candidate_idn | party_code |  city   |
 +---------------+------------+---------+
 |             1 | Democratic | Alaska  |
 |             2 | Republican | Memphis …