Sql 在数据库ORM中，应该将字符串映射到什么？

字符串是无界的，但似乎每个普通的关系数据库都要求列声明其最大长度。这似乎是一个相当显著的差异，我很好奇典型的ORM是如何处理这个问题的

从理论上讲，使用“文本”列类型可以提供更多类似字符串的存储，但据我所知，文本列是不可查询的，或者至少没有效率（无索引？）

---

我正在考虑使用类似NHibernate的东西，但我的ORM需求相对简单，因此如果我能自己编写，可能会节省一些开销。

据我所知，他们不会处理它，或者让ORM定义模式，然后： ORM将决定默认的或由您的配置定义的大小

或者该模式没有被ORM定义，那么它只需要遵守规则，如果插入太大的字符串，那么数据库就会出错

---

我会继续使用varcharish类型，例如用于oracle的varchar2或用于sql server的nvarchar，除非您正在处理CLOB。

例如，sql server只存储数据的实际大小。对我来说，为字符串定义一个足够大的大小就足够了，以至于用户无法识别这些限制

Exmaples：

• 产品名称、人员等：500
• 路径、URL等：1000
• 评论，自由文本：2000或更多

NHibernate在运行时不使用任何大小。您需要使用某种验证器，或者让数据库剪切或抛出异常

引用：“我的ORM需求相对简单”。很难说NHibernate是否过火了。数据访问通常不是那么简单

作为我头顶的简单指南，如果：

• 您有一个细粒度或复杂的域模型。您需要映射继承
• 您希望域模型在某种程度上独立于数据库模型
• 您需要一些延迟加载特性
• 您希望独立于数据库，例如，在SqlServer或Oracle上运行它

---

如果您认为每个表需要一个类，那么实际上并不需要ORM。

“例如，SqlServer只存储数据的实际大小。”--这是否意味着理论上我可以将最大大小声明为类似于max_INT的值，或者这仍然会有一些性能缺陷？NVarchar限制为8000-然后您必须指定NVarchar（max），它实际上是一个具有一些特殊功能的blob，例如可以过滤。如果没有任何性能缺陷，不能说是100%，但我不知道为什么会有这样的缺陷。另一方面，拥有8000个字符的用户名是没有意义的，因为您无法在屏幕或报告上正确显示它。因此，限制合理的价值根本没有坏处。