有没有一种方法可以影响MySQL中用户定义的数据类型?

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

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)

你可以用其他的 string functions 设置其他字段的格式,并将其存储在视图定义中。

对数据库建模的人喜欢哼哼的一个咒语是表示层(格式化)和数据的分离,我相信相关的部分来自 like 类似于:

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

好吧,friedo的答案并不直接与此相反——数据只通过视图呈现,存储仍然是本地的。

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

另外,一旦你走上这条路,你认为它会经过多长时间,直到你必须处理请求,将数据从文本重新解析回一个数字,并可能在这种情况下结束可能是含糊不清的(如DD/MM/YY vs MM/DD/YY)?

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

编辑:(关于数基,把纯粹主义的观点看得更远一点) 说十六进制数数据在其他基中没有意义通常是错误的。

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

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

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

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

现在,如果您有一个存储应用程序配置数据的表,例如 字段格式: 表、字段、格式、CheckRules、LongFormat(或任何在您的情况下最有意义的东西) 然后,上面的问题变得更容易处理,您可以为您的应用程序和业务逻辑选择额外的选项。

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

注意:我在这里采取的是一种纯粹的观点,因为我感觉您在这里做设计决策,而不是追求最后一点性能或便利性(例如在应用程序数据类型和数据库数据类型之间),因为实际问题可能比建模指导原则和规则更重要。但最后一段的问题仍然存在。