D
Грубо говоря каждый раз перед созданием data проверять, есть ли такое уже в таблице, и если есть, отсылать на эту строку?
Можно не проверять даже, достаточно внешний ключ повесить - PostgreSQL сам проверит
Size: a a a
2021 February 13
MS
Можно не проверять даже, достаточно внешний ключ повесить - PostgreSQL сам проверит
это который foreign key?
MS
он может быть композитным же?
D
это который foreign key?
Да. Но, судя по тому, что вы выше написали "Первоначально заложить и такую возможность" - вам нужно всё же m2m
MS
Да. Но, судя по тому, что вы выше написали "Первоначально заложить и такую возможность" - вам нужно всё же m2m
т.е через отдельную реляционную таблицу?
D
т.е через отдельную реляционную таблицу?
Да, но даже так внешние ключи, естественно, нужны
MS
Хорошо. В этой связывающей таблице должен быть какой-то primary key
Но этот ключ должен быть также уникальным
Как это понимать, если есть вероятность как повторения data_id, так и user_id
Но этот ключ должен быть также уникальным
Как это понимать, если есть вероятность как повторения data_id, так и user_id
D
Хорошо. В этой связывающей таблице должен быть какой-то primary key
Но этот ключ должен быть также уникальным
Как это понимать, если есть вероятность как повторения data_id, так и user_id
Но этот ключ должен быть также уникальным
Как это понимать, если есть вероятность как повторения data_id, так и user_id
Там первичный ключ - связка из двух полей
YS
в приведенном запросе видно, что строк мало, они расположены упрядоченно скорее всего и чтение первых 10 строк затрагивает не больше блоков, чем чтение первых 100 строк
В приведённых запросах:
. "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 (потому что она действительно просматривается один раз), считается.
(поправил)
VY
в приведенном запросе видно, что строк мало, они расположены упрядоченно скорее всего и чтение первых 10 строк затрагивает не больше блоков, чем чтение первых 100 строк
тут надо “видеть” как база выполняет проверку предиката (в EXPLAIN не видно), я не знаю и в код сейчас не полезу
предположу, что в первом случае, т.к. даётся массив из 10 значений, мы получаем 10 IndexAccess-es и каждый учитывается отдельно (такой внутренний NestedLoop)
во втором же случае у нас идёт один RangeScan, который обращается к: MetaPage индекса, одной странице индекса и одной странице таблицы.
предположу, что в первом случае, т.к. даётся массив из 10 значений, мы получаем 10 IndexAccess-es и каждый учитывается отдельно (такой внутренний NestedLoop)
во втором же случае у нас идёт один RangeScan, который обращается к: MetaPage индекса, одной странице индекса и одной странице таблицы.
MS
AG
в теории апач может запускать какой-то другой скрипт (где-нибудь копия старая лежит), а ты правишь этот. про разные php.ini уже писали
нашел в логах php следующее:
pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Permission denied
Is the server running on host "192.168.253.130" and accepting
У кого, получается, доступа нет?
pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Permission denied
Is the server running on host "192.168.253.130" and accepting
У кого, получается, доступа нет?
D
Так
Есть некий юзер
У него есть ид
Хочу достать всю его дату
Чтобы обратиться к связывающей таблице, как вы говорите, нужно знать оба айди (user и data)
Как мне узнать этот data.id?)
Есть некий юзер
У него есть ид
Хочу достать всю его дату
Чтобы обратиться к связывающей таблице, как вы говорите, нужно знать оба айди (user и data)
Как мне узнать этот data.id?)
select data.*
from data
join data_users on data_users.data_id and data_users.users_id=твойюзер_idD
Так
Есть некий юзер
У него есть ид
Хочу достать всю его дату
Чтобы обратиться к связывающей таблице, как вы говорите, нужно знать оба айди (user и data)
Как мне узнать этот data.id?)
Есть некий юзер
У него есть ид
Хочу достать всю его дату
Чтобы обратиться к связывающей таблице, как вы говорите, нужно знать оба айди (user и data)
Как мне узнать этот data.id?)
SELECT d.id, d.name FROM data d JOIN data_users du ON du.data_id=d.id AND du.user_id=2345
MS
select data.*
from data
join data_users on data_users.data_id and data_users.users_id=твойюзер_idИтого
Создаю связывающую таблицу
В ней два поля: user_id, data_id
Накидываю на каждую референцию на id в каждой таблице
Что делать с primary key то
Или без него вообще?
Создаю связывающую таблицу
В ней два поля: user_id, data_id
Накидываю на каждую референцию на id в каждой таблице
Что делать с primary key то
Или без него вообще?
D
Итого
Создаю связывающую таблицу
В ней два поля: user_id, data_id
Накидываю на каждую референцию на id в каждой таблице
Что делать с primary key то
Или без него вообще?
Создаю связывающую таблицу
В ней два поля: user_id, data_id
Накидываю на каждую референцию на id в каждой таблице
Что делать с primary key то
Или без него вообще?
Как без него? Связка user_id, data_id - это первичный ключ из двух полей сразу
D
я про композитный primary key же написал выше
MS
Как без него? Связка user_id, data_id - это первичный ключ из двух полей сразу
Хорошоо
Просто primary key (user_id, data_id)?
Ясненько
Просто primary key (user_id, data_id)?
Ясненько
D
MS