New answers tagged database
2
Starting from V11,
Postgres supports Declarative Partitioning where you can divide the table into partitions with built-in Hash partitioning strategy (modulus or round-robin).
It also allows you to explicitly create the partitions using FOR VALUES FROM ... TO .... And you can also use sub-partitioning to further divide partitions that are expected to ...
4
Christophe`s answer is fine, and that kind of EAV model may be perfectly justified. However, your questions provide not much context. It is perfectly possible these approaches are overdesigned. So before implementing a design with separate tables for units and/or dimensions, ask yourself:
Is that kind of flexibility really necessary?
A physical sensor in a ...
3
What's the problem?
Your model seems to be designed for flexibility and the possibility to configure the system easily with new devices and measurements. I suppose you simplified the details, such as the weather station, the reading device and the time stamp.
Unfortunately the DB schema has a redundancy: you have two reading_type that depends on different ...
1
Best practice to seperate Definition from Implementation would be to have a project just containing your interfaces, your domain-model and domain-logic. And then other projects implementing he interfaces with whatever dependency they have.
In your case, having an "Adapter" that translates one datatype (API) to another (Database) you have to use an ...
1
In your case, your foreignkeys are not settable for all the records, so they need to be optional(nullable) for the Main Table that references them.
2
It can make sense if you are achieving a large performance improvement. The techniques you describe are broadly known as "materialized views". The typical scenarios where they are used are pre-aggregation and avoiding a sorting operation where you have a GROUP BY or ORDER BY clause spanning more than one table.
In order to ensure data integrity, ...
Top 50 recent answers are included
