我可以在 Amazon SimpleDB 中仅创建域架构（没有任何数据）吗？
我此时正在评估 Amazon SimpleDB。 SimpleDB 非常灵活，因为它不必具有表（或域）模式。模式随着创建/更新命令的流入而演变。这一切都很好，但是当我使用建模工具（评估 MindScape LightSpeed）时，我需要预先提供模式，以便该工具基于模式生成模型。我可以在 SimpleDB 中手工制作域，这确实有帮助，但为此我必须在域上执行至少一项创建操作。我正在寻找仅创建域模式的能力。有什么线索吗？
I am evaluating Amazon SimpleDB at this time. SimpleDB is very flexible in the sense that it does not have to have table (or domain) schemas. The schema evolves as the create / update commands flow in. All this is good but while I am using a modeling tool (evaluating MindScape LightSpeed) I require the schema upfront, in order for the tool to generate models based on the schema. I can handcraft domains in SimpleDB and that does help but for that I have to perform at least one create operation on the domain. I am looking for the ability to create domain schema only. Any clues?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
SimpleDB 中没有模式。
这就是为什么 NoSQL 人们建议在将范式转移到这些非关系数据存储之前“忘掉”关系数据库的原因。
所以，你不能做你所描述的事情。没有数据，就什么都没有。
There is no schema in SimpleDB.
This is the reason why the NoSQL people suggest to "unlearn" relational databases before shifting the paradigm to these non-relational data stores.
So, you cannot do what you describe. Without the data, there will be nothing.
虽然 SimpleDB 确实没有模式支持，但如果您对数字数据或日期* 运行查询，则保留某些类型信息至关重要。大多数NoSQL产品都有查询和类型，或者无查询和无类型，但SimpleDB选择了查询和无类型。
因此，与主应用程序之外的任何工具集成将要求您执行以下任一操作：
选项 2 似乎更好并选择它，尽管有些人建议，并不意味着你“头脑不正确”。
S3 可能是此数据的一个不错的选择，您可以将其保存在与您的域同名的文件中，并且可以使用与您的 SimpleDB 帐户相同的 AWS 凭证从任何地方访问它。
将数据存储为 attributename=formatname 的列表是我需要做的范围。事实上，您可以将所有这些存储在您域中的一个项目中。唯一的问题是，这个特殊项目可能会无意中从您期望实时数据而不是类型信息的域查询中返回。
我不熟悉 MindScape LightSpeed，但这是我在使用 SimpleDB 时发现的一种通用策略，如果该产品能够在 S3 中加载/存储文件那就更好了。
*注意：需要明确的是，我并不是在谈论重新发明轮子或尝试使用 SimpleDB 作为关系数据库。我说的是数字数据必须用零填充（到您选择的长度）和偏移值（取决于它是有符号还是无符号）存储，以便与 SimpleDB 的基于字符串的查询语言一起使用。一旦您决定在应用程序中使用一种或一组格式，如果源代码工具、查询工具需要该信息，则将该信息隐藏在并分散在源文件中将是愚蠢的、报告工具或任何其他代码。
While it's true that SimpleDB has no schema support, keeping some type information turns out to be crucial if you run queries on on numeric data or dates*. Most NoSQL products have both queries and types, or else no-queries and no-types, but SimpleDB has chosen queries and no-types.
As a result, integrating with any tool outside of your main application will require you to either:
Option 2 seems much better and choosing it, despite what some suggest, does not mean that you "don't have your mind right."
S3 can be a good option for this data, you can keep it in a file with the same name as your domain and it will be accessible from anywhere with the same AWS credentials as your SimpleDB account.
Storing the data as a list of attributename=formatname is the extent of what I have needed to do. You can, in fact, store all this in an item in your domain. The only issue is that this special item could unintentionally come back from a domain query where you are expecting live data not type information.
I'm not familiar with MindScape LightSpeed, but this is a general strategy I have found beneficial when using SimpleDB, and if the product is able to load/store a file in S3 then all the better.
*Note: just to be clear, I'm not talking about reinventing the wheel or trying to use SimpleDB as a relational database. I'm talking about the fact that numeric data must be stored with both zero padding (to a length of your choosing) and an offset value (depending on if it is signed or unsigned) in order to work with SimpleDB's string-base query language. Once you decide on a format, or a set of formats to be used in your application, it would be folly to leave that information hidden in and scattered across your source files in the case where that information is needed by source code tools, query tools, reporting tools or any other code.