问题标签 [design-documents]

有人可以解释一下架构设计与高级设计之间的区别吗？

如果您通过示例进行解释，将对我有所帮助：假设我想构建简单的android在线购物应用程序，那么我应该在我的架构设计和高级设计中添加什么？

我有以下高级要求：

由于 Ruby 是一种具有纯动态类型的语言，所以我永远不太确定我应该对传递给我的方法的类型有什么级别的期望。例如，如果我的方法仅在传递整数时起作用，我应该积极检查以确保是这种情况，还是应该在这种情况下只允许类型异常？

此外，在围绕 Ruby 代码编写设计文档时，指定方法应该操作的类型的正确方法是什么？Javadocs（尽管通常不用于设计文档）例如准确指定方法将操作的类型，因为语言本身是静态类型的，但似乎 Ruby 文档对方法的前置条件和后置条件始终非常不精确. 是否有在 Ruby 中指定这种格式的标准做法？

我正在为 Web 应用程序的模块编写设计文档，在研究设计文档时，我遇到了名称为软件设计文档 (SDD)/软件设计描述 (SDD)、系统设计文档 ( SDD)和技术设计文档 (TDD)。这些文件有什么区别？

就我而言，我需要设计整个模块及其功能，并为其编写设计文档，以便稍后由部门用于其他设计。我正在遵循软件设计文档/软件设计描述 - 部分原因是它位于 IEEE 软件生命周期中，并且可能是其他软件团队在软件设计中使用的基础。谁能解释一下设计文件并建议我的工作最好遵循哪一个？

在某种情况下，我想将一个字段值（以字符串格式）传递给 CouchDB 并获取关联的文档（或仅其 id），该文档在其字段中包含该特定字符串值。如果没有文档包含该特定字段值，我希望 CouchDB 设计函数自动创建一个并返回新创建的文档。

如果没有具有该特定字段值的文档，我可以通过发出 GET 请求，然后发出 PUT 请求来完成此操作。有没有办法只用一个 POST 请求来完成这项工作？

我想检索除设计文档之外的所有文档，但 _all_docs 返回数据库中的所有文档。从答案中，我发现使用两个查询会给出结果。

1. _all_docs?endkey="_" - 列出文档直到第一个设计文档
2. _all_docs?startkey="design_\uffff" - 在设计文档之后列出文档

如果设计文档之后的文档具有_id“``test”，则这不起作用。它给出了 _id 以小写字母开头的文档。_的ASCII是95，反引号是96。小写字母以97开头。那么上面的查询可以修改为：_all_docs?startkey="`"

我一直在同时学习 CouchDB 和 PouchDB，也许这就是为什么我无法理解 PouchDB 处理CouchDB Views的方式。

我已经在 CouchDB 中成功创建了一个视图，并且通过 HTTP（CouchDB 方式）查询它是成功的。

我遇到的问题是如何使用PouchDB查询视图，PouchDB是 CouchDB 或类似 CouchDB 数据库的前端抽象和兼职（？）缓存库。

根据这篇博文， PouchDB 在 2.2.0 版本中引入了一种叫做“持久映射/减少”的东西。但是由于我已经习惯了在 CouchDB 中使用 Views，我对 PouchDB 试图解决的问题感到困惑。

PouchDB 中的持久化 map/reduce 仅仅是从前端舒适地将视图持久化到 CouchDB 的一种方式吗？如果是这样，为什么没有明显的方法来利用已经写在后面的视图？而且，为什么 PouchDB 从一开始就无法做到这一点 - 我理解 Views 是 CouchDB 索引能力的支柱。

假设我决定有一个我知道我会经常使用的视图（或 SQL 领域的索引）。我真的应该使用 PouchDB 通过前端创建它吗？这是否意味着我会遇到关于何时创建视图以及是否应该覆盖它们的问题？PocuhDB 是在幕后简单地使用 CouchDB 视图，还是他们在前端创建自己的 map/reduce 查询，从而在重新索引事物时失去后端更新视图的效率。

从本质上讲，我想我的问题是：PouchDB 是以效率为代价重新发明轮子，还是仅仅拥有 CouchDB 的索引功能？还是其他什么都在一起？

我有一个运行 peruser 数据库配置的 CouchDb 实例。

生成的每个用户数据库（当将用户添加到_users数据库时）需要具有相同的设计文档以及视图/列表逻辑等。

在创建数据库时将设计文档添加到数据库的实际方法是什么？是否只是在成功的用户创建请求后添加它们？或者在 CouchDb 中是否有更优雅的方式来执行此操作？

我正在为一个项目使用 CouchDB 和 PouchDB，在该项目中，用户拥有自己的数据库，并且可以相互添加以查看或编辑他们的文档。

目标是具有不同级别的可访问性：根据文档本身，非 docs.owner 的其他用户将具有有限的写入/更新权限。数据库所有者/管理员授予这些权限。

我不确定如何正确实施。

目前我的解决方案是让数据库所有者“成为”其他用户，并将他们作为成员添加到 db/_security，同时使用 _design 文档限制写作权限，如下所述：https ://github.com/pouchdb -community/pouchdb-authentication/blob/master/docs/recipes.md

但我需要用户特定权限和数据库特定权限的混合。所以我的策略是让用户/所有者除了默认的“members”和“admins”之外添加特殊角色到 db/_security。

例子：

用户paula拥有数据库paulas_DB并希望授予用户 jan 更改每个文档的属性“位置”的权利。因此，Paula 将jan添加到_security 中的members.names中，并在 _security 中添加了一个名为“movers”的新列表：

paulas_DB中的文档结构如下：

现在在她的数据库中有一个设计文档，检查任何想要更改文档的人至少是一个成员，然后检查他们是否想像这样更改位置：

这种方法似乎有效并且相当简单，但是将非标准属性添加到 _security 中感觉有些不对劲。

是否有另一种适当的方法来做同样的事情？或者对于文档/用户特定的权限系统来说，这是一个可接受的设计吗？

我正在尝试创建一个等效于传统 RDBM 中使用的创建/更新触发器。create_ts 的创建很好，但是 update_ts 部分对我不起作用。

文件创建好了：

{"error":"conflict","re​​ason":"文档更新冲突。"}

我觉得我在理解 couchdb 文档更新时遗漏了一些基本的东西。

我正在尝试索引圣经经文，在设计文档中创建视图。这个想法是创建允许字典顺序搜索、连接书本、章节和诗句编号的键。为此，我需要在章节和诗句编号上填充零。

我尝试使用 .padStart(2,'0') 函数，但创建的视图是空的。

一个 verse 文档可能如下所示： {"_id":"007e0b09","_rev":"1-58c889c","ch":"05","vn":"16","verse":"bla bla废话"}

在 couchdb 设计文档环境中是否有更好的替代功能？我在设计索引键时出错了吗？在这种情况下，我还应该怎么做？设计可以吗，但我应该以某种方式重写或导入 padStart 吗？如何？谢谢阅读。