标签: database-design

我得到了一个事件管理案例研究，以开发实体关系图 (ERD)，并基于它检查生成的关系模式是否满足不同的范式。现在，我已经基于我开发的 SRS 开发了我的 ERD。

我遇到的问题是：当我将 ERD 转换为关系模式时，我的表已经规范化了。由于 ERD，我在规范化过程中没有什么可完成的，所以我很困惑。

我脑海中出现的另一个问题是这是否是一种理想的情况，我的意思是当我从 ERD 本身让我的所有关系正常化时，为什么我需要进行正常化？

换句话说，如果我们从 ERD 中获得了 5NF 中的数据库，那么为什么我们需要考虑规范化？

我进行了搜索，但没有找到有关此主题的任何讨论。在连接表上创建许多额外的列有什么优点和缺点吗？因为我们加入了 3 个表，它会影响数据检索的速度吗？

就我而言，它可能会慢一点，但这是必要的，否则我们如何保存有关多对多关系的额外数据。或者还有其他我不知道的方式吗？

我们有一个非常大的数据库，我们想几乎实时地编写它。我们想要获取数据并将其移动到数据库的另一个实例，在该实例之上将是一个 GUI 和 MI 工具，它将能够报告数据。

到目前为止，我有以下几点 - 在规范这个时，其他人有没有我应该记住的任何考虑因素：

• 数据迁移/保留期限/存储的法律要求
• 需要在报告数据库中可用的表/字段
• 许可/用户访问
• 需要查询的关键字段
• 灾难恢复要求
• 复制时间

我正在为已抓取的多个博客站点的内容构建数据存储。这些站点中的每一个都将在Blog表中包含一个条目

BlogId                  Url                         Version
int, PK, identity       varchar(2500), not null     int, not null
-----------------       -----------------------     -------------
                1       'http://site1.com/                      1
                2       'http://site2.com/                      1
                3       'http://site2.com/                      2

然后会有一张Post表：

BlogId                Url                        PostId
int, FK, not null     varchar(2500) not null     ?

对于我正在查看的大多数博客，我可以轻松辨别出 PostId对它们来说独一无二价值。

对于所有博客，Url将是唯一的BlogId值。但是，Url是经常可能发生变化。

但是，有一些博客PostId在抓取 HTML 时我无法辨别出很好的价值。在这些情况下，我可以得到datetimeoffset发布帖子的信息。发布频率的准确性在分钟级别。

问题是，我需要使用BlogId和PostId但我不确定我应该输入什么PostId。我一直在想两个选择：

• sql_variant- 我可以int对我的大多数网站使用 an ，这很好，然后datetimeoffset用于那些我无法轻易辨别唯一数字的网站PostId
• bigint …

我有customers. 该customers表是这样的

+------------------+
|     Customers    |
+------------------+
| id  (PK)         |
| business_email   |
| business_name    |
| customer_name    |
| payment_terms    |
| currency         |
| business_address |
| city             |
| state            |
| postal_code      |
| country          |
| phone            |
| created_at       |
| updated_at       |
+------------------+

现在，我希望把送货地址在我的应用程序，客户可以任意提他的航运address.SØ我做了一个额外的表shipping address像这样

+------------------+
| Shipping Address |
+------------------+
| id  (PK)         |
| contact_name     |
| contact_address  |
| delivery_address |
| created_at …

我收到了创建一个新表的请求，该表将为客户存储某些信息。除了一个字段外，表的定义有些无关紧要。该字段将存储从终端屏幕检索到的 ANSI 字符。

一开始会有大约 5000 万行，最初，我们估计该字段需要 <= 7,500 个字符，所以我选择使用VARCHAR(8000)数据类型。经过更多分析，我们确定 3000 万行中大约 90% 将 <= 8000，但另外 10% 将 <= 15,000。

VARCHAR由于 8,000 的限制，我显然不能使用它，所以我认为我唯一的选择是text数据类型。我担心“文本”的开销，它最终可能会被删除。我现在正在研究VARCHAR(max)，但我从未在生产环境中使用过它。

我应该使用varchar(max)、text还是寻找一种方法来压缩那 10% 的数据并将其存储在varchar(8000).

我是一名学生，有一个作业问题：

在设计系统以每周 6 天、每天 24 小时实时交易国际股票时，数据库管理员面临哪些问题和挑战？基于云的数据库系统即服务是一种可行的选择吗？

这主要是一个设计问题，我正在寻找有关此方法优缺点的任何反馈。

通常，我将数据库设计分为两类，业务逻辑和记录数据。业务逻辑是那些为记录的数据带来意义的东西。例如，PartSerialNumber 是有意义的，因为我们有带有序列号的部件。

所以我会创建一个像......

CREATE TABLE PartsTable
{
    PartID INT, -- NOT NULL IDENTITY PK...
    PartSerialNumber VARCHAR(20), -- NOT NULL
    CreateDate DATE, -- NOT NULL, maybe default
    -- other stuff related to the specific part
}

 -- this is a business logic table, the codes have meaning to the business
CREATE TABLE ErrorCodes
{
    ErrorCode VARCHAR(5), -- NOT NULL, PK
    ErrorDescription VARCHAR(MAX),
    -- OTHER STUFF FOR THE ERROR CODES
}

然后我们有一个日志系统来捕捉错误，

CREATE TABLE PartErrors
{
    PartID INT , -- NOT …

我有一个应用程序，我必须在其中存储多种位置的地址。

例如，我的应用程序需要人员、酒店和活动场所的地址。

我应该为具有相同字段的不同类型的地址创建单独的表吗？或者我应该添加一个额外的字段来说明地址的类型吗？

我有一个“文本”表，文本表可能来自不同的来源，如推文、短信、电子邮件等，每个来源都有自己的日志，文本来自来源。所以我提出了一些解决方案，但我不知道哪个是最好的。

解决方案1：

Text(
text_id PK
content
source_type (tweet, sms, email, etc)
source_id (can't be FK since it may contain sms_id, tweet_id, or email_id)
)

Tweet(
tweet_id PK
tweet_text
tweet_username
etc...
)

Sms(
sms_id PK
sms_text
sender_number
etc...
)

Email(
email_id PK
email_text
email_sender
etc...
)

解决方案2：

Text(
text_id PK
content
sms_id FK
tweet_id FK
email_id FK
)

Tweet(
tweet_id PK
tweet_text
tweet_username
etc...
)

Sms(
sms_id PK
sms_text
sender_number
etc...
)

Email(
email_id PK
email_text
email_sender
etc...
)

请注意，一个“文本”仅来自一个来源。

因此，如果我使用解决方案 …