Re: Database designpattern - product feature

Sorry. Will do in the future.

Product_freature is a table describing the valid keys for product features.
With this it is possible to limit keys to specific groups of products.

Freundliche Grüsse

Adrian Stern
unchained - web solutions

adrian(dot)stern(at)unchained(dot)ch
+41 79 292 83 47

On Tue, Jun 2, 2015 at 12:58 PM, Dorian Hoxha <dorian(dot)hoxha(at)gmail(dot)com>
wrote:

> Please do reply-all so you also reply to the list.
>
> It's not ~good to develop with sqlite and deploy on posgresql. You should
> have your 'dev' as close to 'prod' as possible.
>
> Product_feature is another table in this case ?
>
> On Tue, Jun 2, 2015 at 11:44 AM, Adrian Stern <adrian(dot)stern(at)unchained(dot)ch>
> wrote:
>
>> Database changeability is not a requirement. It just comes with django
>> and makes development so much easier since I can develop on sqlite and
>> deploy the wherever I want. Django orm is not "great" I agree, but it
>> certainly does not suck, there are alternatives like sqlalchemy which are
>> far more powerful.
>>
>> But yea. I get what you're trying to tell me. And I agree, this
>> postgresql feature for jsonb look really nice. Much more easy to use than
>> the whole xquery stuff. The complete EAV Pattern described on wikipedia is
>> actually pretty complex and seems not easy at all to implement in using
>> django. Therefore, i maybe should run a few tests with the json plugins.
>>
>> So let my sketch another approach.
>>
>> PRODUCT -> P
>> - name
>> - type
>> - features (jsonb)
>>
>> PRODUCT_FEATURE -> PF
>> - name
>> - description
>> - datatype
>> - validation
>>
>> P now has the features field of type jsonb, which allows keys specified
>> in PF together with a value of "datatype" or simply a valid one. PF holds
>> the key-name, its datatype for generating the GUI, and some validation
>> pattern for input sanitizing. There is no relation between the Tables.
>>
>> Getting the description is not an issue. I could even create a view
>> mapping the jsonb keys to rows.
>>
>> Yes I like your approach. Is there anything I should be aware of? Some
>> do's and don'ts or known pitfalls?
>>
>>
>