简介：面向 Odoo 17 二次开发与运维人员的中文数据字典，聚焦于解决英文表结构难查、字段含义不清的痛点，适合需要快速定位模型与字段、理解数据库设计的中级开发者及实施顾问使用。资源包内共 1 个 PDF 文件，约 8.07MB，由 Navicat 从 PostgreSQL 的 odoo 数据库导出整理，按服务器、数据库、public 模式、表逐级编排目录，覆盖 account_account、account_account_account_journal_rel、account_account_tag 及多对多关联表等核心业务表，便于按模块检索。已有 134 人学习，可作为开发调试、报表取数与数据迁移时的案头参考，帮助读者快速掌握表间关系与字段定义，减少反复翻阅源码的时间。
1. 数据字典到底是个什么东西：从“找不到字段”的抓狂说起
接手一套别人搭好的系统，想加个报表，结果打开数据库一看，几百张表名像天书一样排在那里，字段名全是英文缩写，翻遍文档也没人告诉你account_move_line里那个balance到底存的是含税还是不含税。这种抓狂，做过二次开发的人都懂。数据字典就是治这个病的：它把数据库里每张表、每个字段、每个类型和注释整理成一份可查的清单，相当于给数据库配了一本“户口簿”。而 Odoo 17 数据字典（已翻译为中文）这份资料，做的就是把 Odoo 这套庞大 ERP 系统的数据库结构，逐表逐字段地摊开、译成中文，让“odoo学习”不再靠猜字段名硬扛。搞懂它，等于拿到一张数据库地图，知道东西在哪、叫什么、长什么样。
2. 为什么 Odoo 需要一本数据字典：表多、名怪、关系绕
2.1 一张表背后是一整套业务逻辑
Odoo 不是那种“一个功能一张表”的简单系统。它把会计、销售、库存、采购、生产全塞进一个数据库里，表与表之间靠外键和中间关联表串起来。你看到的account_move是会计凭证主表，account_move_line是凭证行，account_partial_reconcile记录核销关系，account_full_reconcile记录完全核销——光会计模块就能拉出几十张表。没有字典，你只能靠表名猜用途，猜错一次，报表数字就对不上，排查半天才发现是关联错了表。数据字典把这些表按模块前缀归类，account_开头的基本是会计，stock_开头的是库存，mrp_开头的是生产，一眼就能定位到业务域。
2.2 字段名是英文缩写，中文翻译省掉一层翻译成本
Odoo 的字段命名有它自己的习惯，比如partner_id指业务伙伴，move_id指凭证，product_uom_qty是产品单位数量。对英文不敏感的人，每看一个字段都要在脑子里转一道弯。这份字典把字段说明翻成中文，等于把“读英文猜意思”这一步砍掉了。举个实际场景：你要在销售订单行上找“已开票数量”，英文界面里叫qty_invoiced，字典里直接告诉你这是“已开票数量”，不用再去翻源码或者试错。对于刚接触 Odoo 的学习者，这种翻译不是锦上添花，是实打实降低门槛。
2.3 数据库结构是二次开发的底图
任何二次开发，只要碰数据，就绕不开表结构。写一个自定义报表，要知道从哪张表取数、跟哪张表 join；做一个数据迁移，要知道目标字段的类型和约束；排查一个显示异常，要确认字段是不是存了空值。数据字典就是这张底图。没有它，开发像在黑暗里摸开关；有了它，至少知道墙上有几个开关、分别控制哪盏灯。Odoo 17 数据字典把public模式下的表逐一亮出来，连关联表（比如account_account_account_journal_rel这种多对多中间表）都列清楚，做查询时不用再靠\d+ 表名一条条敲。
3. 这份字典里到底有什么：表、字段、类型、注释四件套
3.1 表清单：从 account 到 stock 的全景目录
打开这份资料，最先看到的是按字母序排列的表清单。以account_开头的表覆盖了会计核心：account_account是会计科目表，account_journal是日记账，account_move是凭证，account_payment是付款单，account_tax是税。再往后是stock_开头的库存表、res_开头的系统基础表（res_partner业务伙伴、res_users用户）、product_开头的产品表。每张表下面跟着字段列表，字段名、数据类型、是否允许为空、默认值、注释说明，一行一行排开。这种组织方式的好处是：你不需要先懂 Odoo 的模块划分，按前缀就能大致判断一张表属于哪个业务域。
3.2 字段信息：类型和约束比名字更重要
字段名告诉你“叫什么”，字段类型告诉你“怎么用”。同样是存金额，numeric和float在精度处理上不一样；同样是存关联，integer外键和many2one在 Odoo 的 ORM 层表现不同。字典里每个字段都标了 PostgreSQL 层面的类型，比如character varying(255)、numeric、timestamp without time zone、boolean。这些信息在写 SQL 查询时直接决定你怎么写条件、怎么转换。举个例子，account_move_line的balance字段是numeric，你做汇总时就得用SUM(balance)而不是当字符串处理；date字段是date类型，比较时要用日期字面量而不是字符串拼接。字典把这些底细摊开，省掉大量试错。
3.3 关联表：多对多关系的中转站
Odoo 里大量使用多对多关系，落到数据库就是中间关联表。比如account_account_account_journal_rel这张表，名字里两个account_夹一个_rel，一看就知道是会计科目和日记账的关联表，里面通常只有两列：account_account_id和account_journal_id。这种表在业务上不直接对应任何实体，但做查询时经常要经过它。字典把这类表单独列出来，等于告诉你“这里有个中转站，别漏了”。很多初学者写查询时只盯着主表，忘了关联表，结果数据对不上，翻车就翻在这里。
3.4 中文注释：把英文命名翻译成业务语言
字段注释是这份字典的增值部分。Odoo 原生数据库里字段注释很少，大部分信息藏在 Python 源码的字段定义里。这份资料把常见字段的业务含义用中文补上，比如state字段在account_move里是“状态”（草稿/已过账/已取消），在stock_picking里是“调拨状态”。同一个字段名在不同表里含义可能不同，字典按表给出注释，避免张冠李戴。对于“odoo学习”阶段的人来说，这种按表翻译的注释比通用术语表有用得多，因为它贴着具体业务场景。
4. 容易搞混的几个概念：数据字典不是文档，也不是 ER 图
4.1 数据字典 vs 系统操作手册
易混点：两者都叫“文档”，都跟系统有关。为什么混：新手听到“查文档”就以为是一回事。怎么区分：操作手册讲“怎么点按钮”，数据字典讲“数据存在哪”。操作手册面向使用者，数据字典面向开发者和数据分析者。你要查“怎么创建一张发票”，看操作手册；你要查“发票数据存在哪张表哪个字段”，看数据字典。这份 Odoo 17 数据字典通篇是表名、字段名、类型，没有一句“点击这里”，定位非常清楚。
4.2 数据字典 vs ER 图
易混点：都描述数据库结构。为什么混：ER 图上也画了表和字段。怎么区分：ER 图侧重“关系”，用线条画出一对多、多对多；数据字典侧重“明细”，把每个字段的类型、约束、注释列全。ER 图让你一眼看懂表之间怎么连，数据字典让你查某个字段到底存什么。两者互补，不能替代。这份资料是字典形态，按表罗列，适合精确查询，不适合看全局关系。想快速理解业务模型，先看 ER 图；想确认字段细节，翻字典。
4.3 数据字典 vs 源码里的模型定义
易混点：Odoo 的 Python 源码里每个模型都定义了字段，看起来也是“字段清单”。为什么混：两者信息有重叠。怎么区分：源码是“设计态”，字典是“运行态”。源码里定义的字段，落到数据库可能改名、可能加前缀、可能因为继承而分散在多张表。字典反映的是数据库里实际存在的表和列，是psql里\d能看到的东西。做 SQL 查询必须以字典为准，不能直接拿源码字段名当列名用。比如源码里写partner_id，数据库列名就是partner_id，但有些计算字段不落库，字典里就不会出现——这个差异只有对照才能发现。
4.4 数据字典 vs 数据库客户端自带的表结构查看
易混点：用数据库客户端也能看表结构，为什么还要字典。为什么混：功能上确实重叠。怎么区分：客户端给你的是“原始结构”，字典给你的是“翻译过、整理过、带业务注释的结构”。客户端里字段注释可能是空的，表名没有分类，几百张表平铺，找起来费劲。字典做了中文翻译和按模块归类，查起来快。另外字典是离线文档，不依赖数据库连接，开会、写方案时随手翻，比连库查方便。
5. 什么时候该翻这本字典，什么时候别指望它
5.1 适合用的场景：查字段、写查询、做迁移
最典型的用法是写自定义查询。假设你要出一张“每个客户的开票金额汇总”报表，思路是先找发票表account_move（move_type为out_invoice），再关联业务伙伴表res_partner，按partner_id分组汇总amount_total。每一步都需要确认字段名和类型：move_type是不是叫这个、partner_id在account_move里存的是不是整数、amount_total是含税还是不含税。翻字典，三分钟确认完，不用连库试错。再比如做数据迁移，要把外部系统的客户数据导入res_partner，得知道哪些字段必填、name字段长度限制是多少、email有没有格式约束。字典里的类型和约束信息直接告诉你答案。
另一个高频场景是排查数据异常。某张报表数字对不上，怀疑是关联错了表。翻字典看account_move_line和account_move的关联字段，确认是move_id还是move_line_id，避免 join 错方向。这种排查，有字典和没字典，时间差好几倍。
5.2 不适合用的场景：别拿它当业务规则说明书
字典告诉你“字段存在”，不告诉你“字段怎么算”。比如amount_total是发票总额，但含不含税、含不含折扣、多币种怎么换算，这些业务规则不在字典里。字典也不解释“为什么这张表要这样设计”，那是架构文档的事。还有人指望字典给出“最佳查询写法”，它给不了，它只给结构，SQL 怎么写还得靠自己对业务的理解。另外，字典是某一时点的快照，Odoo 升级或装了新模块，表结构会变，字典不会自动更新。拿旧字典查新库，字段对不上是常事，这时候得以实际数据库为准。
5.3 一个具体例子：从需求到查询的完整路径
需求：统计每个销售员名下已确认订单的金额。第一步，找订单表，Odoo 里销售订单是sale_order，字典里确认表名和关键字段：state（状态）、user_id（销售员）、amount_total（总额）。第二步，确认state的取值，字典注释里写“状态”，具体值（draft/sale/done）得结合业务知识，字典不展开枚举。第三步，关联用户表res_users取销售员名字，通过user_id关联。第四步，写查询：
-- 统计每个销售员名下已确认订单的金额 SELECT u.login AS salesperson, SUM(o.amount_total) AS total_amount FROM sale_order o JOIN res_users u ON o.user_id = u.id WHERE o.state = 'sale' -- 只统计已确认订单 GROUP BY u.login ORDER BY total_amount DESC;这段查询里，表名和字段名全部来自字典确认，state = 'sale'这个取值来自业务常识而非字典。字典的作用是保证sale_order、user_id、amount_total、res_users、login这些名字没写错，join 条件没连错表。没有字典，你可能把user_id写成salesman_id，或者把res_users写成res_partner，查询报错再回头改，来回折腾。
5.4 我的习惯：先翻字典再动手
吃过几次亏之后，我养成了一个习惯：任何碰 Odoo 数据库的活儿，动手前先翻一遍字典，把涉及的表和字段列在纸上，确认类型和关联关系，再写第一行 SQL。这个动作花不了几分钟，但能挡掉大部分“字段名拼错”“关联表漏了”“类型不匹配”的低级错误。字典不是万能的，它不教业务、不教 SQL 优化，但它把“数据长什么样”这件事说清楚了，剩下的靠自己去补。希望这份 Odoo 17 中文数据字典，也能帮你少走几段弯路。
本文还有配套的精品资源，点击获取
