так проблема в тебе, а не в преподавателе. Это в школе тебя учат, а в ВУЗе ты сам учишься.

@@DenisAvant выздоравливай

Ваш препод часы расстягивал!

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

О, отлично, рад, что полезно!

Спасибооо!

Мне кажется, что большинство бы предпочло чтобы Леша потратил свое драгоценное время на более нужные в разборе темы, нежели остальные НФ, вы уж извините меня))

​@@baturin_m Никого не заставляю. Комментарий имеет право на существование 🙃

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

Называется денормализация

В таких случаях хранятся нормализованные данные и на основе нормализованных генерируются денормализованные. И соответственно считаются за правду только нормализованные. Денормализованные только читаются и перезаписываются У нас такая схема

Мне кажется он так и объяснил за исключением порядка строк в 1НФ. Впервые слышу об этом.

и рекламы

Да. Только PK не вводил бы суррогатный всё равно

@@t0digital А вдруг android переименуется )

@@t0digital Для варианта с искусственным (суррогатным) первичным ключом ограничение предметной области можно не вводить. Но! Если это ограничение существует объективно (например, в фирме есть правило, запрещающее в одном и том же отделе на одной и той же должности работать людям с одинаковыми ФИО), нам придётся создать уникальный индекс на полях фамилия, позиция и отдел. Поэтому думаю, что для текущего примера - действительно странно вводить суррогатные ключи, можно ведь напротив каждого телефона указать его ось. Но я бы скорей сделал уточнение мол декомпозиция в следующих (2, 3 и тд) нормальных формах это адекватные вещи, а здесь она действительно избыточна. Верно же?

@@SergeySenkin Да. В декомпозиции нет ничего плохого, просто не всегда декомпозиция одной таблицы на две это именно нормализация

Союз 013 fet

Нужно ждать новую версию

В постгресе есть функция pg_column_size, которая показывает размер данных конкретного значения. pg_column_size('Android') - 8 байт pg_column_size(1::bigint) - те же 8 байт Если таблица большая, то идентификатор тоже делают bigint, не просто int. Или UUID - а это уже 16 байт. То есть строковое значение не обязательно занимает больше памяти. Во втором случае - как правило лучше сделать join, чем два запроса.

Да, потерялся, Северная Корея спёрла:)

Вот я тоже заметил, где про 2ю нф, что в 2й таблице от owner_id не зависит фоне

Эта табличка показывает связь "один ко многим". Здесь owner id это внешний ключ. Внешний ключ может быть неуникальным.

@@user-kw4kp7eq9m в видео явно прозвучало, что owner_id есть первичный ключ (11:11). Также прозвучало, что это поле автоинкрементальное. В общем, объяснение понятно, но с картинкой не согласуется. И это запутывает

Запутанно да. Соглашусь. Но Алексей, наверное, имел в виду у таблички "owners" (которой там вообще на скрине нет, но он как бы ее имел в виду), owner id это первичный ключ. Так видимо он мыслил.

Может быть лучше как одно, так и другое. Начать лучше с варианта множества таблиц

Это Союз:) идёт в аналоговый усилок (но не ламповый) и звуковуху:) но эхо бью уже на постпродакшн в изотопе, комната большая, не глушил

@@t0digital Ага, а по логотипу похож на Нойман зелёненький с трансформатором) Ну союз - да тоже хорошие микрофоны, но редкие. В целом - да, звук такой плотный. Ну и за нормализацию спасибо. Все равно бывает трудно отличить глядя на структуру "боевой" БД к какой форме она относятся. Может просто опыт большой нужен.

@@t0digital Ага увидел у вас в инсте Long, работал с ним - отличный предвак 👍😀

@@SergMirny_yt спасибо! По уголку определили:) Случайно на него натолкнулся и не мог не купить, больно хвалили:)

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

Ответ есть на видео в разделе "Это не нормализация". 6:18

Ну как раз таки вариант с суррогатным ключем мне больше нравится.)

@@user-kw4kp7eq9m да, потому что он правильный, по многим причинам.

@@AlexandrZverev ​ он не является правильным по умолчанию для всех возможных случаев, как и не является неправильным для всех возможных случаев. Вы пытаетесь упростить жизнь до единственно верного решения, это глупо.

@@t0digital да, вы правы, глупо. Действительно, практика на однотипных учетных задачах приучила к этому шаблону, а случаи бывают разные.

Касательно того, относится вынос в отдельную таблицу к нормализации или нет - вы спорите с автором ВУЗовского курса по СУБД, учебником по СУБД, который писался под кураторством Postgres Professional, если вам это о чём-то говорит, цитату из этого учебника я приводил в видео. В цитате было даже пояснение, почему это не нормализация

согласен

Первичный ключ должен быть уникальным и not null, всё так

Там owner_id это не PK. Ключ надо делать или дополнительным полем, или составным из owner_id и phone, если оно уникально

@@t0digital Благодарю за ответ!

@@t0digital зачем вы тогда вводите в заблуждение - на 11 мин и 15 сек вы говорите, что owner_id это первичный ключ

декомпозиция применяется для достижения нормальных форм. Верность декомпозиции проверяется по теореме Хеза, когда из производных таблиц должна получиться базовая через natural join, иначе она выполнена неверно. Т.е. для декомпозиции должны быть основания и она должна быть корректной.

Не может быть двух Петь, но два человека могут показать на одного Петю. Тоже самое в примере

Тут надо понимать, есть ли задача работать с ОС отдельно от телефонов. Если есть, значит существует отдельная сущность ОС и её надо декомпозировать в свою таблицу

Насколько я понимаю, голым сиквелом осуществлять добавление чего либо в таблицы - это неправильно! Для этого пишут интерфейсы на процедурных языках типа PL или PLpg

@@user-so7hf8xi7i да не, как правило на sql и пишут. Когда есть dba которые оч любят в pl/pgsql и оч хотят его писать, ну что-то могут написать, да

@@t0digital В моём мире ДБА ничего не пишут, у них совершенно другой функционал. Я совершенно не понимаю как и зачем совершать изменения или вставки в таблицы с ограничениями целостности на чистом сиквеле. Но я и не разработчик. Если это делать без интерфейсов, то гнусный человеческий фактор испортит жизнь ИМХО.

@@user-so7hf8xi7i я работал в нескольких компаниях, в которых дба ещё как писали

Северные корейцы спёрли:)

и то верно:)

Ты про схему на 11:00? В таблице верхней ключ составной - phone и owner_id. 2 этих поля вместе уникальны. В таблице левой нижней ключ - phone. Это поле not null и уникально, а значит может быть первичным ключом. В таблице правой нижней ключ - составной, owner_id и phone.

@@t0digital я говорю про правую нижнюю таблицу. на 11:15 вы говорите, что в этой таблице первичным ключом является именно owner_id. Если первичным ключом является строка целиком, то вопросов нету (хотя странно, что строка целиком это и есть первичный ключ)

@@t0digital в общем получается вы просто оговорились?

​​​@@user-gg4ru6so9hда, я оговорился. Тут не показана таблица владельцев телефонов, там ключ будет числовой, в таблице телефонов строковый, а в связующей таблице составной из 2х колонок - числовой и строковой

@@t0digital спасибо за объяснение. может логично было бы этот момент перезаписать и перезалить ролик, раз там ошибка есть? потому что судя по комментариям не у меня одного такой вопрос возник

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

Название телефона уникальное поле и NOT NULL, и поэтому это PK в таблице телефона. Или вы о другом поле?

@@t0digital нет, я про слова на 11:18 именно. "Первичный ключ это owner_id"

@@tumkir я имею в виду, что owner_id в правой таблице на 11:18 это Foreign Key на таблицу owner, в которой Primary Key это число. В самой правой таблице атрибут owner_id это не Primary Key, конечно

@@t0digital ну то есть получается что во второй таблице РК нет и это просто оговорка. Кстати, первичный ключ не обязателен в этой НФ (и других)?

Ага

Я начинал смотреть это видео, досмотрел до момента, где говорится о нормализации с примером, который нормализацией не является, закрыл после этого. Там автор делает видео по чужим статьям, как понял, так что претензия в первую очередь к автору статьи

@@t0digital т.е. заимствовал без ссылок у того, кто сам так сделал и всё ок?

Нет

Так об этом же сказали)))

Спасибо за ваше мнение, лень спорить

Жаль...

Ну давайте, аргументируете, раз уж накидываете. Конкретику только, пожалуйста, вот тут автор (я) сказал то-то, а вы считаете, что надо так-то. Чтобы без бла бла.

@@t0digital сразу скажу я не силен в этом всем, но я солидарен с коментатором. Когда была речь о первой нормальной форме, там был пример сделать таблицу «ось» как отдельную и просто через фк связывать и мол это лишний джоин и тд. Но разве это бы не исключило в то же время человеческий фактор? я делаю инсерт и пишу вместо “Android” “android” и как мне допустим фильтровать данные по «ос»? тогда сидеть делать через LIKE?) Я не истина и на нее не претендую) Просто имхо

@@user-zm2mn1kr6q я же говорю о нормализации в этом видео. Строковый аргумент вынести в отдельную таблицу и ссылаться на нее с суррогатным ключом это не нормализация и я об этом - некорректно такой пример называть нормализацией.

@@t0digital Я тоже порой люблю спрашивать у тех у кого вокруг все гвно. А что тогда не гвно?))) И с аргументами пожалуйста))) И Сашка Зверев сдулся))) Как я понял первый пример это разделение на две таблицы не есть нормализация. А все подробности того кто как сделал БЫ, это уже не важно. Спасибо за объяснение я теперь хоть знать буду что такое есть)))

@@t0digital Ну смотрите, сначала вы говорите, что нормализация - это здравый смысл, оформленный в определенных терминах, а затем зачем то приводите пример разделения на таблицы с числовым ключом, который абсолютно правильный и говорите что это не нормализация (хотя многие называют это нормализацией). Поэтому здравый смысл негодует, его отставили в сторонку, ради теории. Тогда лучше было бы его вообще не упоминать, или не упоминать этот пример. Ок, бла, бла, бла всё. По сути, почему пример, который не нормализация правильный: 1. Размер БД. 2. Выделение ОС отдельным объектом со своим уникальным идентификатором и свойствами. Прощайте копии с разными наименованиями одной оси, и привет удобной работе с данным объектом. 3. Числовой ключ быстрее текстового, если не вводить индексы. Почему то мне из изучения нормализации запомнились когда-то пример с числовыми ключами, может быть потому что тогда еще не было пайтона и мощных компьютеров, которые прощают любые проектные решения.

Конечно, индексы хранят данные, вы откуда свалились? Почитайте про index only scan, когда вся выборка происходит из индекса, без обращения к таблице

@@t0digital Признаю, это частный случай в pg. Есть частный случай в ms sql в виде included fields. Но вы же это не указывали. В общем случаи индексы не дублируют данные и хранят ссылки.

А как работает, например, btree-индекс не в pg? Как он может не хранить данные? Ссылки на таблицу там есть, конечно, но и сами данные тоже есть, в упорядоченном виде для ускорения поиска.

@@t0digital Да, конечно, сами индексируемые данные хранятся в индексе. Переслушал видео, понял, что меня тригернула фраза "избыточные данные" и неверно восприняв контекст я сморозил х...ю. Почему-то клинонуло на хранение значимых данных не являющихся индексом как в случае с включенными полями. Был не прав. Приношу извинения.

Хуясе заявочки!