好友列表数据库设计

3种解决方法，也谈谈这三种的弊端吧！

方法：

一.每创建一个用户.自动创建一个该用户的好友用户表.每一行的记录是一个好友记录.

二.做一个Frient的表,表中有两列,第一列UID是用户ID,第二列FID是对应该用户的好友

三,在用户信息的表中,有一个字段10000长度的varchar 里边用','号分割各个好友的ID

弊端：

一：只适合少量的用户论坛，如果有100万个注册用户，就得有100万张好友表，这样当用户一多，数据库会很大！

二：这种方法是给用户注册表创建一张好友关联表，这样或许是这三种方法中最好的方式了吧，但是注意记得要添加索引，不然查询起来，数据一多，会非常慢；

三、这样在程序方面会比较麻烦，先取出来，后添加数据，再update，感觉速度会上不来...........

使用现有的主要吸引力一、可扩展的NoSQL数据库

如果您的整个 _active set_ 适合单个机器的主内存（现代商品机器可以高达 128GB +），那么您就没有水平可扩展性问题：即，您绝对没有理由进行分区（“分片") ) 你的数据库和放弃关系。如果您的活动数据集适合内存，那么任何带有索引的适当调整的数据库都将表现得足够好，可以在数据库本身成为限制之前使您的以太网卡饱和。

如果您认为关系模型本身并不合适，您可以轻松地在 MySQL 之上构建一个“面向文档的存储”：这就是 Friendfeed 最终要做的，我会遵循他们的模型（除非我使用 Avro （软件）、Apache Thrift 或 Google Protocol Buffers 而不是特定于语言的序列化）-

http://bret.appspot.com/entry/how-friendfeed-uses-mysql

如果您的站点变得非常成功，您将拥有一个不再适合您机器的主内存的活动集。在这种情况下，设计不当的存储引擎的性能会迅速下降。但是，MySQL 的 InnoDB（或 Postgres 的存储引擎）仍然允许您使用旋转磁盘保持（取决于您的请求分布）大约 2:1-5:1 的数据与内存比率。一旦超出这个范围，性能就会开始迅速下降（因为您要为每个请求进行多次磁盘搜索）。现在，您最好的做法是升级到 SSD（固态驱动器），这再次允许您在数据库成为限制之前使以太网卡饱和。

最后，当您遇到不适合的数据集大小时，例如，软件 raid 1 + 0 配置中的多个 SSD（同时为备份、多个版本的数据等提供空间...），那么您必须水平缩放。也就是说，您必须使用本质上支持分区的数据库（例如 Riak、Voldemort、Cassandra、HBase），或者在基于 MySQL/Postgres 的数据存储之上构建应用程序级分区层。我无法告诉您哪种解决方案是正确的，因为我（或您）都不知道您的数据及其访问模式在那时会是什么样子。也就是说，编写自己的分片层是您可以在代码中引入额外错误的另一个地方：不必构建自己的分布式数据库（您通过构建分片层有效地做的事情）是使用现有的主要吸引力一、可扩展的NoSQL数据

---