É melhor usar tabelas em vez de tipo de campo matrizes no PostgreSQL quando as matrizes não excedam 50 elementos?

votos
16

Ou melhor dizendo: Quando usar matriz como um tipo de dados campo em uma tabela?

Qual a solução proporciona melhores resultados de pesquisa?

Publicado 11/11/2008 em 04:09
fonte usuário
Em outras línguas...                            


5 respostas

votos
4

Eu considerei este problema, bem como a conclusão de que voltei a mim, é a utilização de matrizes quando você quer eliminar a tabela junta. O número de elementos contidos em cada matriz não é tão importante quanto o tamanho das tabelas envolvidas. Se há apenas alguns milhares de linhas em cada tabela, em seguida, juntar para conseguir as 50 linhas sub não deve ser um grande problema. Se você entrar em OR 100 dos milhares ou linhas 10, é provável que você começar a mastigar através de um monte de tempo de processador e disco i / o embora.

Respondeu 11/11/2008 em 05:00
fonte usuário

votos
0

As tabelas serão sempre fornecer melhores resultados de pesquisa supondo que você está consultando algo dentro do array real. Com uma subtabela, você pode indexar o conteúdo trivialmente, enquanto que com um array, você teria que criar literalmente 50 índices (um para cada elemento potencial dentro da matriz).

Respondeu 11/11/2008 em 05:00
fonte usuário

votos
5

I evitar matrizes para 2 razões:

  • armazenando mais de um valor de atributo em uma célula você violar a primeira forma normal (teórico);
  • você tem que executar alguma extra, não-SQL relacionadas, processamento de cada vez que você precisa trabalhar com elementos individuais das matrizes (práticos, mas uma consequência directa do teórico)
Respondeu 11/11/2008 em 11:53
fonte usuário

votos
0

Eu acho que as matrizes têm de ser utilizados para alguns dados personalizados. Mas para chaves estrangeiras - é melhor usar tabela de ligação (ou outra coisa, mas coluna por chave). Desta forma, você tem o controle de dados a nível DB e consultas fáceis para juntar-se - você precisa para se juntar mesmo se você tê-los em matrizes (para conjunto de dados completo) - mas matrizes muito mais complicado do SQL "Standart". PS Desculpe mau Inglês

Respondeu 13/05/2019 em 12:08
fonte usuário

votos
0

Não sei quanto tempo esses links permanecer vivo por isso vou colar os resultados abaixo: http://sqlfiddle.com/#!17/55761/2

TLDR; pesquisar um índice de tabela e, em seguida, juntar é rápida, mas a adição de um índice GIN (usando gin__int_ops) para uma única tabela com uma coluna de matriz pode ser mais rápido. Além disso, a flexibilidade de ser capaz de igualar "alguma" ou um pequeno número de seus valores de matriz pode ser uma opção melhor, por exemplo, um sistema de marcação.

create table data (
    id serial primary key,
    tags int[],
    data jsonb
);

create table tags (
    id serial primary key,
    data_id int references data(id)
);

CREATE INDEX gin_tags ON data USING GIN(tags gin__int_ops); 

SET enable_seqscan to off;

with rand as (SELECT generate_series(1,100000) AS id)
insert into data (tags) select '{5}' from rand;

update data set tags = '{1}' where id = 47300;

with rand as (SELECT generate_series(1,100000) AS id)
INSERT INTO tags(data_id) select id from rand;

Corrida:

  select data.id, data.data, data.tags
  from data, tags where tags.data_id = data.id and tags.id = 47300;

e

  select data.id, data.data, data.tags
  from data where data.tags && '{1}';

Rendimentos:

Record Count: 1; Execution Time: 3ms
QUERY PLAN
Nested Loop (cost=0.58..16.63 rows=1 width=61)
-> Index Scan using tags_pkey on tags (cost=0.29..8.31 rows=1 width=4)
Index Cond: (id = 47300)
-> Index Scan using data_pkey on data (cost=0.29..8.31 rows=1 width=61)
Index Cond: (id = tags.data_id)

e

Record Count: 1; Execution Time: 1ms
QUERY PLAN
Bitmap Heap Scan on data (cost=15.88..718.31 rows=500 width=61)
Recheck Cond: (tags && '{1}'::integer[])
-> Bitmap Index Scan on gin_tags (cost=0.00..15.75 rows=500 width=0)
Index Cond: (tags && '{1}'::integer[])
Respondeu 29/12/2019 em 03:57
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more