向移动设备传输数据最轻/最快的方式是什么？
我正在寻找可以将数据传递给用户的方法。这可能是从 XML 到平面文件数据库再到关系数据库。
该数据库将保存在服务器中，并将根据请求为手持设备、智能手机和平板电脑提供服务。我主要关心的是显示数百万行所请求信息的速度以及如何轻松更新数据。
在发布本文之前，我进行了一些 Google 搜索，将我引向了 SQLite。您对此有何看法？
I am looking for methods that let you deliver data to a user. This may be from XML to a flat-file DB to a relational DB.
This DB will be saved in a server and will serve handheld devices, smartphones and tablets on request. My main concern is the speed of displaying the requested info over millions of rows and how the data can be easily updated.
Before posting this, I made some Google searches pointing me to SQLite. What is your opinion about this ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可能最好设置 SOAP/XML-RPC 服务并在服务器上处理数据并将其一次发送到客户端，同时进行缓存。这可能是“最快”的方式，因为您不必将大文件传输到手持设备。它可能不适合你，但值得一提。
这本质上只是一个文件下载，由传输格式的输出和移动设备数据存储的输入组成。我想你正在描述类似字典的东西，相当静态的东西。
您想要实现的方法需要：
您可以将其作为 CSV 或 JSON 格式的文件，这非常简约；他们不会使用大量数据来描述数据。 XML 并不是最快的，因为它通常具有很强的描述性，但它还有其他优点。另一种选择是发送包含 SQL 插入语句的文本文件。
当然，另一个“选择”可能是使用更新机制并将其作为“更新”推出。我对此的想法是，许多使用移动设备的人都知道更新非常耗时并且下载量通常很大，因此他们在执行此操作时会连接到计算机。这只是一个想法；我不确定这是否真的会更好，但我想我会把它扔掉。
SQLite 是一种在许多移动平台上运行的 RDBMS。它有其局限性，但它可能是您必须处理的全部内容。这是一个不错的选择。
You would probably be better off setting up a SOAP/XML-RPC service and working the data on the server and sending it to the client pieces at a time, caching as you go. This is going to be potentially the "fastest" way, since you don't have to transmit a large file to a handheld. It may not work for you, but it's worth mentioning.
This is essentially just a file download bracketed by an output to a transport format and an input to the mobile device's datastore. I imagine you're describing something like a dictionary, something that is fairly static.
The approach you're going to want to achieve will need to:
You could serve it as a CSV or JSON-formatted file, which are very minimalistic; they don't use a lot of data to describe the data. XML is not the fastest because it is generally very descriptive, but has other advantages. Another option may be send a text file with the SQL insert statements.
Another "option", of course, may be to use the update mechanism and push it out as an "update". My thought on this is that many people with mobile devices know updates are time consuming and are often very large downloads, so they connect to their computer when doing so. This is just a thought; I'm not sure if this would actually be any better, but thought I'd throw it out there.
SQLite is an RDBMS that runs on many mobile platforms. It has it's limitations, but it may be all you have to work with. It's a good option.
如果您希望移动设备对数据执行操作（例如离线处理），我认为 sql lite 是最佳选择。
如果处理无论如何都会在线进行，并且移动设备最适合显示并且处于“始终”在线的环境中，那么用于请求和处理数据的 Web 服务以及后端 sql 服务器将是最佳选择
泪流满面的表演是这样的：
大量数据 = 大量在线流量，因此，如果确实有大量数据，如您所说的数百万行，那么我认为离线是正确的选择，否则流量只会破坏性能
if you want the mobile devices to preform actions on the data(like offline processing) I think sql lite is the way to go.
if the processing gonna happen online anyway and the mobile device would be most for displaying and will be in an environment where you are "always" online then Web services for requesting and processing the data and then a backend sql server would be the way to go
In tearms of preformance it is like this:
alot of data = alot of online traffic so if really alot of data like you said milions of rows then I think offline is the way to go otherwise the traffic would just kill the preformance
如果您正在处理数百万行，并且希望在移动设备上一次显示小样本（其他方法几乎不可能），那么您绝对应该在服务器端进行处理，最好使用 RDBMS。这些是为了处理数百万行而设计的。 Sqlite 快速且简单，但在数百万行范围内，您最好使用 PostgreSQL 或商业品牌之一（Oracle、MS SQL Server，..）。
您可以使用 Web 服务或直接访问数据库，具体取决于情况。您可以在本地进行一些处理，但行的选择必须在服务器上进行。
If you are dealing with millions of rows and you want to display small samples at a time (anything else is hardly possible) on mobile devices, you should definitely do the processing at the server side, best using an RDBMS. Those are made for handling millions of rows. Sqlite is fast and simple, but in the millions-of-rows-range you'd better reach for PostgreSQL or one of the commercial brands (Oracle, MS SQL server, ..).
You can use a web service or direct access to the database, that depends. You can do some processing locally, but the selection of rows has to happen at the server.