当前位置:首页 » 数据仓库 » 数据库一张表存储一对多数据
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

数据库一张表存储一对多数据

发布时间: 2023-01-14 22:04:47

A. 数据库一对多怎么建立,还有主外键的区别

一对多:一个表的唯一健对应另一个表的某个字段 并且这个字段不是唯一的 这就是一对多
主键:唯一健 没的说 插入的值必须唯一
外键:简单地说 你对有外键的表操作的时候要满足外键的约束条件;不然不会让你操作
外键是属于约束的一种,所谓约束顾名思义,就是限制你在数据库的操作。而你对数据库有什么操作,无非是增、删、改、查,外键起的作用就是让你在数据库帮助的情况下更合理的增加数据的正确度。
外键的作用是能够避免如下情况。

【班级信息表】存放的是班级信息表。
【学生表】存放的是学生信息,包含班级信息。
这个时候 在【学生表】中存放的班级信息应该在【班级信息表】存在才合法,自己人为控制的话难免有漏掉的情况,用外键则可以让数据库自动控制,当插入【学生表】中的数据在【班级信息表】不存在的时候,数据库不允许插入。

B. 简述VISUAL FOXPRO数据库中创建表间一对多(1:N关联步骤

1。
将两个表加到同一个数据库中。
2。
“一方”的表按关键字建立主索引或候选索引,“多方”的表按此字段建立普通索引。
3。
打开数据库设计器,按住鼠标左键,从主表的此索引字段拖动到被关联表的此索引字段,此时会出现一条黑线,至此,一对多关系创建完毕。

C. 急急急!数据库查询问题,同表中一对多情况

这样的查询结果一般不是通过sql语句弄出来的,是将结果读到本地,然后再通过循环读取的。

你想,你的一个纵列表示一个字段,你现在只是举例的5条记录,如果记录非常多,那么纵列不就会非常多的啊。你还是考虑通过循环读取吧,而且也只显示部分信息,通过点击详情,然后再出来001对应的所有记录。
希望对你有用。

D. 怎么处理数据库一对多问题

不用创表,你可以再书表中加两个字段(是否借出,借书人编号),再把借书人编号和书生学号关联起来即可。触发器在这里完全没有必要,放在这里也不合适。希望回答对你有所帮助。

E. 一对一、一对多、多对多的数据表应该怎样设计

一对一正确。

一对多和多对一是多个表 ,至少两个表,一对多和多对一是相互的。

主键是自己定义的,一般外键表引用的对应的表的键是主键。

多对多三个表,有一个是关系表(中间表)。

中间表没有普通字段,一般只有有两个外键,同时引用两个表,多对多就出来了。

F. 数据库问题求解:设计数据库时出现一对多的情况该如何解决还有出现多对多呢

出现一对多的情况是数据库表的基本关系,按一对多关系处理。如果出现多对多的情况,那需要再建一张联接表,两张表与联连表形成一对多的关系,这才符合数据库设计的要求。

G. 数据库如何建立表间一对多关系

MySQL里面有如下的表

user:id username
photo:id name
photo_favour(图片收藏关系表):photo_id user_id

假设这几个表都相当大,需要进行分表。我的分表规则是:
user表按照id取模,这样user相关的表都可以按照这个取模后的结果来分表;
photo表按照id取模,同样与photo相关的表都可以按该规则分表;
至于photo_favour是一个多对多的关系表,我现在的想法是该表复制多一份,一份以photo_id来分表,一份以user_id分表,分别建立不同的索引,这样就变为两个一对多的关系。
我有两个问题:
1、这样的分表可行吗,有更好的分表方法吗?
2、一对多的关系在进行分表时候,例如user表和user_favour表都按照user_id来取模得到序号x来确定分表。如果1个用户会有100条收藏记录,那么user_x有100W条记录时候user_favour_x分表就有1000W记录,这时候user_favour_x又需要分表了,怎么解决这种情况?

这种情况我会放弃多对多的形式,弄两个表
user_to_photos: user_id, photo_id_list
photo_to_users: photo_id, user_id_list
1个user喜欢的photo id全塞到photo_id_list
1个photo被哪些用户喜欢了,也全塞到user_id_list
这样的读取就高效了很多,,写的时候注意并发脏写。。。同样你根据user_id爱怎么分表就怎么分。
===
如果收藏量太大,还是不能满足,就要考虑切分记录,1个user可以拥有多条记录,每条记录都可记录多个photo id
user_to_photos: user_id, num, photo_id_list
num字段可有可无,如果你需要精确定位user 222 收藏的 photo 333在哪条记录,就需要安排好算法,找到对应的num
大概是这样,重点是算法逻辑

数据库中建表时经常所说一对一、一对多、多对多等等关系究竟是什么意思?分别在什么情况下要用到一对一或一对式,而又在什么情况下又要用到多对多?在这里我们详细分析,并且用实例来讲解各种关系的实际运用!
关联映射:一对多/多对一存在最普遍的映射关系,简单来讲就如球员与球队的关系;一对多:从球队角度来说一个球队拥有多个球员 即为一对多多对一:从球员角度来说多个球员属于一个球队 即为多对一数据表间一对多关系如下图:

关联映射:一对一关系就如球队与球队所在地址之间的关系,一支球队仅有一个地址,而一个地址区也仅有一支球队。数据表间一对一关系的表现有两种,一种是外键关联,一种是主键关联。图示如下:
一对一外键关联:

----------------------------------------------------------------------------------------------------------
前言:多对多关系至少需要3个表,我们把一个表叫做主表,一个叫做关系表,另外一个叫做字典表或者副表(字典表是纪录比较少,而且基本稳定的,例如:版块名称;副表是内容比较多,内容变化的,例如)。
按照数据库的增删查改操作,多对多关系的查找都可以用inner join或者
select * from 主表 where id in (select 主表id from 关系表)
1,角色任命型
特点:关系表两外键组合无重复纪录,关系表一般不需要时间字段和主键,有一个表是字典类型的表。
界面特点:显示主表,用checkbox或多选select设置多选关系。
例如:任命版主(用户表-关系表-版块名称表),角色权限控制等,用户是5个版块版主,只要关系表5行纪录就可以确立,关系表的两个外键具有联合主键性质。
增加关系:如果没有组合纪录,insert之。
删除关系:如果有组合纪录,删除之。
2,集合分组型
特点:同角色任命型类似,关系表两外键组合无重复纪录,关系表一般不需要时间字段和主键。区别是主副表都不是字典表,可能都很大不固定。
界面特点:显示主表,用搜索代替简单的checkbox或多选select,或者一条一条的添加。
例如:歌曲专集(专集表-关系表-歌曲表)。手机分组(分组表-关系表-手机表)。用户圈子(圈子表-关系表-用户表)。文章标签(文章表-关系表-标签表)
增加关系:同版主任命型。
删除关系:同版主任命型。

3,明细帐型
特点:关系表可以有重复纪录,关系表一般有时间字段,有主键,可能还有文字型的字段用来说明每次发生关系的原因(消费)。
界面特点:显示关系表,用radio或下拉设置单选关系。
例如:现金消费明细帐或订单(用户表-订单表-消费原因表),用户可能多次在同一事情上重复消费。积分变化纪录也属于这类。
增加关系:不管有没有组合纪录,insert之,纪录时间。
删除关系:根据关系表PK删除。

4,评论回复型
特点:同明细帐型关系表一般有时间字段,有主键,区别是重点在文字型的字段用来说明每次发生关系的内容(评论回复)。
界面特点:回复文本框。
例如:论坛回复(用户表-回复表-帖子表),用户可能多次在不同帖子上评论回复费。
增加关系:不管有没有组合纪录,insert之,纪录时间和文字。
删除关系:根据关系表(回复表)PK删除。
5,站内短信型
特点:主副表是同一个,关系表一般有时间字段,有主键,重点在关系表文字型的字段用来说明每次发生关系的内容(消息)或者其他标记位来表示文字已读状态时间等。
界面特点:回复文本框。
例如:站内短信(用户表-短信表-用户表),用户可能给用户群发或者单发,有标记位来表示文字已读状态时间等。
增加关系:不管有没有组合纪录,insert之,纪录时间和文字。
删除关系:根据关系表(回复表)PK删除。
6,用户好友型
特点:主副表是同一个,同集合分组型,关系表两外键组合无重复纪录,关系表一般不需要时间字段和主键。
界面特点:同集合分组型,显示主表,用搜索代替简单的checkbox或多选select,或者一条一条的添加。
例如:下载站点的文件,(文件表-关系表-文件表)可以被软件工具打开,软件工具本身也是一种文件,可以被下载。用户的好友,也是用户(用户表-好友关系表-用户表)
增加关系:同版主任命型。
删除关系:同版主任命型。

7,未知属性型
特点:在设计初期,主表的某些字段类型和名称是不确定的时候,关系表实际上是主表的可扩展字段,
一个[主表](ID),
一个[属性名称表](属性ID.属性名称),
一个[属性值表],包括3个字段:
属性值(属性Value varchar(500))
主表ID
属性ID
这样可以作到最小冗余度。
(和常见的多对多关系不同的是:值统一用varchar来存储,因为这类型的值一般不会用来计算)。
比如:
军队的数据库设计中有种物资叫做“战缴物资”,就是打仗的时候缴获的,军队自己都不知道这些物资有什么属性。
比如缴获的化学品有化学名,通用名,是否有辐射,计量单位,包装规格,数量等等,或者不是化学品是其他任何未知的东西。
这样东西就可以
某奇怪东西.属性集合["某某奇怪属性名"]="某某奇怪值";
某变态东西.属性集合["某某变态属性名"]="某某变态值";
这样存储。
再比如:
手机型号有几千种,除了共同属性外还有不同属性有几百个,属性名和值类型都不一样,有的手机有这属性,有的没有。
对于这样的“多态”,我们就采用上面的设计结构。
其效果相当于:
某奇怪手机.属性集合["某某奇怪属性名"]="某某奇怪值";
某变态手机.属性集合["某某变态属性名"]="某某变态值";
界面特点:设置主表一行纪录的属性时候,要列出所有可能的属性名称,每个对应一个文本框。

H. 数据库中怎么设计一对多的问题

主外键关联法
比如:
货物类别表A和货物类B的关系是:一个类别下有多个货物
A表结构:
类别ID(A表主键)
类别名称
B表结构:
货物ID(B表主键)
货物类别ID(外键,references
A(类别ID))
货物名称

I. 数据库建立一对多关系

表1
可以有用户ID,用户名,用户密码
表2
用户ID,本表ID,日期时间,日历事件,事件类型,备注
某个用户登陆你可以知道它的ID再用此用户ID知道他的日历事件
select * from 表2 where 用户ID=??

J. 数据库一对多、连接表问题

楼主这种,是多对多的关系,我一般是这么处理的。

学生表 (一个主键 学生ID)

课程表 (一个主键 课程ID)

学生选课表
主键为2个字段 学生ID、课程ID
同时建立外键约束
学生选课表中的 学生ID,必须在学生表中存在。
学生选课表中的 课程ID、必须在课程表中存在。

因为 一个学生,选一门课程,是唯一的了。 可以作为主键了。
没有必要再去折腾一个 “选课ID” 作为主键。 然后再给 学生ID 与 课程ID 创建个唯一性的索引。

--

除非是这种情况:

这个 中间的 选课表, 还包含 时间信息的字段.
例如 学生 张三
2010年 选修 Oracle 数据库课程
2011年,又选修 Oracle 数据库课程
2012年,还选修 Oracle 数据库课程

那么,这种情况下, 可以设置 一个由数据库管理的 自增的 "选课ID" 来确保唯一性。