我应该如何用 JSON 表示表格数据?
我正在编写一个 API,用于通过 JSON 从 JDBC 连接的 Java Servlet 检索数据。我选择使用 JSON 是因为我们想要对浏览器中的数据进行排序和其他操作,并且我们将跨域访问数据。
由于我本质上是在 JavaScript 中执行 SQL 查询,因此返回的数据本质上是表格形式的。我开始写这个是为了让你得到一个列标签列表,然后是值数组,例如:
{
"columns": [
"given_name",
"surname",
],
"results": [
[
"Joe",
"Schmoe"
],
[
"Jane",
"Doe"
]
]
}
但是当我开始编写 JavaScript 来处理返回的数据时,我想知道直接输出是否会更好具有键/值对的结果,例如:
{
"results": [
{
"given_name": "Joe",
"surname": "Schmoe"
},
{
"given_name": "Jane",
"surname" : "Doe"
}
]
}
如果您返回大量结果,则表示有大量重复文本。但我们将传输压缩文件,所以我不太关心带宽。
基本上,我应该对此进行设计,以便我可以使用
$.getJSON(query, function(data) {
var columns = data.columns;
var results = data.results;
$.each(results, function(key, row) {
console.log(row[columns.indexOf('surname')]);
});
});
或更漂亮的
$.getJSON(query, function(data) {
var results = data.results;
$.each(results, function(key, row) {
console.log(row.surname);
});
});
方式访问我的数据吗?
本质上,我想知道对性能的潜在影响是否证明后一个选项的更简洁的语法是合理的。
后续
我确实以两种方式和配置文件实现了它。 分析是个好主意!性能差异很小。数据传输大小的差异很大,但通过 Gzip 压缩,两种格式和非常大和非常小的数据集之间的差异降至 5-6%。所以我将采用更漂亮的实现。对于这个特定的应用程序,我可以期望所有客户端都支持 Gzip/Deflate,因此大小并不重要,并且客户端和服务器上的计算复杂性足够相似,因此并不重要。
对于任何感兴趣的人,这里是我的数据和图表!
I'm writing an API for retrieving data from a JDBC-connected Java Servlet via JSON. I've chosen to use JSON because we'll want to do sorts and other operations on the data in the browser, and we'll be accessing the data from across domains.
Since I'm essentially doing SQL queries in JavaScript, the data that comes back is tabular in nature. I started to write this so that you get back a list of column labels, then arrays of values, for example:
{
"columns": [
"given_name",
"surname",
],
"results": [
[
"Joe",
"Schmoe"
],
[
"Jane",
"Doe"
]
]
}
But as I start to write the JavaScript to deal with the returned data, I wonder if it might be better to just output the results with key/value pairs, such as:
{
"results": [
{
"given_name": "Joe",
"surname": "Schmoe"
},
{
"given_name": "Jane",
"surname" : "Doe"
}
]
}
If you're returning a lot of results, that's a lot of repeated text. But we're going to be transporting gzipped, so I'm not too concerned about bandwidth.
Basically, should I engineer this so that I'm accessing my data with
$.getJSON(query, function(data) {
var columns = data.columns;
var results = data.results;
$.each(results, function(key, row) {
console.log(row[columns.indexOf('surname')]);
});
});
or the much prettier
$.getJSON(query, function(data) {
var results = data.results;
$.each(results, function(key, row) {
console.log(row.surname);
});
});
?
Essentially, I want to know if the potential hit to performance justifies the much cleaner syntax of the latter option.
Follow up
I did implement it both ways and profile. Profiling was a great idea! The differences in performance were marginal. The differences in data transfer size were substantial, but with Gzip compression, the variance was down to 5-6% between both formats and between very large and very small data sets. So I'm going with the prettier implementation. For this particular application, I can expect all clients to support Gzip/Deflate, so the size doesn't matter, and the computational complexity on both the client and server is similar enough that it doesn't matter.
For anyone interested, here is my data with graphs!.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
您始终可以将第一个选项转换为其 JSON 表示形式
You can always convert your first option to its JSON representation
综合其他答案:
此外:
Synthesizing other answers:
Further:
只是另一个 JSON 结构,我从中得到了非常好的结果:
遍历所有数据:
Just another JSON structure from which I got very nice results:
Traversing all data:
FWIW 我会选择第二个选项,正如您所观察到的,它适合更干净的 JavaScript,并且也更容易让人阅读和理解。在我看来,可读性胜过从选项 1 中获得的任何一点性能提升。
我还想象,如果您要添加更多列或有一天更改列的顺序,则使用第一个选项,您可能必须重写大量 JavaScript,因为您将处理响应中数据的位置。FWIW I'd go for the second option, it lends itself to cleaner JavaScript as you've observed and will also be easier for a human to read and understand. It seems to me that readability trumps whatever little performance gain you get from option 1.
I also imagine if you were to add more columns or the order of columns changed someday, with the first option, you'll likely have to rewrite a lot of the JavaScript since you'll be working with the position of the data in the response.您不必将代码与更紧凑但也更麻烦的格式联系起来。只需编写一个简单的 JS 适配器来检查返回的结构是否存在
列
。如果缺少它,那么您正在处理一个普通的对象数组。如果它存在,您可以轻松地将繁琐的格式映射到更方便的格式。You don't have to tie your code to the more compact, but also more cumbersome format. Just write a simple JS adapter to check the returned structure for the presence of
columns
. If that's missing you're dealing with a plain array of objects. If it's present you can easily map the cumbersome format to the more convenient format.简介两者。之后优化。
Profile both. Optimize afterwards.