А вы случаем не с MongoDB смигрировались? (Простите)

Нет )

К монге осторожно отношусь

Перечитал 3 раза и яснее не стало. А можете привести пример этой подписной модели?

Ну типа: как у гугла

(YouTube)

Предпосчитать сотню рекомендаций и обновить после пары просмотров не вариант?

А если надо отсечь только новые видео для пользователя, фильтр Блума подойдёт

В uuid же уже вшит таймстамп

В uuid же уже вшит таймстамп

Это про v1?

В uuid же уже вшит таймстамп

т.е. по uuid можно делать сортировку ?

далеко не по всякому

Кто-нибудь знаком с ArangoDB? Не нахожу инфо о том как она производит изменения данных на диске.

Кто-нибудь знаком с ArangoDB? Не нахожу инфо о том как она производит изменения данных на диске.

Ок, там тоже никакой магии нет, автовакум называется compaction. WAL как в постгресе нет - вместо них журналы, которые становятся датафайлами после их заполнения.

Это про v1?

вообще на самом деле да

Ок, там тоже никакой магии нет, автовакум называется compaction. WAL как в постгресе нет - вместо них журналы, которые становятся датафайлами после их заполнения.

https://docs.arangodb.com/3.1/Manual/Architecture/WriteAheadLog.html

https://docs.arangodb.com/3.1/Manual/Architecture/WriteAheadLog.html

ох, значит я старую инфу читал

ну я на самом деле сам только что эту страницу открыл

а кто-нибудь пользовался ArangoDB?

а кто-нибудь пользовался ArangoDB?

очень хороший вопросс

У меня есть вопрос по работе insert ... on conflict. Документация требует при использовании on conflict update обязательно указывать объект конфликта. Если у меня есть таблица с двумя ограничениями уникальности, то возможно ли отработать каждое из них через on conflict update?

ой кажется в хакерсах читал про такое

ссылки не сохранилось?)

У меня есть вопрос по работе insert ... on conflict. Документация требует при использовании on conflict update обязательно указывать объект конфликта. Если у меня есть таблица с двумя ограничениями уникальности, то возможно ли отработать каждое из них через on conflict update?

Так если в одной транзакции можно ведь просто 2 insert сделать.

Так если в одной транзакции можно ведь просто 2 insert сделать.

это концептуальный вопрос на понимание возможностей) обойти я знаю как

У меня есть вопрос по работе insert ... on conflict. Документация требует при использовании on conflict update обязательно указывать объект конфликта. Если у меня есть таблица с двумя ограничениями уникальности, то возможно ли отработать каждое из них через on conflict update?

https://stackoverflow.com/questions/35888012/use-multiple-conflict-target-in-on-conflict-clause — оно?

У меня есть вопрос по работе insert ... on conflict. Документация требует при использовании on conflict update обязательно указывать объект конфликта. Если у меня есть таблица с двумя ограничениями уникальности, то возможно ли отработать каждое из них через on conflict update?

или вот это https://stackoverflow.com/questions/36886134/postgres-conflict-handling-with-multiple-unique-constraints

Нет, не совсем. Они два уникальных ограничения (id1), (id2) превращают в одно (id1,id2). Мне же интересно обработать один и второй последовательно

А можно глупый вопрос? Есть таблица, среди ее полей - id, another_id, is_enabled хочется сделать в другой таблице внешний ключ к another_id, но проблема в том, что another_id без unique constraint'а. Дубликаты another_id в первой таблице есть, но пропадают, если фильтровать по is_enabled == true. Как тут правильнее будет сделать? foreign key на (another_id, is_enabled) кажется чем-то не тем. Чё-т я туплю и не уверен, что знаю, в какую сторону копать.

Делать уникальный ключ по (another_id, is_enabled) и ссылаться на него таблицей, где только (another_id) нельзя - придётся и в неё тащить is_enabled. Правильно создать отдельную таблицу с уникальными another_id и на неё ссылаться из первой и второй таблиц

точно, логично ведь. спасибо большое

Всем привет, Кто может подсказать по LOndiste ?

получается что дроп констрейнт не может проверяться на if exists

А там не alter table имя_таблицы drop constraint if exists имя_ограничения?

через час гляну - пока не могу

но скорее всего ты прав. Порядок перепутал

А там не alter table имя_таблицы drop constraint if exists имя_ограничения?

Проверил. Ты прав, не верный порядок

Меня вот что озадачивает. Laravel почему-то constrait делает к уникальному индексу. Почему просто бы не создавть уникальный индекс? Есть какая-то важная деталь, зачем констрейт делают вместе с индексом?

Просто дропать такой индекс не получается :( приходится потом писать предварительный изврат типа убивания ключа

Причем когда я уникальный индекс делаю через запрос, никаких связанных ключей не созадется автоматом

То есть получается это инициатива LARAVEL А оно мне надо?

LARAVEL вычеркиваем

Тогда по другому задам вопрос. Если кто-то делает ключ вместе с уникальным индексом, то это кому-то надо. Какая польза от такого подхода?

Так разве уникальный индекс это не constraint unique (который тоже индекс)? Я не могу понять вопрос

1 сек

сейчас сделаю пример, а может и сам разберусь заодно

Выведете \d и сравните с результатом конструкции alter table add constraint unique

Вы же можете через alter table add constraint добавить primary key, который то же уникальный индекс

Пожалуйста объясни как нубу. Вот есть уникальный индекс (не обязательно это Primary key) зачем нужно создавать ключ. Это како-то прирост к скорости или понятности дает?

Natural join

Natural join

Опередил ?

Ну и модель в которой есть ПК понятнее, чем просто наличие уникального индекса

Ибо ПК — constraint

у меня ситуёвина: Есть поле uiid (оно является первичным ключом) И есть пачка полей, в купе ограничивающие повторения строк Вот на эту пачку полей всегда констрейнт получается надо делать?

Тогда зачем unique index по умолчанию не constraint?

Зачем лишние строки когда, когда архитектура итак давит на то, что это важный и нужный момент

Поясню Я сейчас задаю вопросы не потому чтобы прикопаться или там похоливарить Мне реально не понятно. А т.к. белое пятно в этом месте, сами понимаете, как сейчас пойму, так шаблон поведения и сформируется

Поясню Я сейчас задаю вопросы не потому чтобы прикопаться или там похоливарить Мне реально не понятно. А т.к. белое пятно в этом месте, сами понимаете, как сейчас пойму, так шаблон поведения и сформируется

есть основная концепция, есть implementation detail. иногда можно подёргать все те же implementation detail в обход основной концепции.

Поясню Я сейчас задаю вопросы не потому чтобы прикопаться или там похоливарить Мне реально не понятно. А т.к. белое пятно в этом месте, сами понимаете, как сейчас пойму, так шаблон поведения и сформируется

Первичный ключ нужен для того, чтобы однозначно идентифицировать строку в таблице. И уникальный индекс от него на первый взгляд в этом смысле ничем не отличается. Но есть важные нюансы. Например, первичный ключ не допускает в полях, по которым он строится, NULL. А уникальный индекс позволяет.

Дальше можно уже додумать, почему PK - это констрейнт, а уникальный индекс - нет ))

ERROR: S client not available

Первичный ключ нужен для того, чтобы однозначно идентифицировать строку в таблице. И уникальный индекс от него на первый взгляд в этом смысле ничем не отличается. Но есть важные нюансы. Например, первичный ключ не допускает в полях, по которым он строится, NULL. А уникальный индекс позволяет.

один NULL

один NULL

разве? ведь (null = null) is not true

толсто )

а теперь не ПК, а уник. и два раза

вот во второй раз будет ошибка

всё вставляется, это же не ms sql

всё вставляется, это же не ms sql

угу, потому что NULL не равен NULL ))

всё вставляется, это же не ms sql

может какая-то опция сервера это регулирует?

хотя в mssql хоть что с ansi_nulls делай, всё одно Violation of UNIQUE KEY constraint

Правильно ли я понял? ПК таблицы обязательно констрейт. Остальное не критично и не важно связывать с ключом.

Ну чтобы в кратце. Я вроде перечитал раз 5 но понял только то, что: unique не constrait позволяет добавлять Null в поля constraint ключи нужны чтобы видеть через команду \d что есть первичный ключ

Правильно ли я понял? ПК таблицы обязательно констрейт. Остальное не критично и не важно связывать с ключом.

типа того

Ну чтобы в кратце. Я вроде перечитал раз 5 но понял только то, что: unique не constrait позволяет добавлять Null в поля constraint ключи нужны чтобы видеть через команду \d что есть первичный ключ

constraint ключи нужны чтобы видеть через команду \d что есть первичный ключ - сложная мысль и кажется не совсем полная

constraint - это запрет на что-то. есть unique constraint, есть exclusion constraint, есть check. первые два умеют смотреть в соседние строки таблицы, и из-за этого им нужен индекс, чек смотрит только в текущую, и индекса не требует

primary key - это не констрейнт, это пометка, что в этом столбце лежит айдишник записи. айдишника не может не быть и он не может повторяться, поэтому на это тоже есть проверки.

так получилось, что реализованы они тоже через индекс :)

primary key - это не констрейнт, это пометка, что в этом столбце лежит айдишник записи. айдишника не может не быть и он не может повторяться, поэтому на это тоже есть проверки.

а можешь объяснить, чем на низком уровне отличается unique not null от primary key?

а та ручка индекса, через которую обе эти штуки сделаны, тоже торчит наружу.

а можешь объяснить, чем на низком уровне отличается unique not null от primary key?

подозреваю, что зависит от низости уровня. но на каком-то - ничем. на unique можно сделать foreign key?

подробная статья про UNIQUE KEY и NULL в SQL стандарте и разных СУБД: https://ocelot.ca/blog/blog/2013/09/11/null-and-unique/

подозреваю, что зависит от низости уровня. но на каком-то - ничем. на unique можно сделать foreign key?

я понимаю, что они по факту могут легко заменять друг друга, так как работают одинаково. Но стало интересно, есть ли какая-то пометка в схеме, изменив которую unique not null превратится в primary key

по доке - add primary key при существующей unique not null будет быстрой операцией

думаю, что с точки постгреса они ничем не отличаются. потому что в постгесе нет кластеризованных индексов

то есть по сути все индексы вторичные и primary key это просто алиас

думаю, что с точки постгреса они ничем не отличаются. потому что в постгесе нет кластеризованных индексов

"Кластерных" м.б. ?

wikipedia считает, что да, "кластерных". google говорит, что оба термина используются часто

по мне так "кластеризованный" — более точный перевод слова clustered