实际项目中外键,应该用"userid"(账号)还是用user表"ID"

实际项目中外键,应该用"userid"(账号)还是用user表"ID"




表"ID"好处:

用id因为是int类型,比字符串类型的性能高得多,特别是在大数据量的情况下。在数据库的设计上,除非非常高级的系统,才会考虑int快和慢的问题。


"userid"(账号)

如果数据量比较大,有的情况下需要考虑尽量减少表连接的操作


这种情况我们一般叫“逻辑id”和“物理id”


userid------作为数据的物理id标识

用户名---------是数据的逻辑id


一般来说中小型项目通常使用物理id做为标识

而大型项目往往使用逻辑id做标识


区别,大型项目因为数据量大,结构复杂,网络硬件配置复杂,网络结构复杂,存储介质复杂。他们通常采用分布式的数据存储介质和分布式的网络环境,而在分库,分表的情况下,数据库的物理id就不可预览了,所以更多情况下使用逻辑id作为标识


比如:银行系统通常使用不与数据库id关联的,账户号做标识。而电信系统则因为硬件环境的限定使用电话号码做标识(电信系统通常的前置机只认主叫号,被叫号这种逻辑标识,而不认你自己的数据库id)


优化方案:

为了提高性能可以作数据冗余。例如:字段比较多,数据量又很大,你可以把Name字段上加入包含性列(不过这会占用一点额外的存储空间了)

可能修改的账号字段定义为loginid,用户表使用id,userid,作为标识。 UserName修改的机会要大很多,特别是企业应用,客户如果要求改一下用户名,如果用户名是外键那影响就大了.



相关话题:

外键约束会影响数据库性能,所以考虑只作业务约束。

表连接也有技巧:尽量用left join,不用inner join,这样可以提高效率

一个同事认为3次表连接以上就很可能会有性能问题

单机的情况下,4次表连接,主表20万行,在E8400+2G的机器上,做Group By统计,运行时间超过半个小时.后来将3个表连接保存为一个视图,再与主表连接,问题解决,30秒内完成.(不知道用的什么数据库,我不太信)


转载于:https://my.oschina.net/u/2438634/blog/511512

请生成一个汽车展览销售系统的数据库E-R图,包含以下实体及关系: 1. **实体与属性** - **用户 (User)** - 主用户ID - 属性:账号、密码、姓名、性别、手机、头像 - **车辆信息 (Vehicle)** - 主:车辆ID - 属性:车辆名称、价格、库存、排量、变速箱类型 - :品牌ID(关联品牌)、类型ID(关联车辆类型) - **品牌 (Brand)** - 主:品牌ID - 属性:品牌名称 - **车辆类型 (VehicleType)** - 主:类型ID - 属性:类型名称 - **订单 (Order)** - 主:订单ID - 属性:购买数量、金额、是否支付 - 用户ID(关联用户)、车辆ID(关联车辆信息) - **评论 (Comment)** - 主:评论ID - 属性:评分、评论内容 - 用户ID(关联用户)、车辆ID(关联车辆信息) - **收藏 (Favorite)** - 主:收藏ID - 用户账号(关联用户)、车辆ID(关联车辆信息) 2. **实体间关系** - **用户 ↔ 订单**:1个用户可创建多个订单(1:N) - **用户 ↔ 评论**:1个用户可发多条评论(1:N) - **用户 ↔ 收藏**:1个用户可收藏多辆车辆(1:N) - **车辆信息 ↔ 品牌**:1个品牌对应多辆车(1:N) - **车辆信息 ↔ 车辆类型**:1个类型对应多辆车(1:N) - **车辆信息 ↔ 订单**:1辆车可被多次购买(1:N) - **车辆信息 ↔ 评论**:1辆车可有多条评论(1:N) 3. **格式要求** - 主用 🔑 标记,用 → 标注指向的。 - 关系线标注“1:N”或“多对一”。 - 用户用蓝色,车辆用绿色,订单用橙色,品牌/类型用灰色。
最新发布
03-18
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值