hql 集合查询 Order(订单表)与Orderdetail(订单详情表) 类似淘宝的那种

hql 集合查询 Order(订单表)与Orderdetail(订单详情表) 类似淘宝的那种,第1张

我简单写个思路,因为我也不知道你是直接写的hql还是使用的hibernate的动态hql生成类。

select od from orderdetail od where odshop = 1 and odorder = 1

如果还需要order信息就再关联上order表

new一个order对象,save就行了

看你的意思就是在orderdetail表中做一次带条件的查询

这个问题可能是由于视图里的字段和表间的关系不正确导致的。请检查你在INNER JOIN的字段是否是实际的主键或外键关系,以确保这四个表是正确关联的。

此外,你也可以试试使用LEFT JOIN或RIGHT JOIN,看看能否获得期望的结果。还可以尝试将查询语句复制到SQL管理器中执行,检查是否有任何错误信息。

订单表和商品表一对多,一个订单有多个商品。订单表:ID、订单号、顾客姓名、****、配送地址商品表:ID、订单ID、商品名称、商品价格、商品数量添加的时候先添加一条订单返回mysql_insert_id()做为关联。

为了建立冗余较小、结构合理的数据库,设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库,必须满足一定的范式。

真正要明白”范式(NF)”是什么意思,首先看下教材中的定义,范式是“符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度”。实际上可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。就像家里装修买建材,最环保的是E0级,其次是E1级,还有E2级等等。数据库范式也分为1NF,2NF,3NF,BCNF,4NF,5NF。一般在我们设计关系型数据库的时候,最多考虑到BCNF就够。符合高一级范式的设计,必定符合低一级范式,例如符合2NF的关系模式,必定符合1NF。

在实际开发中最为常见的设计范式有三个:

首先是第一范式(1NF)。

符合1NF的关系(你可以理解为数据表。“关系”和“关系模式”的区别,类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例,你可以把”关系”理解为一张带数据的表,而“关系模式”是这张数据表的表结构。1NF的定义为:符合1NF的关系中的每个属性都不可再分。表1所示的情况,就不符合1NF的要求。

表1

实际上,1NF是所有关系型数据库的最基本要求,你在关系型数据库管理系统(RDBMS),例如SQL Server,Oracle,MySQL中创建数据表的时候,如果数据表的设计不符合这个最基本的要求,那么 *** 作一定是不能成功的。也就是说,只要在RDBMS中已经存在的数据表,一定是符合1NF的。如果我们要在RDBMS中表现表中的数据,就得设计为表2的形式:表2

表2

但是仅仅符合1NF的设计,仍然会存在数据冗余过大,插入异常,删除异常,修改异常的问题,例如对于表3中的设计:

每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大

假如学校新建了一个系,但是暂时还没有招收任何学生(比如3月份就新建了,但要等到8月份才招生),那么是无法将系名与系主任的数据单独地添加到数据表中去的 ----—插入异常

假如将某个系中所有学生相关的记录都删除,那么所有系与系主任的数据也就随之消失了(一个系所有学生都没有了,并不表示这个系就没有了)。——删除异常

假如李小明转系到法律系,那么为了保证数据库中数据的一致性,需要修改三条记录中系与系主任的数据。——修改异常。

正因为仅符合1NF的数据库设计存在着这样那样的问题,我们需要提高设计标准,去掉导致上述四种问题的因素,使其符合更高一级的范式(2NF),这就是所谓的“规范化”。

第二范式

第二范式在第一范式的基础之上更进一层。是指2NF在1NF的基础之上,消除了非主属性对于码的部分函数依赖。

函数依赖:若在一张表中,在属性(或属性组)X的值确定的情况下,必定能确定属性Y的值,那么就可以说Y函数依赖于X,写作 X → Y。

表中的函数依赖关系例如:

系名 → 系主任

学号 → 系主任

(学号,课名) → 分数

但以下函数依赖关系则不成立:

学号 → 课名

学号 → 分数

课名 → 系主任

(学号,课名) → 姓名

码:假如当 K 确定的情况下,该表除 K 之外的所有属性的值也就随之确定,那么 K 就是码。码也可以理解为主键。

第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。

比如要设计一个订单信息表,因为订单中可能会有多种商品,所以要将订单编号和商品编号作为数据库表的联合主键,如下表所示。

订单信息表

这样就产生一个问题:这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关,而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。

而如果把这个订单信息表进行拆分,把商品信息分离到另一个表中,把订单项目表也分离到另一个表中,就非常完美了。如下所示。

订单信息表

订单项目表

商品信息表

这样设计,在很大程度上减小了数据库的冗余。如果要获取订单的商品信息,使用商品编号到商品信息表中查询即可。

因此可以总结判断的方法是:

第一步:找出数据表中所有的码。

第二步:根据第一步所得到的码,找出所有的主属性。

第三步:数据表中,除去所有的主属性,剩下的就都是非主属性了。

第四步:查看是否存在非主属性对码的部分函数依赖。

第三范式

3NF在2NF的基础之上,消除了非主属性对于码的传递函数依赖。也就是说, 如果存在非主属性对于码的传递函数依赖,则不符合3NF的要求。

则就是第三范式需要确保数据表中的每一列数据都和主键直接相关,而不能间接相关。

比如在设计一个订单数据表的时候,可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息(比如姓名、所属公司等)的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。

订单信息表

客户信息表

这样在查询订单信息的时候,就可以使用客户编号来引用客户信息表中的记录,也不必在订单信息表中多次输入客户信息的内容,减小了数据冗余。

由此可见,符合3NF要求的数据库设计,基本上解决了数据冗余过大,插入异常,修改异常,删除异常的问题。当然,在实际中,往往为了性能上或者应对扩展的需要,经常 做到2NF或者1NF,但是作为数据库设计人员,至少应该知道,3NF的要求是怎样的。

CREATE TABLE `mmall_user` (

  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用户表id',

  `username` varchar(50) NOT NULL COMMENT '用户名',

  `password` varchar(50) NOT NULL COMMENT '用户密码,MD5加密',

  `email` varchar(50) DEFAULT NULL,

  `phone` varchar(20) DEFAULT NULL,

  `question` varchar(100) DEFAULT NULL COMMENT '找回密码问题',

  `answer` varchar(100) DEFAULT NULL COMMENT '找回密码答案',

  `role` int(4) NOT NULL COMMENT '角色0-管理员,1-普通用户',

  `create_time` datetime NOT NULL COMMENT '创建时间',

  `update_time` datetime NOT NULL COMMENT '最后一次更新时间',

  PRIMARY KEY (`id`),

  UNIQUE KEY `user_name_unique` (`username`) USING BTREE

) ENGINE=InnoDB AUTO_INCREMENT=22 DEFAULT CHARSET=utf8;

CREATE TABLE `mmall_product` (

  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '商品id',

  `category_id` int(11) NOT NULL COMMENT '分类id,对应mmall_category表的主键',

  `name` varchar(100) NOT NULL COMMENT '商品名称',

  `subtitle` varchar(200) DEFAULT NULL COMMENT '商品副标题',

  `main_image` varchar(500) DEFAULT NULL COMMENT '产品主图,url相对地址',

  `sub_images` text COMMENT '地址,json格式,扩展用',

  `detail` text COMMENT '商品详情',

  `price` decimal(20,2) NOT NULL COMMENT '价格,单位-元保留两位小数',

  `stock` int(11) NOT NULL COMMENT '库存数量',

  `status` int(6) DEFAULT '1' COMMENT '商品状态1-在售 2-下架 3-删除',

  `create_time` datetime DEFAULT NULL COMMENT '创建时间',

  `update_time` datetime DEFAULT NULL COMMENT '更新时间',

  PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=30 DEFAULT CHARSET=utf8;

CREATE TABLE `mmall_category` (

  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '类别Id',

  `parent_id` int(11) DEFAULT NULL COMMENT '父类别id当id=0时说明是根节点,一级类别',

  `name` varchar(50) DEFAULT NULL COMMENT '类别名称',

  `status` tinyint(1) DEFAULT '1' COMMENT '类别状态1-正常,2-已废弃',

  `sort_order` int(4) DEFAULT NULL COMMENT '排序编号,同类展示顺序,数值相等则自然排序',

  `create_time` datetime DEFAULT NULL COMMENT '创建时间',

  `update_time` datetime DEFAULT NULL COMMENT '更新时间',

  PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=100031 DEFAULT CHARSET=utf8;

CREATE TABLE `mmall_order` (

  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '订单id',

  `order_no` bigint(20) DEFAULT NULL COMMENT '订单号',

  `user_id` int(11) DEFAULT NULL COMMENT '用户id',

  `shipping_id` int(11) DEFAULT NULL,

  `payment` decimal(20,2) DEFAULT NULL COMMENT '实际付款金额,单位是元,保留两位小数',

  `payment_type` int(4) DEFAULT NULL COMMENT '支付类型,1-在线支付',

  `postage` int(10) DEFAULT NULL COMMENT '运费,单位是元',

  `status` int(10) DEFAULT NULL COMMENT '订单状态:0-已取消-10-未付款,20-已付款,40-已发货,50-交易成功,60-交易关闭',

  `payment_time` datetime DEFAULT NULL COMMENT '支付时间',

  `send_time` datetime DEFAULT NULL COMMENT '发货时间',

  `end_time` datetime DEFAULT NULL COMMENT '交易完成时间',

  `close_time` datetime DEFAULT NULL COMMENT '交易关闭时间',

  `create_time` datetime DEFAULT NULL COMMENT '创建时间',

  `update_time` datetime DEFAULT NULL COMMENT '更新时间',

  PRIMARY KEY (`id`),

  UNIQUE KEY `order_no_index` (`order_no`) USING BTREE

) ENGINE=InnoDB AUTO_INCREMENT=118 DEFAULT CHARSET=utf8;

CREATE TABLE `mmall_order_item` (

  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '订单子表id',

  `user_id` int(11) DEFAULT NULL,

  `order_no` bigint(20) DEFAULT NULL,

  `product_id` int(11) DEFAULT NULL COMMENT '商品id',

  `product_name` varchar(100) DEFAULT NULL COMMENT '商品名称',

  `product_image` varchar(500) DEFAULT NULL COMMENT '商品地址',

  `current_unit_price` decimal(20,2) DEFAULT NULL COMMENT '生成订单时的商品单价,单位是元,保留两位小数',

  `quantity` int(10) DEFAULT NULL COMMENT '商品数量',

  `total_price` decimal(20,2) DEFAULT NULL COMMENT '商品总价,单位是元,保留两位小数',

  `create_time` datetime DEFAULT NULL,

  `update_time` datetime DEFAULT NULL,

  PRIMARY KEY (`id`),

  KEY `order_no_index` (`order_no`) USING BTREE,

  KEY `order_no_user_id_index` (`user_id`,`order_no`) USING BTREE

) ENGINE=InnoDB AUTO_INCREMENT=135 DEFAULT CHARSET=utf8;

CREATE TABLE `mmall_cart` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `user_id` int(11) NOT NULL,

  `product_id` int(11) DEFAULT NULL COMMENT '商品id',

  `quantity` int(11) DEFAULT NULL COMMENT '数量',

  `checked` int(11) DEFAULT NULL COMMENT '是否选择,1=已勾选,0=未勾选',

  `create_time` datetime DEFAULT NULL COMMENT '创建时间',

  `update_time` datetime DEFAULT NULL COMMENT '更新时间',

  PRIMARY KEY (`id`),

  KEY `user_id_index` (`user_id`) USING BTREE

) ENGINE=InnoDB AUTO_INCREMENT=127 DEFAULT CHARSET=utf8;

CREATE TABLE `mmall_pay_info` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `user_id` int(11) DEFAULT NULL COMMENT '用户id',

  `order_no` bigint(20) DEFAULT NULL COMMENT '订单号',

  `pay_platform` int(10) DEFAULT NULL COMMENT '支付平台:1-支付宝,2-微信',

  `platform_number` varchar(200) DEFAULT NULL COMMENT '支付宝支付流水号',

  `platform_status` varchar(20) DEFAULT NULL COMMENT '支付宝支付状态',

  `create_time` datetime DEFAULT NULL COMMENT '创建时间',

  `update_time` datetime DEFAULT NULL COMMENT '更新时间',

  PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=61 DEFAULT CHARSET=utf8;

CREATE TABLE `mmall_shipping` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `user_id` int(11) DEFAULT NULL COMMENT '用户id',

  `receiver_name` varchar(20) DEFAULT NULL COMMENT '收货姓名',

  `receiver_phone` varchar(20) DEFAULT NULL COMMENT '收货固定电话',

  `receiver_mobile` varchar(20) DEFAULT NULL COMMENT '收货移动电话',

  `receiver_province` varchar(20) DEFAULT NULL COMMENT '省份',

  `receiver_city` varchar(20) DEFAULT NULL COMMENT '城市',

  `receiver_district` varchar(20) DEFAULT NULL COMMENT '区/县',

  `receiver_address` varchar(200) DEFAULT NULL COMMENT '详细地址',

  `receiver_zip` varchar(6) DEFAULT NULL COMMENT '邮编',

  `create_time` datetime DEFAULT NULL,

  `update_time` datetime DEFAULT NULL,

  PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=30 DEFAULT CHARSET=utf8;

GitHub 地址:>

以上就是关于hql 集合查询 Order(订单表)与Orderdetail(订单详情表) 类似淘宝的那种全部的内容,包括:hql 集合查询 Order(订单表)与Orderdetail(订单详情表) 类似淘宝的那种、各位大虾,K3的订单序时簿如何以ODBC数据刷新的方式导出至EXCEL谢谢 。、购物车里面有10个项目,如何批量提交到数据库保存等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9692965.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-01
下一篇 2023-05-01

发表评论

登录后才能评论

评论列表(0条)

保存