ак
Универсально, не требует ходить в базу, позволяет использовать хеш таблицы и быстро по ним искать.
Size: a a a
2021 February 08
R
Тогда какой это сиквенс? Это просто набор интов с дырками. Хотя согласен, что все свойства (id1 < id2) сохраняются.
DT
А потом инкрементить
В
Автоинкремент - это штука специфическая для RDBMS. Поэтому ваши сущности оказываются завязаны на БД. Поэтому я тоже голосую за uuid, как вариант наиболее универсальный. Это не отменяет возможности иметь autoincrement primary key, если это удобно или требуется вашим ORM. Why not both?
Тут нет необходимости уходить от реляционных БД, и навряд ли она когда-нибудь возникнет)) Так что не аргумент в этом контексте.
SP
аминоуксусная кислота
Универсально, не требует ходить в базу, позволяет использовать хеш таблицы и быстро по ним искать.
это утверждение привязано к конкретноу СУБД
В
Вообще, спасибо большое за советы. Подумаю, разовью тему.
SP
Тогда какой это сиквенс? Это просто набор интов с дырками. Хотя согласен, что все свойства (id1 < id2) сохраняются.
секвенс не про дырки, секвенс про порядок. Порядок есть, пускай и могут быть дырки
ак
это утверждение привязано к конкретноу СУБД
Не понял вас, честно говоря
DT
Тогда какой это сиквенс? Это просто набор интов с дырками. Хотя согласен, что все свойства (id1 < id2) сохраняются.
Сиквенс без дырок, а результат может быть с дырками
R
секвенс не про дырки, секвенс про порядок. Порядок есть, пускай и могут быть дырки
Окей. Остаётся проблема синхронизации шардов)
SP
аминоуксусная кислота
Не понял вас, честно говоря
ну например в pg хэш индексы не выйдет юзать как PK или uniq. Только btree.
Но это придирки)
Но это придирки)
SP
Окей. Остаётся проблема синхронизации шардов)
да, для шардинга уже не катит конечно. Для партицирования еще сойдет. Но шардинг с РДБМС в целом не такой частый зверь.
SM
Проекту 8 лет, везде сиквенсы. Теперь надо делать экспорт/импорт всего. Чтоб можно было насетапить чет сложное на сендбоксе и перенести в прод. Будем переходить на uuid. Это как кейс когда надо.
SB
Тут нет необходимости уходить от реляционных БД, и навряд ли она когда-нибудь возникнет)) Так что не аргумент в этом контексте.
Ну как знать. Да, конечно YAGNI, но...
SP
Проекту 8 лет, везде сиквенсы. Теперь надо делать экспорт/импорт всего. Чтоб можно было насетапить чет сложное на сендбоксе и перенести в прод. Будем переходить на uuid. Это как кейс когда надо.
похожий кейс. Миграцию на uuid начали 3 года назад и до сих пор не закончили)
SB
Распиливали монолит на event-driven микросервисы. Без uuid там было бы грустно. Справились :)
2021 February 09
k
халп
простой (ХЗ, на самом деле не очень) вопрос. Стоит ли держать спеку (напр. OAS) в отдельной от эндпоинтов, которые она описывает, репе?
Ну тип если рассмотреть монорепо-проект - часто всю спеку полностью кладут в отдельную папку. У нас проблема в том, что хотят запихнуть спеку по всем эндпоинтам (которые в разных репах) в одну общую репу документации.
Мне кажется, что с точки зрения кохижена и каплинга лучше всего пихать спеку к тому модулю, который спека описывает, это упростит изменения(не надо делать коммит в 2 репозитория по 1 фиче), удобнее будет подключать валидацию по json-schema.
Кто как делает?
простой (ХЗ, на самом деле не очень) вопрос. Стоит ли держать спеку (напр. OAS) в отдельной от эндпоинтов, которые она описывает, репе?
Ну тип если рассмотреть монорепо-проект - часто всю спеку полностью кладут в отдельную папку. У нас проблема в том, что хотят запихнуть спеку по всем эндпоинтам (которые в разных репах) в одну общую репу документации.
Мне кажется, что с точки зрения кохижена и каплинга лучше всего пихать спеку к тому модулю, который спека описывает, это упростит изменения(не надо делать коммит в 2 репозитория по 1 фиче), удобнее будет подключать валидацию по json-schema.
Кто как делает?
АГ
одна и та же спека бывает нужна в 2+ модулях. не?
k
одна и та же спека бывает нужна в 2+ модулях. не?
зачем? 🤔
k
ну т.е. вроде нет