看你需要实现什么功能才决定需要多少张表啊,最基本的:商品分类表,商品列表,管理员表,用户信息表,订单表,关于我们等等,复杂一点还要加上seo表,友情链接表,新闻资讯表,广告图表,留言表,数据统计表等
SQL SERVRE 2000 测试通过
CREATE DATABASE shop
GO
use shop
/ 用户信息 /
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMATABLES
WHERE TABLE_NAME = 'UserInfo_table')
DROP TABLE UserInfo_table
GO
CREATE TABLE UserInfo_table
(
userId smallint /用户编号/
IDENTITY(1,1),
loginName varchar(20) not null, /登陆名称/
userName varchar(20) not null, /用户名称/
userPwd varchar(10) not null, /用户密码/
userType varchar(20) not null, /用户类型/
userSex varchar(2), /用户性别/
userPhone varchar(20), /用户电话/
userEmail varchar(40), /用户邮件/
userAddress varchar(200), /用户地址/
userZip varchar(10), /用户邮编/
createTime datetime default getdate(), /注册时间/
updateTime datetime, /更新时间/
userStatus varchar(4) not null, /用户状态/
userLevel int, /用户级别/
constraint pk_userinfo primary key(userId)
)
/ 系统代码表 /
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMATABLES
WHERE TABLE_NAME = 'CommonCode_table')
DROP TABLE CommonCode_table
GO
CREATE TABLE CommonCode_table
(
codeType varchar(20) not null, /代码类型/
codeName varchar(20) not null, /代码名称/
codeValue varchar(100) not null, /代码值/
constraint pk_commoncode primary key(codeType, codeName)
)
/ 菜单信息 /
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMATABLES
WHERE TABLE_NAME = 'MenuShop_table')
DROP TABLE MenuShop_table
GO
CREATE TABLE MenuShop_table
(
menuId varchar(50) not null,
menuName varchar(50),
menuImg varchar(50),
menuSelImg varchar(50),
menuAction varchar(50),
menuLevel smallint not null,
parentMenuId varchar(50),
menuLine smallint not null,
isUserMenu bit not null,
constraint pk_menushop primary key(menuId)
)
/ 用户订单 /
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMATABLES
WHERE TABLE_NAME = 'UserOrder_table')
DROP TABLE UserOrder_table
GO
CREATE TABLE UserOrder_table
(
orderId varchar(50) not null, /订单号/
userId smallint not null, /订购人ID/
orderTime datetime not null, /订单产生日期/
orderStatus char(2) not null, /订单是否确认,0/1/
orderPassTime datetime, /确认时间/
orderPassId smallint, /订单处理人/
orderSendState char(2), /订单发送状态/
orderRecName varchar(20), /订单接收人姓名/
orderRecMail varchar(20),
orderRecAddress varchar(200), /订单接收地址/
orderRecZip varchar(10), /订单接受地址邮编/
orderTotalPrice decimal(10,2), /订单总价/
lineIndexNext int,
constraint pk_userorder primary key(orderId)
)
/ 订单中项目信息 /
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMATABLES
WHERE TABLE_NAME = 'LineItem_table')
DROP TABLE LineItem_table
GO
CREATE TABLE LineItem_table
(
orderId varchar(50) not null, /订单号/
lineIndex int not null, /订单索引/
itemId varchar(50) not null,
productId int not null, /产品ID/
quantity int not null, /订单项数量/
unitPrice decimal(10, 2) not null, /该订单项的价格/
orderStatus int not null,
constraint pk_lineitem primary key(orderId, lineIndex)
)
/ 商品类别信息 /
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMATABLES
WHERE TABLE_NAME = 'ProductCategory_table')
DROP TABLE ProductCategory_table
GO
CREATE TABLE ProductCategory_table
(
catId int
IDENTITY(1,1), /类别编号/
catName varchar(100) not null, /类别名称/
parentId int, /父级类别ID/
catHaveChild varchar(2) not null, /是否有子类别Y/N/
sort int not null, /排序标志/
inputdate datetime default getdate(), /建立时间/
isValid varchar(2), /此类别是否有效/
decs varchar(255), /说明/
constraint pk_productcategory primary key(catId)
)
/ 产品信息 /
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMATABLES
WHERE TABLE_NAME = 'ProductInfo_table')
DROP TABLE ProductInfo_table
GO
CREATE TABLE ProductInfo_table
(
productId int
IDENTITY(1,1), /编号/
catId int not null, /类别ID/
productName varchar(100), /物品名称/
productContent varchar(4000),
productDesc varchar(1000), /物品简介/
isPrompt bit default 0, /是否优惠/
registerTime datetime default getdate(), /上架日期/
listPrice decimal(10, 2), /物品价格/
unitPrice decimal(10, 2), /会员价格/
orderDesc varchar(1000), /订购说明/
productImgUrl varchar(200), /物品/
sort int, /排序标记/
productCount int, /库存量/
isValid bit not null,
constraint pk_productInfo primary key(productId),
constraint fk_product foreign key(catId)
references ProductCategory_table(catId)
)
/ /
create index ProductCategory on ProductInfo_table(catId);
create index ProdcutName on ProductInfo_table(productName);
/ 公告信息 /
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMATABLES
WHERE TABLE_NAME = 'BulletinInfo_table')
DROP TABLE BulletinInfo_table
GO
CREATE TABLE BulletinInfo_table
(
bulletinId int
IDENTITY(1,1), /编号/
bulletinTitle varchar(100) not null, /公告板标题/
bulletinBody varchar(4000), /公告板内容/
inputDate datetime default getdate(), /添加日期/
updateDate datetime, /更新日期/
inputUserId smallint, /添加管理员ID/
bulletinPoint int, /浏览量/
bulletinSort int, /排序标记/
isValid char(2) default 1, /是否有效/
constraint pk_bulletinInfo primary key(bulletinId)
)
/ 公告信息 /
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMATABLES
WHERE TABLE_NAME = 'ItemInfo_table')
DROP TABLE ItemInfo_table
GO
CREATE TABLE ItemInfo_table
(
itemId varchar(50), /项目ID/
productId int not null, /项目产品ID/
quantity int not null,
listPrice decimal(10,2), /物品价格/
unitPrice decimal(10,2), /会员价格/
status varchar(2), /更新日期/
constraint pk_iteminfo primary key(itemId)
)
/ /
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMATABLES
WHERE TABLE_NAME = 'Serial_Number')
DROP TABLE Serial_Number
GO
CREATE TABLE Serial_Number
(
serialId varchar(50) not null,
SerialNumber int,
constraint pk_SerialNumber primary key(serialId)
)
(狭义)大数据是指无法使用传统流程或工具在合理的时间和成本内处理或分析的信息,这些信息将用来帮助企业更智慧地经营和决策。而广义的大数据更是指企业需要处理的海量数据,包括传统数据以及狭义的大数据。(广义)大数据可以分为五个类型:Web 和社交媒体数据、机器对机器(M2M)数据、海量交易数据、生物计量学数据和人工生成的数据。
Web 和社交媒体数据:比如各种微博、博客、社交网站、购物网站中的数据和内容。
M2M 数据:也就是机器对机器的数据,比如 RFID 数据、GPS 数据、智能仪表、监控记录数据以及其他各种传感器、监控器的数据。
海量交易数据:是各种海量的交易记录以及交易相关的半结构化和非结构化数据,比如电信行业的 CDR、3G 上网记录等,金融行业的网上交易记录、core banking 记录、理财记录等,保险行业的各种理赔等。
生物计量学数据:是指和人体识别相关的生物识别信息,如指纹、DNA、虹膜、视网膜、人脸、声音模式、笔迹等。
人工生成的数据:比如各种调查问卷、电子邮件、纸质文件、扫描件、录音和电子病历等。
在各行各业中,随处可见因数量、速度、种类和准确性结合带来的大数据问题,为了更好地利用大数据,大数据治理逐渐提上日程。在传统系统中,数据需要先存储到关系型数据库/数据仓库后再进行各种查询和分析,这些数据我们称之为静态数据。而在大数据时代,除了静态数据以外,还有很多数据对实时性要求非常高,需要在采集数据时就进行相应的处理,处理结果存入到关系型数据库/数据仓库、MPP 数据库、Hadoop 平台、各种 NoSQL 数据库等,这些数据我们称之为动态数据。比如高铁机车的关键零部件上装有成百上千的传感器,每时每刻都在生成设备状态信息,企业需要实时收集这些数据并进行分析,当发现设备可能出现问题时及时告警。再比如在电信行业,基于用户通信行为的精准营销、位置营销等,都会实时的采集用户数据并根据业务模型进行相应的营销活动。
大数据治理的核心是为业务提供持续的、可度量的价值。大数据治理人员需要定期与企业高层管理人员进行沟通,保证大数据治理计划可以持续获得支持和帮助。相信随着时间的推移,大数据将成为主流,企业可以从海量的数据中获得更多的价值,而大数据治理的范围和严格程度也将逐步上升。
序列,站点名,站点连接,显示LOGO
基本上也就这几个,如果有特殊需要可以增加其他的段。
反正就算你现在只用四个段,但将来使用中如果感觉少了还是可以增加的,所以也不必太在意现在使用几个段。
对于第一个问题,设计一个schema->(messageID,likedCount),记录每条微博的点赞数。messageID是微博的编号,likedCount是该微博的点赞人数。但是这里有两个问题需要解决,第一是并发,第二是数据量。
每条微博都有可能有很多人同时点赞,为了保证点赞人数精确就需要保证likedCount++是原子 *** 作,这个可以由应用程序来实现,也可以用redis的事务来实现(如果redis有事务机制或者自增功能的话),但是我觉得为了性能考虑,也可以不用实现原子 *** 作,具体原因就不展开了。
每天都上亿可能更多的微博内容产生,这样就会有上亿个新的(messageID,likedCount)生成,这样的数据量是比较大的,单机数据库比较难提供高效的服务,所以需要采取sharding的功能(有时候也叫分表分库),可能根据messageID把这些schema分散到十个或者更多的shards上(据说,sina微博有600个节点,如何三个节点组成一个shard,就有200个shards),这样每个shard处理的请求就只有原来的十分之一,从而就能提高服务的性能。
关于点赞人列表的设计,一般来说,可能想到的schema是(messageID,userID),但是这样的设计有一个小问题,就是有些大发的微博可能会得到几十万的点赞,这样就会产生几十万个条数据,这样数据有点多,读取起来可能也慢。所以可以用这样一个schema(messageID,partID,userIDs),让一个messageID对于多个userID,同时比对应太多的userID,所以加入一个新的partID,一个part存1000个userID,这样几十万个点赞,只需要存几百条数据。这样做还有一个好处,用户点赞人时的,一般都不是完全显示所有点赞人,而是一批一批显示,这样可以一次只读一条数据,就可显示一批点赞用户信息。
以上就是关于做一个简单的商城网站,数据库里面大约需要做几张表比较适合,希望有前辈可以赐教下!全部的内容,包括:做一个简单的商城网站,数据库里面大约需要做几张表比较适合,希望有前辈可以赐教下!、建立购物网站数据库 需要哪些表和字段 越详细越好、属于web和社交媒体的数据等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)