我实际上是 Ruby 和 Rails 框架的初学者，这就是为什么我决定在做一些违反框架约定的事情之前寻求帮助的原因。
我有相当扎实的OO编程背景，而且我对初学者->中级 SQL 查询非常熟悉。但是，我一直无法ActiveRecord理解 Rails 提供的类。我的直觉是完全放弃 ActiveRecord 类，并手动编写我自己的 SQL 查询并将它们包装在模型中。然而，我知道 ActiveRecords 是 Rails 框架中相当重要的一部分，避免它们只会让我在未来感到痛苦。
以下是我的MySQL模式（我稍后会写Rails Migration）。我会尽量让这个问题保持简洁，但我可能需要介绍一些背景知识来解释我为什么要像我一样对模式进行建模。我并没有过分依赖它，所以如果人们对结构有更好的想法，那就太好了。
-- Users table is a minimalized version of what it probably will be, but contains all pertinent information
CREATE TABLE IF NOT EXISTS users (
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(20) UNIQUE NOT NULL
) Engine=InnoDB;
CREATE TABLE IF NOT EXISTS hashtags (
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
tag VARCHAR(30) UNIQUE NOT NULL
) Engine=InnoDB;
CREATE TABLE IF NOT EXISTS content_mentions (
content_id INT UNSIGNED NOT NULL,
user_id INT UNSIGNED NOT NULL,
INDEX(content_id),
FOREIGN KEY(user_id) REFERENCES users(id) ON DELETE CASCADE
) Engine=InnoDB;
CREATE TABLE IF NOT EXISTS content_hashtags (
content_id INT UNSIGNED NOT NULL,
hashtag_id INT UNSIGNED NOT NULL,
INDEX(content_id),
FOREIGN KEY(hashtag_id) REFERENCES hashtags(id) ON DELETE CASCADE
) Engine=InnoDB;
CREATE TABLE IF NOT EXISTS content_comments (
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
user_id INT UNSIGNED NOT NULL,
content_id INT UNSIGNED NOT NULL,
text_body VARCHAR(1000) NOT NULL,
date_created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY(user_id) REFERENCES users(id) ON DELETE CASCADE,
INDEX(content_id)
) Engine=InnoDB;
CREATE TABLE IF NOT EXISTS polls (
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
user_id INT UNSIGNED NOT NULL,
question VARCHAR(100) NOT NULL,
text_body VARCHAR(1000) NOT NULL,
date_created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY(user_id) REFERENCES users(id) ON DELETE CASCADE
) Engine=InnoDB;
CREATE TABLE IF NOT EXISTS poll_options (
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
poll_id INT UNSIGNED NOT NULL,
content VARCHAR(150) NOT NULL,
active VARCHAR(1) NOT NULL DEFAULT 'Y',
FOREIGN KEY(poll_id) REFERENCES polls(id) ON DELETE CASCADE
) Engine=InnoDB;
CREATE TABLE IF NOT EXISTS poll_answers (
poll_option_id INT UNSIGNED NOT NULL,
user_id INT UNSIGNED NOT NULL,
FOREIGN KEY(poll_option_id) REFERENCES poll_options(id) ON DELETE CASCADE,
FOREIGN KEY(user_id) REFERENCES users(id) ON DELETE CASCADE,
PRIMARY KEY(poll_option_id,user_id)
) Engine=InnoDB;
正如架构所示，这是一个非常基本的网络投票应用程序。每个投票都有多个选项，每个选项可以有不同用户的多个答案。现在，奇怪的部分可能是content_*桌子。我可以解释这一点的最好方法可能是将其描述为一个abstract表格。我以前从来没有真正做过这样的事情，通常关系是在两个或多个显式表之间，我会根据需要添加外键。然而，在这种情况下，我最终可能会得到多种不同类型的content，所有这些都需要标签/提及/评论。我事先不知道它content_id指的是哪个表（代码将适当地处理它接收到的数据），所以我indexed现在只是列。content_*type列在某个阶段，因为存在不止一个content表，如果两个表都使用自动递增的主键，则可能会有重复content_id的条目，但我认为这有点超出了问题的范围。
关于 ActiveRecord 类的结构。第一部分是处理提及/主题标签的解析。我写了一个抽象Content类来处理表格的“抽象”方面。它是这样的（为简洁起见，一些解析已被删除）。
class Content < ActiveRecord::Base
self.abstract_class = true;
# relationships
belongs_to :user
has_many :content_mentions;
has_many :content_hashtags;
has_many :mentions, { :through => :content_mentions, :source => :user, :as => :content };
has_many :hashtags, { :through => :content_hashtags, :as => :content };
# available columns (in the abstract side of things)
attr_accessible :text_body, :date_created;
# database hooks
around_save :around_save_hook
# parsing
ENTITY_PATTERN = /removed_for_brevity/iox;
def render_html()
# parsing of the text_body field for hashtags and mentions and replacing them with HTML
# goes in here, but unrelated to the data so removed.
end
protected
# Is this the best way to do this?
def around_save_hook()
# save the main record first (so we have a content_id to pass to the join tables)
yield
# parse the content and build associations, raise a rollback if anything fails
text_body.scan(ENTITY_PATTERN) do |boundary,token,value|
m = $~;
if m[:token] == '@'
# mention
unless mentions.where(:name => m[:value]).first
mention = User::where(:name => m[:value]).first;
next unless mention;
raise ActiveRecord::Rollback unless content_mentions.create({ :content_id => id, :user_id => mention.id });
end
else
# hashtag
unless hashtags.where(:tag => m[:value]).first
hashtag = Hashtag.where(:tag => m[:value]).first;
unless hashtag
hashtag = Hashtag.new({ :tag => m[:value] });
raise ActiveRecord::Rollback unless hashtag.save();
end
raise ActiveRecord::Rollback unless content_hashtags.create({ :content_id => id, :hashtag_id => hashtag.id });
end
end
end
end
end
我在这里遇到的主要问题是around_save_hook，这是解析和保存关联的最佳位置吗？我将如何做到这一点，以便如果text_body更新并且从原始标签中删除了一些主题标签/提及，这些更改将反映在content_*关联中，而不仅仅是添加新的主题标签/提及而不检查删除？
其余ActiveRecord类定义如下：
class Poll < Content
has_many :poll_options;
has_many :poll_answers, { :through => :poll_options }
attr_accessible :user_id, :question;
validates :text_body, :presence => true, :length => { :maximum => 1000 };
end
class PollOption < ActiveRecord::Base
belongs_to :poll;
has_many :poll_answers;
attr_accessible :content, :active, :poll_id;
end
class PollAnswer < ActiveRecord::Base
belongs_to :poll_option;
belongs_to :user;
attr_accessible :user_id, :poll_option_id;
end
class User < ActiveRecord::Base
attr_accessible :name;
validates :name, :presence => true, :length => { :maximum => 20 };
end
class Hashtag < ActiveRecord::Base
attr_accessible :tag;
validates :tag, :presence => true, :length => { :maximum => 30 };
end
# Join table for content->users
class ContentMention < ActiveRecord::Base
belongs_to :user;
belongs_to :content, { :polymorphic => true };
attr_accessible :content_id, :user_id;
end
# Join table for content->hashtags
class ContentHashtag < ActiveRecord::Base
belongs_to :hashtag;
belongs_to :content, { :polymorphic => true };
attr_accessible :content_id, :hashtag_id;
end
所以我想我的问题如下：
- 模式本身是否正确（即它是否非常低效且设计不佳以与 Rails 一起使用？（如果是这样，关于如何纠正它的建议会很棒）
- 是
Around Save解析和更新关联的正确位置吗？ - 我的 ActiveRecords 是否根据当前架构结构正确设置？（特别是我不确定我
polymorphic是否正确使用了该属性） - 我如何向
Poll实例添加选项/答案，而不重新保存投票的整个内容（从而触发对内容的另一个冗余解析），同时仍然保留一种OOP方法？（即选项/答案是通过Poll模型中的公共 API 创建的）
如果有人真的很熟悉Rails，Ruby并且ActiveRecord可以让我快速了解他们将如何实现这一点，那就太好了。正如我所说，我以前从未使用过ActiveRecord该类，所以我什至不确定这个简单的代码save()已经在一次调用中触发了多少原始 SQL 查询。