小编Mat*_*hew的帖子

我有一个表，该表当前在一列中有重复的值。

我无法删除这些错误的重复项，但我想防止添加其他非唯一值。

我可以创建一个UNIQUE不检查现有合规性的吗？

我曾尝试使用NOCHECK但未成功。

在这种情况下，我有一个表格将许可信息与“公司名称”联系起来

编辑：具有相同“公司名称”的多行是错误数据，但我们目前无法删除或更新这些重复项。一种方法是让INSERTs 使用一个存储过程，该过程将因重复而失败......如果可以让 SQL 自行检查唯一性，那将是可取的。

此数据按公司名称查询。对于少数现有的重复项，这意味着返回并显示多行...虽然这是错误的，但在我们的用例中是可以接受的。目的是防止将来发生。从评论看来，我必须在存储过程中执行此逻辑。

在设计 SQL 服务器数据架构和后续查询、sproc、视图等时，对于明确部署在 SSD 平台上的数据库设计，集群索引和磁盘上数据顺序的概念是否有意义？

http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx
“聚集索引决定了表中数据的物理顺序。”

在物理磁盘平台上，考虑它们的设计对我来说很有意义，因为对数据进行物理扫描以检索“顺序”行可能比通过表查找性能更高。
在 SSD 平台上，所有数据读取访问都使用相同的查找。没有“物理顺序”的概念，数据读取不是“顺序”的，因为位存储在同一块硅片上。

那么，在设计应用数据库的过程中，聚集索引的考虑是否与该平台相关？

我最初的想法是，这并不是因为“有序数据”的想法不适用于 SSD 存储和搜索/检索优化。

编辑：我知道 SQL Server会创建一个，我只是在思考在设计/优化期间考虑它是否有意义。

我们经常会遇到“如果不存在，则插入”的情况。Dan Guzman 的博客对如何使此进程线程安全进行了出色的调查。

我有一个基本表，它只是将字符串从SEQUENCE. 在存储过程中，我需要获取该值的整数键（如果它存在），或者INSERT它然后获取结果值。该dbo.NameLookup.ItemName列有一个唯一性约束，因此数据完整性没有风险，但我不想遇到异常。

这不是一个IDENTITY所以我无法获得，SCOPE_IDENTITY并且NULL在某些情况下价值可能是。

在我的情况下，我只需要处理INSERT桌面上的安全问题，所以我试图决定是否使用MERGE这样的方法更好：

SET NOCOUNT, XACT_ABORT ON;

DECLARE @vValueId INT 
DECLARE @inserted AS TABLE (Id INT NOT NULL)

MERGE 
    dbo.NameLookup WITH (HOLDLOCK) AS f 
USING 
    (SELECT @vName AS val WHERE @vName IS NOT NULL AND LEN(@vName) > 0) AS new_item
        ON f.ItemName= new_item.val
WHEN MATCHED THEN
    UPDATE SET @vValueId = f.Id
WHEN NOT MATCHED BY TARGET THEN
    INSERT …

我听到了关于这方面的混合信息，希望得到权威或专家的意见。

如果我有多个LEFT OUTER JOINs ，每个都依赖于最后一个，嵌套它们更好吗？

对于一个人为的例子，JOINtoMyParent取决于JOINto MyChild：http : //sqlfiddle.com/#!3/31022/5

SELECT
    {columns}
FROM
    MyGrandChild AS gc
LEFT OUTER JOIN
    MyChild AS c
        ON c.[Id] = gc.[ParentId]
LEFT OUTER JOIN
    MyParent AS p
        ON p.[id] = c.[ParentId]

与http://sqlfiddle.com/#!3/31022/7相比

SELECT
    {columns}
FROM
    MyGrandChild AS gc
LEFT OUTER JOIN
    (
    MyChild AS c            
    LEFT OUTER JOIN
        MyParent AS p
            ON p.[id] = c.[ParentId]
    )
    ON c.[Id] = gc.[ParentId]

如上所示，这些在 SS2k8 中产生不同的查询计划

正如SQLDenis 解释的DATETIME那样INT，SQL Server 在内部存储为两个值。

DATE类型（SQL Server 2008+）存储为单个 是否正确（按逻辑扩展）INT？

我们目前有多个数据库，但希望将它们组合起来，取而代之的是使用模式分离我们的域上下文。

在 MS SQL Server 2008 R2 中，如何将一个架构的所有内容批量重定位到另一个架构中？

例如，我们在dbo模式中创建的所有表、视图、过程、索引等……现在都将存在于foo模式中。

编辑：我想根据 AaronBertrand 的精彩评论进行澄清。这不是多租户情况。我们的情况是，内部工具插件是由开发人员单独开发的，他们没有将他们的表合并到工具的数据库中。

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

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

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

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

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

我有一个连续修改的已处理事件表。处理时间的 UTC 时间和 eventId。

使用 SYSUTCDATETIME() 作为主键是否安全？我可以轻松使用代理键，但感觉很有趣。

这个问题是从这里提出的优秀问题中提取出来的：

迄今为止的演员阵容是可以讨论的，但这是一个好主意吗？

就我而言，我不关心该WHERE子句，而是关心加入具有类型列的事件表DATE

一个表有DATETIME2，另一个有DATE......所以我可以有效地JOIN使用aCAST( AS DATE)或者我可以使用“传统”范围查询（>=日期和<日期+1）。

我的问题是哪个更可取？这些DATETIME值几乎永远不会与谓词DATE值匹配。

我希望保持在 200 万行DATETIME和 5000行以下DATE（如果这个考虑有所不同）

我是否应该期望在JOIN使用该WHERE子句时具有相同的行为？我应该更喜欢哪个通过缩放来保持性能？答案是否随 MSSQL 2012 而改变？

我的通用用例是将我的事件表视为日历表

SELECT
    events.columns
    ,SOME_AGGREGATIONS(tasks.column)
FROM
    events
LEFT OUTER JOIN
    tasks
        --This appropriately states my intent clearer
        ON CAST(tasks.datetimecolumn AS DATE) = events.datecolumn 
        --But is this more effective/scalable?
        --ON tasks.datetimecolumn >= events.datecolumn 
        --AND tasks.datetimecolumn < DATEADD(day,1,events.datecolumn)
GROUP BY
    events.columns

我有一个用于存储事件的 SQL Server 表。

我只希望表包含最近添加的 1000 行，当插入第 1001 行时，应删除第 1 行。

我有一个 DateCreatedUTC 列和一个自动编号列......我可以编写一个查询来执行删除并触发它，INSERT但我不知道这是最合适的解决方案。