这种情况都是无所谓的,需要具体情况具体分析的。
数据库的设计基本是要遵循范式的,你这种的情况主要是ID这个列有重复,如果你的查询需要根据ID来进行查找而ID需要唯一的话,显然2个表是不好的。如果表一是个商品表,表二是表一的父表,比如表二有个name是水果。这种时候就不适合进行一个表的合并设计。具体问题具体分析吧,希望把实际情况发上来,帮你看看
master
tempdb
model
msdb
在实例中默认显示为4个,有一个是隐藏的Resource记录系统表信息
系统数据库 说明
master 数据库 记录 SQL Server 实例的所有系统级信息。
msdb 数据库 用于 SQL Server 代理计划警报和作业。
model 数据库 用作 SQL Server 实例上创建的所有数据库的模板。对 model
数据库进行的修改(如数据库大小、排序规则、恢复模式和其他数据库选项)将应用于以后创建的所有数据库。
Resource 数据库 一个只读数据库,包含 SQL Server 包括的系统对象。系统对象在物理上保留在 Resource 数据库中,但在逻辑上显示在每个数据库的
sys 架构中。
tempdb 数据库 一个工作空间,用于保存临时对象或中间结果集
1商品编号(主键),商品名称,单价,数量,单位
2流水号(主键),交易时间, [客户信息等其他可能的可以由流水号确定属性]
3ID(主键,可以是自增int或其他根据需要) , 流水号(外键) , 商品编号 (外键) , [本次交易数量 等其他可以由流水号,商品编号 确定的属性]
1数据库中的多对多关联关系一般需采用中间表的方式处理,将多对多转化为两个一对多。
2通过表的关系,来帮助我们怎样建表,建几张表。
一对一
一张表的一条记录一定只能与另外一张表的一条记录进行对应,反之亦然。
学生表:姓名,性别,年龄,身高,体重,籍贯,家庭住址,紧急联系人
其中姓名、性别、年龄、身高,体重属于常用数据,但是籍贯、住址和联系人为不常用数据
如果每次查询都是查询所有数据,不常用的数据就会影响效率,实际又不用
常用信息表:ID(P),姓名,性别,年龄,身高,体重
不常用信息表:ID(P),籍贯,家庭住址,紧急联系人
解决方案:将常用的和不常用的信息分享存储,分成两张表
不常用信息表和常用信息表,保证不常用信息表与常用信息表能够对应上:找一个具有唯一性的
字段来共同连接两张表。
一个常用表中的一条记录永远只能在一张不常用表中匹配一条记录,反之亦然。
一对多
一张表中有一条记录可以对应另外一张表中的多条记录;但是反过来,另外一张表的一条记录
只能对应第一张表的一条记录,这种关系就是一对多或多对一
母亲与孩子的关系:母亲,孩子两个实体
母亲表:ID(P),名字,年龄,性别
孩子表:ID(P),名字,年龄,性别
以上关系:一个妈妈可以在孩子表中找到多条记录(也可能是一条),但是一个孩子只能找到一个妈妈
是一种典型的一对多的关系。
但是以上设计:解决了实体的设计表问题,但是没有解决关系问题,孩子找不到母亲,母亲也找不到孩子
解决方案:在某一张表中增加一个字段,能够找到另外一张表中的记录:在孩子表中增加一个字段
指向母亲表,因为孩子表的记录只能匹配到一条母亲表的记录。
母亲表:ID(P),名字,年龄,性别
孩子表:ID(P),名字,年龄,性别,母亲表ID(母亲表主键)
多对多
一对表中(A)的一条记录能够对应另外一张表(B)中的多条记录;同时B表中的一条记录
也能对应A表中的多条记录
老师和学生
老师表T_ID(P),姓名,性别
学生表S_ID(P),姓名,性别
以上设计方案:实现了实体的设计,但是没有维护实体的关系
一个老师教过多个学生,一个学生也被多个老师教过
解决方案:增加一张中间关系表
老师与学生的关系表:ID(P),T_ID,S_ID
老师表与中间表形成一对多的关系,而中间表是多表;维护了能够唯一找到一表的关系;
同样的学生表与中间表也是一个一对多的关系;
学生找老师:找出学生ID--->中间表寻找匹配记录(多条)--->老师表匹配(一条)
老师找学生:找出老师ID--->中间表寻找匹配记录(多条)--->学生表匹配(一条)
以上就是关于数据库设计 表结构相同 是创建多个表 还是创建一个表 全部的内容,包括:数据库设计 表结构相同 是创建多个表 还是创建一个表 、sqlserver一个数据库4个表怎么创建、数据库设计:遇到一对多的情况,需要创建几个表,怎么创建等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)