Адаптер для 3 моделей с одинаковой структурой

[Drugpunker]

Ок, сложно, в схеме магазина увидеть статьи

Еще гугл поиск, в картинках



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

Думаю привирает. минут 15 точно потратил!
https://eax.me/database-design/

Итого
Когда ТЫ знаешь что ищешь - то найдешь.
Вот когда не знаешь, то ни гугл, ни книги, ни видео, ни форумы - да, ничем не помогут.

"Никого ничему нельзя научить. Можно только помочь научитьСЯ"

Вот это уже по делу.
А теперь главный вопрос.
Как заполнять таблицы жанр, страну и группу?
Только без воды пожалуйста.
Как бы Вы сделали это средствами Yii?
Как бы реализовали форму? Как модель?
...на пути к моему вопросу из первого поста.

[Drugpunker]

Итого
Когда ТЫ знаешь что ищешь - то найдешь.
Вот когда не знаешь, то ни гугл, ни книги, ни видео, ни форумы - да, ничем не помогут.

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

Поэтому надо донести до человека, что сперва нужно разобраться с вопросами "Правильно ли хранится информация с БД? А что если через месяц у меня еще будет 5 свойств, что тогда мне нужно будет делать? Множить модели и создавать таблицы? Как этого избежать?"

Даже если он зарегистрирован тут в 2014 году - это ни о чем не говорит

Гляньте пожалуйста мой вопрос выше.
Как бы Вы это реализовали?

[ElisDN]

Как заполнять таблицы жанр, страну и группу?
Только без воды пожалуйста.
Как бы Вы сделали это средствами Yii?

Сгенерировать через Gii класс ActiveRecord и CRUD к нему.

[unknownby]

Гляньте пожалуйста мой вопрос выше.
Как бы Вы это реализовали?

Я разве не расписал всё по полочкам?

[skynin]

-- Дело может быть в том, что человек только начал свою деятельность в сфере IT и многое предстоит ему изучить.
та это понятно что начал.

Вопрос только - сам себе ответил - зачем, на кой?
- Для фана, попробовать, мое-не мое, та ну его в пень, лучше я на бас-гитаре буду играть
- Продавец в магазинчике заскучал, а вот сделать бы для магазинчика сайтик, и в глазах начальника окрутею, и может того, буду сайтики на фрилансе поделывать
- Решил стать программистом! и интересно, и платят неплохо

-- Поэтому надо донести до человека
Если человек не понял о себе что он нуб - то что ему можно донести?
Это и есть самые невменяемые. Из разряда "лошадь можно привести к водопою, но нельзя заставить пить".

Может секрет для кого, но на любого начинающего когда берут на работу смотрят именно с этой позиции - как растет? в состоянии развиваться? нет, ну, прощаемся через пару месяцев.

-- сперва нужно разобраться с вопросами
вначале - с собственными целями нужно разобраться.
Затем с шагами по их достижению.

Например, массово, выбравшие "Решил стать программистом!"
ну, ок, покажи свой репозиторий, куда комитил свои пробы, уроки, "лабы"
Нет такого?
То есть из тьмы статей что должен сделать начинающий программист ты не прочел ни одной?
Это так решил стать?

Но если скажешь такое - ой, какие слезки, обидки то услышишь в ответ

...Чисто случайно, в дуолингво помнится в уроках есть учебное предложение
Прося о помощи, не забывай что никто не обязан тебе помогать.

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

[Drugpunker]

Гляньте пожалуйста мой вопрос выше.
Как бы Вы это реализовали?

Я разве не расписал всё по полочкам?

Нет. Где?
По полочкам?
В примере того надменного чувака есть 3 таблицы группа, страна, жанр. Как бы ты сделал их заполнение?
Не надо кода. Просто в 2 предложениях.

[skynin]

-- Просто в 2 предложениях.
водянисто как-то просите.
в 1 но предложение требуйте!

[Drugpunker]

Как заполнять таблицы жанр, страну и группу?
Только без воды пожалуйста.
Как бы Вы сделали это средствами Yii?

Сгенерировать через Gii класс ActiveRecord и CRUD к нему.

...может быть мне только кажется, что я по-русски пишу, а на самом деле нет...

Дмитрий может быть Вы мне поможете разобраться.

Хорошо, сделал круд для всех 3 таблиц.
Формат данных и структура в них одинаковые.
Круд подарил мне 3 формы для заполнения.
Логично, что удобнее поддержтвать код только в одной модели и работать лишь с одной формой. Ибо зачем дублировать код.
Как бы Вы это сделали?
То есть нужен 1 круд для 3 таблиц в бд.
Как?
Или я зря задаюсь таким вопросом, т.к. нужно принять как догмат, много одинаковых форм и моделей обработки форм (не путать с моделью таблицы в бд)?

[skynin]

-- удобнее поддержтвать код только в одной модели
я же ответил вам в первом посте в этой теме.
Надо одну модель - делайте!

В чем вопрос то у вас?
Надо одну модель на 3 таблицы - ДЕЛАЙТЕ.

[unknownby]

Нет. Где?
По полочкам?
В примере того надменного чувака есть 3 таблицы группа, страна, жанр. Как бы ты сделал их заполнение?
Не надо кода. Просто в 2 предложениях.

Для каждой таблицы своя модель, свой контроллер и свои вьюхи.
Берем пример с названиями таблиц, которые приведены выше.
Во-1 потому что у всех таблиц своя структура данных, свои наименования полей. Не очень логично писать три таблицы и для каждой указывать идентификатор id и поле с названием name. В конце можно запустаться, где и чей name берется, а так же где и с каким id связывается та или иная модель (когда прописываем связь hasOne|hasMany)
Логичней называть поля в бд к примеру group_id, group_name. По аналогии country_id, country_name|| genre_id, genre_name.
Это что касается во-1.
Во-2 Сегодня нужны все жанры, а завтра нужно сделать чтобы выбирались только актуальные жанры, добавляется ganre_actual с буленовским значением (1/0) и при помощи дополнительного фильтра выбираются уже актуальные. Структура модели и таблицы уже отличается от двух других.
Что касается контроллеров, то что мы создаем для каждого свой контроллер, не значит что мы не можем использовать единообразные action.

Код: Выделить всё

public function actions()
    {
        return [
            'export' => [
                'class' => 'app\components\actions\ExportAction',
            ],
        ];
    }

Пример того, что можно сделать одно действие и его вызывать во всех контроллерах.

Надо просто понимать, что это разные сущности, а значит для них всё будет разное. В самом начале не нужно стремиться всё унифицировать и сделать разработку прям в 2 клика, такого не будет

Вначале сделай чтоб работало и у каждого пусть будет написан личный код. Потом будет понимание какой код "дублированный" можно вынести в отдельное место.

P.S.
Судя по всему диалогу, у тебя должно быть две модели, два контроллера и вьюхи для всего этого (различные). Т.е. у тебя одна модель с фильмами, а другая с жанрами. К фильму присоединяем жанры по итогу

[Drugpunker]

-- удобнее поддержтвать код только в одной модели
я же ответил вам в первом посте в этой теме.
Надо одну модель - делайте!

В чем вопрос то у вас?
Надо одну модель на 3 таблицы - ДЕЛАЙТЕ.

Да, да. Вы молодец.
Опытный весь такой. ПРОФЕССИОНАЛ. Понял я уже. Спасибо. С умной миной можете дальше пыль метлой разгонять. Насытился я беседами с такими профессионалами уже.

[skynin]

Да, да. Вы молодец.

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

Вы бы вместо обидок рассказали бы конкретно

Почему вы не можете сделать одну модель?
Какие конкретно сложности у вас возникли.

Но пока вы - все что вам пишут другие - пропускаете мимо ушей
И не можете внятно сказать - что у вас не получается.

Решиили ж делать одну модель?
Так делайте!
Не можете? Что именно вы не можете сделать то?

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

Это вас еще начальник не крыл *ями нежный какой

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

Насытился я беседами с такими профессионалами уже.

Да, не общайтесь с профессионалами, дело то
Сами все освоите, будете на фриланс бирже брать заказы, и ух, заживете!
Заказчики правда тоже кроют *ями нередко, за сорванные сроки...

А вы уже насытились. Может ну его, программироване это?

[Drugpunker]

Нет. Где?
По полочкам?
В примере того надменного чувака есть 3 таблицы группа, страна, жанр. Как бы ты сделал их заполнение?
Не надо кода. Просто в 2 предложениях.

Для каждой таблицы своя модель, свой контроллер и свои вьюхи.
Берем пример с названиями таблиц, которые приведены выше.
Во-1 потому что у всех таблиц своя структура данных, свои наименования полей. Не очень логично писать три таблицы и для каждой указывать идентификатор id и поле с названием name. В конце можно запустаться, где и чей name берется, а так же где и с каким id связывается та или иная модель (когда прописываем связь hasOne|hasMany)
Логичней называть поля в бд к примеру group_id, group_name. По аналогии country_id, country_name|| genre_id, genre_name.
Это что касается во-1.
Во-2 Сегодня нужны все жанры, а завтра нужно сделать чтобы выбирались только актуальные жанры, добавляется ganre_actual с буленовским значением (1/0) и при помощи дополнительного фильтра выбираются уже актуальные. Структура модели и таблицы уже отличается от двух других.
Что касается контроллеров, то что мы создаем для каждого свой контроллер, не значит что мы не можем использовать единообразные action.

Код: Выделить всё

public function actions()
    {
        return [
            'export' => [
                'class' => 'app\components\actions\ExportAction',
            ],
        ];
    }

Пример того, что можно сделать одно действие и его вызывать во всех контроллерах.

Надо просто понимать, что это разные сущности, а значит для них всё будет разное. В самом начале не нужно стремиться всё унифицировать и сделать разработку прям в 2 клика, такого не будет

Вначале сделай чтоб работало и у каждого пусть будет написан личный код. Потом будет понимание какой код "дублированный" можно вынести в отдельное место.

P.S.
Судя по всему диалогу, у тебя должно быть две модели, два контроллера и вьюхи для всего этого (различные). Т.е. у тебя одна модель с фильмами, а другая с жанрами. К фильму присоединяем жанры по итогу

Ты всё правильно написал. Так и есть.
Но у меня метод в модельке, который перестраивает позиции элементов в базе.
Нужно это для того, чтобы элементы выводились в списке в нужном порядке. Захотел поменять порядок, выбрал в форме, в селекте, элемент (поле позиция до), и элемент поменял свою позицию. И этот нужно делать для данных всех 3 таблиц. То есть для любой из них.
Вот я смотрю на это всё, и понимаю, что метод придётся копировать в каждую модель. Ну или же вынести его в отдельный класс компонент и передавать в него объект конкретной модели. И при этом придётся оставить (на твой взгляд) 3 одинаковых формы. Много одинакового кода просто не даёт покоя.

[skynin]

-- Вот я смотрю на это всё, и понимаю, что метод придётся копировать в каждую модель
не копируйте.
Создайте одну модель.

-- Много одинакового кода просто не даёт покоя.
Создайте одну модель.

Что не получается при создании одной обобщенной модели?

[ElisDN]

Круд подарил мне 3 формы для заполнения.
Логично, что удобнее поддержтвать код только в одной модели и работать лишь с одной формой. Ибо зачем дублировать код.

Этот код обслуживает разные вещи, так что логического дублирования одного и того же в нём нет. Объединять нужно только то, что стопроцентно является дублированием одного и того же и технически, и по смыслу. По смыслу страна и жанр - вещи абсолютно разные.

То есть нужен 1 круд для 3 таблиц в бд. Как?

С такой же логикой вы можете решить и всё в одну таблицу в БД всё закинуть, чтобы не дублировать таблицы. Станет не лучше.

Формат данных и структура в них одинаковые.

Это просто случайно получилось, что структура пока одинаковая.

Как только к стране или жанру потребуется добавить какое-то другое поле, так сразу форматы начнут отличаться и ваше обобщение мгновенно развалится. И тогда вам же придётся героически разбивать всё обратно на три формы. Либо в вашу одну форму нагромождать кучи if-ов.

Как бы Вы это сделали?

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

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

Вот именно такие реальные смысловые дубли и нужно объединять, чтобы формула или регулярка была только в одном месте.

А простые полупустые крудовские контроллеры и формы воспринимайте как расходный материал.

[ElisDN]

Захотел поменять порядок, выбрал в форме, в селекте, элемент (поле позиция до), и элемент поменял свою позицию. И этот нужно делать для данных всех 3 таблиц. То есть для любой из них. Вот я смотрю на это всё, и понимаю, что метод придётся копировать в каждую модель. Ну или же вынести его в отдельный класс компонент и передавать в него объект конкретной модели.

Вот такие мелкие нестандартные вещи и выносите поштучно в отдельные компоненты/хэлперы/виджеты/валидаторы. И их уже используйте во всех трёх крудах.

[Drugpunker]

-- Вот я смотрю на это всё, и понимаю, что метод придётся копировать в каждую модель
не копируйте.
Создайте одну модель.

-- Много одинакового кода просто не даёт покоя.
Создайте одну модель.

Что не получается при создании одной обобщенной модели?

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

[Drugpunker]

Захотел поменять порядок, выбрал в форме, в селекте, элемент (поле позиция до), и элемент поменял свою позицию. И этот нужно делать для данных всех 3 таблиц. То есть для любой из них. Вот я смотрю на это всё, и понимаю, что метод придётся копировать в каждую модель. Ну или же вынести его в отдельный класс компонент и передавать в него объект конкретной модели.

Вот такие мелкие нестандартные вещи и выносите поштучно в отдельные компоненты/хэлперы/виджеты/валидаторы. И их уже используйте во всех трёх крудах.

Спасибо. Понял. Так и сделаю.
Там ещё про enum было мнение. Но я как-то не готов понять, зачем его использовать взамен классического хранения в отдельных таблицах.
Может быть лучше использовать его?
И почему лучше? Или почему нет?
Выигрыш вижу лишь в отсутствии кучи моделей. Но в работе с данными бд потом, не возникнут ли проблемы?

[skynin]

-- Я не знаю как это сделать.
Что конкретно из моего первого ответа - как это сделать - не понятно?

-- От Вас не услышал ни одного дельного совета.
Бывает, да, когда уши не слышат
Что и промывка "водой" - тоже не помогает.
И картинки на "какой подход будет верным" - тоже глаза не видели.
Бывает

-- с воздуха взятых выводов о моём неумении проектировать бд, и т.п.
Ну вам другой человек написал тоже самое. Что с вежливого переводится так же:
Чувак, ты хню напроектировал.
Да, и третий вам написал - как вообще-то надо, и намекнул тоже самое
Парень, так не делают, хню ты напроектировал.

Но вы продолжаете пребывать в уверенности что правильно все спроектировали, потому что "умеете"?
Ну-ну.

-- Понял. Так и сделаю.
Ну вот и замечательно!
Хоть какой-то из трех одинаковых по сути ответа вы услышали!

[unknownby]

Ты всё правильно написал. Так и есть.
Но у меня метод в модельке, который перестраивает позиции элементов в базе.
Нужно это для того, чтобы элементы выводились в списке в нужном порядке. Захотел поменять порядок, выбрал в форме, в селекте, элемент (поле позиция до), и элемент поменял свою позицию. И этот нужно делать для данных всех 3 таблиц. То есть для любой из них.

Тут еще всё намного проще
Метод который перемещает что-то и куда-то и перестраивает позиции. Зачем он вообще?
Можно два варианта использовать.
Первый - создаем поле integer, называем его "Порядок следования" и вписываем цифру, какой по порядку будет выводиться в списке. Можно даже делать порядок с разбежкой в 10. типо 1, 11, 21, 31 и потом взять например 21ый переместить на 9ую позицию.
Второй - (очень хороший вариант) сортировать по наименованию, так скажем от А до Я.
Почему Молоко должно быть позже чем Яблоко, и раньше чем Азбука?

Все трое тут говорят одну и ту же вещь тебе Если сущности разные, разные таблицы, если сущности одинаковые, то одна таблица (одна модель)