所以，标题总结了它。

我有一个包含 28 个表和 86 个必须进行逆向工程的存储过程的 SQL Server 数据库。我很确定有些表从未使用过，并且并非所有 proc 都使用过。

最大的问题是所有创建用于此数据库的 Windows 服务以及所有软件和数据库文档都丢失了，并且无处可寻设计整个系统的人。

我已经设法创建了一个 ER 图来帮助我理解这些关系，但是由于我没有数据库管理经验，我不知道应该从哪里开始。

如果不打算在这里问这种问题，我也很抱歉。

在我们上一次每周例会上，一个没有数据库管理背景经验的人提出了这个问题：

“会不会有一种情况证明将数据存储在行（字符串）而不是多行中是合理的？”

让我们假设有一个表，称为countryStates我们想要存储一个国家的州的位置；我将在这个例子中使用美国，为了懒惰，不会列出所有的州。

在那里我们会有两列；一个叫Country，另一个叫States。正如这里所讨论的，以及@srutzky 的回答所提出的，这PK将是ISO 3166-1 alpha-3定义的代码。

我们的表看起来像这样：

+---------+-----------------------+-------------------------------------------------------+
| Country | States                | StateName                                             |
+---------+-----------------------+-------------------------------------------------------+
| USA     | AL, CA, FL,OH, NY, WY | Alabama, California, Florida, Ohio, New York, Wyoming |
+---------+-----------------------+-------------------------------------------------------+

当向一位开发人员朋友提出同样的问题时，他说从数据流量大小的角度来看，这可能有用，但如果我们需要操纵这些数据，则不是。在这种情况下，应用程序代码必须有智能，可以在列表中转换此字符串（假设有权访问此表的软件需要创建一个组合框）。

我们得出的结论是这个模型不是很有用，但我怀疑可能有办法让它有用。

我想问的是，你们中是否有人已经以真正有效的方式看到、听到或做过这样的事情。

问题

记录数据的表是

CREATE TABLE [dbo].[Almoxarifado](
    [idAlmoxarifado] [varchar](20) NOT NULL,
    [tipoAlmoxarifadoId] [varchar](30) NOT NULL,
    [entidadeId] [bigint] NOT NULL,
    [dtInclusao] [smalldatetime] NOT NULL,
    [dtUltimaAlteracao] [smalldatetime] NULL,
    [descricao] [varchar](255) NOT NULL,
    [terceiro] [bit] NOT NULL
) ON [PRIMARY]

这是一个SELECT TOP 10 *示例（该表有超过 100 万个条目）：

如您所见，该idAlmoxarifado字段存储的分层数据与大多数分层表没有分层关系。

现在我想把这些数据带到一个通常的层次表中：

CREATE TABLE [dbo].[Almoxarifado2](
    [idMaster] [bigint] IDENTITY(1,1) NOT NULL,
    [idAlmoxarifado] [int] NOT NULL,
    [idAlmoxPai] [int] NOT NULL DEFAULT ((0)),
    [entidadeId] [bigint] NOT NULL,
    [tipoAlmoxarifadoId] [varchar](30) NOT NULL 
    [dtInclusao] [datetime] NULL DEFAULT (getdate()),
    [dtUltimaAlteracao] [datetime] …

我有以下查询：

SELECT DISTINCT
           COUNT(CD_BarCode)
           ,CD_Carrier
           ,SUBSTRING(CONVERT(VARCHAR,DT_Arriving,103),1,11) Date
FROM TB_AGIL 
WHERE 
           DT_Arriving >= @date
           AND DT_Arriving < DATEADD(MONTH,+1,@date)
           AND CD_TRACKING = 14
GROUP BY CD_Carrier, SUBSTRING(CONVERT(VARCHAR,DT_Arriving,103),1,11)
ORDER BY Date 

我用它来查看上个月货物移动的结果。结果是按日期分组的cd_tracking金额列表，如下所示：

| Amount | Carrier |    Date    |
|--------|---------|------------|
|  2599  |   44    | 01/08/2015 |
|  2504  |   44    | 03/08/2015 |
|  4597  |   44    | 04/08/2015 |
|  5058  |   44    | 05/08/2015 |
|  2413  |   44    | 06/08/2015 |
|  4853  |   44    | 07/08/2015 …

标题总结了它。

我已经了解到并一直听说表中的索引可以改进 CRUD 操作。我上周末遇到的一位开发人员告诉我，他不喜欢索引，因为它们很糟糕——是的，“糟糕”并没有说明什么，但我们没有时间进一步讨论它（我们参加了一个聚会）。

无论如何，也许是因为我缺乏经验，我不知道索引会在 CRUD 操作期间引起麻烦的场景，但也许有一些。我问这个问题是想知道是否有任何...

今天我们讨论了以下问题：

巴西有 27 个州，每个州都有自己的缩写（就像美国一样）。所以我们有RJ里约热内卢、SP圣保罗、MG米纳斯吉拉斯州等等。

我们的一个程序员的建议，我们应该使用这些缩写（RJ，SP，MG等）PK上States表中，我们正在计划添加到一个新的项目。

推断我们数据库的使用，我反驳了他的论点，说如果我们-有一天-将我们的服务扩展到其他国家，我们会遇到重复缩写的问题，例如：在美国SC，南卡罗来纳州和巴西都有我们已经到SC了圣卡塔琳娜州；对于MT,PA和也会发生同样的情况MA。基于这一点，我们同意应该有一ID列 as PK IDENTITY。

现在，假设我们不将我们的服务扩展到其他国家并且只停留在巴西，我开始考虑使用 VARCHAR(2) 列作为 PK 的想法。在这种情况下，这听起来并不完全是个坏主意。是吗？为什么？在哪些情况下可以应用？是否应该考虑记忆以便从一种选择到另一种？