这些信息直接来自于我的亲身经历。我被迫学习 Bugzilla 如何组织数据库，因为用户对措辞的细微更改提出了吹毛求疵的要求，而不是让人重新学习或弄清楚如何围绕该工具进行我们的流程。这很糟糕，但它可能会而且将会发生在你身上，所以学习模式如何工作并在发生时处理它。
所以，你现在拥有了全新的 Bugzilla 安装。你已经设置好了 MySQL，Apache 工作正常，Perl DBI 和 DBD 与数据库完美地对话。也许你甚至输入了一些测试错误，以确保电子邮件工作正常；人们似乎收到了关于新错误和更改的通知，你可以随心所欲地输入和编辑错误。也许你已经费力地为人们设置了一个网关，以便通过电子邮件向你的数据库提交错误，并让一些人进行了测试，并收到了来自你的 Beta 测试人员的好评。
你接下来要做什么？当然是为你的开发团队制定培训策略，让他们尽快熟悉你花费数小时辛勤工作的新工具。
你的第一次培训课程开始得非常好！你有一个专注的听众，他们似乎被这个叫做“Bugzilla”的东西所体现的效率所吸引。你正沉浸在描述那些漂亮的功能，人们如何在数据库中保存喜欢的查询，将它们设置为页面上的页眉和页脚，自定义他们的布局，生成报告，以前所未有的效率跟踪状态，一步跨越摩天大楼，并从必死无疑的魔爪中拯救简！
但是必死无疑发话了——一个微小的声音，从会议室的黑暗角落传来。“我有一个顾虑，”那个声音从黑暗中嘶嘶地说，“关于‘verified’这个词的使用。”
房间里，之前充满了快乐的聊天声，陷入了虔诚的寂静，因为必死无疑（更广为人知的身份是软件工程副总裁）继续说道。“你看，两年来我们一直使用‘verified’这个词来表示开发人员或质量保证工程师已经确认，实际上，一个错误是有效的。我不想因为一个新的软件产品而失去两年的培训成果。你需要尽快将 ‘verified’ 的错误状态更改为 ‘approved’。当然，为了避免混淆。”
哦，不！恐惧袭击了你的心脏，你发现自己喃喃自语“是的，是的，我不认为那会是一个问题，”你和必死无疑一起回顾了这些更改，并继续唠叨，“不，这不是太大的改变。我的意思是，我们有源代码，对吧？你知道，‘使用原力，卢克’等等……没问题，”与此同时，你内心像一只搁浅的水母一样颤抖，在牙买加炎热的沙丘上冒泡、咕嘟咕嘟和沸腾……
因此，你的 Bugzilla 之心冒险之旅开始了。你被迫了解了不可移植的 enum() 字段、varchar 列和 tinyint 定义。冒险在等待着你！
如果你像我一样，在这一点上你完全不了解 MySQL 的内部结构，如果不是因为这位副总裁的行政命令，你根本不会关心 MySQL 中 "bigint" 和 "tinyint" 条目之间的区别。我建议你参考 MySQL 文档，可在 MySQL.com 上找到。以下是你需要了解的关于 Bugzilla 数据库的基础知识。查看上面的图表以了解更多详情。
连接到你的数据库
bash# mysql -u root
如果这在没有要求你输入密码的情况下工作，真为你感到羞耻！你应该像安装说明告诉你的那样锁定你的安全。你可以在本目录中的 Bugzilla FAQ（在“安全性”下）中找到关于锁定数据库的详细信息，或者在 MySQL 可搜索文档 中找到更强大的通用安全性信息。
你现在应该看到一个如下所示的提示符
mysql>
在提示符下，如果 "bugs" 是你在localconfig文件中为你的 Bugzilla 数据库选择的名称，输入
mysql use bugs;
将你的 MySQL 数据库想象成一系列电子表格，你就不会太离谱。如果你使用此命令
mysql> show tables from bugs;
你将能够看到数据库中所有 "电子表格"（表）的名称。
从上面发出的命令中，你应该有一些看起来像这样的输出
+-------------------+ | Tables in bugs | +-------------------+ | attachments | | bugs | | bugs_activity | | cc | | components | | dependencies | | fielddefs | | groups | | keyworddefs | | keywords | | logincookies | | longdescs | | milestones | | namedqueries | | products | | profiles | | profiles_activity | | shadowlog | | tokens | | versions | | votes | | watch | +-------------------+ |
以下是每个表作用的概述。每个表中的大多数列都有
描述性名称，这使得弄清楚它们的作用相当容易。
attachments: 此表存储所有附加到错误的附件。它往往是你的
最大的表，但通常也具有最少的条目，因为文件
附件非常（相对）大。
bugs: 这是你的系统的核心。bugs 表存储了大多数
关于错误的当前信息，除了存储在
其他表中的信息之外。
bugs_activity: 这存储了关于对错误进行了哪些更改的信息
何时进行的 -- 一个历史文件。
cc: 这个小表仅存储任何错误的 CC 信息，这些错误在
错误的 CC 字段中有任何条目。请注意，像 Bugzilla 中的大多数其他表一样
它不通过用户名引用用户，而是通过他们的唯一
userid 引用，userid 作为 profiles 表中的主键存储。
components: 这存储了 Bugzilla 的程序和组件（或产品和
组件，在较新的 Bugzilla 术语中）。奇怪的是，“程序”
（产品）字段是产品的全名，而不是其他唯一的
标识符，就像 bug_id 和 user_id 在数据库的其他地方一样。
dependencies: 存储关于那些很酷的依赖关系树的数据。
fielddefs: 一个漂亮的小表，用于定义其他表。例如，当你
提交一个表单，该表单更改了 "AssignedTo" 的值时，此表允许
转换为实际字段名称 "assigned_to" 以输入到 MySQL 中。
groups: 定义组的位掩码。位掩码是一个可以唯一
标识组成员资格的数字。例如，假设允许
调整参数的组被分配值 "1"，允许编辑
用户的组被分配 "2"，而允许创建新组的组
被分配位掩码 "4"。通过唯一地组合组位掩码（很像
UNIX 中的 chmod 命令），你可以识别用户被允许调整
参数和创建组，但不允许编辑用户，通过给他一个位掩码
"5"，或者一个允许编辑用户和创建组，但不允许调整
参数的用户，通过给他一个位掩码 "6"。简单，对吧？
如果这让你感到困惑，请在 mysql 提示符下尝试此操作
mysql> select * from groups;
你将看到列表，这样理解起来会更容易。
keyworddefs: 要使用的关键字的定义
keywords: 与你想象的不同，此表保存了哪些关键字
与哪些错误 ID 相关联。
logincookies: 这存储了分配给你的每个登录 cookie，用于每个
你从中登录 Bugzilla 的机器。奇怪的是，它从不做任何
清理 -- 我在此文件中看到了几个月没用过的 cookie。然而，
由于 Bugzilla 永远不会过期你的 cookie（为了方便起见），这很
有道理。
longdescs: bugzilla 的核心 -- 这里是所有用户评论的存储位置！
每个评论你只有 2^24 字节（这是一个 mediumtext 字段），所以请谨慎发言
-- 这只是《圣经》旧约（未压缩，16 兆字节）所占空间的大小。
每个评论都键入到它所附加的 bug_id，因此顺序必然是按时间顺序排列的，因为
评论按照接收顺序播放。
comments are played back in the order in which they are received.
milestones: 有趣的是，里程碑与特定产品相关联
在此表中，但 Bugzilla 尚不支持通过
标准配置界面按产品区分里程碑。
namedqueries: 这是每个人存储他们的“自定义查询”的地方。非常
酷的功能；它比不得不为每个你构建的酷查询添加书签要好得多。
construct.
products: 你有哪些产品，是否允许为
产品输入新的错误条目，你正在为该产品努力实现的里程碑，投票等。当 components 表支持这些相同的功能时，那将
会很好，这样你就可以关闭特定组件以防止错误输入，而无需关闭
整个产品...
entire product...
profiles: 啊，所以你想知道你宝贵的用户信息
存储在哪里？就在这里！密码以明文形式存储，供所有人查看！（但是
嘘... 不要告诉你的用户！）
profiles_activity: 需要知道谁在何时对谁的个人资料做了什么？这会
告诉你，这是一个相当完整的历史记录。
shadowlog: 我可能在这里弄错了，但我相信这个表会告诉你何时
更新了你的影子数据库以及使用了哪些命令来更新它。我们
我们的站点尚未使用影子数据库，所以它对我们来说非常空。
versions: 每个产品的版本信息
votes: 谁在何时为什么投票
watch: 谁（根据 userid）正在监视谁的错误（根据他们的
userid）。
===
详细信息
===
啊，所以你想知道如何处理上面的信息？在
mysql 提示符下，你可以使用以下命令查看关于表中列的任何信息（其中 "table" 是你想查看的表的名称）
mysql> show columns from table;
mysql> show columns from table;
你还可以使用以下命令查看表中的所有数据
mysql> select * from table;
-- 注意：如果
你有 50,000 个错误，那么在 "bugs" 表上执行此操作是一个非常糟糕的主意。你将在那里坐一会儿，直到你 ctrl-c 或
50,000 个错误在你的屏幕上播放。
你可以使用以下命令稍微限制上面的显示，其中
"column" 是你想限制信息的列的名称
mysql> select * from table where (column = "some info");
-- 或反过来
mysql> select * from table where (column != "some info");
让我们以引言中的示例为例，并假设你需要更改
resolution 字段中的 "verified" 单词为 "approved"。我们从
上面的信息中知道，resolution 很可能存储在 "bugs"
表中。请注意，我们需要更改一些 perl 代码以及此数据库
更改，但我不打算在本文件中深入探讨这一点。让我们验证
信息是否存储在 "bugs" 表中
mysql> show columns from bugs
（此处截断了过长的输出）
| bug_status| enum('UNCONFIRMED','NEW','ASSIGNED','REOPENED','RESOLVED','VERIFIED','CLOSED')||MUL | UNCONFIRMED||
抱歉这条长线。我们从中看到 "bug status" 列是
一个 "enum field"，这是 MySQL 的一个特性，其中字符串类型字段可以
只能有某些类型的条目。虽然我认为这非常酷，但它不是
标准 SQL。无论如何，我们需要通过更改 "bugs" 表来添加可能的 enum 字段条目
'APPROVED'。
mysql> ALTER table bugs CHANGE bug_status bug_status
-> enum("UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED", "RESOLVED",
-> "VERIFIED", "APPROVED", "CLOSED") not null;
（请注意，我们可以写三行或更多行 -- 在
分号之前输入的任何内容都将被评估为单个表达式）
现在如果你这样做
mysql> show columns from bugs;
你将看到 bug_status 字段有一个额外的 "APPROVED" enum，它是
可用的！也很酷的是，这也反映在你的查询页面上
-- 你可以按新状态查询。但是它如何适应现有的
方案？
看起来你需要回去查找 Bugzilla 的 perl 代码中 "verified" 单词的实例
-- 无论你在哪里找到 "verified"，都将其更改为
"approved"，你就成功了（确保那是区分大小写的搜索）。
虽然你可以按 enum 字段查询，但在你进行 perl 更改之前，你无法为某事物赋予 "APPROVED" 的状态。
的 "APPROVED" 状态。请注意，我提到的这种更改也可以通过编辑 checksetup.pl 来完成，checksetup.pl 可以自动化很多
的操作。但是你无论如何都需要了解这些东西，对吧？
的操作。但是你无论如何都需要了解这些东西，对吧？