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

Question

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

它们都应该可以通过完整搜索文本和分面/过滤进行搜索，例如：http://www.pricegrabber.com/computers/laptop/p-13/

数据库是postgresql。

无论是否愚蠢，我的计划是为每个规范本身设置一个表格。所以我会为cpus 创建一个表，其中有所有不同的 CPU 选项，例如“Intel 4.33 Ghz 四核”或其他任何东西，并对hard_disks、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 和 amd_cpus，但现在我觉得我走得太远了。

最重要的考虑是使其易于从外部搜索，然后使其易于维护和组织，而性能则排在最后，因为数据库中根本不会有很多项目。

期待听到您的想法！

Answer 1

在我看来，您想将资源嵌套很多层，如下所示：

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

正如我所假设的“使其可从外部搜索”你的意思是你想让它成为一个好的 RESTful API，想想你必须为第一台笔记本电脑的第一个 CPU 的第一个 AMD 指定什么路线：

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

或者在您尝试链接到某个特定路径时在内部想象：

link_to laptops_cpus_amd_path

不太可读。而且只有三层深。

你说过你想让所有这些东西都可以通过全文搜索来搜索。这种数据库设计将如何帮助呢？ Postgresql 已经可以进行开箱即用的全文搜索，也就是说，如果在您的笔记本电脑表中您有一个值“Intel 4.33 Ghz Quad Core”，PG 可以找到它。将 CPU 抽象为它自己的模型根本无济于事，只会让你的 API 变得更糟。

其实有一篇关于PG全文搜索的优秀Railscast：

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