设为首页 加入收藏

TOP

11招教你如何玩转数据库设计 (11 Important Database designing rules)(三)
2012-04-13 14:36:15 来源:c-sharpcorner 作者:Shivprasad 【 】 浏览:43262次 评论:0


Rule 1:- What is the Nature of the application(OLTP or OLAP)?

When you start your database design the first thing to analyze is what is the natureof theapplication you are designing for, is it Transactional or Analytical. You will find many developers by default applying normalization rules without thinking about the nature of the application and then later getting in to performance and customization issues. As said there are 2 kinds of applications transaction based and analytical based,let's understand what these types are.

Transactional: - In this kind of application your end user is more interested in CRUD i.e. Creating, reading, updating and deleting records. The official name for such kind of database is called as OLTP.

Analytical: -In these kinds of applications your end user is more interested in Analysis, reporting, forecasting etc. These kinds of databases have less number of inserts and updates. The main intention here is to fetch and analyze data as fast as possible. The official name for such kind of databases is OLAP.

a2.jpg

So in other words if you think insert, updates and deletes are more prominent then go for normalized table design or else create a flat denormalized database structure.

Below is a simple diagram which shows how the names and address in the left hand side is a simple normalized table and by applying denormalized structure how we have created a flat table structure.

a3.jpg

Rule 1:弄清(OLTPOLAP)应用的本质是什么?

当开始制作数据表单设计时,首先,要分析你设计的这个程序的本质是什么?是事务性还是分析性的?你会发现许多开发者会默认应用常规化规则,随后才考虑性能问题而不考虑应用的本质。

关于事务性和分析性,一起来看下两者区别。

Transactional:这种应用,用户对CRUD较为感兴趣,即创建、读取、更新和删除记录。这种数据,官方名称之位OLTP。

Analytical:用户对分析、报告、预测等方面感兴趣。这类数据库很少有嵌入和更新。主要目的是为了尽快获取和分析数据。官方名称之为OLAP

Rule 2:- Break your data in to logical pieces, make life simpler

This rule is actually the 1st rule from 1st normal formal. One of the signs of violation of this rule is if your queries are using too many string parsing functions like substring, charindexetc , probably this rule needs to be applied.

For instance you can see the below table which has student names , if you ever want to query student name who is having "Koirala" and not "Harisingh" , you can imagine what kind of query you can end up with.

So the better approach would be to break this field in to further logical pieces so that we can write clean and optimal queries.

a4.jpg


Rule 2:将数据按照逻辑思维分成不同的块,让生活更简单

这个规则其实就是 “三范式” 中的第一范式。这样设计的目标,是为了当你需要查询套多的字符串解析功能时,如子串,charindexetc,它能为你提供这项功能。

例如,注意观看下面的图表,如果你想查询某个学生的姓名,通过“Koirala”和“Harisingh”来进行区分。

因此,更好的方法就是打破数据逻辑思维,以便我们编写更加简洁、容易查询的表单。

Rule 3:- Do not get overdosed with rule 2

Developers are cute creatures. If you tell them this is the way, they keep doing it; well they overdo it leading to unwanted consequences. This also applies to rule 2 which we just talked above. When you think about decomposing, give a pause and ask yourself is it needed. As said the decomposition should be logical.

For instance you can see the phone number field; it's rare that you will operate on ISD codes of phone number separately(Until your application demands it). So it would be wise decision to just leave it as it can lead to more complications.

Rule 3:当数据太多时,rule 2不可用

开发者们的思维有时很单一,如果你告诉他们某种方式,他们会一直这么做下去,要知道过度的使用会造成不必要的麻烦。正如我们之前谈到的rule 2,首先要进行分解,明确自己的需求。例如,当你看到电话号码字段时,你可以在ISD代码上进行操作区分这些电话号码(直到满足你的需求)。尽管这是不错的方法,但会给你带来更多的并发症。

a5.jpg

 

Tags:数据库 设计 责任编辑:admin
首页 上一页 1 2 3 4 5 6 7 下一页 尾页 3/10/10
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇索引的原理及索引建立的注意事项 下一篇最新翻译书籍《SQL语言详解》出版

最新文章

热门文章

推荐文章

相关文章