sqlite 的清单类型何时有用？
sqlite 使用作者称之为“Manifest Typing”的东西，这基本上意味着 sqlite 是动态的typed：如果需要，您可以将 varchar 值存储在“int”列中。
这是一个有趣的设计决策，但每当我使用 sqlite 时，我都会像使用标准 RDMS 一样使用它，并将类型视为静态类型。 事实上，在其他系统中设计数据库时，我从来不希望有动态类型的列。
那么，这个功能什么时候有用呢？ 有没有人在实践中发现它的良好用途，而使用静态类型列则无法轻松完成？
sqlite uses something that the authors call "Manifest Typing", which basically means that sqlite is dynamically typed: You can store a varchar value in a "int" column if you want to.
This is an interesting design decision, but whenever I've used sqlite, I've used it like a standard RDMS and treated the types as if they were static. Indeed, I've never even wished for dynamically typed columns when designing databases in other systems.
So, when is this feature useful? Has anybody found a good use for it in practice that could not have been done just as easily with statically typed columns?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
它实际上只是使类型更易于使用。 您无需再担心数据库级别的该字段需要有多大，或者您的整数可以有多少个数字。 或多或少这是一个“为什么不呢？” 事物。
另一方面，SQL Server 中的静态类型允许系统更好地搜索和索引，在某些情况下好得多，但对于一半的应用程序来说，我怀疑数据库性能的改进是否重要，或者它们的性能对于其他应用程序来说“很差”原因（每次选择、指数选择等都会创建临时表）。
我一直在 .NET 项目中使用 SqLite 作为客户端缓存，因为它太容易使用了。 现在，如果他们只能让它使用与 SQL Server 相同的 GUID，我会很高兴。
It really just makes types easier to use. You don't need to worry about how big this field needs to be at a database level anymore, or how many digets your intergers can be. More or less it is a 'why not?' thing.
On the other side, static typing in SQL Server allows the system to search and index better, in some cases much better, but for half of all applications, I doubt that database performance improvements would matter, or their performance is 'poor' for other reasons (temp tables being created every select, exponential selects, etc).
I use SqLite all the time for my .NET projects as a client cache because it is just too easy too use. Now if they can only get it to use GUIDs the same as SQL server I would be a happy camper.
动态类型对于存储配置设置等内容很有用。 以 Windows 注册表为例。 每个键很像具有以下形式的 SQLite 表：
CREATE TABLE Settings (Name TEXT PRIMARY KEY, Value);
其中 Value 可以是 NULL (REG_NONE) 或 INTEGER (REG_DWORD/REG_QWORD)、TEXT (REG_SZ) 或 BLOB (REG_BINARY)。
另外，我必须同意 Jason 的观点，即不强制执行字符串最大大小的有用性。 因为大多数时候，这些限制纯粹是任意的，并且您可以指望有一天会找到需要存储在 VARCHAR(30) 中的 32 字节字符串。
Dynamic typing is useful for storing things like configuration settings. Take the Windows Registry, for example. Each key is a lot like having an SQLite table of the form:
CREATE TABLE Settings (Name TEXT PRIMARY KEY, Value);
where Value can be NULL (REG_NONE) or an INTEGER (REG_DWORD/REG_QWORD), TEXT (REG_SZ), or BLOB (REG_BINARY).
Also, I'll have to agree with the Jasons about the usefulness of not enforcing a maximum size for strings. Because much of the time, those limits are purely arbitary, and you can count on someday finding a 32-byte string that needs to be stored in your VARCHAR(30).