R
Yaroslav Schekin
Стоит показывать реальные схемы (CREATE TABLE) вместо диаграмм в неведомой нотации, IMNSHO.
Это для визуализации. Я через typeorm буду делать а не на чистом sql
Size: a a a
2020 July 16
VY
Сделать 3 скила логично же и связать
вот и покажите мне, как для 1 пользователя завести 3 разных скила в такой схеме
EM
varchar без лимита по длине
varchar(n) имелся в виду лучше не использовать
varchar(n) имелся в виду лучше не использовать
VY
varchar без лимита по длине
varchar(n) имелся в виду лучше не использовать
varchar(n) имелся в виду лучше не использовать
> varchar(n) имелся в виду лучше не использовать
почему?
почему?
EM
> varchar(n) имелся в виду лучше не использовать
почему?
почему?
ну при вставке длинной строки эксепшен будет
EM
> varchar(n) имелся в виду лучше не использовать
почему?
почему?
YS
не вижу ничего против
varchar, если действительно нужно ограничивать длину. зачастую даже полезно… без ограничений — text проще, т.к. писать меньшеvarchar и text без ограничений довольно близки. Но я бы выбирал text — это native type, corner cases с ним чуть-чуть меньше.
А для ограничений есть CHECK.
А для ограничений есть CHECK.
VY
Yaroslav Schekin
varchar и text без ограничений довольно близки. Но я бы выбирал text — это native type, corner cases с ним чуть-чуть меньше.
А для ограничений есть CHECK.
А для ограничений есть CHECK.
они внутри одинаково реализованы
EM
Это для визуализации. Я через typeorm буду делать а не на чистом sql
в некоторых ормах (не знаю что такое typeorm) по дефолту варчар требует ограничений. в частности django orm
YS
Это для визуализации. Я через typeorm буду делать а не на чистом sql
Ну и эту "визуализацию" мало кто понимает (потому что их немало, и все они примерно одинаково бесполезны).
Как "удачно", правда? ;)
Как "удачно", правда? ;)
VY
ну при вставке длинной строки эксепшен будет
именно так. и я хочу, чтобы он был, чтобы данные в таблице соответствовали тому формату, что в него заложен
если нужно хранить просто большие чанки — конечно
если нужно хранить просто большие чанки — конечно
textR
Yaroslav Schekin
Ну и эту "визуализацию" мало кто понимает (потому что их немало, и все они примерно одинаково бесполезны).
Как "удачно", правда? ;)
Как "удачно", правда? ;)
Да. Но "просто посмотреть" пойдет
s
Альтернатива — лог изменений, как было выше сказано, только инсерты. Либо в партицию, либо(какашками не кидать) в отдельную таблицу yyyymmddhh
Apache kafka просится
EM
именно так. и я хочу, чтобы он был, чтобы данные в таблице соответствовали тому формату, что в него заложен
если нужно хранить просто большие чанки — конечно
если нужно хранить просто большие чанки — конечно
textну да
вот бывает расчитываешь что не будет строк длиной 255 а потом в продакшене они появляются )
вот бывает расчитываешь что не будет строк длиной 255 а потом в продакшене они появляются )
YS
они внутри одинаково реализованы
Ну и что? А "снаружи" поведение-то немного отличается в крайних случаях.
В общем, правильную Вам ссылку дали.
В общем, правильную Вам ссылку дали.
VY
Yaroslav Schekin
Ну и что? А "снаружи" поведение-то немного отличается в крайних случаях.
В общем, правильную Вам ссылку дали.
В общем, правильную Вам ссылку дали.
да в курсе я этой ссылки-то… и в курсе отличий во внешнем поведении
YS
Да. Но "просто посмотреть" пойдет
Кому, извините? Если лично Вам — смотрите, но зачем это тут выкладывать? ;)
EM
ну это конечно дело конкретной задачи
иногда varchar(n) нормально и может правильно
но так в целом кажется в большинстве случаев просто головная боль
иногда varchar(n) нормально и может правильно
но так в целом кажется в большинстве случаев просто головная боль
YS
ну это конечно дело конкретной задачи
иногда varchar(n) нормально и может правильно
но так в целом кажется в большинстве случаев просто головная боль
иногда varchar(n) нормально и может правильно
но так в целом кажется в большинстве случаев просто головная боль
Да редко когда именно такие ограничения бывают. И даже в таких случаях CHECK с length как-то приятнее, IMHO.
AG
Apache kafka просится
тут много что просится, вопрос возможности изменения приложения и процессов