问题标签 [rdbms]

如何在不使用触发器或以任何方式修改数据库结构的情况下监视 SQL Server 数据库以了解对表的更改？我首选的编程环境是.NET和 C#。

我希望能够支持任何SQL Server 2000 SP4 或更高版本。我的应用程序是另一家公司产品的附加数据可视化。我们的客户群数以千计，因此我不想要求我们在每次安装时都修改第三方供应商的表格。

“对表的更改”是指对表数据的更改，而不是对表结构的更改。

最终，我希望更改触发我的应用程序中的事件，而不是必须每隔一段时间检查更改。

考虑到我的要求（没有触发器或架构修改，SQL Server 2000 和 2005），最好的做法似乎是使用T-SQLBINARY_CHECKSUM中的函数。我计划实施的方式是这样的：

每 X 秒运行一次以下查询：

并将其与存储的值进行比较。如果值已更改，请使用以下查询逐行浏览表：

并将返回的校验和与存储的值进行比较。

我一开始是故意让这个很模糊的。我正在寻找讨论以及哪些问题比我寻找硬性答案更重要。

我正在设计一个执行投资组合管理之类的应用程序。我到目前为止的设计是

• 问题：需要解决的问题
• 解决方案：针对一个或多个问题提出的解决方案
• 关系：两个问题、两个解决方案或一个问题和一个解决方案之间的关系。进一步细分为：
  • 父子 - 某种分类/树层次结构
  • 重叠 - 两个解决方案或两个问题真正解决同一概念的程度
  • 地址 - 问题解决解决方案的程度

我的问题是关于这些事物的时间性质。问题突然出现，然后消失。解决方案有一个预期的解决日期，但在开发过程中可能会进行修改。随着问题和解决方案的发展，关系的程度可能会随着时间而改变。

那么问题来了：对这些东西进行版本控制的最佳设计是什么，这样我就可以同时了解我的投资组合的当前和历史观点？

后来：也许我应该提出一个更具体的问题，尽管@Eric Beard 的回答值得一提。

我考虑了三种数据库设计。我将充分展示它们的缺点。我的问题是：选择哪个，或者你能想出更好的东西吗？

1：问题（以及单独的解决方案）在版本控制中是自引用的。

这是有问题的，因为每次我想要一个新版本时，我都必须复制整行，包括那个长description列。

2：新建关系类型：版本。

这只是将关系从问题和解决方案表移动到关系表中。同样的重复问题，但可能有点“干净”，因为我已经有了一个抽象的关系概念。

3：使用更类似于Subversion的结构；将所有问题和解决方案属性移动到单独的表中并对其进行版本控制。

这意味着要加载问题或解决方案的当前版本，我必须获取属性的所有版本，按日期对它们进行排序，然后使用最新版本。那可能并不可怕。对我来说真正糟糕的是我无法在数据库中对这些属性进行类型检查。该value列必须是自由文本。我可以将该name列作为对具有列的单独attribute_names表的引用type，但这不会强制表中的类型正确attributes。

稍后：回复@Eric Beard 关于多表外键的评论：

唉，我所描述的很简单：只有两种类型的事物（问题和解决方案）。我实际上有大约 9 或 10 种不同类型的事物，因此在您的策略下我将有 9 或 10 列外键。我想使用单表继承，但事物的共同点太少了，将它们组合到一个表中会非常浪费。

最近，我开始更改我们的一些应用程序以支持MS SQL Server作为替代后端。

我遇到的一个兼容性问题是使用 MySQL 的 CREATE TEMPORARY TABLE 来创建内存表，这些表保存数据以便在会话期间非常快速地访问，而无需永久存储。

MS SQL 中的等价物是什么？

一个要求是我需要能够像使用其他任何表一样使用临时表，尤其是JOIN与永久表一起使用。

源数据库相当大。目标数据库不会自动增长。它们在不同的机器上。

我来自 MS SQL Server，MySQL 背景和 IDS11 似乎过于复杂（我敢肯定，有充分的理由）。

在 SQL Server 中设置外键时，在什么情况下应该在删除或更新时级联，其背后的原因是什么？

这可能也适用于其他数据库。

我最关注的是每种场景的具体示例，最好是来自成功使用它们的人。

有很多关于对象关系映射器以及如何最好地避免阻抗不匹配的信息，如果要使用对象数据库，所有这些似乎都没有实际意义。我的问题是为什么不更频繁地使用它？是因为性能原因还是因为对象数据库导致您的数据成为应用程序的专有，还是由于其他原因？

我做过很多网络应用程序，你做的第一件事就是创建一个包含用户名、密码、姓名、电子邮件和所有其他常见问题的用户表。我目前的项目提出了一种情况，即非用户记录需要与用户类似的功能，但不需要成为一阶用户的能力。

创建第二个表是否合理people_tb，即主关系表和数据存储，并且仅使用users_tb用于身份验证？分离是否user_tb存在people_tb任何问题？如果通常这样做，有哪些策略和解决方案以及缺点？

作为程序员，我曾在各种系统上工作过，有些使用 Oracle，有些使用 MySQL。我经常听到人们说 Oracle 更稳定、更健壮、更安全。是这样吗？

如果是这样，以什么方式，为什么？

出于这个问题的目的，考虑一个中小型生产数据库，可能有 500,000 条左右的记录。

我们都有自己喜欢的数据库。如果您客观地看待您选择的数据库，它有哪些缺点以及可以改进的地方？

规则：

• 每个缺点回复一个；
• 限制的简短描述，然后是；

• 更详细的描述，对如何做得更好的解释或不具有相同限制的另一种技术的示例。

• 不要diss任何您没有广泛使用的数据库。对其他技术进行攻击很容易，但我们希望从您的经验中学习，而不是您的偏见。

我应该为使用高级语言（如 Python、Ruby）开发的项目使用手写模式，还是应该让我的 ORM 解决方案自动生成它？最终，我需要在不破坏所有数据的情况下进行迁移。可以绑定到特定的 RDBMS，但如果可以以某种方式支持约束和过程等功能，那就太好了。