PHP: PHP NN #4: два доклада для поклонников Symfony и сочувствующих - видео HD

Дениса очень тяжело слушать, речь плохо поставлена, рассказывает сумбурно и с большим количеством паразитных слов. А так, в целом, интересная тема. Жаль маловато технических подробностей.
Валентин ожидаемо на высоте! Пища для ума очень зацепила.
Спасибо.

Денис, вам стоит поработать над подачей.
1. Речь тяжело воспринимается.
2. Ваши примеры настолько абстрактны, что понятны только вам, остальным приходится сильно включать воображение.
Ваше выступление досмотреть не смог и прокрутил.

Денис, ну это просто жесть! Ну как, как ты — человек, делающий доклад о «структурировании данных» можешь уместить в своей голове такое, как: «у нас раньше юзер имел одну реляционную связь, а теперь возникла необходимость использовать у юзера вторую связь, поэтому, 'самый простой вариант' — вторую учетку… ». И потом тоже бред.. КАК? Даже самый отсталый разраб, имеющий начальные представления про SQL, сразу скажет, что если нет необходимости множить избыточность связями 1к1, то всей этой лабуде место в одной таблице, а один ко многим (многие к одному) и многие к многим — по нормальной здоровой расчетной ситуации. Таблицы с этими связями нужны обязательно (если логика этого требует). Ты ведь не заводишь отдельные учетки для «владельцев котов» и «владельцев собак»? (Типа — у Марины есть кот — это одна Маринина учетка, а вторая учетка Марины — это для собаки. А для хомячка, Марина себе (не хомячку) еще одну заведет. ) Или я ошибаюсь?
SQL — structured query language. Если схема данных спроектирована нормально, то и запросы становятся максимально структурированными, информативными понятными и удобными для использования. ORM иногда вредит тем, что разрабы мало уделяют внимания вторичным ключам и лепят все по книжке сущностей или моделей. Это правильно, но сначала надо понимать изнутри.
Поэтому, «ManyToOne», «OneToMany», «ManyToMany», «OneToOne» — основы для архитектуры реляционной БД. И именно благодаря реляционному построению такие задачи решаются просто, хоть и с немного бОльшим количеством таблиц. К сожалению не все, но там уже другие способы есть.
Есть еще «NoSQL» — но это другая тема, хоть и с общим смыслом. Технология отличается.

Мне прям зашло package by feature, долго дамул как отделять структуру правильно и слои не очень нравились, а в этом есть смысл

Хотел бы поработать в команде с Валентином, чтобы научится правильно разбивать