2010-05-26 3 views
1

Я новичок в Postgresql и пытался с ним.Поиск многомерного массива PostgreSQL

Я создал простую таблицу:

CREATE table items_tags ( 
ut_id SERIAL Primary KEY,  
item_id integer, 
item_tags_weights text[] 
);         

где: item_id - Id товара с эти теги связаны item_tags_weights - Теги, связанные с ITM, включая вес

Example entry: 
-------------------- 
    ut_id | item_id |                     item_tags_weights 
---------+---------+------------------------------------------------------------------------------------------------------------------------------- 
     3 |  2 | {{D,1},{B,9},{W,3},{R,18},{F,9},{L,15},{G,12},{T,17},{0,3},{I,7},{E,14},{S,2},{O,5},{M,4},{V,3},{H,2},{X,14},{Q,9},{U,6},{P,16},{N,11},{J,1},{A,12},{Y,15},{C,15},{K,4},{Z,17}} 
1000003 |  3 | {{Q,4},{T,19},{P,15},{M,14},{O,20},{S,3},{0,6},{Z,6},{F,4},{U,13},{E,18},{B,14},{V,14},{X,10},{K,18},{N,17},{R,14},{J,12},{L,15},{Y,3},{D,20},{I,18},{H,20},{W,15},{G,7},{A,11},{C,14}} 
     4 |  4 | {{Q,2},{W,7},{A,6},{T,19},{P,8},{E,10},{Y,19},{N,11},{Z,13},{U,19},{J,3},{O,1},{C,2},{L,7},{V,2},{H,12},{G,19},{K,15},{D,7},{B,4},{M,9},{X,6},{R,14},{0,9},{I,10},{F,12},{S,11}} 
     5 |  5 | {{M,9},{B,3},{I,6},{L,12},{J,2},{Y,7},{K,17},{W,6},{R,7},{V,1},{0,12},{N,13},{Q,2},{G,14},{C,2},{S,6},{O,19},{P,19},{F,4},{U,11},{Z,17},{T,3},{E,10},{D,2},{X,18},{H,2},{A,2}} 
(4 rows) 

где: { D, 1} - D = тег, 1 = вес тега

Ну, я просто хотел перечислить items_id где теги = 'U' соответствуют весу тега.

На пути следует выбрать ВСЕ теги из базы данных и выполнять обработку на высокоуровневом языке с сортировкой и использовать набор результатов.

Для этого, я могу сделать следующее:

1) SELECT * FROM user_tags WHERE 'X' = ANY (interest_tags_weights)

2) Извлечение и сортировки информации и отображения.

Но, учитывая, что несколько элементов могут быть связаны с одним «TAG», и при условии ввода 10 миллионов этот метод будет, безусловно, вялым.

Любая идея перечислить при необходимости с функцией CREATE или так?

Любые указатели будут полезны.

Большое спасибо.

ответ

1

Вы считали нормализацию, то есть перемещение поля массива в другую таблицу? Помимо простого запроса и расширения, он, вероятно, будет иметь лучшую производительность в больших базах данных.

+0

Лучше нормализироваться здесь. Если вы НЕОБХОДИМО хранить эту денормализованную информацию, hstore (проверьте библиотеку postgres contrib) будет намного лучше. – rfusca

+0

_чтобы хранить эту денормализованную информацию, hstore будет намного лучше_ При условии, что элемент не имеет одинаковых тегов с разным весом, потому что hstore не поддерживает дубликаты ключей. –

+0

Имеются ли в других записях эти данные? Если нет, денормализация будет лучше - вы не получите производительности и не сэкономите место. На самом деле, взгляды на взлеты будут дороже. – dman

Смежные вопросы