只有一行的SQL表?

时间:2021-11-21 14:12:49

What is the point (if any) in having a table in a database with only one row?

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

Note: I'm not talking about the possibility of having only one row in a table, but when a developer deliberately makes a table that is intended to always have exactly one row.

注意:我并不是在讨论表中只有一行的可能性,而是当开发人员故意创建一个表时,这个表的目的是始终只有一行。

Edit:

编辑:

The sales tax example is a good one.

销售税是一个很好的例子。

I've just observed in some code I'm reviewing three different tables that contain three different kinds of certificates (a la SSL), each having exactly one row. I don't understand why this isn't made into one large table; I assume I'm missing something.

我刚刚在一些代码中看到,我正在检查三个不同的表,它们包含三种不同的证书(la SSL),每一种都只有一行。我不明白为什么这不是一张大桌子;我想我漏掉了什么。

18 个解决方案

#1


10  

I've seen something like this when a developer was asked to create a configuration table to store name-value pairs of data that needs to persist without being changed often. He ended up creating a one-row table with a column for each configuration variable. I wouldn't say it's a good idea, but I can certainly see why the developer did it given his instructions. Needless to say it didn't pass review.

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

I've just observed in some code I'm reviewing three different tables that contain three different kinds of certificates (a la SSL), each having exactly one row. I don't understand why this isn't made into one row; I assume I'm missing something.

我刚刚在一些代码中看到,我正在检查三个不同的表,它们包含三种不同的证书(la SSL),每一种都只有一行。我不明白为什么这不是排成一行;我想我漏掉了什么。

This doesn't sound look a good design, unless there are some important details you don't know about. If there are three pieces of information that have the same constraints, the same use and the same structure, they should be stored in the same table, 99% of the time. That's a big part of what tables are for fundamentally.

这听起来不是一个好的设计,除非有一些重要的细节你不知道。如果有3条信息具有相同的约束、相同的用途和相同的结构,那么它们应该被存储在相同的表中,99%的情况下是这样的。这是表格的一个重要组成部分。

#2


8  

For some things you only need one row - typically system configuration data. For example, "current sales tax rate". This might change in the future and so shouldn't be hardcoded, but you'll typically only ever need one at any given time. This kind of data needs to be in the database so that queries can use it in computations.

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

#3


6  

It's not necessarily a bad idea.

这不一定是个坏主意。

What if you had some global state (say, a boolean) that you wanted to store somewhere? And you wanted your stored procedures to easily access this state?

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

You could create a table with a primary key whose value range was limited to exactly one value.

您可以创建一个具有主键的表,其值范围仅限于一个值。

#4


3  

Single row is like a singleton class. purpose: to control or manage some other process.

单行类似于单例类。目的:控制或管理其他过程。

Single row table could act as a critical section or as deterministic automaton (kind of dispatcher based on row values)

单行表可以作为关键部分或确定性自动机(基于行值的调度程序)

Single row is use full in a table COMPANY_DESCRIPTION, to obtain consistent data about that company. Use full on company letters and addressing.

单行在表COMPANY_DESCRIPTION中充分使用,以获得关于该公司的一致数据。在公司信件和地址上使用。

Single row is use full to contain an actual value like VAT or Date or Time, and so on.

单行包含增值税、日期或时间等实际值。

#5


2  

It can be useful sometime to emulate some features the Database system doesn't provide. I'm thinking of sequences in MySQL for instance.

有时候模拟数据库系统没有提供的一些特性是很有用的。我在考虑MySQL中的序列。

#6


1  

A table with a single row can be used to store application level settings that are shared across all database users. 'Maximum Allowed Users' for example.

一个只有一行的表可以用来存储跨所有数据库用户共享的应用程序级别设置。“最大允许用户”。

#7


1  

What is the point (if any) in having a table in a database with only one row?

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

A relational database stores things as relations: a tuples of data satisfying some relation.

关系数据库将事物存储为关系:满足某种关系的数据元组。

Like, this one: "a VAT of this many percent is in effect in my country now".

就像这个:“这么多的增值税现在在我的国家生效了”。

If only one tuple satisifies this relation, then yes, it will be the only one in the table.

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

SQL cannot store variables: it can store a set consisting of 1 element, this is a one-row table.

SQL不能存储变量:它可以存储由1个元素组成的集合,这是一个单行表。

Also, SQL is a set based language, and for some operations you need a fake set of only one row, like, to select a constant expression.

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

You cannot just SELECT out of nothing in Oracle, you need a FROM clause.

在Oracle中,您不能凭空选择,您需要一个FROM子句。

Oracle has a pseudotable, dual, which contains only one row and only one column.

Oracle有一个伪表dual,它只包含一行和一列。

Once, long time ago, it used to have two rows (hence the name dual), but lost its second row somewhere on its way to version 7.

很久以前,它曾经有两行(因此命名为dual),但是在到版本7的途中丢失了第二行。

MySQL has this pseudotable too, but MySQL is able to do selects without FROM clause. Still, it's useful when you need an empty rowset: SELECT 1 FROM dual WHERE NULL

MySQL也有这个伪表,但是MySQL可以执行select而不使用FROM子句。不过,当您需要一个空行集:从dual中选择1时,它还是很有用的

I've just observed in some code I'm reviewing three different tables that contain three different kinds of certificates (a la SSL), each having exactly one row. I don't understand why this isn't made into one large table; I assume I'm missing something.

我刚刚在一些代码中看到,我正在检查三个不同的表,它们包含三种不同的证书(la SSL),每一种都只有一行。我不明白为什么这不是一张大桌子;我想我漏掉了什么。

It may be a kind of "have it all or lose" scenario, when all three certificates are needed at once:

这可能是一种“一劳永逸”的场景,同时需要三个证书:

SELECT  *
FROM    ssl1
CROSS JOIN
        ssl2
CROSS JOIN
        ssl3

If any if the certificates is missing, the whole query returns nothing.

如果缺少证书,则整个查询不返回任何内容。

#8


1  

I use the totally awesome rails-settings plugin for this http://github.com/Squeegy/rails-settings/tree/master

我为这个http://github.com/Squeegy/rails-settings/tree/master使用了非常棒的railssettings插件

It's really easy to set up and provides a nice syntax:

它非常容易建立和提供一个很好的语法:

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

Want a list of all the settings?

想要一个所有设置的列表吗?

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

Set defaults for certain settings of your app. This will cause the defined settings to return with the Specified value even if they are not in the database. Make a new file in config/initializers/settings.rb with the following:

设置应用程序的某些设置的默认值。这将导致定义的设置以指定的值返回,即使它们不在数据库中。在配置/初始化器/设置中创建一个新文件。rb以下:

Settings.defaults[:some_setting] = 'footastic'

#9


0  

Unless there are insert constraints on the table a timestamp for versioning then this sounds like a bad idea.

除非表中有插入约束,否则这听起来不是个好主意。

#10


0  

Funny... I asked myself the same question. If you just want to store some simple value and your ONLY method of storage is an SQL server, that's pretty much what you have to do. If I have to do this, I usually end up creating a table with several columns and one row. I've seen a couple commercial products do this as well.

有趣的…我问自己同样的问题。如果您只想存储一些简单的值,并且您惟一的存储方法是SQL服务器,那么这就是您必须做的事情。如果必须这样做,我通常会创建一个包含多个列和一行的表。我也看到过一些商业产品也这样做。

#11


0  

We have used a single-row table in the past (not often). In our case, this table was used to store system-wide configuration values that were updatable via a web interface. We could have gone the route of a simple name/value table, but the end client preferred a single row. I personally would have preferred the latter, but it really is up to preference, especially if this table will never have any sort of relationship with another table.

我们过去使用过单行表(不经常)。在我们的示例中,这个表用于存储通过web接口可更新的系统范围的配置值。我们可以使用一个简单的名称/值表,但是最终客户端更喜欢一行。我个人更喜欢后者,但它确实取决于偏好,特别是如果这个表永远不会与另一个表有任何关系。

#12


0  

If your database is your application, then it probably makes sense for storing configuration data that might be required by stored procedures implementing business logic.

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

If you have an application that could use the file system to store information, then I don't think there is an advantage to using the database over an XML or flat file, except maybe that most developers are now far more well versed in using SQL to store and retrieve data than accessing the file system.

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

#13


0  

There was a table set up like this in a project I inherited. It was for configuration data, and the reason that was given was that it made for very simple queries:

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

SELECT WidgetSize FROM ConfigTable
SELECT FooLength  FROM ConfigTable

Okay fine. We converted to a generalized configuration table:

好了好了。我们转换成一个通用配置表:

ID  Name  IntValue StringValue TextValue

This has served our purposes well.

这对我们的目的很有帮助。

#14


0  

I really cannot figure out why this would be the best solution. It seams more efficient to just have some kind of config file that will contain the data that would be in the tables one row. The cost of connecting to the database and querying the one row would be more costly. However if this is going to be some kind of config for the database logic. Then this would make a little bit more sense depending on the type of database you are using.

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

#15


0  

CREATE TABLE VERSION (VERSION_STRING VARCHAR2(20 BYTE))

?

吗?

#16


0  

I used a single datum in a SQLite database as a counter in a dynamic web page. That's the simplest way I can think of to make it thread-safe (or process-safe to be precise). But I am not sure whether it's a good idea.

在一个动态web页面中,我使用一个SQLite数据库中的单个数据作为计数器。这是我能想到的使它线程安全(或者精确地说,流程安全)的最简单方法。但我不确定这是不是一个好主意。

#17


0  

I think the best way to deal with these scenarios is to, rather than using a database at all, use the configuration file (which is usually XML) or make your own configuration file that is read during start up of the application. It only takes a few minutes to write the code to read the file in.

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

The advantage here is that the there is no chance accidentally adding additional values for the same XML variable, and its great for testing because you don't need to write a lot of code to test the different inputs, just a simple change to the text value and re-run the application.

这里的优势在于,没有机会意外添加额外的值相同的XML变量,测试和它的伟大,因为你不需要编写大量的代码来测试不同的输入,只是一个简单的改变和重新运行应用程序的文本值。

#18


0  

A use for this might be to store the current version of the database.

这样做的一个用途可能是存储数据库的当前版本。

If one were storing database versions for schema changes it would need to reside within the database itself.

如果要为模式更改存储数据库版本,则需要驻留在数据库本身中。

I currently analyse the schema and update accordingly but am thinking of moving to versioning. Unless someone has a better idea.

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

I use vb.net and sql express

我使用vb.net和sql express

#1


10  

I've seen something like this when a developer was asked to create a configuration table to store name-value pairs of data that needs to persist without being changed often. He ended up creating a one-row table with a column for each configuration variable. I wouldn't say it's a good idea, but I can certainly see why the developer did it given his instructions. Needless to say it didn't pass review.

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

I've just observed in some code I'm reviewing three different tables that contain three different kinds of certificates (a la SSL), each having exactly one row. I don't understand why this isn't made into one row; I assume I'm missing something.

我刚刚在一些代码中看到,我正在检查三个不同的表,它们包含三种不同的证书(la SSL),每一种都只有一行。我不明白为什么这不是排成一行;我想我漏掉了什么。

This doesn't sound look a good design, unless there are some important details you don't know about. If there are three pieces of information that have the same constraints, the same use and the same structure, they should be stored in the same table, 99% of the time. That's a big part of what tables are for fundamentally.

这听起来不是一个好的设计,除非有一些重要的细节你不知道。如果有3条信息具有相同的约束、相同的用途和相同的结构,那么它们应该被存储在相同的表中,99%的情况下是这样的。这是表格的一个重要组成部分。

#2


8  

For some things you only need one row - typically system configuration data. For example, "current sales tax rate". This might change in the future and so shouldn't be hardcoded, but you'll typically only ever need one at any given time. This kind of data needs to be in the database so that queries can use it in computations.

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

#3


6  

It's not necessarily a bad idea.

这不一定是个坏主意。

What if you had some global state (say, a boolean) that you wanted to store somewhere? And you wanted your stored procedures to easily access this state?

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

You could create a table with a primary key whose value range was limited to exactly one value.

您可以创建一个具有主键的表,其值范围仅限于一个值。

#4


3  

Single row is like a singleton class. purpose: to control or manage some other process.

单行类似于单例类。目的:控制或管理其他过程。

Single row table could act as a critical section or as deterministic automaton (kind of dispatcher based on row values)

单行表可以作为关键部分或确定性自动机(基于行值的调度程序)

Single row is use full in a table COMPANY_DESCRIPTION, to obtain consistent data about that company. Use full on company letters and addressing.

单行在表COMPANY_DESCRIPTION中充分使用,以获得关于该公司的一致数据。在公司信件和地址上使用。

Single row is use full to contain an actual value like VAT or Date or Time, and so on.

单行包含增值税、日期或时间等实际值。

#5


2  

It can be useful sometime to emulate some features the Database system doesn't provide. I'm thinking of sequences in MySQL for instance.

有时候模拟数据库系统没有提供的一些特性是很有用的。我在考虑MySQL中的序列。

#6


1  

A table with a single row can be used to store application level settings that are shared across all database users. 'Maximum Allowed Users' for example.

一个只有一行的表可以用来存储跨所有数据库用户共享的应用程序级别设置。“最大允许用户”。

#7


1  

What is the point (if any) in having a table in a database with only one row?

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

A relational database stores things as relations: a tuples of data satisfying some relation.

关系数据库将事物存储为关系:满足某种关系的数据元组。

Like, this one: "a VAT of this many percent is in effect in my country now".

就像这个:“这么多的增值税现在在我的国家生效了”。

If only one tuple satisifies this relation, then yes, it will be the only one in the table.

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

SQL cannot store variables: it can store a set consisting of 1 element, this is a one-row table.

SQL不能存储变量:它可以存储由1个元素组成的集合,这是一个单行表。

Also, SQL is a set based language, and for some operations you need a fake set of only one row, like, to select a constant expression.

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

You cannot just SELECT out of nothing in Oracle, you need a FROM clause.

在Oracle中,您不能凭空选择,您需要一个FROM子句。

Oracle has a pseudotable, dual, which contains only one row and only one column.

Oracle有一个伪表dual,它只包含一行和一列。

Once, long time ago, it used to have two rows (hence the name dual), but lost its second row somewhere on its way to version 7.

很久以前,它曾经有两行(因此命名为dual),但是在到版本7的途中丢失了第二行。

MySQL has this pseudotable too, but MySQL is able to do selects without FROM clause. Still, it's useful when you need an empty rowset: SELECT 1 FROM dual WHERE NULL

MySQL也有这个伪表,但是MySQL可以执行select而不使用FROM子句。不过,当您需要一个空行集:从dual中选择1时,它还是很有用的

I've just observed in some code I'm reviewing three different tables that contain three different kinds of certificates (a la SSL), each having exactly one row. I don't understand why this isn't made into one large table; I assume I'm missing something.

我刚刚在一些代码中看到,我正在检查三个不同的表,它们包含三种不同的证书(la SSL),每一种都只有一行。我不明白为什么这不是一张大桌子;我想我漏掉了什么。

It may be a kind of "have it all or lose" scenario, when all three certificates are needed at once:

这可能是一种“一劳永逸”的场景,同时需要三个证书:

SELECT  *
FROM    ssl1
CROSS JOIN
        ssl2
CROSS JOIN
        ssl3

If any if the certificates is missing, the whole query returns nothing.

如果缺少证书,则整个查询不返回任何内容。

#8


1  

I use the totally awesome rails-settings plugin for this http://github.com/Squeegy/rails-settings/tree/master

我为这个http://github.com/Squeegy/rails-settings/tree/master使用了非常棒的railssettings插件

It's really easy to set up and provides a nice syntax:

它非常容易建立和提供一个很好的语法:

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

Want a list of all the settings?

想要一个所有设置的列表吗?

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

Set defaults for certain settings of your app. This will cause the defined settings to return with the Specified value even if they are not in the database. Make a new file in config/initializers/settings.rb with the following:

设置应用程序的某些设置的默认值。这将导致定义的设置以指定的值返回,即使它们不在数据库中。在配置/初始化器/设置中创建一个新文件。rb以下:

Settings.defaults[:some_setting] = 'footastic'

#9


0  

Unless there are insert constraints on the table a timestamp for versioning then this sounds like a bad idea.

除非表中有插入约束,否则这听起来不是个好主意。

#10


0  

Funny... I asked myself the same question. If you just want to store some simple value and your ONLY method of storage is an SQL server, that's pretty much what you have to do. If I have to do this, I usually end up creating a table with several columns and one row. I've seen a couple commercial products do this as well.

有趣的…我问自己同样的问题。如果您只想存储一些简单的值,并且您惟一的存储方法是SQL服务器,那么这就是您必须做的事情。如果必须这样做,我通常会创建一个包含多个列和一行的表。我也看到过一些商业产品也这样做。

#11


0  

We have used a single-row table in the past (not often). In our case, this table was used to store system-wide configuration values that were updatable via a web interface. We could have gone the route of a simple name/value table, but the end client preferred a single row. I personally would have preferred the latter, but it really is up to preference, especially if this table will never have any sort of relationship with another table.

我们过去使用过单行表(不经常)。在我们的示例中,这个表用于存储通过web接口可更新的系统范围的配置值。我们可以使用一个简单的名称/值表,但是最终客户端更喜欢一行。我个人更喜欢后者,但它确实取决于偏好,特别是如果这个表永远不会与另一个表有任何关系。

#12


0  

If your database is your application, then it probably makes sense for storing configuration data that might be required by stored procedures implementing business logic.

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

If you have an application that could use the file system to store information, then I don't think there is an advantage to using the database over an XML or flat file, except maybe that most developers are now far more well versed in using SQL to store and retrieve data than accessing the file system.

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

#13


0  

There was a table set up like this in a project I inherited. It was for configuration data, and the reason that was given was that it made for very simple queries:

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

SELECT WidgetSize FROM ConfigTable
SELECT FooLength  FROM ConfigTable

Okay fine. We converted to a generalized configuration table:

好了好了。我们转换成一个通用配置表:

ID  Name  IntValue StringValue TextValue

This has served our purposes well.

这对我们的目的很有帮助。

#14


0  

I really cannot figure out why this would be the best solution. It seams more efficient to just have some kind of config file that will contain the data that would be in the tables one row. The cost of connecting to the database and querying the one row would be more costly. However if this is going to be some kind of config for the database logic. Then this would make a little bit more sense depending on the type of database you are using.

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

#15


0  

CREATE TABLE VERSION (VERSION_STRING VARCHAR2(20 BYTE))

?

吗?

#16


0  

I used a single datum in a SQLite database as a counter in a dynamic web page. That's the simplest way I can think of to make it thread-safe (or process-safe to be precise). But I am not sure whether it's a good idea.

在一个动态web页面中,我使用一个SQLite数据库中的单个数据作为计数器。这是我能想到的使它线程安全(或者精确地说,流程安全)的最简单方法。但我不确定这是不是一个好主意。

#17


0  

I think the best way to deal with these scenarios is to, rather than using a database at all, use the configuration file (which is usually XML) or make your own configuration file that is read during start up of the application. It only takes a few minutes to write the code to read the file in.

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

The advantage here is that the there is no chance accidentally adding additional values for the same XML variable, and its great for testing because you don't need to write a lot of code to test the different inputs, just a simple change to the text value and re-run the application.

这里的优势在于,没有机会意外添加额外的值相同的XML变量,测试和它的伟大,因为你不需要编写大量的代码来测试不同的输入,只是一个简单的改变和重新运行应用程序的文本值。

#18


0  

A use for this might be to store the current version of the database.

这样做的一个用途可能是存储数据库的当前版本。

If one were storing database versions for schema changes it would need to reside within the database itself.

如果要为模式更改存储数据库版本,则需要驻留在数据库本身中。

I currently analyse the schema and update accordingly but am thinking of moving to versioning. Unless someone has a better idea.

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

I use vb.net and sql express

我使用vb.net和sql express