Let's say I have a site that sells laptop computers of different brands and specs. Specs include things like CPU power, memory, hard disk space, and even such things as insurance, service, and accessories.
They should all be searchable via full search text and faceting/filtering, like this: http://www.pricegrabber.com/computers/laptop/p-13/
The database is postgresql.
My plan, stupid or not, is to have a table for each spec itself. So I would create a table for cpus
where I have all the different options for CPUs, like "Intel 4.33 Ghz Quad Core" or whatever, and repeat the process for things like hard_disks
, memories
, video_cards
, and so on.
In the end, thus, the main table would look something like this:
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
Is this stupid design? I'm aware this could be based on opinion, but I would love any pointers, like if I'm objectively doings things totally wrong. I sort of plan to even go deeper, i.e. referencing something which in turn references something. cpus
could be split up into intel_cpus
and amd_cpus
, for example, but now I feel I've gone too far.
The most important consideration is making it all easily searchable from the outside, then make it easily maintainable and organized, and at the bottom of the list comes performance, because there won't be many items in the database at all.
Looking forward to hear your thoughts!