个人学习笔记（部分转载）

1.锚点设计时，返回空数据时可返回1*1的gif图片，这样能保证响应速度。（谷歌和百度都采用这样方式）

2.关于sqlserver最多可以建多少表的问题：

那么一张SQL server中最多到底可以有多少张表呢，在SQL server2008 R2的官方文档中， 是这么说的

 

     Tables per database

     32bit: Limited by number of objects in a database

     64bit: Limited by number of objects in a database

 

    就是说取决于数据库中对象数的限制，那么如何解释这个对象数的限制呢？

    Database objects include objects such as tables, views, stored procedures, user-defined functions, triggers, rules, defaults, and constraints. The sum of the number of all objects in a database cannot exceed 2,147,483,647.

 

    数据库对象包含了表，视图，存储过程，自定义函数，触发器，规则，默认值，以及约束等。这个数据的总和不能超过 2,147,483,647.也就是说，所有的数据对象加在一起不能超过有符号整数的正数范围。

    由此，也就是说，数据库要支持个20多亿个数据对象，那么如果不是给每个列都设上默认值的话，要创建个几亿个表应该都说不成什么问题。所以在一般的情况下，我们也就可以理解SQL server对表的创建数量是没有限制的。

 

    另外，附一下SQL server中最大值说明的情况，msdn上写的都很清楚

    http://msdn.microsoft.com/en-us/library/ms143432.aspx

3.大量考勤数据的数据库表应该怎样设计？

方案可参考：

以下是几种常见的分表算法。

 

1.按自然时间来分表/分库;

 

如一个应用的数据在一年后数据量会达到200w左右，那么我们就可以考虑用一年的数据来做为一个表或者库来存储，例如，表名为app，那么2010年的数据就是app_2010，app_2011;如果数据量在一个月就达到了200w左右，那么我们就可以用月份来分，app_2010_01，app_2010_02.

 

2.按数字类型hash分表/分库;

 

如果我们要存储用户的信息，我们应用的注册量很大，我们用单表是不能满足存储需求的，那么我们就可以用用户的编号来进行hash，常见的是用取余操作，如果我们要分30张表来存储用户的信息，那么用户编号为1的用户1%30=1，那么我们就存在user_01表里，如用户的编号为500，那么500%30=20，那么我们就将此用户的信息存储在user_20的表里.

 

3.按md5值来分表/分库;

 

我们假设要存储用户上传的文件，如果上传量大的话，也会带来系统的瓶颈问题，我们做过试验，在一个文件夹下如果超过200个文件的话，文件的浏览效率会降低，当然，这个不属于我们本文讨论的范围，这块也要做散列操作.我们可以用文件的用户名来md5或者用文件的md5校验值来做，我们就可以用md5的前5位来做hash，这样最多我们就可以得到5^5=3125个表，每次在存储文件的时候，就可以用文件名的md5值的前5位来确定这个文件该存那张表.

 

4.实例:某微博的url加密算法和存储策略的猜想.

 

现在好多微博都用这样的url来访问，如果他们的域名为www.example.com，那么如果你发微博的时候，你会发现你所发的url都变成了http://t.cn/Mx4ja1，这样的形式，他们是怎么进行这样的转换呢?我猜想就是用到了我们上面讲的md5的存储和查找规则，用你发的url来进行md5，得到md5值之后，如我们例子来说，就会用前6位来进行分表.

 

5.分表所带来的问题.

 

分表也会带来一系列的问题，如分页的实现，统计的实现，如果我们要做一个所有数据的分页，那么我们得每张表都得遍历一遍，这样访问效率会很低下.之前我尝试过用mysql的代理来实现，最终用tcsql来实现了.

 

6.分表算法的选择.

 

首先，分表适合于没有大的列表的应用来使用，要不然，会为这部分做好多额外的工作，如果你的应用数据量不是特别大的话，最好别用分表。

 

7.针对每秒插入数据500+的设想

 

  为什么要copy这个呢，因为很多数据库在数据上千万级别后，每秒插入数据的数度不是很快了，所以500/秒的速度够呛，解决方案设想：

 建立数据总表及两个缓冲表，结构完全相同，将数据先插入其中一个缓冲表中，等到一定时间(插入效率降低之前)，转向插入另一个缓冲表，同时启动一个后台进程将第
一个缓冲表的的数据转入总表，转入总表后删除第一个缓冲表中的数据; 再等到一定时间(还是插入效率降低之前)，转向插入第一个缓冲表，这时启动一个后台进程将第
二个缓冲表的的数据转入总表，转入总表后删除第二个缓冲表中的数据; 如此循环往复...

如果后台进程处理的时间超过两个缓冲表的循环周期的话，甚至可以考虑建立三个乃至四个缓冲表。

这仅仅是解决插入效率，查询什么的问题也大。

个人想法：

考勤数据因为和时间相关，可以使用按自然时间来分表/分库。

某个时间以前的数据可以系统自动将其整合，减少资源的耗费。