Questions tagged «primary-key»

在为我之前问过的另一个问题创建测试数据库时，我记得有一个主键可以被声明 NONCLUSTERED 什么时候使用NONCLUSTERED主键而不是CLUSTERED主键？ 提前致谢

169 sql-server  primary-key 

我正在阅读有关是否使用Guid和的原因int。 int体积更小，速度更快，易于记忆，并按时间顺序排列。至于Guid，我发现的唯一优势是它是独一无二的。在那种情况下，a Guid会比更好int，为什么？ 从我所看到的来看，int除了数量上的限制外没有其他缺陷，在许多情况下这是无关紧要的。 为什么要精确Guid创建？实际上，我认为它除了用作简单表的主键外，还有其他用途。（是否有用于实际应用的示例Guid？） （Guid = UniqueIdentifier）SQL Server上的类型

97 performance  sql-server  primary-key  uniqueidentifier 

关于PostgreSQL中索引的工作，我有几个问题。我有一个Friends具有以下索引的表： Friends ( user_id1 ,user_id2) user_id1并且user_id2是user表的外键 这些等效吗？如果没有，那为什么呢？ Index(user_id1,user_id2) and Index(user_id2,user_id1) 如果我创建主键（user_id1，user_id2），它会自动为其创建索引并 如果第一个问题中的索引不相等，则在上述主键命令上创建哪个索引？

73 postgresql  index  primary-key 

我想建立一个分布式系统。我需要将数据存储在数据库中，使用UUID或GUID作为某些表上的主键会很有帮助。由于UUID / GUID很大，而且几乎是随机的，因此我认为这种设计有缺点。替代方法是使用自动递增的INT或LONG。 使用UUID或GUID作为表的主键有什么缺点？ 我可能将Derby / JavaDB（在客户端上）和PostgreSQL（在服务器上）用作DBMS。

60 postgresql  primary-key  datatypes  derby 

我了解代理/人工密钥的一大好处-它们不会更改，因此非常方便。无论它们是单个字段还是多个字段，只要它们是“人造”字段，都是如此。 但是，有时将自动递增的整数字段用作每个表的主键似乎是一个政策问题。拥有这样的单字段密钥始终是最好的主意吗？为什么（为什么不这样做）？ 明确地说，这个问题不是关于人工还是自然的问题，而是关于所有人工密钥是否应为单一字段的问题

33 database-design  primary-key  surrogate-key 

我有一些具有相同基本结构的非常大的表。每个都有一个RowNumber (bigint)和DataDate (date)列。每天晚上使用SQLBulkImport加载数据，并且从未加载过任何“新”数据-它是历史记录（SQL Standard，不是Enterprise，因此没有分区）。 因为每个数据位都需要绑定到其他系统，并且每个RowNumber/DataDate组合都是唯一的，所以这就是我的主键。 我注意到，由于我在SSMS Table Designer中定义PK的方式，RowNumber第一和DataDate第二列出了。 我还注意到，我的碎片始终非常高，高达〜99％。 现在，由于每个DataDate索引仅出现一次，所以我希望索引器每天都添加到页面中，但是我想知道它是否实际上是RowNumber首先基于索引编制的，因此是否需要转移其他所有内容？ Rownumber不是一个标识列，它是一个由外部系统生成的int（很糟糕）。它在每个开始时重置DataDate。 示例数据 RowNumber | DataDate | a | b | c..... 1 |2013-08-01| x | y | z 2 |2013-08-01| x | y | z ... 1 |2013-08-02| x | y | z 2 |2013-08-02| x | y | z …

33 sql-server  sql-server-2008-r2  primary-key  clustered-index 

我在索引，主键和外键上苦苦挣扎，而且都需要全部使用。 如果我有两个表，它们两个都有一个整数作为主键。 第一个表通过FK引用第二个表的主键。 在两个表上，我在ID列上都有一个主键索引 我在table1.ref_field参照第二张表格（table2.id）的PK时创建了FK约束 我在上添加了一个索引 table1.ref_field 这是组织这些索引（主键和外键）的最佳方法吗？

30 postgresql  database-design  index  foreign-key  primary-key 

我正在设计一个包含多个查找表的数据库，其中包含主要实体的可能属性。我正在考虑使用4或5个字符的键来标识这些查找值，而不是自动递增的整数，这样当我将这些属性ID存储在主表中时，我会看到有意义的值，而不仅仅是随机数。 使用字符字段作为主键而不是整数对性能有何影响？ 如果这很重要，我正在使用MySQL。 [编辑] 这些查找表具有很少添加的新记录。它们是手动维护的，基于字符的键也是手动创建的。这是一个例子： CUISINES ID Description ----- -------------- CHNSE Chinese ITALN Italian MXICN Mexican

30 mysql  primary-key 

我想知道为什么我应该使用int作为查找表的主键，而不是仅使用lookup值作为主键（在大多数情况下为字符串）。 我知道，如果将nvarchar（50）而不是int链接到具有许多记录的表，则会使用更多空间。 另一方面，直接使用查找值基本上可以节省我们进行连接的时间。我可以想象，如果始终需要加入，这将节省很多钱（我们正在开发一个Web应用程序，因此这很重要）。 除了将int主键用作“标准操作”以外，还有什么好处？

30 sql-server  primary-key 

我想修改SQL Azure表上的现有主键。 它当前有一个列，我想添加另一列。 现在，在SQL Server 2008上，这简直是小菜一碟，只是在SSMS里做了。做完了 如果我从SQL Server编写PK，这就是它的样子： ALTER TABLE [dbo].[Friend] ADD CONSTRAINT [PK_Friend] PRIMARY KEY CLUSTERED ( [UserId] ASC, [Id] ASC ) 但是，在SQL Azure上，当我尝试执行上述操作时，它当然会失败： Table 'Friend' already has a primary key defined on it. 很好，因此我尝试删除密钥： Tables without a clustered index are not supported in this version of SQL Server. …

25 primary-key  azure-sql-database 

我有一张桌子 员工ID 等等 blahblah2 ..... 记录月 回顾年 因此，每个员工只应有一个匹配的条目来输入月，年，Emp＃。如何设置表格。 那么，如何设置表以使EmployeeID可以每月更新一次，但永远不能在匹配的月份和年份中有两个条目？

23 mysql  primary-key 

浏览数据库时，我遇到了一个表，该表使用其主键作为自身的外键。 我已经看到，表本身可以具有外键来构建层次结构，但是它将使用另一列来引用主键。 由于主键是唯一的，因此在这种情况下行是否只能指向自身？这似乎是一个重言式的链接，因为如果我已经有了该行，那么我已经有了该行。 有什么理由要这样做吗？ 我确定约束是以这种方式编写的（不仅仅是查看图表），因为相同的表和列用于定义的两半。

21 sql-server  foreign-key  primary-key 

我正在使用Django，偶尔我会收到此错误： IntegrityError：重复的键值违反了唯一约束“ myapp_mymodel_pkey” 详细信息：键（id）=（1）已存在。 实际上，我的Postgres数据库确实有一个myapp_mymodel对象，其主键为1。 为什么Postgres会再次尝试使用该主键？或者，这很可能是我的应用程序（或Django的ORM）引起的吗？ 刚刚，此问题连续发生了3次。我发现的是，对于给定的表，它确实发生了一次或多次，然后不再发生。它似乎在每个表完全停止运行几天之前就发生了，每个表至少发生一分钟左右才发生，并且只是间歇地发生（并非所有表都立即发生）。 这个错误是如此断断续续的事实（在2周内仅发生了3次左右-数据库上没有其他负载，只是我测试了我的应用程序）使我非常警惕低级问题。

21 postgresql  primary-key  constraint  postgresql-9.2 

我是DBMS的新手，但仍在学习该理论。 我对这个关键业务感到非常困惑，在谷歌搜索之后，我将其范围缩小到只有我没有得到的两个关键（主键和超级键）。 我对DBMS有几个问题。如果您能为我回答，我将不胜感激。 1）DBMS中的主键和超级键有什么区别？ 如果您可以使用一个全面的示例正确解释，请多多关照 2）主键和超级键都可以有多个列组合形成主键和超级键吗？ 3）主键是超级键的子集，反之亦然吗？

20 primary-key  unique-constraint  candidate-key 

从数学的角度来看，假设一个表最多具有一个主键，那么用某种任意名称而不是简单的表属性来引用主键似乎是一个短时的设计决策。 因此，要将主键从非集群键更改为集群键，反之亦然，您必须首先搜索其名称，然后删除它，最后读取它。 使用我看不到的任意名称是否有一些优势，或者DBMS不对主键使用任意名称？ 编辑2011-02-22 （对于那些不想在那里排序的人，则为02/22/2011）： 让我展示一下该函数，您可以使用该函数从其表名派生主键的名称（使用早期的sql-sever aka sybase系统表）： create function dbo.get_pk (@tablename sysname) returns sysname as begin return (select k.name from sysobjects o join sysobjects k on k.parent_obj = o.id where o.name = @tablename and o.type = 'U' and k.type = 'k') end go 如gbn所述，当您不提供显式名称时，没有人真的喜欢生成的名称： create table example_table ( id …

19 primary-key