Chapter 23 Denormalized Data Types j 204

In the rst case, using jsonb is a great enabler in terms of your application’s capabilities to process the documents it manages, including searching and ltering using the content of the document. See jsonb Indexing in the PostgreSQL documentation for more information about the jsonb_path_ops which can be used as in the following example and provides a very good general purpose index for the @> operator as used in the previous query:

1create index on js using gin (extra jsonb_path_ops);

Now, it is possible to use jsonb as a exible way to maintain your data model. It is possible to then think of PostgreSQL like a schemaless service and have a heterogeneous set of documents all in a single relation.

This trade-o f sounds interesting from a model design and maintenance perspective, but is very costly when it comes to daily queries and application development: you never really know what you’re going to nd out in the jsonb columns, so you need to be very careful about your SQL statements as you might easily miss rows you wanted to target, for example.

A good trade-o f is to design a model with some static columns are created and managed traditionally, and an extra column of jsonb type is added for those things you didn’t know yet, and that would be used only sometimes, maybe for debugging reasons or special cases.

This works well until the application’s code is querying the extra column in every situation because some important data is found only there. At this point, it’s worth promoting parts of the extra eld content into proper PostgreSQL attributes in your relational schema.

Enum

ThisdatatypehasbeenaddedtoPostgreSQLinordertomakeiteasiertosupport migrations from MySQL. Proper relational design would use a reference table and a foreign key instead:

1create table color(id serial primary key, name text);

2

3create table cars

4(

Chapter 23 Denormalized Data Types j 205

8);

9

10insert into color(name)

11values ('blue'), ('red'),

14insert into cars(brand, model, color)

15select brand, model, color.id

16from (

In this setup the table color lists available colors to choose from, and the cars table registers availability of a model from a brand in a given color. It’s possible to make an enum type instead:

1create type color_t as enum('blue', 'red', 'gray', 'black');

2

3 drop table if exists cars;

4create table cars

5(

9);

10

11insert into cars(brand, model, color)

12values ('ferari', 'testarosa', 'red'),

Be aware that in MySQL there’s no create type statement for enum types, so each column using an enum is assigned its own data type. As you now have a separate anonymous data type per column, good luck maintaining a globally consistent state if you need it.

Using the enum PostgreSQL facility is mostly a matter of taste. Af er all, join operations against small reference tables are well supported by the PostgreSQL SQL engine.