业务表

平台有3个系统业务表：

user 用户表

{
    id: bigint,     // 物理主键
    phone: text,    // 手机号码，登录用
    mail: text,     // 邮件地址，登录用
    role: [],       // 角色，控制权限用
    wx: {},         // 微信公众号账号信息
    mp: {},         // 微信小程序账号信息
    x: {},
    y: {}
}

asset 资源表

{
    id: bigint,
    auth: bigint,     // 创建人ID
    type: text,       // 类型，i是image, v是video, f是file
    url: text,        // 资源在对象存储服务器的地址，虚拟字段，并不真实存在
    name: text,       // 文件名
    ext: text,        // 文件后缀/扩展名
    size: integer,    // 文件大小(K)
    del: timestamp,   // 逻辑删除时间戳
    v: {},            // 每日访问(Visit)统计
    x: {},
    y: {}
}

存放用户上传的图片/视频/文件信息，此表在用户上传资源时由平台自动创建。很少直接使用。

order 订单表

{
    id: bigint,
    auth: bigint,        // 创建人ID
    type: text,          // 订单分类
    note: text,          // 订单描述
    total: numeric,      // 付款总金额
    refund: numeric,     // 退款金额
    refunding: boolean,  // 是否正在退款
    x: {},
    y: {}，
    z: {}                // 支付信息，由zc平台维护
}

注意：total和refund的存储类型是numeric，为保持数值精度其返回前端的类型是字符串。如需要计算可考虑转换成浮点型：parseFloat(totol)。

其它业务表可到【内置DB】栏中创建。

自建业务表

{
    id: bigint,       // 物理主键
    key: text,        // 业务主键
    auth: bigint,     // 创建人ID
    x: {},
    y: {}
}

表名大小写敏感。建议采用统一的命名规则以避免与变量名混淆，比如在表名后加【表】字：商品表，或在表名前面加【t】字母：t商品，英文表名首字母大写：Product。
自建业务表可以添加自定义字段，添加索引，但通常都不需要。

id

物理主键id由平台统一生成，它由16位数字组成，可以用isId()来判断参数是否是有效ID。
它前10位是该记录的创建时间(精确到秒)，可以用date()从id中提取时间。还可以用id()通过时间参数来构建一个id并以此来查询数据库。

auth

创建人（author）在插入数据时由平台自动填入当前登录用户的id。

x/y

每个表都有json类型的x和y字段。x存放具体的业务数据，通常把整个x放入表单给用户编辑并整体保存回数据库。而作为附加数据的y存放不让用户直接修改/不常变动的信息，比如审批信息。

在后端执行的表达式中，如果要访问x字段里面的属性，需要使用x.前缀；
在前端，平台为了方便会把x字段里面的属性复制一份到x字段外面，可直接访问x字段里面的属性就而省略x.前缀。

嵌套 vs. 母子表

x和y字段是可以嵌套数组的，可存放非常复杂的数据，传统子表里的数据都可以一起塞到里面。那什么时候用母子表存储什么时候用嵌套存储呢？
通常不经常变化的、信息量少的、记录条数有限的、无需单独拎出来查询的数据适合嵌套，否则就应该分开存储。
客户表中的多个联系人，商品表中的多种规格多个计量单位，会计凭证表中的多个分录，都可以嵌套，它们总量不多，也很少独立变化。
而用户发布的文章和用户登录系统的历史数据就不应嵌套的用户表中，文章的评论也不应嵌套的文章表里，因为它们的数量难以估计，也经常独立更新，还需要单独查询。
文章的阅读量字段也最好别嵌套，虽然量少（就一个字段一条记录），但它变化太频繁，