麻烦问下，数据库表扩展字段的使用？

小眼狗熊拿鱼钩钓王八 2019-01-10 10:23:54

我想再某个表里多创建一些扩展字段，这些字段现在不会使用，但也许将来可能会用到，不想通过主子表来实现，那样用起来要麻烦。所以想问下，如果表中多加了一些扩展字段，但这些字段还未被使用，即里面都为NULL，那这种会影响性能吗？

...全文

443 2 打赏收藏举报

写回复

2 条回复

切换为时间正序

请发表友善的回复…

发表回复

二月十六 2019-01-10

打赏
举报

回复

加几个多余不用的null字段，对性能影响不大，但是数据多了的话，空间浪费

Csdn技术大神 2019-01-10

打赏
举报

回复

影响不大都可以使用的挺好的

django 自带的权限框架，其中auth_user表的字段，很难满足正常的需求，因此需要扩展，至于扩展，一般有如下几种选择: 1. 直接修改django 源码，修改User class 的定义，以及各种方法等,然后把数据库auth_user表里的字段扩展到与自己需求一致.(源代码在：django.contrib.auth.models import User),这种方式，每次升级django都得

为什么需要扩展字段一个产品不可能罗列出所有的字段，比如：员工表，你能罗列所有企业OA系统中员工的信息字段吗？ “不可能的”。咱也别有穷举这种妄念。管理方面理解：固定规则和自由度需要结合起来，总公司不能把子公司规定死死的，也需要给一定的自由度灵活处理。固定规则为了保证秩序，业务系统中是为了保证系统可以正常运行，自由度是为了适配各地各种没有预想到的场景，业务系统中就是预留可扩展字段给用户，这样方可为上册。多一嘴：有一些人只是从技术角度看系统，说明他只在看山还是山的第一层。搞Saas的都再这一层会遇到

扩展字段笔记

在做项目的时候，发现刚刚开始设计的数据库表，到了后期需求的变更，会增加其属性字段，由此涉及到数据库字段动态扩展。有几种方法：1. 动态添加属性字段。需要时，添加需要的属性时。显然这种方式不利于灵活扩展，而且在一张大表添加一个字段需要较长时间，这也不适合7*24的服务。2. 先预留字段，到时再用。就是先给表定义几个扩展字段，以商品表为例。给product添加field1,field2...

但问题是——订单表是线上核心表，千万级数据，直接执行DDL语句极有可能锁表，影响线上业务运行，后果严重。简而言之，它不是对原表直接操作，而是旁边新建一个影子表，把旧表数据同步到新表里，然后在“合适时间”切换表名。我开始意识到，搞数据结构改动，本质就是一场战斗，要考虑的不仅仅是“能不能改”，而是“如何优雅不出事地改”。而且，这种方案也需要评估触发器带来的写入延迟，表结构切换的时机控制也很重要。这样一来，以后有新字段就塞进去，不用再修改表结构，非常灵活。我查了下现在是512，考虑到未来需求，打算调到2000。

22,298

社区成员

121,727

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章