mysql - 关系数据库中的数据粒度

Question

我正在制作一个 rest-api 接收指令列表，服务器上的特定线程应该在 24 小时内执行，称之为每日计划。在一个时间间隔内执行相同的指令:

[
    {
        instructionName: string
        args : [    
            string
            ...         
        ]
        startHh : int
        startMm : int
        endHh : int
        endMm : int
    }   
    ...   
]

args的内容因instructionName而异。

时间表应该保存在 MySql 中。每隔 x 秒，线程应该向数据库询问当前指令并做一些工作。

我的问题是我不确定在数据库中存储指令列表的最佳选择是什么。在我看来，我有两个选择:

使用第一种方法，我所要做的就是将 args 连接到一个字符串，然后直接将 json 解析为 DTO 对象并持久化它，我必须注意不要存储 instructionNames和工作线程稍后无法解释的参数。工作线程可以方便地查询指令表，得到当前指令的时间间隔。

在第二种方法中，我必须首先使用 instructionName 找出表，查看参数是否对该表有效，然后将其插入。工作线程无法以简单的方式获取当前指令，因为指令被分隔在不同的表中。当工作线程确定要查询哪个表时，线程可以确保参数的格式正确，因为它们被拆分成单独的列。

在我的应用程序中将有许多类型的指令，并且在应用程序的生命周期内将不断添加新的指令类型。

这两种方法似乎都有很大的问题，我无法找出适合我的特定用例的最佳方法。我想知道我是否应该为这些类型的数据使用关系数据库。

欢迎任何意见。

Answer 1

In my application there are going to be many types of instructions and new instruction types will be added continuously during the lifetime of the application.

选择哪种解决方案有点取决于您对许多 和连续 的定义。数据库非常擅长查询现有数据。它在更改存储数据和添加新数据方面相当不错。更改数据库布局很糟糕。所以你应该尽量避免改变布局。

如果连续改变意味着一天几次，我不建议为每个应用程序制作一个表。

即便如此，如果许多应用程序意味着数千个应用程序/参数配置，那么每个应用程序一个表将导致数千个表，这是相当不希望的。

另一方面，如果您选择第一种方法，那么，正如您所说，您将必须妥善存储命令及其参数。

如果您有一些存储库模式来处理您的问题的用例，那么您可以让存储库在将参数存储到您的数据库之前检查参数。

void ScheduleBackupTask(TimeSpan startTime, TimeSpan stopTime, ... <backup parameters>)
{
     // check the parameter list, to see if they match the parameters of a backup task
     // and create the command
     var command = CreateBackupCommand(<backup parameters>);
     ScheduleCommand(startTime, stopTime, command);
}

void ScheduleCleaningTask(TimeSpan startTime, TimeSpan stopTime, <cleaning parameters>)
{
    // check the parameter list, to see if they match the parameters of a clean task
    // and create the command
    var command = CreateCleanCommand(<cleaning parameters>);
    ScheduleCommand(startTime, stopTime, command);
}

void ScheduleCommand(TimeSpan startTime, TimeSpan stopTime, Command command)
{
      using (var dbContext = new MyDbContext()
      {
           Schedule schedule = new Schedule(startTime, stopTime, command);
           dbContext.Schedules.Add(shedule);
           dbContext.SaveChanges();
      }
}

每次您必须支持新命令或必须更改命令的参数时，您都必须创建或更改Create...Command 函数。只有一处需要检查参数。

即使您选择了第二个解决方案，您也需要一个函数来检查您的参数并将它们按正确的顺序排列。所以你的第二个解决方案不会有帮助。

执行命令

显然，使用第一种方法查询必须执行的命令会更容易、更快速。获取命令(包括 commandType)后，很容易执行它:

IEnumerable<Command> commandsToExecute = FetchCommandsToExecute(TimeSpan time);
foreach (Command command in commandsToExecute)
{
     switch (command.CommandType)
     {
          case CommandType.Backup:
               ExecuteBackup(...);
               break;
          case CommandType.Clean:
               ExecuteClean(...);
               break;
     }
}

显然，在支持新命令时，您必须更改开关。但是，在您的第二个解决方案中，您还必须更改执行函数。

Summarized: if you think of a lot of commands to support, regularly changing parameters or kind of commands to support, may advice would be to have one table containing all commands to support. Let your repository pattern check the parameters before adding / updating / executing