Quote (carteblanche @ 11 Sep 2013 17:33)
if you know there's a fixed number of subcategory levels and they're all related, you can make a separate table for each one. if you're not convinced, then use a single table and linked-list it.
no
bad
that makes for awful queries
you clearly don't know what you're talking about
here's my initial thought, not fully thought through w.r.t normalization and everything (I think it's 3nf anyways)
Code
table computer-types
id, type
table computer-category
id, category, typeId ref computer-types
table computer-models
id, name, category ref computer-category
table specs
id, modelId ref computer-models, other info goes here
note: for specs, you could potentially be referencing yet more tables containing part ids and specs for components
so computer-types contains (1,"Tablet")
computer-categories would contain (1,"SuperTablet",1) (2, "weakTablet", 1)
computer-models would contain (1,"Super Tablet - 1",1) (2, "Super Tablet - 2", 1) (3, "punyTablet", 2)
specs would contain (1,1,"500gb hd") (2,1, "750gb hd") (3, 2, "500gb hd") (4,3, "100gb hd")
Quote (flyinggoat @ 11 Sep 2013 20:32)
Wouldn't simply using an extra table that keeps count of the amount of each computer be enough? It seems that's all you'd need for the bulk of your statistical queries. All update operation could be performed through a class that would maintain the counter table programmatically.
As for more complicated queries, is the development cost of a relational db scheme outweighed by the size of your db or the frequency of such queries over parsing the full db at application spawn?
If he was at the level where an additional cache count table was necessary he wouldn't be asking for help here.
If you use a properly designed schema like mine, querying those things is trivial.
This post was edited by J_B on Sep 11 2013 11:50pm