blocks|key|4410770|text|首先，我会将该列命名为“StayDuration”或“StayLength”，因为仅仅是“Stay”本身仍然有点令人困惑。完成后，我看到了两种可以接受的方法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4410771|4410772|将您的长度放入一个单独的表中，并让您的现有列将一个外键存储到该表中。|unordered-list-item|4410773|存储一个整数，以便可以通过一个简单的公式轻松地将该整数的值扩展为停留长度限制的实际值。(示例：“短”停留时间可以是1天或更短时间，“中”停留时间可以是一周或更短时间，然后所有其他时间都是长的，您可以使用0、1和7作为整数。|4410774|4410775|我倾向于避免在这里直接存储varchar类型的数据。它需要更多的存储空间，并且很容易导致输入错误或过时的数据。|4410776|一种混合的方法也是可能的，这样来自第一个选项中的新表的“键”映射到第二个选项中提出的整数值。|4410777|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|R|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

First of all, I would name the column 'StayDuration' or 'StayLength', as just 'Stay' by itself is still a little confusing. Once that is done, I see two acceptable approaches:

<ul>
<li>Put your lengths in a separate table and have your existing column store a foreign key into that table.</li>
<li>Store an integer, such that the value of the integer can be easily expanded into actual values for the stay length barriers via a simple formula. (Example: a 'short' stay could be 1 day or a less, 'medium' one week or less, and then everything else is long, you might use 0, 1, and 7 for your integers.</li>
</ul>

I tend to avoid storing varchar-type data directly here. It requires more storage and makes it easy to end up with mis-typed or obsolete data.

A hybrid approach is also possible, such that the 'keys' from the new table in the first option map to the integer values proposed in the 2nd.

blocks|key|345767|text|基本上有3种选择：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|345768|345769|某些数据库支持专门用于这种情况的枚举类型。(对Oracle不太确定)|unordered-list-item|345770|您可以使用char(6)|345771|您可以使用int并在应用程序级别将这些类型映射到适当的类型。|345772|345773|我会说Enum是“最干净的”选项。但是一些ORM并不能正确地支持这一点。|345774|你可能会对这个问题感兴趣：|345775|How+to+use+enums+in+Oracle?|offset|length|345776|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/203469/how-to-use-enums-in-oracle^0|0|0|0|0|0|0|0|0|0|R|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|13|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|14|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@$Q|19|R|1A|1|1B]]|A|$]]|$1|S|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

There are basically 3 options:

<ul>
<li>Some databases support the type Enum specifically for this situations. (not sure about Oracle)</li>
<li>You can use a char(6)</li>
<li>You can use an int and map these at application level to the appropriate type.</li>
</ul>

I would say Enum is the 'cleanest' option. But some ORM don't support this properly.

This SO question might be interesting for you:

<a href="https://stackoverflow.com/questions/203469/how-to-use-enums-in-oracle">How to use enums in Oracle?</a>

blocks|key|4410818|text|使用VARCHAR2(6)。CHAR(6)具有空格填充的语义，这使用起来很奇怪；这也意味着您每次使用单词'Long‘时都要存储完整的6个字符。几乎没有令人信服的理由使用CHAR而不是VARCHAR2。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4410819|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Use VARCHAR2(6). CHAR(6) has blank-padded semantics, which is weird to use; it also means you store a full 6 characters for the word 'Long' every time you use it. There is almost never a compelling reason to use CHAR instead of VARCHAR2.

blocks|key|4410955|text|如果有可用的ENUM类型，请使用该类型。否则，我建议两个选项：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4410956|4410957|将其存储为单字节(或可用的最小整数类型)。然后，您可以随意在应用程序中与枚举进行相互转换。我认为这是最干净的方法，并且作为键值对与ComboBoxes绑定得很好。|unordered-list-item|offset|length|style|CODE|4410958|您还可以将字符串存储在一个单独的表中，并将现有列作为这个新表的外键。然后很容易连接到这个表，并获得一个快速的字符串查找来显示在您的表单上。但是，这会增加额外的开销，并且可能会将字符串放在两个位置-应用程序和数据库。此外，如果你想本地化，你会遇到真正的麻烦。--|4410959|4410960|4410961|如果您想围绕此列构建任何应用程序逻辑，我不建议使用string+(VARCHAR+/+CHAR)选项。你会整天都在比较字符串，这是相当丑陋和缓慢的。它们的排序和查询速度也比简单的整型要慢。(但是，您在示例中是安全的，因为您可以只比较第一个字符“S”、“M”或“L”-一个字节。但您必须专门指示它以这种方式进行排序和查询。)|4410962|如果你只是想要显示值，你可以使用字符串，但要记住大小。通过存储字符串，您的数据库很容易膨胀：|4410963|使用CHAR(6)的|4410964|1,000,000行比使用单个字节多5,000,000字节。使用VARCHAR(6)的|4410965|对于1,000,000行，平均长度为5=+4,000,000字节。|4410966|4410967|entityMap^0|0|0|1T|8|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|12|8|@$F|13|G|14|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|15|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|18|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|19|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1A|8|@]|9|@]|A|$]]|$1|T|3|U|5|E|7|1B|8|@]|9|@]|A|$]]|$1|V|3|W|5|E|7|1C|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|Z|$]]

If there is an ENUM type available, go with that. Otherwise, I suggest two options:

<ul>
<li>Store it as a single byte (or the smallest integral type available). Then you can convert to and from an enum in your application at will. I think this is the cleanest approach and binds quite well to <code>ComboBox</code>es as a key-value pair.</li>
<li>You can also store the strings in a separate table and have the existing column be a foreign key into this new table. It's then easy to JOIN on this table and get a fast string lookup to display on your form. However, it is additional overhead and possibly puts your strings in two locations - your application and the database. Moreover, if you ever want to localize, you're in for a real hassle.</li>
</ul>

<hr>

I can't recommend going with the string (VARCHAR / CHAR) option if you want to build any application logic around this column. You'll be stuck comparing strings all day, which IMHO is rather ugly and slow. They're also slower to sort and query on than a simple integral type. (You are safe in your example, however, because you can just compare the first character 'S', 'M', or 'L' - a single byte. But you'll have to specifically instruct it to sort and query that way.)

If you simply are looking to display the value, you can go with the string, but keep in mind the size. Your database can easily blow up in size by storing the strings: 

<ul>
<li>1,000,000 rows of a CHAR(6) is 5,000,000 bytes more than using a single byte. </li>
<li>Using VARCHAR(6) would yield an average length of 5 = 4,000,000 bytes extra for 1,000,000 rows.</li>
</ul>

blocks|key|346012|text|使用带有值'S‘、'M’、‘L’的CHAR(1)；可选地将该列链接到第二个表，其中S/M/L是主键，"small/medium/long“是varchar(255)解释。这样，您就有了最佳的代码大小(1字节尽可能短)，同时仍然能够在报告中打印“好”的名称。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|346013|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Use a CHAR(1) with values 'S', 'M', 'L'; optionally link the column to a second table where S/M/L are the primary keys, and "small/medium/long" are varchar(255) explanations. That way, you have optimal code size (1 byte is as short as possible), while still being able to print "nice" names in a report.

blocks|key|1036193|text|使用数字数据类型可以更容易地按大小对对象进行排序。我不能代表Oracle说话，但很多时候，使用一个字节并不能节省你太多，因为它无论如何都会被塞进一个4字节的字中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1036194|而且，你现在只有三个尺寸，但将来你可能会有更多的尺寸。使用单个字符可以使区分XL和XXL大小成为一个真正的挑战。|1036195|根据您正在处理的应用程序的类型，如果您需要本地化您的应用程序，则在数据库中存储呈现给用户的字符串可能会产生影响。如果你将整个数据库作为应用程序的一部分发布，只要你把它们放在一个查询表中就没什么大不了的。如果你正在处理一个web应用程序，它需要不同的用户以不同的语言访问相同的数据库，这可能会导致一些问题。|1036196|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Using a numeric datatype makes it much easier to sort things by size if that's ever something you want to do. I can't speak for Oracle, but lots of times, using a single byte doesn't save you much, since it's going to get shoved into a 4 byte word anyway.

Also, you only have three sizes now, but you may well have many more in the future. Using a single character can make distinguishing between the XL and XXL size a real challenge.

Depending on the sort of application you're working on, storing strings presented to the user in the database can have implications down the road if you ever need to localize your application. If you're shipping the whole DB as part of the app, it's no big deal as long as you have them in a lookup table. If you're dealing with, say, a web application that needs to have different users accessing the same database in different languages, it can cause some problems.

I am currently creating a small table in Oracle and am unsure of which data type to choose for a particular column.

The column is labelled 'stay' and I would like it to contain only these values 'Short', 'Medium' and 'Long'. The end goal is to have these values in a drop down list within a form.

Am I right in picking a data type of 'char(6)' here?

Is it then possible to use Oracle form builder to make this into a list of values?

Thank you for your time.

Basic SQL Question - Data Type Choice

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我目前正在Oracle中创建一个小表，不确定为特定列选择哪种数据类型。该列被标记为“stay”，我希望它只包含“Short”、“Medium”和“Long”这些值。最终目标是将这些值放在表单的下拉列表中。这里我选择的数据类型是'char(6)‘，对吗？那么，是否可以使用Oracle form builder将其转换为值列表呢？谢谢您抽时间见我。

问基本SQL问题-数据类型选择
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问基本SQL问题-数据类型选择EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问基本SQL问题-数据类型选择
EN