1

这不是编程问题，我想是逻辑问题或数据库设计问题。

要回答这个问题，您需要了解一些有关银行交易的知识。

基本上，对于您进行的每笔交易（销售、退款、强制销售），如果主机批准该交易，主机就会向您发送一个 RRN（参考检索号），这是一个用于识别该交易的号码。

问题是我不知道主机如何管理这个号码，我的意思是我想这种方法：

RRN 是通过以下方式生成的：

  • 交易类型
  • RRN
  • 会员资格（取决于货币）
  • 批号或批号

这四个实体可以在数据库中创建一个 UNIQUE KEY，问题是我如何知道何时必须重置 RRN 值。

我不能限制数据库中的唯一键，因为如果你今天进行交易，我不知道主机是否在不知道的情况下重置了 RRN 值，我可能会在第二天重复 RRN 的数量，我会抛出一个发送违反唯一密钥的错误，但这不是预期的行为，理论上我不必控制 RRN 号码，因为这是主机的工作，但是，我如何在如果我想取消或回滚该事务，请 DB。

如果我想查询一个唯一的交易，我不能有多行。

我唯一想到的是在不进行 UNIQUE 限制的情况下识别这四个实体的事务，但是如果我查询该事务并且我有多个结果，则会抛出一个错误，指出数据已损坏。

4

2 回答 2

1

如果 RRN 不仅在 DB 端生成，还不足以检测交易记录。这将是大量交易的问题。RRN 可以在终端端生成，在这种情况下，您的数据库根本不受记录重复的保护。

为了检测必要的交易，通常使用几个附加参数：终端 ID (TID)、商家 ID (MID)、至少交易时间戳等。

POS 集成商可以为后面的许多终端使用相同的 TID 和 MID，并且可能还可以复制 RRN。

正如已经建议的那样，更好地使用内部数据库的唯一 ID 并根据 KEY 为多个字段记录所有内容而不受限制。有必要进行投诉研究。

从 DB 中选择交易（用于完成、逆转或链式充值）和重复检测程序（用于传入交易记录）应该可以使用来自交易记录的附加值来实现。

于 2016-07-21T08:23:42.870 回答
0

RRN 通常只是一个主机端计数器，例如“限制”为 (iirc) 11 位的数据库 ID。RRN 通常是非常永恒的（至少 6 个月以确保退款匹配）

您似乎在谈论的可能是 systan - 用于请求/响应匹配的值，它通常在 24 小时内是唯一的，并且通常仅限于 TID 和传输时间字段。

请参阅此处基于 Ruby 的方法来构建可以驱动 RRN 和 systans 的通用计数器

续集（Ruby），如何以安全的方式递增和使用数据库计数器？

解决方案可能是保留主机 RRN 作为发送到主机的事务的安全参考，但为您的客户端维护自己的 RRN 并将两者都存储在数据库中（例如：pos 来，通过 pos rrn 查找事务，获取收单方rrn 来自交易，发送无效）

于 2016-08-06T06:04:34.533 回答