Odoo 17数据字典：中文版数据库结构详解与二次开发指南

简介面向 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_movemove_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 中文数据字典也能帮你少走几段弯路。本文还有配套的精品资源点击获取