标签: schema

这是我的第一个问题，如果这个问题很简单，请原谅我。我被困在这里，试图实现下面表示的数据的关系。我想垂直缩放它（新行），而不是水平添加新列作为城市名称（新列）。

到目前为止，我只能推断出两个表：

1. 带有主键的城市表。(6 行)
2. 带主键的距离表。(13 行)

我将如何关联这两个表？或者我应该按照下面的表示方式处理一张桌子？

原谅我的标题，我想不出任何能准确描述我在说什么的东西。

我目前有以下关系。

CREATE TABLE Events 
(
    ID INT IDENTITY(1,1) NOT NULL,
    Name NVARCHAR(64) NOT NULL,
    PRIMARY KEY(ID)
)

CREATE TABLE Locations
(
    ID INT IDENTITY(1,1) NOT NULL,
    EventID INT NOT NULL,
    Name NVARCHAR(64) NOT NULL,
    PRIMARY KEY(ID)
)

ALTER TABLE Locations ADD FOREIGN KEY(EventID) REFERENCES Events(ID)

基本上，一个事件可以有零个或多个位置。我现在想要的是将捐赠与事件相关联，或者更具体地将其与位置相关联。

CREATE TABLE Donations
(
    ID INT IDENTITY(1,1) NOT NULL,
    EventID INT NOT NULL,
    LocationID INT NULL, -- this is optional
    PRIMARY KEY(ID)
)

ALTER TABLE Donations ADD FOREIGN KEY(EventID) REFERENCES Events(ID)
ALTER TABLE …

我正在对具有多重性的数据进行建模，如下所示：

每个 Composition/Anthology 相关对必须共享一个 Composer。此外，每本选集必须包含至少一个作品。你会如何推荐我建模这个？

这是一种几乎强制一致性的可能表示（它不强制 1+ Composition : 0+ Anthology 多样性）。然而，它复制了 FK_Composer 很多地方（作为副烦恼破坏了我的一些实体框架功能）。

Composer    Composition    junction          Anthology
--------    -----------    --------------    ---------
                           FK_Anthology   -> PK
PK       <- FK_Composer <- FK_Composer    -> FK_Composer
            PK          <- FK_Composition

注意：我也在尝试在业务逻辑和 ORM 层解决这个问题，并且在那里也遇到了障碍。

• /sf/ask/1139159171/
• /sf/ask/1141908911/

在 SQL Server 2008 中，我有视图WITH SCHEMABINDING，我需要更改一个视图。

我正在更改列而不更改其别名，因此消费者不会受到影响。

如果我要删除所有其他依赖于此的视图，我将能够再次重新创建它们，因此SCHEMABINDING仍然有效。

我可以暂时禁用此视图上的架构锁ALTER吗？

或者我必须删除依赖视图并在更改后重新创建它们？

我们正在 SQL Server 中设计一个数据库来处理销售佣金。当前模式的图表如下所示：

这个项目只有我们几个人，我们的老板把这个设计交给了我们。我是一个新手，但我很担心这个Slot表，因为我们似乎正在朝着 EAV 模型前进，而且我认为我们的团队没有足够的经验来克服这些陷阱。

ASlot可以是公司、地点、地区、路线或位置（基于其SlotType）。我们有这些实体的表格，但管理层希望“灵活”地为彼此分配插槽 ( SlotHierarchy)。我不会陷入适用于每个槽位、槽位类型、槽位级别、槽位级别类型和员工职位分配的混乱的生效日期。所有生效日期都是因为管理层想要控制每一件作品。

计划是将Employeeget 分配到位置槽 ( SlotPositionAssignment)，然后可以将其分配到位置、路线或区域槽。一个职位在给定时间只能分配一名员工。不过，一个位置可以分配给任意数量的插槽。

因此，我们可能有PositionType“销售员”和SlotDesc“销售 1”和“销售 2”两个职位（插槽），每个职位都分配了一名员工。这两个职位可以分配到多个路线、地区、地点或公司时段。这SlotHierarchy有助于解决这个问题。

我的担忧：
恐怕我们可能会因此而自诩。我不介意编写额外的应用程序逻辑，但这似乎“太聪明了”。直言不讳并使用映射到现实生活中的表格而不是将它们隐藏为“插槽”不是更有意义吗？

我想取消将职位作为插槽并使用Position表格，或者可能只是PositionType在我们失去报告公司特定职位的能力时使用，例如“Rt 1 Manager”。当我提出这个问题时，我被告知它不会“灵活”，这就是它的结束。

有没有更好的方法来组织这个，或者做出一些妥协，或者我什么都不担心？我是新手，不介意犯错，只要我知道为什么我错了。

在浏览数据库架构时，我遇到了 Schema 的 . 我很困惑：

逻辑模式

物理模式

这两个模式如何存在于数据库中？

如何根据需要操纵这些？

逻辑模式和物理模式如何相关？

我将把500,000,000张图片的签名插入到数据库中。签名将使用libpuzzle生成。每个签名是 338 个字节。（所以 160 GB）加上一个搜索表（阅读下文）。我更愿意将主数据库保留在带有标准 HDD 的 VPS 服务器上（由于成本问题，没有 SSD）。

最重要的方面是搜索时间，插入时间无所谓。

过去，我在 MySQL 中尝试了所有这些（记录更少），并且所有内容都使用一个数据库，主要搜索采用如下方案：

--
-- Table structure for table `signatures`
--

CREATE TABLE IF NOT EXISTS `signatures` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `compressed_signature` varchar(338) NOT NULL,
  `picture_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `picture_id` (`picture_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=1107725 ;

-- --------------------------------------------------------

--
-- Table structure for table `stored_pictures`
--

CREATE TABLE IF NOT EXISTS `stored_pictures` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `url` varchar(255) …

我是一名开发人员（学生），正在寻找一些关于在创建表以对具有许多可选字段的实体建模时应该遵循的最佳方法的建议。

需要对Organization具有几个关键字段（例如id和 ）的实体进行建模name。还有一个连接表 from UserstoOrganization指定谁属于Organization以及他们的角色是什么。

这个问题我有涉及许多属于可选字段Organization，如website，email和social links。以下是我目前处理这个问题的想法：

1. 将它们作为可选字段添加到表中
   • 优点：在一张表上轻松完成 CRUD，比导航连接等更快。
   • 缺点：对我来说似乎有点脏。将来迁移会变得困难吗？
2. 创建一个contact_information表，该表从查找表中organization_id引用contact_type_id（网站、电子邮件、Facebook 等），并具有value用于实际内容的通用字段。
   • 优点：感觉更干净，将来允许任意数量的联系人类型
   • 缺点：可能会慢很多。更多的桌子。

我倾向于#2，因为它与我为物理地址所做的方法类似，但我不确定它是否是最好的解决方案，因为 DBA 不是我的强项。如果有我不知道的第三个甚至第四个选项，我也很想知道这些。

（我对将下面的问题视为问题的特例的答案特别感兴趣：RDBMS 应该如何强制执行比“一对多”和“多对多”更具体的结构约束？）

生物医学研究中的许多实验数据都是在矩形排列的“孔”的“板”中收集的。这些孔阵列板有几种标准尺寸的市售：2 × 3、4 × 6、8 × 12、16 × 24 和 32 × 48。

考虑以下两种替代方案，用于在 RDB 中存储 2 × 3 板孔的测量值：

-- alternative 1
CREATE TABLE measurement_foo (
    plate_id FOREIGN KEY REFERENCES plate(plate_id),
    plate_row CHAR(1),
    plate_column INTEGER,
    value REAL
);

-- alternative 2
CREATE TABLE measurement_foo (
    plate_id FOREIGN KEY REFERENCES plate(plate_id),
    a1 REAL,
    a2 REAL,
    a3 REAL,
    b1 REAL,
    b2 REAL,
    b3 REAL
);

我的直觉是采用替代方案 1：它可以推广到任何尺寸的板，并且可以以一种直接的方式进行修改，以记录每个孔的多个不同测量值，如

CREATE TABLE measurement (
    plate_id FOREIGN KEY REFERENCES …

我有一个拥有数百万个实例的实体。每个实例都必须引用一个有序的项目列表。列表必须是唯一的，因此不会多次存储列表。但是一旦创建，列表和实体实例都是不可变的。实体实例将远多于列表，并且数据库必须支持实体的快速插入。

5   1   10
5   2   20
5   3   30
    

5   10   20 …