数据理论、json 和客户端应用
所以，我编写网络应用程序已经有一段时间了......通常我已经完成了数据结构和检索以及客户端编码。我现在有一个数据管理队友和我一起工作，他唯一的工作就是将数据从数据库返回到提供 json 服务的 api；标准的东西。
最近，我和他在这个数据应该如何返回的问题上一直存在分歧。本质上，我们有两个 json 对象，第一个在应用程序启动时远程加载一次（其中包括赛车手名称、赛车手编号等）。其次，（在比赛期间，这是一个重复的定时数据调用）我们逐渐接收位置，其中包含赛车手的纬度/经度、速度等。
我们的不同之处在于，他指出返回赛车手姓名是“低效的”（ telem 字符串（第二次调用）中的第一次调用）。这迫使我做的是将第一个数据 obj 保留在全局 obj 中，然后使用连接查找函数“即时”从第二个数据 obj 中获取赛车手的纬度/经度、速度，然后返回一个新的我使用 jqGrid 填充到赛车网格的 json obj （看起来像这样： getRaceDataByID(json[0].id){//通过 json[1] 中的赛车 id 查找比赛数据，其中json[1].id == json[0].id[lat/lon, spd] 并返回新的 json obj 行以填充 jqgrid}))。
结果似乎是一个过度编码/缓慢的客户端（jquery）应用程序。
我的问题是关于理论的。当然，我了解传统的数据结构、规范化、sql 等...但在当今的“webapps”世界中，以及大型 Web 服务似乎正在远离“传统 sql”数据结构，而只是将数据作为返回值的想法客户需求。从这个意义上说，这意味着在每个位置 telem 调用的 sql 调用中添加大约 3 个字段（名称、号码布号、车辆类型等...），以便我可以根据接口的要求（数据显示实时速度、纬度/经度等的表格...）。
最后，我的问题是：有没有人必须处理这样的情况，我是否认为每行 3 个字段，在当今依赖大量数据的 Web 应用程序世界中，这不是一个大问题？吵架了。
请注意：我理解，传统上，您不会希望发送超出您需要的数据，并且他对数据结构和低效数据传输（不发送超出您需要的数据）的理解实际上是正确的。
但是，很多时候，当我编写网络应用程序时，浏览器的无状态性质通常会以不同的方式看待，恕我直言，发送所需的数据要容易得多。我的问题并不是不想编写解决方案，而是试图通过不必将 json obj 重新缝合到我首先需要的东西中来减少客户端的负载。
So, I've been coding web apps for some time now... typically I've done both the data structs and retrieval and the client side coding. I now have a data admin teammate working with me and his sole job is to return data from a database to an api that serves json; standard stuff.
Recently, I have been having a disagreement with him on how this data should be returned. Essentially, we have two json objs, the first loaded remotely once (which includes racer name, racer number, etc...) when the application starts. Secondly, (during the race which is a recurring timed data call) we receive positions incrementally which contains a racer's lat/lon, spd etc.
Where we differ is that he is stating that it is "inefficient" to return the racer name (the first call) in the telem string (the second call). What this forces me to do is to keep the first data obj in a global obj, and then essentially get the racer's lat/long, spd from the second data obj "on the fly" using a join lookup function, which then returns a new json obj that I populate to a racer grid using jqGrid (looks something like this: getRaceDataByID(json[0].id){//lookup race data by racer id in json[1] where json[1].id == json[0].id[lat/lon, spd] and return new json obj row to populate jqgrid})).
The result seems to be to be an overly-coded/slow client (jquery) application.
My question is about theory. Of course I understand traditional data structs, normalization, sql etc... But in today world of "webapps" and the idea that it seems that larger web services are going away from "traditional sql" data structures and just returning the data as the client needs. In this sense, it would mean adding about 3 fields (name, bib number, vehicle type, etc...) to the sql call on each position telem call so I can display the data on the client per the interface's requirement (a data table that display real-time speed, lat/lon, etc...).
So finally, my question: has anyone had to deal with a situation like this and am I "all wet" in thinking that 3 fields per row, in today's world of massive data dependent web applications, that this is not a huge issue to be squabling over.
Please note: I understand that traditionally, you would not want to send more data than you need and that his understanding of data structs and inefficient data transfers (not sending more data than you need) is actually correct.
But, many times when I'm coding a web apps, it's often looked at a bit differently b/c of the stateless nature of the browser, and IMHO and it's much easier to just send the data that is needed. My question, is not being driven by not wanting to code the solution, but rather trying to put less load on the client by not having to re-stitch the json obj into something that I needed in the first place.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为将这 3 个字段与其余数据一起发送是有意义的，即使这需要某种重复。您将获得以下优势：
就速度而言，您正在远程调用中完成大部分工作，恕我直言，添加另外 3 个字段并不重要。它使您的应用程序更干净。
所以我想我同意你的观点。
I think it makes sense to send these 3 fields with the rest of the data, even if this warrants some sort of duplication. You get the following advantages:
As far as speed goes, you are doing the majority of the work in your remote call, adding another 3 fields doesn't matter IMHO. It makes your app cleaner.
So I guess I agree w/you.