我为每个项目(其中有~50个)有许多日历事件ID(0 location
),我使用calendar.getEventSeriesById(_event_id_).getLocation()
。
这应该是一个灵活的用户界面,我的老板可以用来查看任何特定项目的< = 9个不同事件的详细信息。但是,在使用此信息填充UI时,此单个调用显着会减慢执行时间(加载5个事件最多需要10秒,具体取决于服务器负载)。
由于UserProperties
是帐户限制的,并且所有我的脚本在同一个“boss”(经理)帐户下运行,UserProperties
会是 可靠的 解决方案,每学期存储200 + eventIDs
(4个月)?由于我的其他脚本都没有设置属性,并且日历事件ID是唯一的,因此我不需要担心冲突/覆盖。但是,这个系统依赖于重度这些键/值对,所以是否有任何关注UserProperties
通过某些自动化过程(不是我的脚本或我手动)或其他一些过程被清除腐败的形式?
是否有更多方法可以避免对此用例过度调用CalendarApp
?或者Spreadsheets
/ UserProperties
是唯一真正的选择吗? - >除了数据库,这也是过度的......
编辑:我确实将其作为测试实施,并且用户界面的加载时间平均提高了约500%,这非常棒。但是,是否存在与UserProperties
或ScriptProperties
相关的可靠性问题?
答案 0 :(得分:1)
不使用,他们不是为了那个。使用scriptDb。关于存储数据的气体帮助页面进一步解释了这一点请参阅气体帮助和此https://developers.google.com/live/shows/ahNzfmdvb2dsZS1kZXZlbG9wZXJzcg4LEgVFdmVudBjb7o4DDA
答案 1 :(得分:1)
如果您的问题严格关于可靠性,答案肯定是是的,您可以依靠它(除了几年前的一个错误我从未遇到任何失败但是,正如Zig在他的回答中提到的那样,ScriptDb是为做出的,并且受到更好的保护,因为没有人可以通过“正常”Ui访问它并意外破坏数据。
此外,如果您需要存储除字符串值之外的任何内容,它还可以处理简化过程的对象。