Я так понял, после прочтения книжки по постгрес Алексей открыл для себя что-то новое и интересное и решил поделиться этим с остальными) спасибо большое!

@sio80orel

Жыл бұрын

хоть кто-то читает эти унылые книжки)

@MrLotrus

Жыл бұрын

Алексей дал значительно больше чем там есть

@codingfox

Жыл бұрын

@@sio80orel унылые можно не читать) про книжку о postgres я бы такого не сказал

Топ контент, так нехватает чего то выше джуновского уровня, а не треша какой ЯП изучать новичкам.

@user-xp5bw5nl6i

Жыл бұрын

Просто вам не часто такое попадается. Ищите и найдёте

@_4ado

Жыл бұрын

​@@user-xp5bw5nl6i ну не надо басней, 49.5% контента для людей уровнем выше джунов это конференции, ещё 49.5% это видосы с неподражаемым индийским акцентом по скидке за 480 рублей и 1% это видосы вроде этого

@Erwin_Anderson

Жыл бұрын

@@user-xp5bw5nl6i Мб посоветуешь что то?)

@user-zf5vn2lw8b

Жыл бұрын

​@@Erwin_Anderson совет один, сиди на попе ровно

Спасибо, полезно! Мозг прям возрадовался приятной и понятной подаче материала! 👍

Алексей! Доброго времени. Внедрю пожелание лайфхака. Следующее видео делайте в соседней комнате. Мы-же тоже дзырим ваши замечательные апартаменты. Пыточную из прошлых видео изучили, теперь понятно место откуда вещали прошлые видосы. Похоже что дальняя коричневая дверь стоит на вентиляции микроклимата. Фигасе. Спасибо за идею. За окна понятно, но двери - это свежо!😂 Отличный контент. Ну сказать что-нибудь надо, вот и сказал. Вот...

Спасибо! Как раз сейчас тема MySQL в ПТУ прохожу. Ну и вообще курс, ваш, очень помогает.

Спасибо! Интересно было послушать по UUID и всё с ними связанное. Понравилось, что осветили плюсы и минусы каждого подхода/типа. 👍

Большое спасибо. Очень полезная информация

Спасибо! Очень полезно! Думал, что давно всё знаю по этой теме.

Спасибо, тебе за такой ролик, узнал для себя много нового. Делай дальше, у тебя это круто получается

Я только недавно начал изучать PostgreSQL, но некоторые моменты из видео заставили более внимательно относиться к структуре БД.

От души спасибо, очень легко и интересно рассказываешь.

Очень качественный материал 👍 спасибо

Спасибо, было познавательно! Отличное видео.

Это просто охуительно, бесконечно великолепно! Спасибо за просветление

Очень полезная информация. Буду использовать в своем дипломе)

Спасибо за Primary key. интересные мысли, рассуждения

Большое спасибо за вашу работу. Отличное видео, очень полезный материал!

@t0digital

10 ай бұрын

Спасибо!

Спасибо, было очень интересно и полезно!

👍Спасибо большое за видео. Для себя узнал несколько полезных штучек! Алексей, ты крут!✌😁

Ржу нимагу! "Но вот на практике нифига, нифига!" )) Классно делаешь ролики, много информации и весело! Продолжай в том же духе! :D

Первичные ключи в маленьких табличках часто бывают внешними ключами в больших. И вот там можно много сэкономить.

Спасибо, очень информативно!)

Сел покушать, а тут и годный контент подъехал. Сразу лайк!

Сначала накачал с трекеров терабайты обучащих курсов от инфоцыган теперь позатер их и смотрю ваши ролики. КПД намного выше. Большое спасибо.

Доступный и подробный разбор вариантов первичных ключей, спасибо за информацию! Наверное нет смысла спорить о применении в первичных ключах int или даже smallint, потому что если такая надобность будет, то разработчик это увидит и применит. А кто-то посчитает что необходимости применения 2-х или 4-х байтового числового первичного ключа не случается никогда.

@vryaboshapko

Жыл бұрын

Я знаю примерно три случая, когда можно использовать small int в качестве первичного ключа, и во всех трёх случаях есть решение в виде естественного аналога: это списки валют, стран и языков. На все три есть ISO с буквенными кодами, и такие коды будут сильно удобнее, потому что их после минимальной тренировки может читать человек. Не то, чтобы я утверждаю, что small int категорически не нужен, просто вспонилось несколько частных случаев.

Отлично рассказан материал, коммент для активности.

Для тех кто не знал, количество номеров ограничено. Операторы очень часто перепродают номера, которыми давно не пользовались. Така ситуация буквально с моим номером произошла. Год не пользовались симкой, не пополнялся баланс и у меня её номер забрали и отдали другому человеку

@vryaboshapko

Жыл бұрын

Перепродажа номеров - это скорее не от ограниченности номерного пространства, а от экономии. В России телефонный номер состоит из 10 цифр, это 10 миллиардов вариантов, это больше, чем людей на земле. Даже если взять, что у мобильных номеров первая цифра всегда 9, всё равно остаётся 1 миллиард номеров, это больше, чем по 7 номеров на каждого жителя страны. Но расширение номерного пространства стоит денег (нужно «купить» ещё один префикс), так что логично использовать номера отключённых абонентов.

Частный случай префиксных ключей - это номера паспортов и других подобных документов. Они содержат серию и номер. Серия назначена по территориальному принципу, а номер - это просто счётчик. То есть, каждому актору, имеющему право генерировать первичный ключ, присваиватеся свой префикс, а он внутри себя следит за простым счётчиком. Причём, счётчик персистится с помощью write ahead log: каждый новый паспорт заносится в журнал, и ему присваивается номер на единичку больше от предыдущего занесённого. Ничто не ново под Луной, как говорится)

Спасибо! Очень полезно!

Спасибо за видео! У меня тоже была как проблема с инкрементом sequence, когда я прям на горячем проде с 150k rpc в секунду добавил строку вручную с явным указанием id. И как посыпались ошибки! Ух... Хорошо быстро поправил sequence номер.

Спасибо, много нового узнал.

Спасибо большое! Было очень интересно и познавательно, хоть я и мобильный разработчик)

Классный первичный ключ - сотовый телефон Только у пользователя может быть несколько телефонов, ну и телефон можно потерять. На мой взгляд - Естественные ключи использовать крайне ненадежно. Вы должны быть уверены, что естественный ключ уникален в рамках проекта, концов которой не видно. (Подразумевается что вы работаете в проекте, а не пришлый наемник для решения одной задачи) Префиксы в начале - это реинкарнация Венгерской нотации от MS 😃

@t0digital

Жыл бұрын

Один телефон может быть главным, остальные будут сохранены дополнительно (если нужно их сохранять). Тут больший вопрос по смене телефона, если он PK, то надо будет менять потенциально много записей в разных таблицах, что может быть тяжело. Поэтому пример с телефоном может быть не лучший, да, но мне важнее было показать суть.

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

@andreybogdanov3

Жыл бұрын

on update cascade 😉

@vryaboshapko

Жыл бұрын

Вцелом согласен, но тут стоит ещё заметить, что номер телефона, номер паспорта, мыло, номер аськи - это всё примеры неудачного естественного ключа, как раз потому, что они могут меняться. Примеры более удачных ключей - это налоговые номера (ИНН, TIN, NIF и др.) и номера социального стразования (СНИЛС, SSN и др.), так как они назначаются один раз и на всю жизнь.

@user-vz3uy3hh2q

Жыл бұрын

@@andreybogdanov3 спасибо, я что то забыл про такую возможность

@user-vz3uy3hh2q

Жыл бұрын

​@@vryaboshapko в таких ключах есть ещё одна проблема. Это опечатки, а ключ уникальный. И вот оператор вводит, например СНИЛС или номер серию паспорта, если это составной естественный ключ. И делает там опечатку в одной цифре. А в другую организацию приходит человек именно с таким номером, например паспорта. И в той организации ввести его данные не могут и разобраться без помощи разработчиков тоже не могут, потому что опечатку сделала другая организация. В итоге в базе данные не правильные и ввести правильные нельзя. В общем использовать естественные ключи можно, но как по мне с таким количеством нюансов - ну его...

@vryaboshapko

Жыл бұрын

@@user-vz3uy3hh2q для этого в СНИЛС и ИНН зашита проверка целостности. Грубо говоря, если хитро сложить первые цифры, получится последняя (точные алгоритмы публичны и легко гуглятся). Такая же, кстати, есть для номеров баноковских карт, но это не относится к теме естественных ключей). Плюс есть публичные базы данных, по которым можно провалидировать, например, что номер соответствует ФИО или дате рождения. А номер паспорта точно нельзя использовать как естественный ключ (даже как часть составного) по той же причине, что и номер телефона: он меняется. Это уникальный номер документа, а не человека.

Это я люблю, спасибо!

Если phone_num PK, то чел. уже не сможет его поменять. PK -- это не только UNIQUE NOT NULL, но ещё и read-only. Всё же не нужно юзать phone_num в качестве PK. Это сущность/запись клиент-человек. Даже здравый смысл подсказывает нам, что нельзя его отождествлять/идентифицировать/привязывать к номеру телефона.

Благодарю!

Спасибо за информацию

23:00 как ни странно иногда вставка уидов может быть быстрее чем вставка в условный bigint. Особенно если база уже большая и не новая, по той же как раз причине, что вы и описали. При очень интенсивной вставке, если вставка идёт одновременно из множества сессий, то возможны проблемы за конкурентный доступ последней страницы в которую данные льются, а при уидах вставка происходит в рандомные страницы в разных местах индекса и сессии друг другу не мешают)

@alexeyvoronin4651

Жыл бұрын

Вопрос не в вставке, а в последующем использовании. Чем тяжелее ключ, тем тяжелее join .

@MichioSempai

8 ай бұрын

При интенсивной вставке в таблицу где pk - uuid, будет происходить очень частая и тяжёлая перестройка индекса, из-за этого как раз и может происходить существенная просадка по производительности.

Спасибо за контент! А я даже не думал что такие способы есть. На мой взгляд id должен быть наподобии штрих-кода, но чтоб информация там была зашифрована для стороннего пользователя.

Круто :)

По примеру с естественным ключом в виде номера телефона: - очень удобно, особенно когда пользователь хочет поменять номер телефона. Т.е. что проще, посмотреть по номеру телефона id и далее делать все тоже самое по id или при смене телефона иметь ад по сохранению целостности данных? Проблема в том, что зачастую многие естественные ключи не являются абсолютно константными и это создает гораздо большую проблему, чем та польза, о которой говориться. P.S. да, я читал статью про IDотов, к сожалению не могу придумать каламбур про Естественно-отов =)

12:50 - при этом надо понимать, что естественный первичный ключ для справочника тех же пользователей - это та еще мина замедленного действия (помимо потребности хранить длиннющий UID или 11 знаков номера телефона во всех связанных таблицах, где могут быть сотни миллионов записей). Из того же примера в видео: вот пользователь деактивировал сим-карту и мобильный оператор продал этот номер спустя время новому физ.лицу :) Логика сломается уже на этапе регистрации в приложении где-то на бэкенде при обращении к базе. Про момент защиты персональных данных уже в ролике озвучено - тут сразу получается не вариант с естественным первичным ключом

Сразу лайк!

Хороший материал, которого всегда не хватает. Кстати, а какую вы тему используете для psql? Вижу, что у вас есть автодополнения и подсветка.

@t0digital

Жыл бұрын

Это pgcli

не досмотрел еще, и не знаю подняли ли эту тему, но хочу сказать, что правильные первичные ключи важны для производительности некоторых кейсов пагинации (я говорю про то, что зачастую правильный первичный ключ - это единственный способ сделать правильную пагинацию без использования медленного оффсета)

По поводу always generate. А что если нам требуется восстановить таблицу из бэкапа и при этом в ней есть пропуски(удаленные записи)?

Алексей, респект за контент, а когда будет стрим как на новый год?очень душевно было

Приветствую! Спасибо за видос, очень актуально и полезно. Интересно ваше мнение по вопросу: где удобнее всего и эффективнее разрабатывать схему БД? В кансоле сразу, или может в pgAdmin, а может по старинке на листочке схему рисовать?)

@t0digital

Жыл бұрын

Для проекта, когда думаю о данных, сущности рисую иногда сначала на бумаге, чтобы было наглядно. А создавать таблицы уже где угодно. Миграциями как правило, джанговыми или алембик

Очень неплохо бы разобрать тему uuid6 в сторону ускорения до uuid7 и 8

спасибо!

Классные видосы для гиков у тебя. Я подписан

@t0digital

Жыл бұрын

Спасибооо!

Про использование identity column было очень интересно. Не был в курсе подобной опции. Впрочем, при грамотном использовании serial не доставит никаких проблем. Достаточно целиком отдать генерацию id на откуп базы данных

"Индекс - это отсортированная структура данных" - это справедливо для b-tree, но есть ведь индекс, основанный на хэш-мапе

Как можно проверить, что uuid_v6 (ulid, objectId) в качестве primary_key работает быстрее на больших объемах данных, чем uuid v4? Какой тест тут лучше применить? Для записи приходит в голову что-то типа "генерируем 10ккк uuidV4, затем в другой таблице 10ккк uuidV6, сравниваем время". А для чтения это как лучше проверить?

А есть видео где рассказывается про настройку терминала? Что бы так же дополнение запросов было? Или же это именно дополнение из консоли постгресс ?

А что если префиксную часть сделать модифицируемой по длине? Тогда мы сможем выбирать приоритет на скорость записи или скорость чтения из БД соответственно по скорости формирования и чтения индекса

Пример с телефоном очень показательный. Есть у нас история действий пользователей с неким номером телефона. Казалось бы удобно. Но люди бывают что меняют номера телефонов. и если пользователь сменит свой телефон он лишиться всей своей истории.

Алексей, а как ты настроил code-completion при работе с psql в терминале?

@brenkovd

Жыл бұрын

pgcli

Мысль про ключи естественные ок, но пример с номером телефона плох(опасен). Клиент может захотеть сменить номер телефона и вот тут придётся менять ваш PK, что выльется в проблемы и боль миграций.

а если использовать "generated always as identity" то не будет проблем при импорте? Например если одна запись удалена просто заново сгенерировать не вариант.

Капец ты гений какой то)

Алексей, подскажите пожалуйста, насколько будет эффективен индекс для поля, ну допустим varchar(300)?

@t0digital

Жыл бұрын

Да просто потестируйте сами. Сгенерите данных, сколько у вас будет в табличке, сделайте analyze, чтобы обновилась статистика, и сравните выборку без индекса и с индексом. Индекс - не гарантия эффективного выполнения запроса, он даже не обязательно будет использоваться в конкретном запросе, это как планировщик решит.

Алексей, а что по поводу скорости поиска по uuid ключам по сравнению с числовым типом? Кажется сравнение строк должно сильно ухудшить этот показатель. Или для uuid используется какое-то хитрое быстрое сравнение?

@romul23

Жыл бұрын

Postgresql автоматически создает индекс для primary key. Поиск по индексированному полю работает быстро.

@programisli

Жыл бұрын

UUID это не строки, а 128 бит и нужно сравнивать 128 бит, что достаточно быстро. Но int будет занимать меньше месте на диске и если это внешний ключ то по числу поиск будет чуть более эффективнее, потому что меньше нужно держать в памяти или читать с диска. Просто индекс будет компактнее

@cristianglodeanu2329

Жыл бұрын

@@programisli пхах, какраз когда прочитал 128 бит, в видосе на 20:13 прозвучало "весит 128 бит"

@vryaboshapko

Жыл бұрын

128 бит - это 16 байт. То есть, сравнение двух UUID-ов занимает столько же времени, сколько сравнение двух строк из 16 символов (если речь не про юникод, конечно). Но стандартоне текстовое представление UUID-а (123e4567-e89b-12d3-a456-426614174000) - это 36 байт, то есть, сравнение двух строковых представлений UUID-ов занимает больше времени, чем сравнение двух честных UUID-ов. Кроме того, UUID в памяти может быть представлен не как набор байт, а, например, как два лонга (64-битные целые), и тогда сравнене будет ещё быстрее, потому что современные 64-битные процессоры могу сравнивать 64-битные целые за один такт.

@stripeberry

Жыл бұрын

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

UUID v6 выглядит перспективно, но я бы вообще пошел дальше и использовал nanoTime, а для формирования рандомной части оставил последние 11 байт (12 символов).

21:01 - чтобы ориентироваться по времени как вариант можно использовать uuid v7

крутая картинка. кач хорош

как в ПГ при импорте дампа сделать ремап имени схемы по аналогии с oracle remap_schema? =(

Полезное видео, спасибо! А где можно найти параметр, отвечающий за такую зеленую подсветку кода?

@t0digital

6 ай бұрын

Спасибо! Это pgcli

4:08 а потом пользователь захочет сменить почту) и полетел наш первичный ключ во всех связных таблцах. Первичный ключ лучше всегда делать искусственным.

@programisli

Жыл бұрын

Конечно это просто пример, хотя не вижу проблем с заменой email, это же не автоинкремент и поле изменять можно. Будут проблемы с обновлением связей - да, но решаемо. Никогда не говори всегда. Возможно email был не самым лучшим примером, но вот например у тебя есть таблица стран и у стран есть Abbreviation - Name со значениями RU - Россия, US - США. Не нужен тут искусственный ключ, если первичный ключ на Abbreviation будет уникальным, и гарантирует уникальность Abreviation.

@kl45gp

Жыл бұрын

@@programisliтак вот чтобы потом не думать как исправлять, надо тупо делать искусственный ключ. По этой же причине надо не думать и делать сразу микросервисную архетиктуру, потому что сделав монолит через года можно сильно пожалеть.Сколько таких случае когда куда не глянь а все монолит свой пилят на сервисы? Всетоки есть практики - железны, которые уже написаны кровью

@kl45gp

Жыл бұрын

@@programisli а потом в один прекрасный момент у страны всеже поменяется Abbreviation-Name) Или изменится вид с двух значного на трехзначный.

@t0digital

Жыл бұрын

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

@kl45gp

Жыл бұрын

@@t0digital все решается, только нафига перебирать все таблицы и заменять связи? Когда есть скажем так профессиональные подходы, я имею ввиду некое решение сбалансированное которые не подведет никогда как показывает практика. И чего кривляться когда оно надежное? Это как многие вещи в разработке стали стандартами дефакто, например докер. Чтобы ты не делал всегда все делай в контейнерах - простой рецепт решающий все будущие проблемы. Или микросервисы - никогда не делай монолиты иначе рано или поздно обожжешься на масштабируемости.

А почему у вас PSQL такой красывый? На первой минуте. Или это для маков эксклюзив?

@t0digital

Жыл бұрын

pgcli

До этого видео относился к UUID как к безумной глупости. Побежал добавлять это дело к себе в петпроект

👏

Прикольное худи Lacoste. Подскажи, модель или серийник)

Круто! А про индексы планируется видео?

@t0digital

Жыл бұрын

возможно:)

Как в постгре работают индексы под капотом уже был видос? :)

Кайф

9:30 т.е. create view с join и работать так же с телефоном но с view нет?

@t0digital

Жыл бұрын

не понял вопрос

23:32 а в чём сложность с WAL в этой модели?

Будет ли видео про обновление питона до 3.12?

@t0digital

Жыл бұрын

Будет

Просто для заметки: Если x = "Иногда" и y = "Всегда" то y = K * x, при условии К - частота случае "Иногда" и она стремиться к бесконечности )))))

Расскажи про timescaledb

а что делать, если юзер, которую вы определили первичным ключем номер телефона, поменял номер телефона? получается, что возможности в аккаунте на смену номера уже не будет?

@t0digital

Жыл бұрын

Возможность есть, но, конечно, надо тогда везде будет менять ключи во всех таблицах, ссылающихся на юзера. Смена телефона к которому привязан акк это оч редкая операция. Тут вот в комментах кто-то писал, что в ВК решается через запрос в поддержку с паспортом

@kotbajan

Жыл бұрын

Для микросервисной архитектуры, где создать общий ID для всех систем проблемно, а обрабатывать одну и ту же сущность надо - это вполне себе рабочий вариант. Широковещательным сообщением по системам разносится требование обновить PK с ON UPDATE CASCADE и должно работать. Плохой, лучше все-таки генерить сквозной ID для всех систем. И не забыть про денормализованные структуры, которая содержит те же данные, но без FK.

Спасибо, послушал с интересом. Единственно не согласен с настойчивой рекомендацией использовать bigint в качестве ПК. Обычного int хватает в 99%, если только вы не собираетесь автоматизировать весь мир. В любом случае нужно понимать на какие объемы проектируется система, и принимать проектные решения исходя из этого. Еще раз спасибо, хорошая подача материала!

@vladislavstepanov7591

9 ай бұрын

Накладные ресурсы которые уйдут на bigint не сравнятся с болью перелапачивать бд и менять типы с int на bigint

Я извиняюсь, только включил ролик и увидел прикольный вывод в консоли команд, это что за утилита? pgcli , увидел дальше в видео

@vyacheslavkapitonov9677

Жыл бұрын

pgcli

@t0digital

Жыл бұрын

Да, она. На питоне написана, немного багнутая, отправлял туда PR)

У ulid есть некоторая проблема в том, что инстансы приложения генирующие улиды могут находиться на разных физических машинах с рассинхроном времени, проблему рассинхрона ещё человечество до конца не решило. Поэтому в распределенной системе не факт, что каждый следующий сгенерированный ulid будет лексикографически старше предыдущего.

@vladislavstepanov7591

9 ай бұрын

Разве рассинхрон в несколько миллисекунд это проблема?

@wskeal86

9 ай бұрын

@@vladislavstepanov7591 фишка ULID в том, что один ULID больше другого, если он сгенерировался позже на 1мс, чем первый. Но если на разных тачках есть рассинхрон, то польза от ULID'a нивелируется и проще использовать UUID v4

Случайно наткнулся на видео, не лишним было бы упомянуть про вставку батчем и генерацию айдишников на стороне бэка.

@t0digital

Жыл бұрын

Имеете в виду, что вставка пачкой ссылающихся друг на друга записей возможна с айдишниками, которые генерятся не в базе? Об этом есть в видео

@tirnik707

Жыл бұрын

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

Говорят mongodb при частых обращениях может занимать место в ОЗУ для более быстрого ответа, наверняка ведь pg не с диска каждый раз читает? Может быть сможет кто-то пояснить?

@t0digital

Жыл бұрын

Конечно, pg не с диска читает каждый раз. Кэш и всякое такое имеется

@nikitabugrovsky1492

Жыл бұрын

Когда постгресс запускается, стартует постмастер процесс. Он ждет подключения от клиентов БД. От посмастера также форкаются множество других бэкенд процессов, которые выполняют CRUD операции и разные служебные задачи типа логирования, создания WAL, репликации. Процессы, которые выполняют CRUD, имеют общий доступ к ограниченному сегменту оперативной памяти - shared buffer. Это позволяет процессу брать результаты sql запросов из оперативной памяти, если такой запрос уже был адресован БД. Если в общем буфере результата запроса не найдено, есть шанс, что результат будет найден в кэше ОС ( другой сегмент оперативки). Если нигде ничего не найдено, придется обращаться к файлу БД - это уже IO.

Опечатка в назавании ULID v6?

@t0digital

Жыл бұрын

Спасибо, поправил

Впервые слышу термин "искусственный" в отношении первичного ключа. Устоявшимся является "суррогатный", нет?

@t0digital

22 күн бұрын

возможно, да

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

Сделай видево как быстро считать количество всех результатов выборки, с учетом фильтров, в постгресе

@t0digital

Жыл бұрын

Count(*) же

Ого, а интересно, как консоль на маке собирает таблицу для оторбражения? Красиво же выглядит, не то, что поплывшие таблицы на символах -- | А не, тоже плывёт.

Иметь или быть* если я правильно понял, то какая книга имелась ввиду

Хочу чтобы в кадре была красная кружка с лого "D!"

с таким крупным шрифтом ты очень быстро сломаешь себе глаза! 12 должен быть максимальный.

@t0digital

Жыл бұрын

Шрифт для видео увеличиваю, чтобы было видно всем

360*1500= 540к, неплохо))

@t0digital

Жыл бұрын

налоги, комиссии, съемка, монтаж, команда с зарплатами и 31 день работы в месяц - неплохо

05:57 а зачем использовать для этого именно композитный первичный ключ-то? Первичный ключ - он для идентификации. Для избежания дублирования просто создаёшь индекс уникальности по нужным колонкам. Это то, что делает первичный ключ, кстати.

@alexgorodecky1661

Жыл бұрын

Это порождает избыточность. Удобство искусственных первичных ключей зависит, в первую очередь, от запросов. Пример: settings - настройки с учётом года. Входить в эту таблицу мы всегда будем через , и ссылок из других таблиц на settings часто тоже нет. Итог - в данном случае лучше составной естественный ключ

@user-fh6xg9pn3y

Жыл бұрын

@@alexgorodecky1661 Я о другом. Выбирайте вариант, который Вам нужен. Но конкретно задача избавления от дублирования решается уникальным индексом, для неё не нужно накрывать колонки первичным ключом.

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

@t0digital

3 ай бұрын

Есть такое

get_random_uuid был добавлен в PostgreSQL 13