标签: sql-server-2005

请看这段代码：

create table #t1(
  id int identity (1,1),
  val varchar(10)
);


insert into #t1 values ('a');
insert into #t1 values ('b');
insert into #t1 values ('c');
insert into #t1 values ('d');

现在，每当你执行这个

select *, 
    ( select top 1 val from #t1 order by NEWID()) rnd 
from #t1 order by 1;

您将得到一个结果，其中所有行都具有相同的随机值。例如

id          val        rnd
----------- ---------- ----------
1           a          b
2           b          b
3           c          b
4           d          b

我知道一种使用游标循环抛出行并获得不同随机值的方法，但这不是高效的。

一个聪明的解决方案是

select t1.id, t1.val, t2.val
from #t1 t1
    join (select …

我正在争论是否最好PRIMARY KEY使用Identity Columns，我们使用显式生成唯一 id 的 UDF 。

• 我在为身份栏争论。
• 我的合作伙伴主张手动生成值，他声称
  • 通过将 UDF 放在另一个可以拥有 UDF 的桌子上
    • 锁定资源
    • 递增的ID表叫做一个字段ID_Value由1
    • 将此用作全局唯一标识符
  • 或者id+1在插入时让表做一个
  • 在没有识别约束的服务器和/或环境之间移动数据更简单；从一个有数据的数据库移动到另一个类似的数据库，比如暂存或虚拟数据。对于非生产中的测试，我们可能希望将昨天的所有记录提取到暂存以进行测试。

哪个实现更有意义？

什么是使存储过程足够健壮以使其可以很好地扩展并包含错误处理的好方法？

此外，在存储过程中处理多个错误场景并拥有一个智能反馈系统来向调用应用程序返回有意义的错误信息的最佳方法是什么？

我正在使用 SQL Server 2005 Express。

在一个场景中，我在存储过程中Begin Transaction的INSERT语句之前添加了命令。当我执行这个存储过程时，它锁定了整个表，所有并发连接都显示挂起，直到INSERT完成。

为什么整个表都被锁定了，我如何在 SQL Server 2005 Express 中解决这个问题？

已编辑

查询如下：

INSERT INTO <table2> SELECT * FROM <table1> WHERE table1.workCompleted = 'NO'

我正在试验快照隔离级别。每当我尝试访问链接服务器时，都会收到错误消息：

事务隔离级别“快照”不支持远程访问

关于这个问题，我在 BOL 或 Google 中找不到任何有意义的信息。

限制似乎相当令人沮丧。除了在本地缓存所有远程数据之外，是否有解决方法？

我试图了解我们的软件供应商决定将日期和时间保存在不同的列中。例如，当行被创建或更新时。时间和日期都是 DateTime 列。我们使用的是 SQL Server 2005。

数据库保存我们 ERP 系统的数据，我相信最大的表包含大约 300 万行。大多数表大约在 100 000 - 1 000 000 行之间。

我个人会默认为单个时间戳选择单个 DateTime。这将允许更容易的时差计算，并且可以轻松地从时间戳中提取日期和时间部分。它也将占用更少的空间。

将日期和时间分开是不好的做法还是我不明白这个设计中有什么非常棒的东西？

场景：
SQL Server 2005 数据库为 ASP.NET 应用程序提供服务（在单独的 Web 服务器上）。

数据库：
DB 中有大约 5GB 的“正常”数据，以及大约 15GB 的“文件”（例如：200k PDF 存储为图像（BLOB），诸如此类）。用户上传的文件越来越多，并且正在迅速消耗更多的磁盘空间（在接下来的几个月中，DB 可能会增长到 50GB，主要是文件）。

顾虑：
在数据库中存储如此多的文件已经引起了问题（例如：数据库的总大小很大使得偶尔的整个数据库备份和部署变得困难。）。

而且我们担心会出现更多问题。（例如：性能问题 - 可能是由于无法将整个数据库保存在 RAM 中引起的，也许？）

问题：
您对这个问题有什么技术解决方案？将文件存储在文件系统中？将数据库一分为二，并为文件使用一个更大、更慢的数据库？

如果需要更多详细信息：
这些文件不是非常重要，并且不需要非常快的访问时间 - 几秒钟就可以了，目前最多每小时可能有十几个选择。数据库中的其他“正常”数据包括每秒需要多次的信息。

我希望能够预测 DELETE 是否会违反约束，而无需实际执行删除。

我有什么选择来做这件事？有没有一种简单的方法可以对 DELETE 进行“试运行”？

我有一个 SQL Server 2008 R2 服务器，其中包含一堆当前在兼容级别 90 (2005) 下运行的已发布数据库。

订阅数据库也是 SQL Server 2008 R2，但是目标数据库设置为兼容性级别 100，并且复制工作正常。

如果我更改已发布数据库的兼容性级别，它会以任何方式影响复制，还是只是重新初始化所有订阅并重新启动复制的情况？

我怀疑更改已发布的数据库兼容性级别可能会稍微改变复制存储过程的功能，但我不是 100% 确定。

是这种情况吗？

我使用的是 SQL Server 2005。我有两个包含聚合信息的表。信息不断更新，每天产生近 5GB 的日志数据。（这比整个数据库还大！）我想禁用对这些表的日志记录，因为回滚并不是真正必要的。但是，我想继续登录数据库中的其他表。

是否可以禁用数据库中某些表的日志记录？如果没有，我可以将两个表放在同一个架构中，然后禁用架构上的日志记录吗？将两个表移动到单独的数据库并在那里禁用日志记录的唯一选择是什么？

更新： 我想我会解释为什么我真的不需要在这些表上记录活动。

这两个表充满了 GPS 数据，因此它们变得非常大。第一个表从现场的六个 Android 表中捕获原始位置。来自每个平板电脑的新数据每 5-10 秒就会出现一次。然后将该信息聚合为 locationA、locationB、travelTime。目标是根据实际驾驶数据，最终实现所有地点之间最短的旅行时间。数据只针对小城市，精确到小数点后四位，易于管理。然而，随着新的原始数据的出现，需要更新的旅行时间变慢，需要插入新的旅行时间。

汇总原始数据后，将对其进行清除。我们不会倒退到更长的旅行时间，所以这就是为什么在这些表中回滚并不那么重要。