P
поборников докера и orm хоть в отдельный чат выводи ...
Size: a a a
2021 January 19
Ð
на хабр выселить )
П
Я как-то предлагал чат разделить на несколько - дба, sql, архитектура...
D
Ну, блин) Вчера я раздул оффтоп, потому что у меня пригорело. Ладно, больше не буду
РЖ
Я как-то предлагал чат разделить на несколько - дба, sql, архитектура...
Сначала надо детский сад отделить :)
E
Занимаюсь миграцией с Монги. Возник вопрос - есть у меня одна коллекция, наполненная json-ами вида {reason: "string" date: Date}.
Как будет каноничнее:
1) сделать отношение с атрибутами reason "STRING" и date "DATETIME" и править само приложение, разбирая этот json на примитивы
2) делать отношение вида [value: "JSON"] и пихать JSON
2.1) когда JSONB хорошо, а когда нет?
Как будет каноничнее:
1) сделать отношение с атрибутами reason "STRING" и date "DATETIME" и править само приложение, разбирая этот json на примитивы
2) делать отношение вида [value: "JSON"] и пихать JSON
2.1) когда JSONB хорошо, а когда нет?
m
Занимаюсь миграцией с Монги. Возник вопрос - есть у меня одна коллекция, наполненная json-ами вида {reason: "string" date: Date}.
Как будет каноничнее:
1) сделать отношение с атрибутами reason "STRING" и date "DATETIME" и править само приложение, разбирая этот json на примитивы
2) делать отношение вида [value: "JSON"] и пихать JSON
2.1) когда JSONB хорошо, а когда нет?
Как будет каноничнее:
1) сделать отношение с атрибутами reason "STRING" и date "DATETIME" и править само приложение, разбирая этот json на примитивы
2) делать отношение вида [value: "JSON"] и пихать JSON
2.1) когда JSONB хорошо, а когда нет?
зависит от того, какие у вас предполагаются выборки
m
подозреваю, что правильнее будет сделать два обычных поля и в них разложить поля из джсона,
а если пользоваться постгресом как монгой, то какой смысл тогда вообще переходить?
а если пользоваться постгресом как монгой, то какой смысл тогда вообще переходить?
V
коллеги, а память work_mem при конфигурировании входит в effective_cache_size или не входит?
V
PGTune на сайте настройки рассчитывает исходя из того что входит похоже
VY
коллеги, а память work_mem при конфигурировании входит в effective_cache_size или не входит?
effective_cache_size вообще никуда не входит, это рекомендательная “подсказка”
am
коллеги, а память work_mem при конфигурировании входит в effective_cache_size или не входит?
effective_cache_size — это же вообще подсказка планировщику.
V
так и думал, но она не говорит вообще системе сколько файлового кэша юзать да? чисто рекомендация понял
am
Занимаюсь миграцией с Монги. Возник вопрос - есть у меня одна коллекция, наполненная json-ами вида {reason: "string" date: Date}.
Как будет каноничнее:
1) сделать отношение с атрибутами reason "STRING" и date "DATETIME" и править само приложение, разбирая этот json на примитивы
2) делать отношение вида [value: "JSON"] и пихать JSON
2.1) когда JSONB хорошо, а когда нет?
Как будет каноничнее:
1) сделать отношение с атрибутами reason "STRING" и date "DATETIME" и править само приложение, разбирая этот json на примитивы
2) делать отношение вида [value: "JSON"] и пихать JSON
2.1) когда JSONB хорошо, а когда нет?
1. Никто не знает, кроме тебя.
2. json(b) хорош тогда, когда хранить надо ничем не валидированный json, который тебе прислали.
2. json(b) хорош тогда, когда хранить надо ничем не валидированный json, который тебе прислали.
mm
Привет всем.
Такой вопрос, есть таблица, пусть будет
Короче говоря, много столбцов
Как можно легко вывести данные кроме ID
Немного перефразирую вопрос:
Такой вопрос, есть таблица, пусть будет
create table testtable (id serial, col1 int, col2 int ...... col20 int);Короче говоря, много столбцов
Как можно легко вывести данные кроме ID
Немного перефразирую вопрос:
SELECT testtable.* from testtable - выведет нам все столбцы, как сделать всё, кроме ID, но чтобы не писать каждый столбец после SELECT ?П
Занимаюсь миграцией с Монги. Возник вопрос - есть у меня одна коллекция, наполненная json-ами вида {reason: "string" date: Date}.
Как будет каноничнее:
1) сделать отношение с атрибутами reason "STRING" и date "DATETIME" и править само приложение, разбирая этот json на примитивы
2) делать отношение вида [value: "JSON"] и пихать JSON
2.1) когда JSONB хорошо, а когда нет?
Как будет каноничнее:
1) сделать отношение с атрибутами reason "STRING" и date "DATETIME" и править само приложение, разбирая этот json на примитивы
2) делать отношение вида [value: "JSON"] и пихать JSON
2.1) когда JSONB хорошо, а когда нет?
ухты, а как решаете проблему разницы полей у данных, особенно если это были поля, задаваемые пользователем. Или у вас всё хорошо с данными в монге и такого нет?
E
Павел
ухты, а как решаете проблему разницы полей у данных, особенно если это были поля, задаваемые пользователем. Или у вас всё хорошо с данными в монге и такого нет?
С данными всё хорошо.
@maxp_dev подтвердит )
@maxp_dev подтвердит )
m
ничего тут подтвердить по поводу данных не могу, но взять из джсона строку и дату, а потом положить в соответствующие колонки вполне реально :))
YS
Занимаюсь миграцией с Монги. Возник вопрос - есть у меня одна коллекция, наполненная json-ами вида {reason: "string" date: Date}.
Как будет каноничнее:
1) сделать отношение с атрибутами reason "STRING" и date "DATETIME" и править само приложение, разбирая этот json на примитивы
2) делать отношение вида [value: "JSON"] и пихать JSON
2.1) когда JSONB хорошо, а когда нет?
Как будет каноничнее:
1) сделать отношение с атрибутами reason "STRING" и date "DATETIME" и править само приложение, разбирая этот json на примитивы
2) делать отношение вида [value: "JSON"] и пихать JSON
2.1) когда JSONB хорошо, а когда нет?
Канонично — это нормализовать (уже посоветовали).
Потому что в реляционных СУБД лучше всего обычно работают реляционные модели. :)
Потому что в реляционных СУБД лучше всего обычно работают реляционные модели. :)
YS
коллеги, а память work_mem при конфигурировании входит в effective_cache_size или не входит?
Умозрительно — нет, не входит.
Но обе они — рекомендации / основы для оценок планировщика, к тому же effective_cache_size не очень "чувствительная" (т.е. существенное с виду изменение (на 1/8 RAM, например) может на практике вообще никак не повлиять на выбираемые планы).
Но обе они — рекомендации / основы для оценок планировщика, к тому же effective_cache_size не очень "чувствительная" (т.е. существенное с виду изменение (на 1/8 RAM, например) может на практике вообще никак не повлиять на выбираемые планы).