s
Yaroslav Schekin
Вам не кажется, что это крутовато? Есть много (довольно очевидных) ситуаций, где int на практике хватит "навсегда" — поставщики, клиенты, сотрудники и т.д. и т.п.
Никогда нельзя предугадать.
Size: a a a
2020 May 22
s
Вот серьезно. Ребята из openstreetmap тоже думали что им int хватит когда-то
V
Ну а как это сделать. Есть два списка id. Один те что в компании. Второй что у пользователя. Тут либо итерироваться по первому и проверять что кто-то не попал во второй. Либо проверить вхождение множества.
Вы описания таблиц то покажите? А то по вашим словам, связь ачивок с компанией в той же таблице, где и связь ачивок с пользователями....
YS
Никогда нельзя предугадать.
Преувеличиваете, вот серьёзно. См. примеры выше.
s
Yaroslav Schekin
Преувеличиваете, вот серьёзно. См. примеры выше.
Ну так если записей мало, то зачем место под пару байт экономить? А если много - ну вы таки поняли.
s
Но вообще на откуп проектировщику конечно
АК
Вы описания таблиц то покажите? А то по вашим словам, связь ачивок с компанией в той же таблице, где и связь ачивок с пользователями....
Нет конечно. Я же написал что связь у компаний с ачивками один ко многим. Значит у ачивок есть foreign key на компании. Всего 4 таблицы. Компании, ачивки, пользователи и таблица связей пользователей с ачивками.
s
Нужно то в итоге конкретно что? Ачивки имеющиеся перечнем получить нужно? Отсутствующие перечнем нужно? Количество тех и других? Сам факт отсутствия всех ачивок?
YS
Ну так если записей мало, то зачем место под пару байт экономить? А если много - ну вы таки поняли.
Если с этой стороны смотреть — то, в принципе, да. ;)
Но все эти id-ники могут быть и в (многих, потенциально) FK, и размер таблиц, к примеру, many-to-many (теоретически) может существенно отличаться.
Но все эти id-ники могут быть и в (многих, потенциально) FK, и размер таблиц, к примеру, many-to-many (теоретически) может существенно отличаться.
YS
Нет конечно. Я же написал что связь у компаний с ачивками один ко многим. Значит у ачивок есть foreign key на компании. Всего 4 таблицы. Компании, ачивки, пользователи и таблица связей пользователей с ачивками.
Вот и показали бы эти таблицы — сколько можно "танцевать о литературе"? ;)
V
У ачивок ФК на компанию и мтм к пользователям.... И всего 4 таблицы...
MS
Добрый день! Вопрос по внешним ключам. Можно ли удалить запись из главной таблицы, если на эту запись больше не ссылаются внешними ключами никакие записи из другой таблицы? Подскажите, пожалуйста
s
Можно даже если ссылаются, но не указано on delete restrict
YS
Добрый день! Вопрос по внешним ключам. Можно ли удалить запись из главной таблицы, если на эту запись больше не ссылаются внешними ключами никакие записи из другой таблицы? Подскажите, пожалуйста
Да.
YS
Можно даже если ссылаются, но не указано on delete restrict
Эээ... нет?
W
Ув. тов. мозг, какие есть варианты чтобы ускорить работу Пг, кроме отключения fsync? Сохранность данных не важна (я опять про тесты), время жизни данных - пока с ними работают. Потом кластер будет удален.
РЖ
Ув. тов. мозг, какие есть варианты чтобы ускорить работу Пг, кроме отключения fsync? Сохранность данных не важна (я опять про тесты), время жизни данных - пока с ними работают. Потом кластер будет удален.
Сделать все таблицы unlogged
W
Роман Жарков
Сделать все таблицы unlogged
На unlogged вроде транзакционная целостность не распространяется.
s
Yaroslav Schekin
Эээ... нет?
Ну удалить то даст физически. Либо удалит и в ссылающейся таблице при cascade, либо null воткнёт.
Можно ли с организационной точки зрения - на мой взгляд вопрос за пределами компетенции чата, оттого вряд ли задан именно в этом смысле.
Возможно, конечно, есть целая цепочка из таблиц с FK, в которой очередной ключ restrict кинет.
Можно ли с организационной точки зрения - на мой взгляд вопрос за пределами компетенции чата, оттого вряд ли задан именно в этом смысле.
Возможно, конечно, есть целая цепочка из таблиц с FK, в которой очередной ключ restrict кинет.
YS
Ув. тов. мозг, какие есть варианты чтобы ускорить работу Пг, кроме отключения fsync? Сохранность данных не важна (я опять про тесты), время жизни данных - пока с ними работают. Потом кластер будет удален.
https://www.postgresql.org/docs/current/non-durability.html
Кстати, по идее, synchronous_commit по сравнению с fsync — примерно то же самое по производительности, зато кластер не "накроется", если что.
Кстати, по идее, synchronous_commit по сравнению с fsync — примерно то же самое по производительности, зато кластер не "накроется", если что.