Я новичок в 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 или так?
Любые указатели будут полезны.
Большое спасибо.
Лучше нормализироваться здесь. Если вы НЕОБХОДИМО хранить эту денормализованную информацию, hstore (проверьте библиотеку postgres contrib) будет намного лучше. – rfusca
_чтобы хранить эту денормализованную информацию, hstore будет намного лучше_ При условии, что элемент не имеет одинаковых тегов с разным весом, потому что hstore не поддерживает дубликаты ключей. –
Имеются ли в других записях эти данные? Если нет, денормализация будет лучше - вы не получите производительности и не сэкономите место. На самом деле, взгляды на взлеты будут дороже. – dman