I would realize that features as Decorators from the Decorators pattern. Ie, each could envelope another decorator. So, the every real object will have features : FirstObject, FirstObject.envelopes, FirstObject.envelopes.envelopes, ... up to the last. You will have to make a function, that shows for any decorators all inner ones. And the function that will make from your DB such "MATRYOSHKA".
Any decorator will have its specific fields:
- name of the feature
- Value of the feature. A list of possible feature values should be set as a static list into every Decorator class.
- Where it would be shown on what page at which format. This I would realize as a map of page types as keys and values=objects of a class Placement, will include place and format. These placements will do the real showing of the feature on the page.
- Will you also analyze other pages? For here you could set also places where on the pages these features could be found. But this is very hard point.
- Here you could put dependencies - what decorators could envelop by which.
- Also here should be a mechanism for passing important information from the inner decorators to the outer ones. But that is the part of the design pattern standard.
The other variant - every object is a list of such features, only independent ones. But that is, IMHO, too dynamic construction for your task, and is harder to control.
This is the most primitive model.
As for more elaborated ones, you should take into account synonyms of the feature names. That means, that the list of possible feature values will change to list of lists.
The next step - some features could exist apart or together as one string. For example, GeForce or 590 or GeForce 590. For realization of this you should use Congregator instead of Decorator.
One more step - you should consider features that are represented by numbers (price, date). It is independent on the two previous steps. Instead of lists of possible values, the decorator will have a range of possible values. The search pattern will be changed so, that the range setting will be possible.
The next independent step - ordering by features. You have all features ordered by including and all values are ordered by order in the lists of possible values. This is the natural order. But you could change the order.
So, two power instruments you should do: searcher UI and orderer UI. IMHO, try not to do the search or ordering for these objects by your code, use SQL instead. Objects should only represent them, used for input and output and setting search/ordering UI definition.
Of course, it could be elaborated further, but it would be better to realize the task step by step.