zoukankan      html  css  js  c++  java
  • 数据库表设计时一对一关系

    今天,想着数据库表结构设计的时候,为什么对于 “一对一 ”关系, 为什么也要设计成两张表呢?这两张表怎么关联呢?带着这些疑问,去检索查阅了一些资料。记录一下

    原文: http://blog.csdn.net/u014075041/article/details/49251167?reload

    ------------------------------------------------------------------------------------

    在表设计过程中,我无意中觉得一对一关系觉得好没道理,直接放到一张表中不就可以了吗?真是说,网上信息什么都有,也可以说与我一样困惑的有好多人。感谢大神在网上的活跃,我知道了一对一关系存在的必要性。

    1.首先就是这种关系出现的场景是什么样子,最好可以举个实际中的需求。

    这样的场景有很多,比如:就拿最普通的用户信息来说,数据库中有一个表为user,一个表为user_auth.user表主要存放的字段为用户基本的信息(用户ID、真实姓名、昵称、真实头像、性别、职位、教育程度、专业、创建该用户的时间等),而在user_auth为验证表(用户ID、用户密码、邮箱、手机号等)。当涉及到一个具体实体的信息量较多,或者可以分类的时候,就可以使用了1-1,当然只要你能把一个实体的关系拆分成几个有归类的部分也可以适用。

    2.为什么要使用两个表来维护一对一关系,为什么不直接将两个表中的字段全都放在一张表里来展示?

    如果都放在一张表里,一:不便于管理(包括查询执行速度),二:也就达不到关系型数据库的特性。三:可更好对业务进行事务隔离操作

    3.提出这种关系的目的是什么,就是为提高我们数据库查询条件吗?

    目的:为第二问答案。这与数据库查询条件没有必然的说法。你说查询速度或者为了方便区分查询管理还说得过去。

    还有

    1. 公司和公司地址,总经理和公司,部门经理和部门 都是一对一

    2. 对于小字段小数据量的数据库来说,放到一起无所谓了,但是对于大字段的数据库,要添加删除修改某一个字段,由于数据库大,字段多,数据库找到这个字段耗时久,造成锁表等问题。同时分离存储大数据的表时,查询也会节省时间,因为某些框架会映射表里面所有的字段,存在一起查询时会把不需要的字段也映射进来造成耗时过久。还有,大数据量的表分离存储对于索引创建,读写分离,分割等操作都有优势。

    3. 同2

    我觉得这两种答案比较好。COPY在这里,记得时常看看,记在心里。

    -------------------------------------------------------补充更新-----------------------------2017年9月19日13:14:36----------------------------------

    一对一有时候需要建表,因为“继承+多态”的原因。
    比如"用户表"和"VIP用户表"的关系。(或者"普通用户"和"企业用户"的关系)
    正常情况下是需要一个是否VIP标记位就可以了。
    但是当下面情况发生的时候,需要建单独的表:
    1,当VIP的属性字段比普通用户多很多,并且衍生的逻辑关系比普通用户复杂很多。
    比如一般用户20个字段就够了,但是VIP需要40个字段,并且关联一大堆表,这些表都和普通用户没关系。
    2,VIP记录数量比普通用户少很多 。
    普通用户有几十万,但是VIP只有几百个。
    所以,按照这种情况,虽然是一对一的关系,如果不分开建表,那么就太冗余了。
    可以把这种一对一,理解成一对多的特例。
    因为这样的数据库结构同样支持一对多。

  • 相关阅读:
    【转】Android Touch事件传递机制解析
    通过Selector来设置按钮enable/unable状态的样式
    Android中的selector
    Android单元测试
    Android Lint简介
    制作高仿QQ的聊天系统(下)—— Adapter & Activity
    EditText的监听器和自定义回车事件
    监听Listview的滚动状态,是否滚动到了顶部或底部
    制作高仿QQ的聊天系统(上)—— 布局文件 & 减少过度绘制
    数据更新后让ListView自动滚动到底部
  • 原文地址:https://www.cnblogs.com/oxspirt/p/7550710.html
Copyright © 2011-2022 走看看