4 ms·
No, i suggest reverse these kinds of advice and DO THIS instead. Why ? Because IF it's said not to do this, it should not be implemented in first place. This
by revskill 3y ago
No, i suggest reverse these kinds of advice and DO THIS instead.
Why ?
Because IF it's said not to do this, it should not be implemented in first place.
This is a trap.
For example, "Don't use table inheritance", you should always use this to reuse the table definition. If not, what's the alternative ?
- laerus 3y agoThe alternative is to just copy paste the table definition or do composition with foreign keys. Seems like field inheritance was invented only because we are too lazy, I have not seen yet valid cases for inheritance in Postgres or any OOP language.
- mattashii 3y agoUntil the implementation of declarative partitioning, inheritance was the only way to do table partitioning. Although the partitioning use case has mostly been replaced, that doesn't mean it can just be removed as there are existing systems using inheritance to manage their data.
- remram 3y ago> it should not be implemented in first place Some of it exists for important reasons, that are documented on the page. For example, respecting the SQL standard, or maintaining compatibility with database from a time/system without the replacement feature, or for special circumstances that don't apply to you.