D
Не за что. Про внешние ключи не забудь.
Size: a a a
2021 February 13
MS
Не за что. Про внешние ключи не забудь.
Пошел читать уже)
VY
Пошел читать уже)
хочу предупредить, что суррогатные ключи допускают наличие дубликатов в бизнес-данных.
MS
хочу предупредить, что суррогатные ключи допускают наличие дубликатов в бизнес-данных.
Наличие дубликатов в бизнес-данных..
Грубо говоря есть вероятность того, что у одного юзера могут быть две повторяющихся строки с данными?
Просто навесить дополнительную проверку в бизнес логике?
Грубо говоря есть вероятность того, что у одного юзера могут быть две повторяющихся строки с данными?
Просто навесить дополнительную проверку в бизнес логике?
KK
https://www.db-fiddle.com/f/cctTtuS3sSizzyTxTGn6iF/1 - как можно интерпретировать результаты эксплейна
Buffers: shared hit=22 в запросе, который достает только 10 строк и
Buffers: shared hit=3 в запросе, который достает 100 строк ?
Buffers hit - это абстрактная метрика вроде cost-ов, которые нельзя напрямую сравнивать?
Buffers: shared hit=22 в запросе, который достает только 10 строк и
Buffers: shared hit=3 в запросе, который достает 100 строк ?
Buffers hit - это абстрактная метрика вроде cost-ов, которые нельзя напрямую сравнивать?
buffer hits - это не абстрактная метрика. Это совершенно конкретная величина - сколько страниц мы достали из shared buffers Т.е. если написано
Buffers: shared hit=22 read=2
значит 22 страницы мы нашли в шаред памяти. а 2 прочитали.
С тем сколько мы достали строк это напрямую не связано: нам могло понадобиться прочитать много страниц индекса, чтобы добраться до одной записи
Buffers: shared hit=22 read=2
значит 22 страницы мы нашли в шаред памяти. а 2 прочитали.
С тем сколько мы достали строк это напрямую не связано: нам могло понадобиться прочитать много страниц индекса, чтобы добраться до одной записи
VY
Наличие дубликатов в бизнес-данных..
Грубо говоря есть вероятность того, что у одного юзера могут быть две повторяющихся строки с данными?
Просто навесить дополнительную проверку в бизнес логике?
Грубо говоря есть вероятность того, что у одного юзера могут быть две повторяющихся строки с данными?
Просто навесить дополнительную проверку в бизнес логике?
10-Вася-Пупкин-активный
11-Вася-Пупкин-активный
11-Вася-Пупкин-активный
VG
Yaroslav Schekin
В приведённых запросах:
. "WHERE id < 100" — это один проход от корня индекса до страницы (все эти записи на одной): metapage; root → leaf.
. "WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9 ,10)" — десять таких проходов (да, от корня), каждое "касание" страницы, кроме metapage (потому что она действительно просматривается один раз), считается.
(поправил)
. "WHERE id < 100" — это один проход от корня индекса до страницы (все эти записи на одной): metapage; root → leaf.
. "WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9 ,10)" — десять таких проходов (да, от корня), каждое "касание" страницы, кроме metapage (потому что она действительно просматривается один раз), считается.
(поправил)
спасибо
VG
buffer hits - это не абстрактная метрика. Это совершенно конкретная величина - сколько страниц мы достали из shared buffers Т.е. если написано
Buffers: shared hit=22 read=2
значит 22 страницы мы нашли в шаред памяти. а 2 прочитали.
С тем сколько мы достали строк это напрямую не связано: нам могло понадобиться прочитать много страниц индекса, чтобы добраться до одной записи
Buffers: shared hit=22 read=2
значит 22 страницы мы нашли в шаред памяти. а 2 прочитали.
С тем сколько мы достали строк это напрямую не связано: нам могло понадобиться прочитать много страниц индекса, чтобы добраться до одной записи
меня смутило, что это скорее всего те же самые страница/ы, но по несколько раз. Звучит, будто достать 10 записей по id (пусть и на одной странице) может быть дольше, чем 100 подряд
MS
10-Вася-Пупкин-активный
11-Вася-Пупкин-активный
11-Вася-Пупкин-активный
Как этого избежать?
Проверить что данные уже имеются? Или можно повесить if not exists с созданием таблиц?
Проверить что данные уже имеются? Или можно повесить if not exists с созданием таблиц?
Н
Как этого избежать?
Проверить что данные уже имеются? Или можно повесить if not exists с созданием таблиц?
Проверить что данные уже имеются? Или можно повесить if not exists с созданием таблиц?
Тут сложнее... Допустим, есть два -Вася Пупкина....
VY
меня смутило, что это скорее всего те же самые страница/ы, но по несколько раз. Звучит, будто достать 10 записей по id (пусть и на одной странице) может быть дольше, чем 100 подряд
а так и есть, больше операций, к большеу кол-ву блоков обращаемся. они, скорее всего, будут в кэше и разница будет малозначительной
MS
Тут сложнее... Допустим, есть два -Вася Пупкина....
Нет, тут у меня у каждого юзера 100% различные id
Речь о телеграм пользователях, где primary key я беру chat_id, создаваемый самим телеграмом
Речь о телеграм пользователях, где primary key я беру chat_id, создаваемый самим телеграмом
VY
Как этого избежать?
Проверить что данные уже имеются? Или можно повесить if not exists с созданием таблиц?
Проверить что данные уже имеются? Или можно повесить if not exists с созданием таблиц?
обычно вешают дополнительный Unique Key на бизнес данные, типа уникальное имя, или там номер паспорта…
MS
Даже если сделать два одинаковых имени, id будут разными
MS
обычно вешают дополнительный Unique Key на бизнес данные, типа уникальное имя, или там номер паспорта…
user_data_id в связывающей таблице?
Н
Нет, тут у меня у каждого юзера 100% различные id
Речь о телеграм пользователях, где primary key я беру chat_id, создаваемый самим телеграмом
Речь о телеграм пользователях, где primary key я беру chat_id, создаваемый самим телеграмом
Разговор был про бизнес данных. А id это не бизнес данный :))
KK
меня смутило, что это скорее всего те же самые страница/ы, но по несколько раз. Звучит, будто достать 10 записей по id (пусть и на одной странице) может быть дольше, чем 100 подряд
Вообще говоря это справедливо. Ну может там не такое соотношение (10 к 100). Но обращение к странице в шаред буферах ес-но не бесплатно. Это хорошо видно по index only scan. В ноде IOS пинится 1 страница visibility map-а, по которой проверяется видимость записи. 1 страница мапа покрывает пол гига. Если табличка больше, то скорость IOS резко проседает. Если увеличить число запинненых страниц, то эту границу можно отодвинуть.
MS
Разговор был про бизнес данных. А id это не бизнес данный :))
Так
Видимо я чего-то не понимаю))
У меня есть некоторые функции, которые работают с ORM либой (ЯП не имеет значения), чтобы связываться с бд на постгресе
Если мне нужно получить данные определенного пользователя, я вызываю функцию, передавая ей ид этого человека.
При создании нового пользователя я проверяю на наличие такого же user_id в таблице
На каком из этапов может появиться дубликат?
Видимо я чего-то не понимаю))
У меня есть некоторые функции, которые работают с ORM либой (ЯП не имеет значения), чтобы связываться с бд на постгресе
Если мне нужно получить данные определенного пользователя, я вызываю функцию, передавая ей ид этого человека.
При создании нового пользователя я проверяю на наличие такого же user_id в таблице
На каком из этапов может появиться дубликат?
Н
Так
Видимо я чего-то не понимаю))
У меня есть некоторые функции, которые работают с ORM либой (ЯП не имеет значения), чтобы связываться с бд на постгресе
Если мне нужно получить данные определенного пользователя, я вызываю функцию, передавая ей ид этого человека.
При создании нового пользователя я проверяю на наличие такого же user_id в таблице
На каком из этапов может появиться дубликат?
Видимо я чего-то не понимаю))
У меня есть некоторые функции, которые работают с ORM либой (ЯП не имеет значения), чтобы связываться с бд на постгресе
Если мне нужно получить данные определенного пользователя, я вызываю функцию, передавая ей ид этого человека.
При создании нового пользователя я проверяю на наличие такого же user_id в таблице
На каком из этапов может появиться дубликат?
Дубликаты id не появляются.. Появляются разные user ы одинаковыми ФИО. Так что, можно не обращать внимания.
MS
Дубликаты id не появляются.. Появляются разные user ы одинаковыми ФИО. Так что, можно не обращать внимания.
Хорошо, надеюсь с этим проблем не будет))