优化错误消息

本文关键字：消息 错误 优化 | 更新日期: 2023-09-27 18:25:13

我想知道存储错误消息的最佳方式是什么，而不是在数据库中存储超过200个字符，并且所述错误消息可以包含不同的参数。

用参数格式化消息并将其直接插入数据库更好吗

或

将带有错误代码的参数存储在数据库中，并让应用程序确定带有错误代码和参数的消息是什么？

应用程序输出：

Error 36 : This is a test error message that can last forever.... 
          {I might insert a date and some other parameters here...}
           and continue the endless message

数据库端：

案例1

Table ErrorMessage
ErrorCode | Message                                          
36        | This is a test error message that can last...date + RandomParameter

案例2

Table ErrorMessage
ErrorCode | Date      | AdditionalInfo
36        | 2015-12-23| RandomParameter

哪种效率更高？

编辑：稍后将搜索这些消息。它可以是查看特定用户是否出现了许多错误并帮助他解决这些问题，也可以是管理错误消息，其中应用程序中发生了更改，并且与特定用户发生了冲突。它将登录到数据库中，并且在用户联系管理员时需要进行搜索。

优化错误消息

你所有的分数都有优点。这两种方法都有优点和缺点。

  • 您可以将两者都存储起来。这两者都有优点，唯一的缺点是增加了存储空间。

  • 如果您不选择同时存储两者，请存储完全格式化的消息。原因是，如果与号码相关的消息随新版本而更改，则您可能需要查看记录时的消息。

  • 如果您有查询参数的特定需求，那么就这样做。但是YAGNI适用。不要因为你认为你将来可能会这么做。稍后可以使用正则表达式提取它们。

对我来说，YAGNI的考虑是决定性的。除非你有具体的理由，否则今天，做任何其他事情，都要做符合要求的最简单的事情。这可能是为了存储完整的信息。

正如你从评论中看到的，理智的人对此可能会有不同的看法。我认为这是因为这取决于解释。

此外，你要求"最好的"answers"最高效的"——这总是一个上下文问题，这取决于你想要优化什么。

然而，我相信以下说法是正确的。

您的应用程序有一个称为"错误"的域概念。错误有类型，可用于对错误进行分类。错误可能包含有助于理解和传达错误的附加信息。每个错误类型可能具有不同的附加信息。附加信息的结构松散，不符合传统的关系模式。对于每次出现的错误类型，附加数据的内容都会发生变化，但其结构不会发生变化。

如果这都是真的，我建议最"关系"的模型是：

ErrorTypes
------------
ErrorTypeID (PK)
ErrorTypeDescription
ErrorOccurrence
-----------------
UserID
Date
ErrorTypeID (FK)
AdditionalInformation (JSON, XML, whatever)
相关文章：