使用 XML 作为（只读）人类可读的调查问题数据源
科学或市场研究调查问卷主要由以下形式的问题组成：
简介：表明您对以下陈述的同意程度...
选项：非常 - 相当 - 所以- 所以 - 而不是 - 根本不是
ITEM 1：我喜欢可口可乐
...
ITEM n：...
让我们将整个事情称为SCALE。 一个量表由多个项目组成，有一个介绍，有一定数量的选项。 该数据库具有表“intro”、“option”、“items”和“scale”以及必要的外键。 通过适当的查询，我选择此信息并将其注入表单视图中，以显示我的调查问卷规模。
只要没有非技术第三方必须编辑这些音阶，就可以了。 最近我想到了一种替代方法。 我认为可以使用 XML 文件作为量表，其中包含所有前面提到的数据，包括翻译。
我知道 XML 是一种传输方式，而不是数据存储，我知道查询 XML 并不像对数据库使用 SQL 那样容易……但是第三方呢？ 我应该为他们开发一个后端，让他们可以编辑问题吗？ 您对此有何看法？ 您是否知道存储调查问题（量表）的第三种替代方法？
到目前为止总结：好的，看来编辑界面是更好的解决方案。 有人可以写一些关于 XML 的速度问题吗？
Scientific or market research questionnaires mainly consist of questions in the following form:
INTRO: Indicate how much you agree with the following statements...
OPTIONS: very much - rather - so-so - rather not - not at all
ITEM 1: I love Coca-Cola
...
ITEM n: ...
Let's call the whole thing a SCALE. One scale consists of several items, has an intro, has a certain number of options. The database has the tables 'intro', 'option', 'items' and 'scale' with the necessary foreign keys. With the appropriate queries I select this information and inject them into the form-view in order to display my questionnaire scale.
This is ok as long as there is no non-tech third party who has to edit these scales. Recently an alternative approach has come to my mind. I thought it might be possible to use XML files for the scales, containing all the beforementioned data including translations.
I know that XML is a means of transport and not data storage, I know that querying XML is not as easy as using SQL against a database... but what about the third party? Should I rather develop a backend for them, where they can edit the questions? What is your opinion on that? Do you maybe know an alternative third way of storing questions (scales) for surveys?
SUMMARY SO FAR: ok, it seems that the edit interface is the better solution. Could anyone maybe write something about the question of speed concerning XML...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
最好的方法是为非技术第三方构建简单的后端。
非技术用户在编辑 XML 文件时可能会遇到困难，在编辑文件后如何检查文件格式是否正确？ 您的软件必须检查输入并输出有意义的错误消息，这意味着无论如何您都将编写一个基本的后端。
The best way would be to build that simple back-end for non-technical third parties.
Non-technical users would probably have trouble editing an XML file, and how would you check that the file was properly formatted after they edit it? Your software would have to check the input and spit out meaningful error messages, which means you would be writing a rudimentary back-end anyway.
您已经看过 MS InfoPath 了吗？ 这正是他们正在做的事情，而且效果很好。
Did you already take a look at MS InfoPath? This is exactly what they are doing, and it works quite well.
就表示而言，XSLT（用于转换的 XML 样式表）可以将文档转换为“可表示的”界面。 但是，您仍然需要一种机制来捕获和存储结果。 但如果它是 XML 格式的，您可以在其前面放置几乎任何可以想象到的接口，即使不使用 XSL。
与关系数据库相比，XML 方法的优点之一是可以提供内置的可变性。 我已经构建了一些这样的系统，并且想出一个还可以处理调查结构和数据的可变性的健全的数据库结构是很困难的。
As far as presentation goes, XSLT (XML style sheets for transformation) can transform the document into a "presentable" interface. You'll still need a mechanism to capture and store the results, however. But if it's in XML you can put pretty much any imaginable interface in front of it, even without using XSL.
One advantage of an XML approach, over a relational database, is the built-in variability you can offer. I've built a few systems like this, and coming up with a sane database structure that can also handle the variability of survey structure and data is tough.
通过后端来完成此操作（这是正确的术语吗？）比每次发生更改时解析配置文件（本质上是您的 xml 文件）要更简单。
It would be simpler to do it via a backend (is that the right term?) than parsing a config file (essentially what your xml file is) everytime something changed.
如果您希望它采用 XML 格式，那么我建议您查看 Interactive Schema Interpreter (http:// sourceforge.net/projects/interactive/）。
If you want it to be in XML then I suggest you to have a look at Interactive Schema Interpreter (http://sourceforge.net/projects/interactive/).