如何合理的实现用户注册信息收集

在做注册用户管理时，常见做法是，一个User对象包括了用户的所有属性，比如：用户登陆名、密码、爱好、特长、邮箱、性别、年龄、地址、电话等等信息。

结果就是这个表的字段非常多：

  create_table "users", :force => true do |t|
    t.string   "login"
    t.string   "crypted_password",          :limit => 40
    t.string   "salt",                      :limit => 40
    t.string   "remember_token"
    t.datetime "remember_token_expires_at"
    t.boolean  "is_admin"
    t.boolean  "can_send_messages",                       :default => true
    t.string   "time_zone",                               :default => "UTC"
    t.string   "email_verification"
    t.boolean  "email_verified"

    t.string   "first_name"
    t.string   "last_name"
    t.string   "website"
    t.string   "blog"
    t.string   "flickr"
    t.text     "about_me"
    t.string   "aim_name"
    t.string   "gtalk_name"
    t.string   "ichat_name"
    t.string   "icon"
    t.string   "location"
    t.string   "email"
    t.boolean  "is_active",        :default => false
    t.string   "youtube_username"
    t.string   "flickr_username"

    t.datetime "created_at"
    t.datetime "updated_at"
  end

另外一种做法是分成User和Profile两个对象，用户注册的时候只需填写简单的用户名和密码（邮箱）信息就可以完成注册，Profile信息则注册完成后，用户根据需要来填写，非强制性的，这样用户也乐意注册。同时User信息来了也方便和其它系统集成，比如要加入论坛等功能时。参考lovd-by-less的做法：

create_table "profiles", :force => true do |t|
    t.integer  "user_id"
    t.string   "first_name"
    t.string   "last_name"
    t.string   "website"
    t.string   "blog"
    t.string   "flickr"
    t.text     "about_me"
    t.string   "aim_name"
    t.string   "gtalk_name"
    t.string   "ichat_name"
    t.string   "icon"
    t.string   "location"
    t.string   "email"
    t.boolean  "is_active",        :default => false
    t.string   "youtube_username"
    t.string   "flickr_username"
    t.datetime "created_at"
    t.datetime "updated_at"
  end

  add_index "profiles", ["user_id"], :name => "index_profiles_on_user_id"

  create_table "users", :force => true do |t|
    t.string   "login"
    t.string   "crypted_password",          :limit => 40
    t.string   "salt",                      :limit => 40
    t.string   "remember_token"
    t.datetime "remember_token_expires_at"
    t.boolean  "is_admin"
    t.boolean  "can_send_messages",                       :default => true
    t.string   "time_zone",                               :default => "UTC"
    t.string   "email_verification"
    t.boolean  "email_verified"
    t.datetime "created_at"
    t.datetime "updated_at"
  end

  add_index "users", ["login"], :name => "index_users_on_login"

表结构是这样的，同时增加User Profile两个模型，在注册的时候，注册完保存用户基本信息的同时创建Profile信息，使User和Profile关联起来，这样就知道profile属于那个用户了。

class Profile < ActiveRecord::Base
  belongs_to :user
end

class User < ActiveRecord::Base
  has_one :profile, :dependent => :nullify #删除user时，将profile的user_id设置为null

  attr_accessor :email

  def before_create
    p = Profile.find_by_email @email
  end

  def after_create
    p = Profile.find_or_create_by_email @email
    raise 'User found when should be nil' unless p.user.blank?
    p.is_active=true #默认是否激活
    p.user_id = id #用户的id
    p.save
  end

end

以后，比如用户的博客、朋友、消息、相册都与Profile关联，不直接与User关联。

嗯。不错，回来试试。

感觉 标题是讲web用户体验，而 内容是讲技术实现。

对于 如何合理的实现用户注册信息收集?
我自己从来不想让用户的注册过程变得麻烦，我不会让他要填写一大堆的个人信息 才能完成注册，注册信息越简单越好，等他注册好了，可以通过可以手段来让用户去填充 个人资料信息。 关于这个，好像以前在讨论过。

把经常用到的用户字段放到一个表里面，反之放到一个表里面

同上，楼主似乎说不到点上

其实吧，我也是分析lovd-by-less得出做法，感觉这种做法很不错，就推荐在这里。

确实有一点遗憾，不过看看构造思路还是很不错的。

 

另外关于系统相关操作信息的统计，我觉得是个非常好的讨论话题，也是很多研究人员长期从事的。

google没放弃任何一个细节，才让今天的使用非常人性化。

我也在考虑后续的系统开发中多注意收集数据，在《rails recipes》里面有关于catch 404的相关讨论，这个思路可以借鉴和传承。如果在使用Catch 404的时候，会发现系统升级后的一些问题。例如当时在看到javaeye的路由配置信息时候，发现他们在做REST迁移时候对于以前url路径的保存，很大的一方面是为了和google缓存提供服务。

你注册的时候一定要把User的所有属性显示出来要用户填写么？可以只写一部分么，没必要这么麻烦做one to one association,其他个人信息可以在作个人资料的修改时候填写