再往 后，取名不用担心了。什么翻康熙字典？不允许
你凭什么翻呀？想反清复明？做梦吧你。
国家有规定，取名有规范，不得取变态名，不得取超长名，象赵C这样的，你敢取？我不给你登记 。
为啥？
看这里：http://news.southcn.com/china/zgkx/content/2009-04/11/content_5057672.htm
我简单摘要一下：
XML/HTML代码
- 两千姓氏用字属生造乱编
-
- 姓名用字则有4000个错字别字，以后取名将被规范
-
- 《规范汉字表》对百姓生活有何影响？
-
- 李宇明表示，《规范汉字表》出台后，中小学教材常用字范围等方面可能面临变化，今后会有专门的相应通知下发。
-
- 王宁则特别谈到，新生儿取名更要强调用字规范。她表示，人名用字也是社会用字的一部分，必须要符合汉字使用的规范，这样才是真正的保障姓名权。
-
- 王宁说，中国人的重名现象绝不是因为能够用来取名的字太少，许多给人留下深刻印象的好名字都是从古典诗词、典籍中化用而来，但即使是这些古籍，用字量也非常有限———过去的童蒙识字课本，不重复的字也才2320个；十三经（在南宋形成的十三部儒家经典，包括《诗经》、《周易》、《论语》、《尔雅》、《孟子》等）不重复的字不到6000个；《全宋诗》收录了18401首诗，才用了4520个汉字。而今天的规范汉字达到8000多个，可以有无数种组合，还不够起名吗？
-
- 但据公安部门透露，在此次换领二代身份证的过程中，使用目前通行的收字7.6万个的汉字国际编码，全国人口的姓名用字中竟还有大概8000个字找不到！而据专家研究，这约8000个字中，至少有一半是错字、别字。
-
- 此外，目前我国公民的姓氏用字大概有7600余字，但其中竟有2000个字所代表的姓只有一个人在使用！也就是说，这些姓几乎都是生造或胡乱编出来，而并非历史传承的。这些现象都表明，规范姓名用字是多么迫在眉睫。
-
- 王宁表示，用一个多数人不认识、基本没人用的生僻字起名，既不利于社会又不利于自己，这又何苦？
架构这个东西，不能一味的盲目抄袭，因为每种新架构的出现往往都有其特定的历史背景，要么是数据访问量太大、要么（想写的一些内容因为存储关系丢失了，一下子又没有想起来，下面是重写的，但内容已经和原来想的不太一样了）
高春辉就在他的勃客里认为，主从数据库不行了，未来的数据存储走向应该不会再是主从，他这么说：
还是有关DAL：http://www.paulgao.com.cn/index.php?itemid=141
- 这里可以先提前说一下吧，记得之前的迁移网站时的帖子里我说过，让 MYSQL 主从架构去死，很多人不太信。
-
- 而现在这个 DAL 的架子越来越清楚，我相信是可以达到99%的可能性，可以使主从架构从最大的用途是读写分离，变成了数据备份。其实我到现在也不知道 MySQL 当时推主从架构是为了读写分离还是数据备份。：D
-
- 我认为不管是主从还是主主结构都有一个最大的问题，主库和从库的数据的延迟更新问题，主主方式会好一些，但是配置起来太麻烦了。尤其是要求越高，就会越感觉到严重性。
-
- 而从程序员的角度，对于数据库的操作，最大的问题就是要把缓存的逻辑和数据逻辑混写，导致代码很难写也很难读，也很难调试清楚。
-
- 那么 DAL 如果能够帮助程序不用再关心缓存逻辑，只关心业务逻辑的话，不知道您是否认同 DAL 的重大作用呢？而代码量在我认为，起码可以减少个20%-30%吧？因为起码去掉了三个逻辑：读取缓存、判断有效和设置缓存。
-
- 我也觉得其实这个 DAL 的最核心功能就是如何自动缓存和清理缓存了。因为不让程序员缓存和清理，就的是程序自己来管理缓存和清理缓存，总得清理嘛。不过这个还是保密一下吧。起码不是某些人想的只能缓存单条数据，也不是某些人想的清理是按照单条方式的清理。当然另外的一个核心功能就是分库分表的自动和透明化，这个功能有很多软件都实现了，就不多说了。
文末，他推荐了一篇InfoQ上的文章，在这里我也进行转载一下，是关于FriendFeed实现基于MySQL的无模式存储，不过他这种架构也不是能拿来就要用的，也需要根据目前的实际情况，只能进行参考。这是一篇翻译文章：
作者 Dave West译者 王丽娟 发布于 2009年4月4日 下午8时7分
对于迅速增长的网站所遇到的问题——“用灵活的模式存储数据、即时创建新的索引”，FriendFeed的Bret Taylor介绍了一种“无模式的解决方案” 。问题本身源自一些需求：需要不断增加新功能，不断更新底层的数据库结构和数据库中存储的数百万条已有记录，还要同时支持新旧功能。FriendFeed的办法是基于MySQL建立一个无模式的解决方案，而不是迁移到别的技术基础上去。Bret描述了基本问题：
尤其是有一两千万行数据的时候，每次修改模式、往数据库中添加索引都会数小时完全锁定数据库。删除旧索引也需要同样长的时间，但不删除又会影响性能，因为 数据库在每次执行INSERT操作时都会继续读写这些不用的块，而重要的块却没有足够的内存。经过一些复杂的操作过程可以克服以上困难（比如在从机上创建 新索引，然后调换从机和主机），但这些操作过程都很容易出错，也都是重量级的，因此会使我们因为害怕改变模式/索引而不敢增加新功能。由于我们的数据库都 是严重分片的，像JOIN这些MySQL的关系型功能对我们毫无用处，所以我们决定看看RDBMS之外的领域。
研究了几个可行的解决方案后，他们决定基于MySQL的自定义一种“无模式”持久化方案，而不是彻底改换门庭。
他们的解决方案是把主要数据和这些数据的索引分离开来。“我们的数据存储储存了无模式的属性包……我们在单独的MySQL表中存储索引，从而在这些实体中索引数据。”这是以容量来换效率。
结果我们比以前多了很多的表，但添加和删除索引却很容易。我们大力优化了填充新索引的进程（我们称之为“Cleaner”），以便该进程能快速填充新索引，而不会让站点中断。
分离数据和索引引起了一致性和原子性问题。他们没有建立严格的事务规则，而是把数据库表推到最简，索引只用来引用，发生实际的数据库读操作的时候才 施加数据过滤。他们改进了持续更新表的自动化进程，让这个“Cleaner”进程不停地对优先级高的被更新实体进行更新和索引修正。尽管可能出现不一致， 但消除不一致的时间平均不到两秒钟。
Bret用平均页面延迟这一指标描述了以下走向。
- 整体来说——尽管有增加的趋势，但还是有显著的减少。
- 过去二十四小时——即使在高峰时段也保持稳定。
- 前一周——明显减少。
Bret的帖子有很多回复。有一种观点认为“对于模式演变，现代的RDBMS不像MySQL局限那么大”，这种观点忽略了选择背后的成本问题。其它读者则回复了更多种不同的解决办法。
有意思的是，并没有人指出FriendFeed的解决方案与古老的ISAM技术（Indexed Sequential Access Method，索引顺序存取法）之间的相似性。ISAM用的是同样的基本架构——分离数据和索引，同时在数据发生变化时自动更新索引。
查看英文原文：FriendFeed Implements Schema-less Storage Atop MySQL
