有没有办法在MySQL中实现用户定义的数据类型？

我有一个数据库，其中存储（除其他外）以下信息：

• 硬件ID

  BIGINT

  s
• 存储容量

  BIGINT

  s
• 硬件名称

  VARCHAR

  s
• 全球通用端口名

  VARCHAR

  s

我希望能够捕获这些数据类型的更精确的定义。例如，硬件ID没有数字意义，所以我不关心它们在显示时的格式。然而，存储容量是基数，根据用户的要求，我想用千位和十进制分隔符来表示它们，例如123456.789。因此，我想将

BIGINT

细化为

ID\u NUMBER

和

CARDINAL

硬件名称也是如此，它们是简单文本，WWPN是十六进制字符串，例如24:68:AC:E0。因此，我想将

VARCHAR

细化为

ENGLISH\u-WORD

和

HEXSTRING

我编写的特定数据类型仅用于说明目的

我想将所有这些信息保存在一个地方，我想知道是否有人知道一种好方法可以将这些信息保存在我的MySQL表定义中。我可以使用表定义的注释字段，但我觉得这有点可疑

一种方法是在其他地方定义数据结构，并使用该定义生成我的

CREATE TABLE

s，但这将是对我目前拥有的代码的重大修改，因此我正在寻找替代方案

---

有什么建议吗？如果有帮助的话，使用的应用程序语言是Perl。

一个好方法是使用视图。例如，要在基数中插入逗号，可以使用：

mysql> create table foo (id int);
Query OK, 0 rows affected (0.12 sec)

mysql> insert into foo (id) values ( 123456789);
Query OK, 1 row affected (0.00 sec)

mysql> create view v_foo as select format(id, 0) as id from foo;
Query OK, 0 rows affected (0.10 sec)

mysql> select * from v_foo;
+---------------+
| id            |
+---------------+
| 123,456,789   |
+---------------+
1 row in set (0.02 sec)

---

您可以使用other设置其他字段的格式，并将其存储在视图定义中。

我将提出一个问题的答案

为数据库建模的人喜欢哼唱的一个咒语是将表示层（格式）和数据分离，我相信其中的相关部分是这样的：

“您不得在数据库中存储格式化数据，也不得歧视任何格式化选择。您应将数据存储在本机支持的数据类型中。应用程序应提供表示层和列格式。”

嗯，弗里多的回答并不直接与此相反——数据仅通过视图显示，存储仍然是本地的

不过，这取决于您如何在那里定义表示层-如果视图和服务器设置被视为表示层的一部分，那么一切都很好，否则会有潜在的问题，因为我，您系统的可能用户，将无法指定我的千位分隔符是一个单引号这一事实（至少是在我现在居住的地方）

此外，一旦您走上这条路，您认为需要多长时间才能处理将数据从文本重新解析回数字的请求，并可能最终导致不明确的情况（例如DD/MM/YY vs MM/DD/YY）

上面的rant只是关于格式化，确定十进制数字的数量定义了数据的域，这是一件好事，因为它限制了不一致数据进入数据库的可能性

编辑：（关于数基，进一步娱乐纯粹主义者的观点） 说十六进制数数据在其他基数中没有意义通常是错误的。 数值没有基，可以在任何基中表示。它们的域（允许的值集）是相同的

由于历史原因，选择十六进制作为MAC地址是很自然的，而且事实上，例如，很容易阅读该格式的供应商部分。 IPv4地址选择“有趣”的格式是一个历史，可能有一个轶事原因

但两者都只是一种选择，在内部，一个好的系统将毫无偏见地存储它们（例如，将IPv4存储为文本不是一件好事）。当RDBMS（在屏幕上）向您显示查询结果时，它已经扮演了应用程序的角色，并以某种方式格式化结果

这并不重要，应用程序中使用的格式不应影响存储容量或其他实体属性的存储方式

所以我是说这是应用程序配置数据（核心日期的元数据），当然可以/应该存储在数据库中，但是使用MySQL（它在定义自定义类型方面不太丰富）它不适合于表定义，应该简单地存储在另一个表中，应用程序在向用户呈现数据时将读取并应用于列，而不是以某种不可移植的黑客方式

例如，视图想法是可行的，但您能否轻松查询视图以获取应用于字段的格式？或者假设您希望在所有使用它的查询中更改字段WWPN的所有引用中的格式（hexstring听起来也已经错了），这容易吗？或者如果有其他查询转换数据并将其写入另一个表中，您是使用应用格式还是不使用应用格式（重新解析）？等等

现在，如果您有一个存储应用程序配置数据的表，例如 字段格式： 表格、字段、格式、检查规则、长格式（或在您的情况下最有意义的任何内容） 然后，上面的问题变得更容易处理，您可以为您的应用程序和业务逻辑选择额外的选项

如果您真的（真的，真的）必须提供对数据库的直接访问，并且本机类型将使用户无法读取数据，并且您只需执行以下操作，那么您甚至可以使用上表半自动地生成和更新视图/查询

注意：我在这里采取的是一种纯粹的观点，因为我觉得你是