Re: Database designpattern - product feature

So product_feature is only 1 row for each product_type, right ? Looks good.

On Tue, Jun 2, 2015 at 1:15 PM, Adrian Stern <adrian(dot)stern(at)unchained(dot)ch>
wrote:

> 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?
>>>
>>>
>>
>