HTML5 应用数据库同步

Question

我目前正在从事一个项目，该项目涉及将数据存储在 HTML5 SQL-Lite 数据库中。目前，我的架构如下（4 个表）：

TransData:
-----------------------------------------------------------
|   TID   | UserName | TransColor | ... |  Date  |  Note  |
-----------------------------------------------------------
|    6    | Brendan  |      Red   | ... |        |        |
-----------------------------------------------------------
|    7    | Brendan  |      Red   | ... |        |     1  |
-----------------------------------------------------------

FullData:
-----------------------------------------------------------
|   TID   | UserName | TransColor | ... |  Date  |  Note  |
-----------------------------------------------------------
|    1    | Brendan  |      Red   | ... |        |  Start |
-----------------------------------------------------------
|    ...  | Brendan  |      Red   | ... |        |        |
-----------------------------------------------------------
|   40    | Brendan  |      Red   | ... |        |  End   |
-----------------------------------------------------------

SalamanderData:
----------------------------------------------------
|   SID   | SalamanderName | Length | ... |  TID   |
----------------------------------------------------
|    1    | Northern-Slimy |   16   | ... |    6   |
----------------------------------------------------
|    2    |   Two-Lined    |   26   | ... |    6   |
----------------------------------------------------  
|    3    |   Two-Lined    |   12   | ... |    7   |
----------------------------------------------------  

SalamanderData:
----------------------------------------------------
|   SID   | SalamanderName | Length | ... |  TID   |
----------------------------------------------------
|    1    | Northern-Slimy |   16   | ... |    6   |       
----------------------------------------------------
|    2    |   Two-Lined    |   26   | ... |    6   |   
---------------------------------------------------- 
|    3    |   Two-Lined    |   12   | ... |    7   |
----------------------------------------------------

注意：TransData 中的“Note”列用于指向 FullData 字段中集合的开始数据点。

我的应用程序和服务器之间的数据库不应该同步。我只是想将所有这些表转储到服务器上的数据库中（我的意思是转储，更新对其他表的引用，然后插入到服务器数据库中）。

我打算使用MAX(TID-Server) + TID-App = new TID-Server，并将更新级联到表格中。

你会怎么做呢？

Answer 1

根据Dan Pichelman 的评论，问题在于客户端将记录插入本地数据库，为此，必须确定它们的主键。但是，鉴于所有不同的客户端都在做同样的事情，新的 PK 会在它们到达服务器时发生冲突。

这是一个常见问题，即物理上断开连接的系统（至少有时如此）或不能存在单点故障的系统，例如共享序列生成器。

一些常见的解决方案是：

GUID

这里的 PK 是一个 128 位（或更大）的随机数。任何两个 PK 相同的可能性非常小。但为了进一步减少冲突的变化，GUID 算法包括使用唯一机器标识符（网络 MAC）和时间播种。在同一台机器上生成的两个 GUID 永远不会发生冲突，在具有不同 MAC 的机器上生成的 GUID 也不会发生冲突。大多数机器和语言都有生成 GUID 的本机函数，但 JavaScript 没有。见：

• Create GUID / UUID in JavaScript?
• Collisions when generating UUIDs in JavaScript?

分区命名方案

在这个方案中，PK 又是一个很大的数字（实际上是位域），并且你将它划分为分层的方式。一个很好的例子是国际电话系统（至少在便携式号码之前）。这里电话号码分为：

• 国家代码：例如美国 - 1
• 区号：例如 Sunnyvale - 615
• 订阅者编号，由交易所控制。

在您的情况下，您可以按以下方式划分数字：

• 用户登录（例如每个用户唯一的号码）
• 会话 ID（例如，每个用户每次登录的唯一编号，以区分同一用户在不同浏览器/计算机上的不同会话）
• 序列号

将这三者结合起来，您将有一个保证唯一的 PK。

PK“许可证”服务器

前两个建议的优点是它们完全脱节。如果您有一个连接的客户端，您可以拥有一个 Web 服务，在客户端请求它们时提供 PK。

为了提高效率，它可能会返回一批，比如 100 个数字。这甚至可能在用户登录时返回。

客户可以全部使用它们并要求更多。可能存在客户端忘记状态并在全局 PK 序列中留下“漏洞”的情况。这几乎肯定不是问题。

一些注意事项

有时您可能会喜欢顺序 PK 用于表排序目的。在这种情况下，您需要按客户订购还是按创建时间订购？如果其中任何一个很重要，您可能会对分区命名方案给予更高的评价。根据需要将客户端或时间作为 first 分区。或者，向您的表格添加更多列。

如果您不想要分区命名方案的固定结构，GUID 会很好用。

如果您想要集中协调，请使用 PK 许可证服务器。

Answer 2

我不知道有一种美观的方式来做到这一点，但我通过编写存储过程“解决”了它：

第一个表很容易 - 根据需要更新或插入。如果进行插入，则获取新插入记录的主键，然后相应地处理依赖表（这通常意味着使用新的主键插入数据）。在您处理关系时根据需要重复。 4张桌子应该没问题，但我不想做40张。

在我的情况下，它很混乱，并且涉及到包含 oldPK 和 newPK 的临时查找表。

这也是一段相当冗长乏味的代码，其唯一可取之处就是它可以工作。

Answer 3

这有点违背你的要求，所以如果这完全不符合要求，请发表评论，我会删除它。但是您没有说明服务器/客户端无法在主键方面同步的任何特定原因（我认为这确实是这里的问题）。

我还假设（根据您的数据和您的问题）我们正在谈论一个带有用户创建内容（如日志）的 web 应用程序，该内容偶尔会上传到服务器。

那么就运动而言，您是否考虑过使用由多个字段构建的主键？这样您就可以在本地数据库中进行自动增量，将数据转储到服务器，并且不会与其他用户数据发生冲突。 SalamanderData 表的示例如下：

CREATE TABLE SalamanderData
(
    SID int NOT NULL,
    SalamanderName varchar(255),
    Length int,
    ... ...,
    TID int NOT NULL,
    CONSTRAINT pk_SDataEntry PRIMARY KEY (SID,TID)
)

然后会根据 SID 和 TID 创建一个 PK。

通读我的帖子并检查其他答案，我意识到这是安德鲁的建议，所以即使这对你有帮助，你也应该真正接受他的回答

保留答案是为了可能澄清解决方案并给出代码示例