随笔分类 -  数据库相关

摘要:最近真是忙翻天了,该是有三个月没写博客了博客目录:Index & Writing Plan这次的需求是在Mongo的使用中碰到的,但是我觉得把这个需求放进传统的RDBMS中更易于理解。需求是这样的:假设你数据库使用的是Sqlserver,有一张表,500W条数据,你要做一个随机在表中选择一条数据的功能假设本文所探讨的数据结构如图(聚集索引在Pk上,UserName上加了非聚集索引):你的第一反应大概是:哎呀妈呀忒巧了,正好主键使用的是Int自增的,我只用生成一个随机数,然后找这个随机数对应的主键就好了实现的步骤大概是:①返回数据库中ID的最大值IdMax ②生成1到IdMax中间一个的 阅读全文
posted @ 2013-03-19 12:00 CrazyJinn 阅读(3775) 评论(56) 推荐(4) 编辑
摘要:其实我一直在准备另一篇博文的基础资料,但是和朋友聊天,他问我最近在做什么,我说在做系统Log模块,并和他交流了一下,于是这篇博客就应运而生我的博客目录:Index & Writing Plan所有数据都可以用如下形式表述:ID,表名,列名,Value比如说现在有这么一条数据要插入User表:ID(Guid,这里为了方便理解用Int)UsernamePasswordEmail1CrazyJinn123456CrazyJinn@W.C这一条记录可以转换为:ID表名列名Value1UserUsernameCrazyJinn1UserPassword1234561UserEmailCrazyJ 阅读全文
posted @ 2012-12-04 13:57 CrazyJinn 阅读(7014) 评论(46) 推荐(11) 编辑
摘要:上篇博客《我们该如何设计数据库(三)》写出来之后,深感自己写得不够清晰,虎头蛇尾,描述问题用了很多篇幅,而问题的解决方案及其优缺点却是一笔带过,于是就写下了这篇博客来负荆请罪示例代码下载:点击这里下载示例代码说明见下文首先让我们来回顾一下《我们该如何设计数据库(三)》中描述的问题:现在有一个系统,我们暂时假设为学校选课系统。系统要按学校来卖。每个学校的选课逻辑都是一样的,而表中的数据有共性,但是也有差异性。比如说基本的Teacher表结构是这样的:现在把系统卖给A学校。A学校除了的Teacher表除了用户名和密码之外,还要储存老师的FirstName和LastName,那么表结构变化如下:现在 阅读全文
posted @ 2012-10-10 11:00 CrazyJinn 阅读(4118) 评论(18) 推荐(6) 编辑
摘要:首先是一些废话:前文链接:我们该如何设计数据库(一)我们该如何设计数据库(二)在《我们该如何设计数据库(二)》中,园友Jacklondon Chen提出了一些问题,大致如下:“man/woman应该设计在同一张表中。用户表大多都设计成一个表。连分 administrator 和 user 都不应该。”我想还是因为我举例太随意,因为博文中Man和Woman只有4个差异属性:HasCar\HasHouse\HasMoney,以及IsBeauty其实对于这个问题我无力吐槽什么,简单的说说吧:假设为Man用户实现的是一个征婚系统,而Woman用户实现的是一个选美系统。这么说应该能理解Man和Woman 阅读全文
posted @ 2012-09-25 11:37 CrazyJinn 阅读(6407) 评论(54) 推荐(6) 编辑
摘要:最近公司要开发新系统,基本决定使用ORM(高层还在犹豫,担心效率问题)。既然使用了ORM,那么自然而然的就想到了用面向对象的思想来设计数据库本篇文章旨在讨论如何抽象(以用户作为抽象的例子),并提出一些解耦的思路我也是第一次在实际项目中使用面向对象的思想来设计数据库,写下这篇博客,也是希望与大家多多交流正文开始首先来需求分析我们的系统有前台和后台,前台用户有:Man,Woman,SuperMan,SpiderMan与IronMan。后台用户为Administrator前台用户都要填写联系方式与地址,然后SuperMan,SpiderMan与IronMan都有Ability需求很简单。那么按照这个 阅读全文
posted @ 2012-08-20 10:46 CrazyJinn 阅读(7215) 评论(75) 推荐(4) 编辑
摘要:数据库该如何设计,一直以来都是一个仁者见仁智者见智的问题。对于某一种数据库设计,并不能简单的用好与不好来区分。或许真的应了那句话,没有最好,只有最适合。讨论某种数据库设计的时候,应该在某种特定的需求环境下讨论。下面来讨论一下在项目中经常碰到的用户的联系方式储存的问题。我在这里套用之前网络上流行“普通——文艺——二逼”的分类方式来描述我下文中提及的三种数据库设计思路,并且通过查询数据(对数据增删改,三种设计要付出的代码成本都差不多)和数据库面临需求变动两个方面来思考这三种设计各有怎样的优劣。普通青年:或许我们都这样设计过数据库学生表 tb_Student:Namevarchar(100)名字Te 阅读全文
posted @ 2012-04-27 15:24 CrazyJinn 阅读(22907) 评论(80) 推荐(31) 编辑
摘要:之前写了一篇文章:关于SQL函数效率的一些测试与思考,在当中提到了将数据库中一对多关系转换为一对一关系显示的两种方法:第一种方法是在数据库中写一个函数,第二种方法为在程序中获取表Class与表Student所有数据,然后对比ClassID。那么除了这两种方法,还有没有更快、更好的方法呢?在这里我再介绍两种方法与大家分享、讨论闲话不多说,下面进入正文。还是那两张表Student:IDStuNameClassID1张三12张三23李四14王五25王五1Class:IDClassName1数学2语文3英语 想要获得的数据效果为IDClassNameStuName1数学张三,李四,王五2语文张三,王. 阅读全文
posted @ 2012-03-24 11:29 CrazyJinn 阅读(3139) 评论(14) 推荐(7) 编辑
摘要:在项目中我们经常能遇到数据库有“一对多”的关系,比如下面两张表:Student:IDStuNameClassID1张三12张三23李四14王五25王五1Class:IDClassName1数学2语文3英语Class-Student就这样构成了一个简单的一对多关系。当然在实际的项目中,也可以再建立一张Relation表来保存他们之间的关系,在这里为了简单,就不做Relation表了。现在在项目中,我需要将Class表中的数据list显示,当然也想显示选择了这门课的Student的StuName。也可以说是将一对多关系转换为一对一关系。我所期望的显示格式是这样的:IDClassNameStuNam 阅读全文
posted @ 2012-02-25 14:43 CrazyJinn 阅读(3850) 评论(22) 推荐(15) 编辑