3 ms·

Table inheritance is a non-starter for the stated use-case. Just don't. If memory serves me well even the Postgres docs recommended against using it for that la

Table inheritance is a non-starter for the stated use-case. Just don't. If memory serves me well even the Postgres docs recommended against using it for that last I read them. The only sane use-case of inheritance I'm aware of is when you're partitioning a table.

colanderman 8y ago
Which has now been usurped by native partitioning as of Postgres 10 :)
- jessedhillon 8y ago
  In Postgres 10, only range-type partition keys are supported, but PG11 will add hash-type partition keys, as well as a number of other partition improvements. https://www.postgresql.org/docs/11/static/ddl-partitioning.html https://www.postgresql.org/docs/11/static/ddl-partitioning.h...
Deimorz 8y ago
> Table inheritance is a non-starter for the stated use-case. Just don't. Can you be more specific about why you shouldn't use it like this? I've used it for similar cases and it's seemed to work fine. You have to declare some foreign keys / constraints that you shouldn't really need to, but it's not really any harder than creating the "child" tables from scratch anyway.
- ddebernardy 8y ago
  I haven't programed in years, but insofar as I can recollect one issue was foreign keys. You basically cannot have a dependable foreign key on tables with child tables. Not a useful one anyway, because the parent and child tables are treated separately. The way foreign keys are (were?) built into Postgres is using built-in system level triggers for on delete/update events. Target the wrong table and all hell breaks loose.
zaarn 8y ago
I'm actually using table inheritance at the moment for a project and it works quite well. I use the table inheritance to manage common fields in the database more easily instead of having to define a separate table and reference it For example the base model, which includes fields for external objects the row might reference and certain option fields or a ratings table that allows an object to include all the necessary fields for rating a product. This way I can also copy a lot of code since the structs on the other side also can share a lot of code and data.

colanderman 8y ago

Which has now been usurped by native partitioning as of Postgres 10 :)

jessedhillon 8y ago
In Postgres 10, only range-type partition keys are supported, but PG11 will add hash-type partition keys, as well as a number of other partition improvements. https://www.postgresql.org/docs/11/static/ddl-partitioning.html https://www.postgresql.org/docs/11/static/ddl-partitioning.h...

Deimorz 8y ago

> Table inheritance is a non-starter for the stated use-case. Just don't. Can you be more specific about why you shouldn't use it like this? I've used it for similar cases and it's seemed to work fine. You have to declare some foreign keys / constraints that you shouldn't really need to, but it's not really any harder than creating the "child" tables from scratch anyway.

ddebernardy 8y ago
I haven't programed in years, but insofar as I can recollect one issue was foreign keys. You basically cannot have a dependable foreign key on tables with child tables. Not a useful one anyway, because the parent and child tables are treated separately. The way foreign keys are (were?) built into Postgres is using built-in system level triggers for on delete/update events. Target the wrong table and all hell breaks loose.

zaarn 8y ago

I'm actually using table inheritance at the moment for a project and it works quite well. I use the table inheritance to manage common fields in the database more easily instead of having to define a separate table and reference it For example the base model, which includes fields for external objects the row might reference and certain option fields or a ratings table that allows an object to include all the necessary fields for rating a product. This way I can also copy a lot of code since the structs on the other side also can share a lot of code and data.