可以将演示数据存储在数据库中吗？

Posted 2023-02-24

【中文标题】可以将演示数据存储在数据库中吗？

【英文标题】：Is it ok to store presentation data in the database?

【发布时间】：2011-08-14 22:20:23

【问题描述】：

我要在网页中显示数据库 (SQL SERVER 2005) 表中的行。这些行包含由 Status 表进一步定义的 statusID（外键）（例如 id、name、modifiedDate）。

各种状态应该以不同的方式显示（假设它们只是具有不同的背景颜色）。

我正在使用php查询数据库，并建立网页表。在构建表格时，我将根据该行的状态将 css 类应用于元素。

我至少有两个选择：

在 php 中定义代码逻辑来处理它，如果数据库中的状态发生变化，我将不得不更改代码。

将“类”存储在数据库中，然后简单地应用已存储的类。

后一个选项对我来说似乎更好，但我不确定将表示性数据嵌入数据库是否是一个糟糕的设计选择。这将是我创建几个 Intranet 实用程序的基础，我想从正确的角度开始。

【问题讨论】：

我认为“应用一个css类”你的意思是应用一个类属性？ ;)

约定优于配置？我只需为 Status 表中的每条记录创建一个“status_”CSS 类...只需应用一些标准字符串修改来删除不适合 CSS 类名的空格和其他字符。

您是否认为您会添加许多不同的状态？如果您允许用户自定义状态及其外观，那么您将不会存储类信息 - 因为他们无法添加类。您可能正在存储特定的可自定义选项，例如背景颜色或字体颜色。通常状态是明确定义的，它不应该有太大变化。像 GetStatusClass(statusValue) 这样返回适当类的简单函数应该不会有太大变化。

@Richard 是的“类属性”。

@Prescott - 好点。虽然我认为状态不会有太大变化，但这个原则将应用于应用程序的其他部分，这只是一个例子。整个事情也处于非常早期的阶段，最初状态可能会发生根本性的变化。

【参考方案1】：

在数据库中存储任何数据都没有错，包括演示数据。如果它可以帮助您产生有效的结果，同时编写更少的代码，那么这是一个很好的做法。您需要确保不要将表示逻辑与数据库逻辑混在一起。

您可以通过将表示层的数据封装在elementInfo 对象的属性中（例如）来确保将这些问题分开。

由于您所说的是 CSS 类，因此该演示数据应与业务数据分开。因此，虽然可以将演示数据和业务数据都存储在数据库中，但将它们存储在同一个表中是不可接受的。

更新回复：评论不，您不应该将 PresentationClassRecord 的 Id 作为 FK 添加到业务对象上。我为下面的数据库制作了一个示例。我将您的业务对象称为DummyTable，其余的遵循规范。最相关的部分是StatusPresentationAssignmentTable

 -----------------------------------------------
 DummyTable
 -----------------------------------------------
 Id      Name     SomeOtherDataField    StatusId
 PK int  varchar  int                   FK int

 -----------------------------------------------
 StatusTable
 -----------------------------------------------
 Id      Name     ModifiedDate
 PK int  varchar  datetime

 -----------------------------------------------
 PresentationTable
 -----------------------------------------------
 Id      PresentationType    Value 
 PK int  varchar            
 sample data:
 43      CssClass            prettyBackground

 -----------------------------------------------
 StatusPresentationAssignmentTable
 -----------------------------------------------
 StatusId    PresentationId 
 FK int      FK int

现在通过两个简单的连接子句，您可以获得演示数据，并且它与您的业务数据完全分离。您的脚本可以执行诸如检查虚拟状态是否有任何演示分配之类的操作。如果是，则查看 PresentationType，获取适当的函数以将演示数据应用于演示，然后执行它。 （您需要为每个 PresentationType 提供一个知道如何处理该值的函数 - 可以由 function applyPresentationValue(presentationElement, presentationType, presentationValue) 之类的东西封装，如果 presentationType == "CssClass" 调用不同的函数 applyCssClass(presentationElement, value) ）。

【讨论】：

是否将另一列链接到“演示文稿”表创建这一层分离？

我喜欢这个例子。但是，在这种特殊情况下，这意味着我将创建许多额外的小型分配表（假设我在整个应用程序中应用了这种意识形态）。我是否应该关心这一点，连接和额外表是否会降低性能？

【参考方案2】：

类本身并不是真正的表示数据。它只是每种状态的标签。理论上，除了决定状态出现在网页上时应该是什么颜色之外，您还可以将它用于许多其他事情。

当你将该类与给定的一组样式结合起来时，那么它就是展示信息。您将在您的 CSS 文件中执行此操作，而不是在数据库中。

但是，如果数据库中的状态发生变化，选项 1 不一定要求您更改 PHP 代码。你的 PHP 可以从状态的id 或name 生成类名。如果状态的 id/name 发生更改，您的 CSS 将不得不更改，但这可能吗？如果应用程序需要表示的状态发生变化，每个状态不应该保持不变，并添加新状态吗？

【参考方案3】：

虽然您可以将 css 类信息存储在数据库中，但许多内容管理系统都会这样做，您最好将状态作为类名的一部分。

即 状态 = 打开、关闭 使用 php 逻辑生成表行并将 css 类设置为 status_name 那么任何时候你添加一个新的状态或者重命名它你只需要添加/编辑css文件，不需要php重新编码。

.status_openbackground-color:green;

.status_closedbackground-color:red;

【参考方案4】：

我看到将其存储在数据库中的优点和缺点。显然，在那里有类信息很方便，但它并不是应用程序的一部分。

我倾向于不将其存储在那里，而是在表示层中根据状态进行处理。我的推理是因为，特别是因为您正在创建实用程序，数据可能会通过 API 或稍后的类没有意义的东西来使用。