我目前正致力于提供时间卡提交的移动应用程序,该应用程序适用于现有的会计应用程序。毋庸置疑,此应用程序在很大程度上依赖于关系数据库,并且特定的依赖性转换为移动应用程序。
在当前状态下,移动应用程序使用WebSQL离线访问在用户可以访问Internet时加载到设备上的表。时间卡在本地数据库上创建,然后在用户重新访问Internet时上载。此功能是应用程序的核心。
我的问题是转向IndexedDB是否是A.)可行和B.)聪明的举动。如果WebSQL避免弃用,这不会是一个问题。我开始更好地理解IndexedDB以及JSON如何使它对相对复杂的数据存储有用,但我无法真正理解它是否能够实际复制关系数据库的功能。
根据应用程序的要求,看起来IndexedDB不是一个替代方案,但我对这个概念仍然是新手,并且对开悟开放。
那么IndexedDB可能是另一种选择吗?可以使用IndexedDB来复制具有多个具有大量数据的相关表的数据库的功能。如果是这样,我在哪里可以找到有关如何操作的信息。如果没有,我可以替代这两个吗? (假设WebSQL确实失去了支持而且IndexedDB不可行)。
在相关的说明中,IndexedDB会加快本地数据库的数量吗? PHP目前用于在用户在线时填充数据库,并且确实需要花费相当多的时间来填充具有大约一百个选项的表。当它接近一千时,应用程序刚刚崩溃(这是一种不常见的情况,并且强烈建议客户不要使用那么多数据)。
对此有任何帮助都很棒,我对编程很新,对Web开发也很陌生。
根据http://www.caniuse.com/indexeddb的说法,对indexedDB的支持相当有限,所以我暂时不会跳到它。但是,当实施成熟时,未来很可能会发生变化。
就个人而言,IndexedDB看起来很奇怪和复杂,特别是当你超越简单的单表操作时。我没有对它进行任何实际测试,但由于你必须手动完成一些事情(比如连接记录),你最终会得到更多的JS代码,这会转换为更多隐藏bug的区域。
那么IndexedDB可能是另一种选择吗?可以使用IndexedDB来复制具有多个具有大量数据的相关表的数据库的功能。如果是这样,我在哪里可以找到有关如何操作的信息。如果没有,我可以替代这两个吗? (假设WebSQL确实失去了支持而且IndexedDB不可行)。
快速搜索会显示http://blog.oharagroup.net/post/16394604653/a-performance-comparison-websql-vs-indexeddb,它显示了IndexedDB多表使用的一些模式。它还显示了一些性能比较,看起来很有希望用于IndexedDB。但是,请参阅this answer并将此基准与一粒盐。
在相关的说明中,IndexedDB会加快本地数据库的数量吗? PHP目前用于在用户在线时填充数据库,并且确实需要花费相当多的时间来填充具有大约一百个选项的表。当它接近一千时,应用程序刚刚崩溃(这是一种不常见的情况,并且强烈建议客户不要使用那么多数据)。
我是一个针对不同行业的类似应用程序的开发人员,我的经验是完全不同的:即使在较旧的iPhone 3GS上,WebSQL解决方案运行得很充分 - 我们已经测试了每个表有几千条记录的模式,没有明显的减速。您是否可以在单独的交易中插入每一行?
我们的大多数客户都对该应用感到满意,因为它可以在iPad,iPhone,Android平板电脑和谷歌浏览器上运行。但是一个客户端的安全要求只允许使用Windows和IE,没有其他浏览器或非Windows移动设备。这是我们看到WebSQL没有削减它的唯一场景。我们研究了IndexedDB和本机应用程序,到目前为止,我们认为原生应用程序是更好的选择(C#基础库可以在Xamarin和Windows Phone应用程序之间共享,更不用说C#比松散类型的JS回调更令人愉快。地狱)。
我已经迟了几年了,但我想我会接受并回答OP的问题(因为他的利益(可能)和任何发现自己有同样问题的人的利益),这些问题尚未得到直接回答,以及提供一些建议!
我有两个替代方案吗? (假设WebSQL确实失去了支持而且IndexedDB不可行)。
IndexedDB是此时唯一保留在W3C标准轨道上的数据库,因此,就本机客户端数据库而言,它几乎是唯一的选择。
那么IndexedDB可能是另一种选择吗?可以使用IndexedDB来复制具有多个具有大量数据的相关表的数据库的功能。
好...
IndexedDB是一个非关系文档存储。
另一方面,关系数据库支持表条目之间关系的定义和维护。这些数据库中的大多数也是行存储,它们(正如您可能知道的)是包含在表中的元组的存储库,这些元组定义了它们各自的结构。
因此,要回答您的问题,是的,您可以在IndexedDB中复制关系数据库为您提供的功能。如果商店中的任何数据项以任何方式彼此相关,则在某种程度上您将不得不这样做。
但是考虑到客户端数据库只是数据的暂时中断,最好只复制最低限度以保持数据的完整性,并且只利用其余的这些功能。一旦数据传输,它就存在于服务器端的关系数据库中。
如果转换的想法似乎仍然可口,那就去吧!
但在此之前,您应该了解有关IndexedDB的一些事项。鉴于数据库的类型,第一个应该是明显的:它本身不支持SQL。第二个是它的API ......至少可以说是笨拙的。
鉴于这些事情,我建议你看看BakedGoods。有了它,例如,将一个或多个数据项放在IndexedDB数据库中就像这样简单:
bakedGoods.set({
data: [{key: "key1", value: "value1"}, {key: "key2", value: "value2"}],
storageTypes: ["indexedDB"],
function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});
由于某些关系数据库功能的复制可能需要复杂的CRUD操作,因此您可能希望利用BakedGood对user-defined storage operation functions的支持。
只是为了完全透明,BakedGoods由这个人维持在这里:)。
通常,使用SQL的开发人员由于其复杂的api而难以使用indexeddb。
解决方案是使用任何indexeddb库,这使得indexeddb非常容易,但是为了使用库,我需要知道indexeddb的几个概念。
JsStore是一个indexeddb库,它删除了indexeddb的复杂性,并使indexeddb的使用变得非常容易。它提供像api这样的Sql,使其易于学习。
让我们说 - 你有SQL查询:select * from table_name where id=1 and name='abc'
在JsStore中 - 查询将是:
var con = new JsStore.Instance(db_name);
con.select({
From:table_name,
Where: {
Id: 1,
Name:'abc'
}
}).then(function(result){
console.log(result)
})