问题标签 [rdbms]

我有一个存储所有值的表......例如 x1、x2、x3 确定模糊集。使用低、中、高的数学函数为每个成员分配隶属度。

我的规则 1 指出，如果 x1 高且 x2 中等，则输出概率为 z。然后我用 min{x1,x2} 来评估规则。规则 2 规定如果 x2 为高或 x3 为中，则输出为 max{x2,x3}。

现在为了去模糊化，我对规则结果进行聚合以找出 2 个规则的输出。我为每个规则定义了 x1 x2 x3 的所有成员级别（0 到 1）。

如何去模糊化？

简而言之，我了解关系数据库、索引、复制、锁定、并发等的基础知识，以及与简单的表达，例如：

但我不了解关系数据库中的任何“高级”主题，例如：

• 域
• 约束
• 指数

谁能给我一个快速入门，对这些方面的作用以及它们如何工作的大致解释？

您可能会否决并完全丢弃这个问题，但请向我解释一下这些主题是如何工作的，因为我需要非常快速地了解关系数据库。

是否有用于查询 OLAP 多维数据集/数据仓库的 ORM 类比？我对 .NET 世界特别感兴趣，但通常对任何事情都感兴趣；-)

在过去的几年里，我设计了几个应用程序，然后不断改进性能和可伸缩性方面，我对 MySQL 领域感到很自在。我也有一些使用 memcached 为经常查询的结果集提供应用程序端加速的经验。最近，我将 Amazon SDB 作为我的主要“数据库”用于电子商务实验。

简单地说，我想到使用 SDB 服务的一个快速理由是，使用无模式数据库结构可以让我专注于我的项目的逻辑问题，并在我的数据存储中快速积累内容。也就是说，不必担心事先设置和规范化产品属性的所有可能排列；只需开始加载产品，SDB 就会记住所有可用的内容。

现在我已经设法完成了项目的前几次迭代，并且我需要为数据设置简单的接口，我遇到了我认为使用 MySQL 理所当然的问题。例如：在 select 语句中分组并限制语法以查询“项目 50 到 100”。使用 SDB 的无模式架构获得的易用性优势，我失去了查询/循环仅包含 1800 多个项目的结果集的性能损失。

现在我正在阅读诸如东京内阁之类的项目，这些项目正在扩展内存中键值存储的概念，以更快的速度提供伪关系功能（我在某处读到的 14 倍）。

我的问题：作为应用程序设计师/开发人员，我是否可以通过一些基本指南或启发式方法来评估哪种数据库技术最适合我的项目的每个阶段。

例如：在原型设计阶段，应用程序的逻辑/技术未知数使数据结构变得流畅：使用 SDB。在更成熟的阶段，优先考虑用户交付，使用传统工具，您不必花费开发时间编写排序、分组或分页逻辑。

非常感谢使用这些工具的实际经验。

谢谢！

沙希布·R。

想知道是否存在这样一种场景，即在两全其美的场景中同时使用基于文档的数据库和关系数据库？

想知道是否可以从基于文档的数据库（例如 couchDB）迁移到 RDBMS（例如 MySQL）。

我正在尝试确定在关系数据库中对记录关系进行建模的最佳方法。这是经典的朋友/关注模式：

~~~~

一个用户可以有零到多个朋友。
一个用户可以有零到多个关注者。

朋友和追随者都是用户本身。

~~~~~

对此进行建模的最佳方法是什么？

谢谢！

我继承的当前项目主要围绕一个未规范化的表。有一些标准化的尝试，但没有设置必要的限制。

示例：在 Project 表中，有一个客户名称（以及其他值），还有一个客户表，其中仅包含客户名称 [任何地方都没有键]。客户表仅用作在添加新项目时为用户提供的值池。客户表上没有主键或外键。

诸如此类的“设计模式”在数据库的当前状态和使用它的应用程序中很常见。我可以使用的工具是 SQL Server 2005、SQL Server Management Studio 和 Visual Studio 2008。我最初的方法是手动确定哪些信息需要规范化并运行 Select INTO 查询。有没有比个案更好的方法，或者无论如何这可以自动化？

编辑： 另外，我发现“工作订单号”不是 IDENTITY（自动编号，唯一）字段，它们是按顺序生成的，并且对于每个工作订单都是唯一的。现有编号中也有一些空白，但都是独一无二的。这是编写存储过程以在迁移之前生成虚拟行的最佳方法吗？

关于我的另一个问题“审计日志删除的最佳方法是什么？” . PostgreSQL 相当于CONTEXT_INFO什么？

我想使用触发器记录删除，但由于我没有将数据库用户用作我的应用程序的逻辑用户，因此我无法CURRENT_USER将触发器代码中的用户记录为删除记录的用户。但是对于INSERT并且UPDATE可以从触发器记录记录更改，因为您可以在记录中添加一个用户字段，比如inserted_byand last_updated_by，并使用这些字段记录到审计表。

之前我发布了一个问题，所以我可以在这里确认我们当前（尽管是过时的）Informix 版本：

您如何识别 Solaris 上的 Informix 版本？

（感谢 Jonathan 和 RET 澄清了这一点）

我们肯定在计划升级，但首先讨论的是此时迁移到 Oracle 或 Sybase 是否更有意义。您对此有何看法？我相信虽然所有 3 种 RDBM 都有自己的独特性，但它们本质上都必须涵盖相同的领域。那么如何决定使用什么数据库呢？

最大的问题是我需要知道如果我们升级 Informix（目前使用 7.13），我们是否需要修改我们的嵌入式 sql C 程序？如果不是，那么坚持使用 Informix 就很有意义。因为如果我们使用 Sybase/Oracle 等，我们将有很多工作要做来更新后端程序。

但是如果切换到另一个数据库可以提供比较大的回报，那么我们仍然会考虑它。我期待听到您的意见。