Hello Adrian,
Sorry for the late response. I've not used Django so I can't provide
specific guidance on how you would implement it with that but in SQLAlchemy
that model is called "joined-table-inheritance":
http://docs.sqlalchemy.org/en/latest/orm/inheritance.html#joined-table-inheritance
That i
(Sorry Jan for receiving this twice)
@ Roxanne & Jan:
Thank you both for your Input. I absolutely see your point against EAV.
I will work out two variants based on the specific solution, where i would
create a (bigger) Table for each group of similar products, and based on
the dynamic JSON soluti
On June 3, 2015 02:04:28 PM Roxanne Reid-Bennett wrote:
> I think you should evaluate your unease with having to update the database
> on release (potentially many times) carefully for what it is and why you
> have it. [I'm not saying it is invalid - just know why you have it]
> Because no matter
On 6/3/2015 2:50 AM, Adrian Stern wrote:
Hi William, thanks for joining the conversation.
1) We do hope for constraints since a connection to an ERP system is
possible in the future. We want to plan ahead.
2) As for the subclass approach: I would need about 30 subclasses and
it will get real
Sent from my iPad
> On Jun 3, 2015, at 7:50 AM, Adrian Stern wrote:
>
> Hi William, thanks for joining the conversation.
>
> 1) We do hope for constraints since a connection to an ERP system is possible
> in the future. We want to plan ahead.
>
> 2) As for the subclass approach: I would ne
Hi William, thanks for joining the conversation.
1) We do hope for constraints since a connection to an ERP system is
possible in the future. We want to plan ahead.
2) As for the subclass approach: I would need about 30 subclasses and it
will get really hard to add new products since a change in
Hello Adrian,
May I ask why you need a non-standard model? By standard models I mean the
following:
1) When you don't need to have subclass specific database constraints: All
subclasses in the same table, subclasses that do not have an attribute have
that column null. This has the best performanc
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
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 gro
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.st...@unchained.ch
+41 79 292 83 47
On Tue, Jun 2, 2
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
wrote:
> Database changeabi
What about keeping all the dynamic columns of each product in a json(b)
column ?
Maybe you can make constraints that check the product_type and
json->field->type ?
On Mon, Jun 1, 2015 at 4:35 PM, Adrian Stern
wrote:
> Hi, I'm new
>
> I've been working as the sole administrator of various postgre
Hi, I'm new
I've been working as the sole administrator of various postgresql projects
for a while now. All of which where django projects.
Since a new project is starting and we've found the need for a more generic
approach I would like to ask a few questions.
I would like to implement a pattern
12 matches
Mail list logo
