Mysql 使用非文本列是否会使数据库表复杂化？

到目前为止，根据我的经验，保存在表的列中的每一条数据都没有一个特定的原因可以是整数或布尔值等等。再一次，我们都建议使用基于数据类型的列类型。我这么做已经很多年了

我想完全放弃这个想法，只使用带有文本列的表。创建它们更容易（不必写类型，但可以复制/粘贴文本），编译器会在需要类型转换时警告我，还有很多类似的原因

---

是否有一个很好的不可击败的理由让我不应该切换到这种做法？

不，我们不会用非文本列使数据库表复杂化，而是让数据库为数据的存储提供一致的格式

通过使用数字、布尔值和日期字段，我们得到了数据库为这些字段实现的所有出色的验证和检索方法

如果不使用特定的数据类型，当我们需要验证和特定的显示格式时，我们将开始重新发明轮子

---

我曾经在一个数据仓库小组工作，这经常让我想对收到的大多数数据有更好的定义数据类型、格式、必填字段和验证。

这是一个非常非常糟糕的主意。如何防止有人将

foobar

存储在您期望的数字列中？或者

46476-77-59

在您希望日期的列中？如果你打算回答“我的申请正在处理这个问题”，那么你是在愚弄自己。您无法控制数据进入数据库的所有方式。我见过很多数据库，人们声称应用程序会处理这个问题，但事实并非如此。我甚至没有谈论从多个应用程序中使用的数据库。不：当有人将

insert写入我的表（一些列）值（'125'）时，“编译器”不会警告您@a_horse_和_no_name OK，显然这不能应用于所有情况。但是，那些只处理从API发送的JSON/XML数据的应用程序呢？这里没有用户交互。也许你只是需要更多的经验。原因有很多。不幸的是，投票以基于意见的方式结束这一次。@Randy你可能是对的。数据库设计不是我的专长。但我几乎每次都是作为编程任务的一部分来做。正如我对Michael说的，也许我确实忘记了不发明轮子的规则。但是这种方法可以用于特定的数据库设计。你同意这一点吗？当您不需要此类验证或没有用户输入交互时。这是否意味着我们不能在所有情况下都将其视为坏主意？不。但所有这些都不能反映我工作了几十年的世界。我避免绝对和规则。当然，在某些情况下，更为“原始存储”的方法是合适的，而对于那些关键价值的存储，如mongoDB，则是合适的。我会尝试选择与您的业务需求相匹配的数据存储方法（此处未定义），而不是让rdbms等特定存储机制满足您的需求。我似乎忘记了黄金法则“不要发明轮子”。）因此，我将继续使用特殊方法设计数据库。不确定的时候，我就按方向盘。