Questions tagged «primary-key»

我最近一直在研究ROWGUID的概念，并遇到了这个问题。 这个答案给出了真知灼见，但由于提到更改主键值，使我陷入了另一个困境。 我一直认为主键应该是不变的，而且自阅读此答案以来，我的搜索仅提供了与最佳实践相同的答案。 创建记录后，在什么情况下需要更改主键值？

18 database-design  primary-key 

在对这一想法进行确认后，我将修复性能不佳的数据库或一个更好的建议（如果有的话）。始终欢迎更好的建议。 我有一个非常大的数据库（20+百万条记录，每天增长约1/2百万条），它们使用GUID作为PK。 我的疏忽大意是，但是PK聚集在SQL Server上，并导致性能问题。 产生引导的原因-该数据库与150个其他数据库部分同步，因此PK需要唯一。同步不是由SQL Server管理的，而是建立了一个自定义过程，该过程使数据保持同步以符合系统要求-全部基于该GUID。 150个远程数据库中的每个数据库都不存储中央SQL数据库中存储的完整数据。他们只存储他们实际需要的数据的子集，并且需求的数据并不是他们唯一的（例如，在150个数据库中，有10个可能具有其他站点数据库中的某些相同记录-它们共享）。另外-数据实际上是在远程站点而不是在中心点生成的，因此需要GUID。 中央数据库不仅用于使所有内容保持同步，而且还将针对该非常大的碎片数据库执行来自3000多个用户的查询。在初始测试中，这已经是一个大问题。 幸运的是我们还没有上线-因此我可以进行更改，并在需要时将其脱机，至少这是必须的。 远程数据库的性能不是问题-数据子集非常小，并且数据库的总大小通常不会超过1GB。记录被定期地反馈到主系统，并在不再需要时从较小的BD中删除。 保留所有记录的中央数据库的性能令人担忧-由于群集GUID是许多记录的主键。索引碎片不在图表上。 所以-我想解决性能问题的想法是创建一个新列-Unsigned BIGINT IDENTITY（1,1），然后更改表BIGINT列的Clustered PK。 我将在GUID字段上创建唯一非聚集索引，该索引是主键。 较小的远程150数据库不需要了解Central SQL Server数据库上的新PK-它仅用于组织数据库中的数据并阻止不良的性能和碎片。 这样做是否可以提高中央SQL数据库的性能，并防止将来出现索引碎片地狱（在一定程度上）？还是我错过了这里很重要的东西，它会跳起来咬我，引起更多的悲伤？

18 sql-server  primary-key 

我有一个很大的数据库，需要从每个表中提取所有主键和外键。 我有pgAdmin III。 有没有一种方法可以自动执行此操作，而不必手动检查每个表？

18 postgresql  foreign-key  primary-key  pgadmin 

Unique Key和之间的主要区别是Primary Key什么？

17 mysql  primary-key  unique-constraint 

我在将DATETIME（甚至日期）作为PRIMARY KEY的第一部分时遇到问题。 我使用MySQL 5.5 这是我的两张桌子： -- This is my standard table with dateDim as a dateTime CREATE TABLE `stats` ( `dateDim` datetime NOT NULL, `accountDim` mediumint(8) unsigned NOT NULL, `execCodeDim` smallint(5) unsigned NOT NULL, `operationTypeDim` tinyint(3) unsigned NOT NULL, `junkDim` tinyint(3) unsigned NOT NULL, `ipCountryDim` smallint(5) unsigned NOT NULL, `count` …

17 mysql  index  mysql-5.5  primary-key 

我了解两者之间的含义或意图可能有所不同，但是集群主键和集群唯一索引之间在行为或性能上是否存在差异？

17 sql-server-2005  index  primary-key  clustered-index 

我有一个表，其中有四列都是不可为空的列，并且数据是如此，因此需要全部四列来区分唯一记录。这意味着如果要创建主键，则需要包含所有列。对表的查询几乎总是要拉回一条记录，即所有列将在查询中被过滤。 由于将需要搜索每一列，因此拥有主键是否对我完全有益（除了强制记录的唯一性）？

17 sql-server-2005  primary-key 

我有以下表和索引定义： CREATE TABLE munkalap ( munkalap_id serial PRIMARY KEY, ... ); CREATE TABLE munkalap_lepes ( munkalap_lepes_id serial PRIMARY KEY, munkalap_id integer REFERENCES munkalap (munkalap_id), ... ); CREATE INDEX idx_munkalap_lepes_munkalap_id ON munkalap_lepes (munkalap_id); 为什么在以下查询中不使用munkalap_id上的索引？ EXPLAIN ANALYZE SELECT ml.* FROM munkalap m JOIN munkalap_lepes ml USING (munkalap_id); QUERY PLAN Hash Join (cost=119.17..2050.88 …

16 postgresql  performance  index  join  primary-key 

我对数据库这个主题很陌生，因此听起来似乎很无知，但是我很好奇为什么应该在表中将键显式化。这主要是为了告诉用户给定的列值（希望）在每一行中都是唯一的吗？即使没有提及，唯一性仍然应该存在。

15 primary-key  unique-constraint 

我有一个死锁报告，告诉我发生了涉及waitresource =“ KEY：9：72057632651542528（543066506c7c）”的冲突，并且我可以看到： <keylock hobtid="72057632651542528" dbid="9" objectname="MyDatabase.MySchema.MyTable" indexname="MyPrimaryKeyIndex" id="locka8c6f4100" mode="X" associatedObjectId="72057632651542528"> 在<resource-list>中。我希望能够找到密钥的实际值（例如，id = 12345）。我需要使用什么SQL语句来获取该信息？

15 sql-server  sql-server-2012  primary-key  deadlock 

我将传感器数据存储在表SensorValues中。该表和主键如下： CREATE TABLE [dbo].[SensorValues]( [DeviceId] [int] NOT NULL, [SensorId] [int] NOT NULL, [SensorValue] [int] NOT NULL, [Date] [int] NOT NULL, CONSTRAINT [PK_SensorValues] PRIMARY KEY CLUSTERED ( [DeviceId] ASC, [SensorId] ASC, [Date] DESC ) WITH ( FILLFACTOR=75, DATA_COMPRESSION = PAGE, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = …

15 sql-server  primary-key 

查找表（或某些人称为代码表）通常是可以为特定列提供的可能值的集合。 例如，假设我们有一个查找表party（用于存储有关政党的信息），该表具有两列： party_code_idn，其中包含系统生成的数值，并且（缺少业务域的含义）可以用作实键的替代。 party_code是表的实键或“自然”键，因为它维护具有业务域内涵的值。 让我们说这样的表保留了以下数据： +----------------+------------+ | party_code_idn | party_code | +----------------+------------+ | 1 | Republican | | 2 | Democratic | +----------------+------------+ 在party_code列，这使价值“共和”和“民主”，在工作台的真正的关键，是建立了一个独特的约束，但我需要添加的party_code_idn，它定义为表（的PK虽然，从逻辑上说，party_code可以用作主键[PK]）。 题 指向事务表中的查找值的最佳实践是什么？我是否应该建立外键（FK）引用（a）直接指向自然和有意义的值，或者（b）替代值？ 例如，选项（a）， +---------------+------------+---------+ | candidate_idn | party_code | city | +---------------+------------+---------+ | 1 | Democratic | Alaska | | 2 | Republican | Memphis | …

14 database-design  foreign-key  primary-key  best-practices 

我知道这类问题很多，但是我还没有阅读任何有说服力的论点来帮助我做出这个决定。请多多包涵！ 我有一个庞大的数据库-它每天增长大约10,000,000条记录。数据是关系数据，出于性能原因，我将表与BULK COPY一起加载。因此，我需要为行生成键，并且不能依赖IDENTITY列。 64位整数（bigint）足够我使用，但是为了保证唯一性，我需要一个集中生成器来为我创建ID。我目前有这样的生成器服务，该服务允许服务保留X序列号并保证不发生冲突。但是，这样做的结果是，我拥有的所有服务都依赖于该集中式生成器，因此我在分配系统方面受到限制，并且对施加的其他依赖项（例如要求网络访问）不满意通过这种设计。有时这是一个问题。 我现在正在考虑使用顺序GUID作为主键（在SQL外部生成）。从我自己的测试中可以确定的是，这些操作的唯一缺点是较宽数据类型的磁盘空间开销（索引中使用它们会加剧这种情况）。与bigint相比，我还没有看到查询性能的任何明显下降。使用“批量复制”加载表的速度稍慢，但幅度不大。得益于我的顺序GUID实现，基于GUID的索引不会变得零散。 基本上，我想知道的是，是否还有我可能忽略的其他注意事项。目前，我倾向于飞跃并开始使用GUID。我绝不是数据库专家，所以我非常感谢任何指导。

14 sql-server  primary-key  uniqueidentifier 

我在另一个数据库中已经存在的数据库中创建了一个表。最初是用旧的DB数据填充的。该表的PK必须接收那些记录上已经存在的值，因此它不能是自动递增的。 现在，我需要新表将其PK作为自动增量。但是，在PK已经存在并且有数据之后，我该怎么办？

14 sql-server  primary-key  auto-increment  identity 

将单个序列用作所有表的主键是否可以接受（不是主键对于给定表是唯一的，而是所有表都是唯一的）？如果是这样，从客观上讲，它比在表中使用单个主键序列更好。 我是一名初级软件开发人员，而不是DBA，因此我仍在学习良好数据库设计的许多基础知识。 编辑：如果有人想知道的话，我最近读了我们公司的一名DBA对数据库设计的评论，他提到了一个问题，即设计没有在整个数据库中使用单个主键，这听起来与事实不同。到目前为止，我已经学到了。 Edit2：要回答注释中的问题，这是针对Oracle 11g的，但是我想知道的是非数据库特定级别。如果这个问题确实取决于数据库，我很想知道为什么，但是在这种情况下，我将寻找针对Oracle的答案。

14 database-design  primary-key