标签: database-design

我正在创建一个 RESTful API。我正在努力决定围绕我的资源设计我的数据库表的最佳方式。

最初，我认为每个资源一个表是一个很好的方法，但我现在担心这会导致你在资源链的下游形成指数级更大的表。

例如，假设我有三个资源 - 用户、客户、销售。用户是我的 api 的订阅者，客户是用户的客户，销售是每个客户对用户帐户的购买。

一个销售资源的访问方式如下

GET /users/{userID}/clients/{clientID}/sales/{salesID}

因此，如果有 10 个用户，每个用户有 10 个客户，并且每个客户有 10 个销售，那么表的大小会随着资源链越往下而越大。

我相当有信心 SQL 可以处理大表，但我不确定读取和写入将如何减慢速度。上面的例子可能没有说明它，但我的 api 将有越来越多的写入和读取我们走的资源链越远。因此，我的数据库中最大的表将比较小的表被读取和写入更多次。

在运行查询之前连接表也是必要的。原因是我允许每个用户有一个同名的客户端。为避免获取错误的客户端数据，用户表和客户端表由 {userID} 连接。销售也是如此。加入大表并运行读写会进一步减慢速度吗？

我已经阅读了几个显示时间有效性和时间特征的 oracle 教程。但是，在我阅读的示例中，演示表中没有使用主键。

http://docs.oracle.com/cd/E16655_01/appdev.121/e17620/adfns_design.htm#ADFNS1005 http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/12c/r1/ilm /temporal/temporal.html

是否应该将主键添加到这些表中？我问是因为我想知道这些时态表中的一个应该如何被另一个表引用。我可以将一个时态表中的外键添加到另一个时态表吗？

如果我添加一个 pk/外键关系，然后用 pk 更新表中的引用，带有 fk 的表指向一个不再相关的记录......时态数据是否破坏了正常的主键 - 外键关系？如果是这样，这如何影响性能，我是否只使用普通列作为“外键”并为查询中的引用时间段选择正确的列？

有没有人知道或手头有任何示例或教程来显示具有正常或伪正常 pk / fk 用法的时间数据？

谢谢

我正在处理现有的 MySQL 数据库。我的任务是为该现有应用程序上的计费系统创建一个新的数据模型。

我创建了一个概念数据模型（点击放大）：

＃＃要求

1. 多种付款类型（例如定期、一次性、分期付款）。

2. 多种支付方式（现金、支票、网上银行）。

3. 供应商（公司）与我们公司（营销主管）之间的合同

4. 供应商可以通过从他们的页面充值（类似于预付费充值）将金额添加到他们的帐户中。

5. 使用不同的包，这取决于包。供应商总余额将除以价值（包裹价值/365）。

6. 如果余额变为 0，他们将不会使用他们的服务，例如：

   set  t1 = package_value / 365  
   if        
   total_balance / t1 > 0
   set
           service = active  
   else
   set
           service = inactive
   

   Run Code Online (Sandbox Code Playgroud)

##SQL 代码

use database_name;
/*==============================================================*/
/* table: company_account                                       */
/*==============================================================*/
create table company_account
(
   account_id           int not null auto_increment,
   company_id           int not null,
   date_created         date not null default now(),
   date_replaced        date not null default '9999-12-31',
   created_by           int not null,
   is_active            bit(1) default 1,
   primary key (account_id)
); …

我在设计时态数据库时遇到问题。我需要知道如何确保在商店的任何给定时间范围内我只有一个活动记录。我已经阅读了这个答案，但恐怕我无法理解触发器的工作原理。特别是，我如何将触发器工作到我现有的触发器中，以防止更新记录，而是插入新记录。我真正的问题是，当完成日期为空时，我不知道如何防止 Store 有多个生效日期。（即防止商店的 2 个活动记录）。

这就是我所拥有的，但它允许我为具有不同生效日期的商店插入新记录。

表定义：

/****** Object:  Table [PCR].[Z_STORE_TEAM]    Script Date: 05/09/2014 13:05:57 ******/
IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[Z_STORE_TEAM]') AND type in (N'U'))
DROP TABLE [Z_STORE_TEAM]
GO

IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[Z_STORE_TEAM]') AND type in (N'U'))
BEGIN
CREATE TABLE [Z_STORE_TEAM](
    [STORENUM] [int] NOT NULL,
    [TEAM] [varchar](10) NULL,
    [EFFECTIVE] [date] NOT NULL,
    [FINISHED] [date] NULL,
PRIMARY KEY CLUSTERED 
(
    [STORENUM] ASC,
    [EFFECTIVE] ASC
)WITH (PAD_INDEX  = …

我正在创建一个带有主键约束和该表中的非聚集索引的新表。

我知道，我想创建另一个具有相同结构和值以及键和索引的表。

create table Dummy (id integer ,name varchar(20),salary integer
Constraint PK_Con_id primary key(id))

insert into Dummy values(11,'AAA',1000);
insert into Dummy values(12,'BBB',2000);
insert into Dummy values(13,'CCC',3000);
insert into Dummy values(14,'DDD',4000);

select * from Dummy;

create nonclustered index IX_Name 
on Dummy(Name)

现在我正在创建Dmy表，但键和约束没有反映Dmy在 SQL Server 2008 R2 的表中。

SELECT * 
INTO Dmy 
FROM Dummy

我在表上添加新列时遇到问题。
我尝试运行了几次，但是运行了 10 多分钟后，由于锁定时间，我决定取消查询。

ALTER TABLE mytable ADD mycolumn VARCHAR(50);

有用的信息：

• PostgreSQL 版本：9.1
• 行数：~ 250K
• 列数：38
• 可空列数：32
• 约束数量：5（1 PK、3 FK、1 UNIQUE）
• 索引数：1
• 操作系统类型：Debian Squeeze 64

我发现了有关 PostgreSQL 管理可空列的方式的有趣信息（通过 HeapTupleHeader）。

我的第一个猜测是，因为这个表已经有 32 个 8 位的可空列MAXALIGN， HeapTupleHeader 是 4 字节长度（未验证，我不知道如何这样做）。

因此，添加新的可为空的列可能需要在每一行上更新 HeapTupleHeader 以添加新的 8-bits MAXALIGN，这可能会导致性能问题。

因此，我尝试更改可空列之一（实际上并不是真正可以为空的），以便将可空列的数量减少到 31，以检查我的猜测是否属实。

ALTER TABLE mytable ALTER myothercolumn SET NOT NULL;

不幸的是，这个改动也需要很长时间，超过5分钟，所以我也中止了。

您知道是什么导致了这种性能成本吗？

我有3张桌子：

• 人们
• 邮政
• 喜欢

当我设计 ER 模型时，它具有循环依赖关系：

         1:N
人 --------< 帖子

         1:N
发帖 ----------< 点赞

         1:N
人们 --------< 喜欢

逻辑是：

• 1个人可以有很多帖子。

• 1个帖子有很多赞。

• 1个人可以点赞多个帖子（创建的人不能点赞自己的帖子）。

我怎样才能消除这种循环设计？还是我的数据库设计错了？

我正在制作一个小程序，用户可以在其中发表帖子或写博客。在这些帖子上，其他用户可以像在 facebook 中一样喜欢或不喜欢帖子，也可以像在 stackoverflow 中一样对帖子投赞成票或反对票。我想知道一个常用的良好数据库结构，并且该程序可以有效地使用该结构。我有两个选择

第一的

邮政：

id   head   message   datepost   likes   dislikes
1     ab    anchdg     DATE      1,2,3   7,55,44,3

上面的方式，id就是postid。在likes 列中，1,2,3是喜欢或upvoted 帖子或博客的用户的ID。7,55,44,3是不喜欢或贬低帖子或博客的用户的 ID。

第二

邮政：

id    head  message   datepost
1     ab    anchdg     DATE

喜欢：

id    postid    userid
1       1         1
2       2         2

不喜欢：

id    postid    userid
1       1         7
2       1         55

这样，我必须为喜欢和不喜欢创建两个单独的表才能获得帖子的喜欢。这样，表 ie Likes&Dislikes将被大量填满。这可能会使表格变重且处理速度变慢。

所以，我想知道哪种更好和标准的方法来完成这项任务？

我想以更直接和更一般的方式重新提问：

如何创建一个表来存储可能是多种不同类型的值？

就我而言，这些值提供有关事件的诊断信息。例如：事件发生 -> 存储来自多个 PLC 的读数，其中包含有关事件的相关信息。PLC 可以监控任何类型的数据。

我能想到的一些例子：

• 为每种可能的类型创建一列并创建另一列以指示要使用的列
  • 例如：列数：IntVal、StrVal、BoolVal、类型。值：空，空，真，“布尔”
• 无论如何将值存储为 varchar

DyanmoDB最佳实践明确指出：

您应该在 DynamoDB 应用程序中维护尽可能少的表。大多数设计良好的应用程序只需要一张表。

我觉得很有趣，我见过的处理 DyanmoDB 的几乎每个教程都有多表设计。

但这在实践中意味着什么？

让我们考虑一个具有三个主要实体的简单应用程序：用户、项目和文档。一个用户拥有多个项目，一个项目可以有多个文档。我们通常必须查询用户的项目和项目的文档。读取数量大大超过写入数量。

一个天真的教程的表格设计将使用三个表格：

Users
Hash key
user-id

Projects
Hash key       Global Index
project-id     user-id

Documents
Hash key       Global Index
document-id    project-id

我们可以很容易崩溃Project，并Document为一个Documents表：

Documents
Hash key    Sort key        Global Index
project-id  document-id     user-id

但为什么要停在那里？为什么不用一张桌子来统治他们呢？既然User是一切的根源...

Users
Hash key    Sort key
user-id     aspect
---------   ---------
foo         user                   email: foo@bar.com ...
foo         project:1              title: "The Foo Project"
foo         project:1:document:2   document-id: 2     ...

然后我们将有一个全局索引，例如，email用于用户记录查找的document-id字段，以及另一个用于直接文档查找的字段。 …