Re: Database designpattern - product feature

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