使用LIKE查询，外键或jsonb数组过滤Postgres SELECT

Question

I have a table, which suppose to contain relations to other tables. But I need these relations only for filtering, ie the relations in this case are not suppose to work as foreign key or some kind of references - I just need to search through them. It works like tags or something.
Here is the example:

CREATE TABLE "public"."table_name" 
(
    "id" uuid NOT NULL DEFAULT uuid_generate_v4(),
    "relations" text NOT NULL,
    "some_column" text,
    "some_another_column" int4,
    "created" timestamp(6) WITH TIME ZONE NOT NULL DEFAULT now(),
    CONSTRAINT "table_name_pkey" PRIMARY KEY ("id") NOT DEFERRABLE INITIALLY IMMEDIATE,
    CONSTRAINT "owner" FOREIGN KEY ("owner") REFERENCES "public"."user" ("id") ON UPDATE NO ACTION ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE,
)
WITH (OIDS=FALSE);
ALTER TABLE "public"."table_name" OWNER TO "postgres";

the relations column will contain multiple uuid keys. This column is not suppose to be SELECT ed, I intend to use it only for filtering. In this case I intend to use this kind of queries to select rows from only this table:

SELECT 
    id, some_column, some_another_column 
FROM 
    table_name 
WHERE 
    relations LIKE '%c56c8a4f-765a-4e1c-9638-f3736a25da17%' 
    AND owner = 'badee659-1fca-412a-bcf6-c73ecf1e65aa';

Of course, I will create a multicolumn (owner,relations) index.

Is this a good approach to perform this kind of search queries? relations column will contain 1 to 10 uuids per each row on the average.

Or, maybe I should create additional table, which will contain, say, one uuid for each 'relation' and FK for referencing to the table_name table? In this case I will use JOIN queries.

Or may be there are better ways? May be I should store uuids as array within jsonb object? Or something else?

Answer 1

Index consideration

Using operator LIKE with leading % is not sargable . It won't use your index, because the optimizer doesn't know how to narrow first characters from relations column.

Design

It's almost always a bad idea to store different values in one column as a string with delimiter.

Remember that relational databases are designed for performing JOIN operations efficiently. In my opinion it would be better to separate that data into rows with atomic values in their columns.

Json consideration

json and jsonb datatypes should only be taken under consideration if your columns are unpredictably changing. By saying this I mean that whenever you can (without much overhead going on) fit your model into relational one, you should always go for it. The same goes for hstore .

You could read this blog post to grab some information to start with when considering using a mechanism for storing dynamic columns.

A little quote from that post:

How to decide when to use json

Use json if your data won't fit in the database using a normal relational modelling.

Credit for above blogpost goes to @Craig Ringer .