Question

假设我有一个销售不同品牌和规格的笔记本电脑的网站。规格包括CPU电源，内存，硬盘空间，甚至保险，服务和配件等。

它们都应通过完整搜索文字和分区/过滤进行搜索，如下所示：http://www.pricegrabber.com/computers/laptop/p-13/

数据库是 postgresql 。

我的计划，无论是否愚蠢，都是为每个规范本身提供一个表格。所以我会为cpus创建一个表，其中包含CPU的所有不同选项，如“Intel 4.33 Ghz Quad Core”或其他任何选项，并重复hard_disks，{{1}之类的过程。 }，memories等等。

最后，主表格看起来像这样：

video_cards

这是一个愚蠢的设计吗？我知道这可能基于意见，但我会喜欢任何指针，比如我是客观地做了完全错误的事情。我有点计划甚至更深入，即引用某些东西反过来引用某些东西。例如，class CreateLaptops < ActiveRecord::Migration def change create_table :laptops do |t| t.references :brands_id t.references :models_id t.references :cpus_id t.references :memories_id t.references :video_cards_id t.references :displays_id t.references :batteries_id t.references :accessories_id t.references :insurances_id # and the list goes on ... t.timestamps null: false end end end可以分为cpus和intel_cpus，但现在我觉得我走得太远了。

最重要的考虑因素是让它可以从外部轻松搜索，然后使其易于维护和组织，并在列表的底部显示性能，因为数据库中根本没有很多项目。 / p>

期待听到您的想法！

Answer 1

听起来，我想要将资源嵌套多层深层，如下所示：

class Laptops < ActiveRecord::Base
  has_many :cpus
end
class CPUs < ActiveRecord::Base
  has_many :intel
  has_many :AMD
end

我假设通过＆＃34;使其可以从外部搜索＆＃34;你的意思是你想把它变成一个好的RESTful API，想想你必须为第一台笔记本电脑的第一个CPU的第一个AMD指定的路由：

example.com/laptops/1/cpus/1/amd/1

或者在想要链接到特定路径时在内部想象：

link_to laptops_cpus_amd_path

不太可读。这只有三层深。

你说你想通过全文搜索来搜索所有这些东西。这个数据库设计将如何帮助它呢？ Postgresql已经可以开箱即用全文搜索，即，如果你的笔记本电脑表中有一个值＆＃34; Intel 4.33 Ghz Quad Core＆＃34;，PG可以找到它。将CPU抽象为自己的模型根本不会有帮助，只会让你的API变得更糟。

事实上，关于PG全文搜索的主题有一个很好的Railscast：

http://railscasts.com/episodes/343-full-text-search-in-postgresql

这是有效的数据库设计还是有太多的外键？

1 个答案: