之前说过要写一个系统，经过一个月的紧张开发，现在终于完成了所有基础功能。来记录一下心得。

数据库表设计

这次是要做一个动态的成本计算，每个图号下边对应多个供应商，每个供应商需要从五个方面针对这个图号提供参数，然后计算出这个图号-供应商组合的成本。

只用语言很难描述，直接上最后确定的数据库表设计图：

图片也许有点小，但下载了看还是能看到详细的。因为程序规模还是比较小，所以没有采用纯业务逻辑控制。

记录两个以前自己没写过的业务：

一对一关系的部分，本来想用OneToOneField，后来发现还不如就用普通外键，然后通过逻辑来控制即可。
设备和使用设备的工序之间的多段多关系需要额外记录一个实际使用的设备数量。这里改用自行创建的表，然后通过ManyToMany的through属性来控制，在更新多对多关系的时候，可以提供该关系表中其他字段的值。

坚持动态配置

由于有大量的参数，在计算的时候，就没有强行要求一定要输入完整的所有参数。而是每次通过图号-供应商来筛选出满足条件的参数进行运算，没有配置或者配置错误的参数都会按照0来参与运算，这样减少了报错，用户使用起来也更流畅。

由于这次提供了用户注册功能，因此还是要稍微配一下权限。

之前接触auth模块的权限较少，这里记录一下心得。

在正常完成用户注册之后，如果不在view中加上权限，那么权限是不会发生的。

在每注册一个模型之后。数据库中的auth_permission表就会默认增加四个权限，其中的code_name字段就是用来判断是否存在该权限的字符串。

这个有点类似于@login_required，需要在视图函数前加上类似如下注释：

@permission_required('cost_structure.add_optiondata', login_url='/forbid/')

实际的字符串，前边需要加上模型所在的app的名字，一开始我就是这里犯了错，只写了code_name。然后还有一个login_url，不要被名称欺骗，这是一个被权限检查阻止访问之后默认的跳转页面。

在所有新增和修改的控制器上加上对应的权限检查之后，注册之后的用户就无法访问这些路径了。

这个就不赘述了，最后一步就是在后台修改该用户的权限。可以一次性开放，也可以详细到具体模型。

整体来说，Django内置auth模块的使用算是非常简单的。这次没有编写用户密码重置的功能，因为觉得略显繁琐。替代方法是让用户找管理员重置密码，然后提供密码修改功能来自行修改密码。这样虽然步骤多一些，但让管理员有了更好的控制。

这次把Java项目中的用户登录、注册、修改密码的页面都移植到了Django中，以后也可以复用了。

记录一下开发到现在用到的所有库，尽量少用点库

放点图吧，Bootstrap 5 风格。