Object-oriented or relational? Why not both? Let's look on PostgreSQL JSONB column type and how it can help you to deliver your applications faster. We dived into how it's stored, when and why it can be as performant as regular approach, and cases when we need to do tradeoffs.
Thank You for that article. But I'm thinking about that example. What is real application for that field type ? I'm sceptical about real world usage. Is storing data in project doing business logic and not having any established structure, makes any sense ? It seems to me that it could lead to mess. Temporary data representation ? For the rest use cases we have already document type storage solutions.
Thank you for the insightful article and detailed explanation. JSONB's schema-less design initially makes it seem like a desirable choice. But as data volume increases, significant performance issues may arise, especially with regards to read delay brought on by the overhead of serialization and deserialization. Furthermore, keeping big payloads in JSONB columns could make backup and restoration more difficult, which could affect system recovery times and dependability.
Consequently, using JSONB should be a conscious design decision based on a thorough comprehension of the long-term effects on performance, maintainability, and scalability. Carefully weighing the trade-offs and coordinating them with the larger system design and operational objectives is essential.
I've done some further study and I think the examples that fail above need a little more thought, the @> might be replaced with a series of -> operators.
I've found several working examples and an explanation of the operators, two links follow:
Thank You for that article. But I'm thinking about that example. What is real application for that field type ? I'm sceptical about real world usage. Is storing data in project doing business logic and not having any established structure, makes any sense ? It seems to me that it could lead to mess. Temporary data representation ? For the rest use cases we have already document type storage solutions.
Thanks for sharing! Your article provides a lot of information in a single read!
Thank you for the insightful article and detailed explanation. JSONB's schema-less design initially makes it seem like a desirable choice. But as data volume increases, significant performance issues may arise, especially with regards to read delay brought on by the overhead of serialization and deserialization. Furthermore, keeping big payloads in JSONB columns could make backup and restoration more difficult, which could affect system recovery times and dependability.
Consequently, using JSONB should be a conscious design decision based on a thorough comprehension of the long-term effects on performance, maintainability, and scalability. Carefully weighing the trade-offs and coordinating them with the larger system design and operational objectives is essential.
Hi,
I tried coding the example starting at CREATE TABLE customers, then INSERT, then SELECT.
At the 3 different SELECTS, I could not get a data match return value for the third example
without changes. For the 3rd SELECT I changed "promotion code" to "purchases".
I'd like to know what to change in the first two SELECTs to get a match, and possibly
an explanation of the operator "@>", what goes where into the fields, and why.
Thank you,
Hi,
I've done some further study and I think the examples that fail above need a little more thought, the @> might be replaced with a series of -> operators.
I've found several working examples and an explanation of the operators, two links follow:
operators URL: https://scalegrid.io/blog/using-jsonb-in-postgresql-how-to-effectively-store-index-json-data-in-postgresql/
jsonb examples with operator explanation URL: https://blog.logto.io/mastering-postgresql-jsonb
If anyone could point me to an example of timescaledb with jsonb, I'd appreciate that.