SM
пока точно непонятно. допустим в 90% строк будет одно значение, в 9% два, в остальных 3+.
А это тут принципиально важно?
А это тут принципиально важно?
Size: a a a
2021 August 19
ST
ну, один enum не опишет случая с 2+ выставленными значениями
SM
да, если важна производительность наверное надо бы битмапу использовать, но смущает что из кода будет не очень удобно, или я не прав? и сходу глядя в бд не очень понятно что за значение.
SM
это понятно, я поэтому указал enum/array of enums
ST
так ответ-то может отличаться для случая с enum и случая с массивом енумов 😊
SM
буду признателен за рассмотрение обоих случаев :) хотя бы кратко самое важное или про что гуглить)
ST
я бы рассмотрел вариант с целочисленным значением, где каждый бит — это соответствующий флаг 😊
ST
а что тут нагуглишь
любое решение есть набор компромиссов, выбирать-то вам
любое решение есть набор компромиссов, выбирать-то вам
ST
если хочется «может так, а может и вот так», то вариант с jsonb выглядит наиболее гибким
PP
Семантически больше всего похоже на set.
Самое близкое. что я знаю в постгресе, это hstore, в котором забили на значения.
Если хочется регулярно искать записи с конкретными значениями ключами (оператор
Самое близкое. что я знаю в постгресе, это hstore, в котором забили на значения.
Если хочется регулярно искать записи с конкретными значениями ключами (оператор
h ? key), можно построить по ним GIN-индекс.SM
ну т.е. bitmap. Да, мне скорее jsonb больше нравится. Кажется что будет меньше кода и понятнее, что глядя на код, что в бд.
Вот от кучи булевых столбцов немного корёжит, но как бы хорошо аргументировать почему :)
Вот от кучи булевых столбцов немного корёжит, но как бы хорошо аргументировать почему :)
SM
Спасибо! Не слышал про такое. Почитаю.
PP
Это почти что jsonb. Только одноуровневый 🙂
Не исключено, что даже реализации пересекаются.
Не исключено, что даже реализации пересекаются.
ST
не слышал про кложурный set?
((
Можно это как-то сократить?
(str/join ", " ((juxt :country :locality :post-code :region :line) ai))SM
Про постгресный hstore :)
ST
ну, я бы сказал, что array of enum ближе к сету, чем hstore
ST
с hstore картинка странная получается для булевских значений, когда «Keys and values are simply text strings.»
ST
то есть либо в значение пишется всякая фигня, и boolean на основе присутствия пары выбирается
либо ещё какие костыли
либо ещё какие костыли
PP
hstore ближе в том ключе, что уникальность ключей в него заложена как в тип данных изначально. Массиву навязать уникальность значений будет не так просто.
А с булями у hstore для этого случая всё просто — если ключ есть, true. Нету — false. (Если в сценарии различать false и null нет необходимости).
А с булями у hstore для этого случая всё просто — если ключ есть, true. Нету — false. (Если в сценарии различать false и null нет необходимости).