Re: Database designpattern - product feature - Mailing list pgsql-general

From Dorian Hoxha
Subject Re: Database designpattern - product feature
Date
Msg-id CANsFX05ma8uC6NpbS8BTNbe9Fm2msrVD=Xyk+_9ygfjK4fuHKQ@mail.gmail.com
Whole thread Raw
In response to Re: Database designpattern - product feature  (Adrian Stern <adrian.stern@unchained.ch>)
List pgsql-general
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.stern@unchained.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


On Tue, Jun 2, 2015 at 12:58 PM, Dorian Hoxha <dorian.hoxha@gmail.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.stern@unchained.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?




pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: pl/python composite type array as input parameter
Next
From: Robert Haas
Date:
Subject: Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1