有单行的SQL表?[闭门]

对于某些情况,您只需要一行数据——通常是系统配置数据。例如,“当前销售税率”。这在将来可能会改变,因此不应该硬编码,但通常在任何给定的时间都只需要一个。这类数据需要在数据库中,以便查询可以在计算中使用它。

当一个开发人员被要求创建一个配置表来存储需要保持而不经常更改的数据的名称-值对时,我看到了类似的情况。他最终创建了一个单行表,每个配置变量有一列。我不认为这是一个好主意,但我可以肯定地看到,为什么开发人员会按照他的指示这样做。不用说,它没有通过审查。

这听起来不是一个好的设计,除非有一些你不知道的重要细节。如果有三条信息具有相同的约束、相同的用途和相同的结构,那么它们应该在99%的时间内存储在同一个表中。从根本上说,这是表格的一大部分。

如果您有某个全局状态(比如布尔值)要存储在某个地方,该怎么办?您希望存储过程能够轻松访问此状态?

可以使用主键创建一个表,主键的值范围仅限于一个值。

单行就像一个单例类。目的:控制或管理其他过程。

单行表可以充当关键部分或确定性自动机(基于行值的调度器)

单行在表格公司描述中完全使用,以获得有关该公司的一致数据。使用完整的公司信函和地址。

单行是使用full来包含实际值,如增值税、日期或时间等。

数据库中只有一行的表有什么意义(如果有的话)?

比如,这个:“a VAT 这是百分之多少 现在在我国生效”。

如果只有一个元组满足这个关系,那么是的,它将是表中唯一的元组。

SQL 无法存储变量:它可以存储由 1

SQL 是一种基于集合的语言,对于某些操作,您需要一个只有一行的伪集合,例如,来选择一个常量表达式。

你不能只是 SELECT 无中生有 Oracle ,你需要一个 FROM 条款

神谕 dual ,它只包含一行和一列。

很久以前,它曾经 行(因此得名) 二重的 ),但在制作版本的过程中丢失了第二排 7 .

MySQL 也有这个假表,但是 MySQL 可以不做选择 从…起 条款但是,当您需要空行集时,它仍然很有用: SELECT 1 FROM dual WHERE NULL

我刚刚在一些代码中观察到,我正在查看三个不同的表,其中包含三种不同类型的证书(a la) SSL

这可能是一种“要么拥有一切,要么失去一切”的场景,此时同时需要所有三个证书:

SELECT  *
FROM    ssl1
CROSS JOIN
        ssl2
CROSS JOIN
        ssl3

如果证书丢失,则整个查询将不返回任何内容。

具有单行的表可用于存储跨所有数据库用户共享的应用程序级设置。”例如,最大允许用户数。

有趣的我问自己同样的问题。如果您只想存储一些简单的值,而您唯一的存储方法是SQL server,那么您就必须这么做。如果必须这样做,我通常会创建一个包含多个列和一行的表。我见过一些商业产品也这样做。

如果您的数据库是您的应用程序,那么存储实现业务逻辑的存储过程可能需要的配置数据可能是有意义的。

如果您有一个可以使用文件系统存储信息的应用程序,那么我认为与XML或平面文件相比,使用数据库没有任何优势,除了大多数开发人员现在可能更精通使用SQL来存储和检索数据,而不是访问文件系统。

我真的不明白为什么这是最好的解决办法。更有效的方法是只使用某种配置文件,其中包含一行表中的数据。连接到数据库并查询一行的成本会更高。但是,如果这将是数据库逻辑的某种配置。然后,根据您所使用的数据库类型,这将更有意义。

为此,我使用了非常棒的rails设置插件 http://github.com/Squeegy/rails-settings/tree/master

  Settings.admin_password = 'supersecret'
  Settings.date_format    = '%m %d, %Y'
  Settings.cocktails      = ['Martini', 'Screwdriver', 'White Russian']
  Settings.foo            = 123

  Settings.all            # returns {'admin_password' => 'super_secret', 'date_format' => '%m %d, %Y'}

为应用程序的某些设置设置默认值。这将导致定义的设置返回指定值,即使它们不在数据库中。在config/initializers/settings.rb中创建一个包含以下内容的新文件:

Settings.defaults[:some_setting] = 'footastic'

这可能用于存储数据库的当前版本。

我目前正在分析模式并进行相应的更新,但正在考虑转向版本控制。除非有人有更好的主意。

除非表上有用于版本控制的时间戳,否则这听起来是个坏主意。

在我继承的一个项目中,有一个这样设置的表。它用于配置数据,给出的原因是它用于非常简单的查询:

SELECT WidgetSize FROM ConfigTable
SELECT FooLength  FROM ConfigTable

好的,很好。我们转换为通用配置表:

ID  Name  IntValue StringValue TextValue

这很好地达到了我们的目的。

CREATE TABLE VERSION (VERSION_STRING VARCHAR2(20 BYTE))

我使用SQLite数据库中的单个数据作为动态网页中的计数器。这是我能想到的使其线程安全(或者确切地说是进程安全)的最简单方法。但我不确定这是否是个好主意。

我认为处理这些场景的最佳方法是,使用配置文件(通常是XML)或创建自己的配置文件(在应用程序启动期间读取),而不是使用数据库。只需几分钟就可以编写代码来读取其中的文件。