Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Всем привет. На тостере тоже задавал подобный вопрос, но что-то тишина там, может кто тут подскажет.
Хотя я, вроде, и решил делать именно так, как описал, но все же мнения интересны.
На сайте есть возможность заказа разных услуг, например:
Доступ к сайту
Веб-хостинг
СМС-шлюз
Что-то еще
У каждой услуги должен быть свой обработчик, так как услуги разные, соответственно с разными API по разным принципам работают. Но методы одинаковые у них:
create(), delete(), block(), unblock().
Хочу сделать общую таблицу с заказами, где будет ID заказа, тип заказа, срок заказа, статус заказа.
А для разных услуг разные таблицы. Например, доступ к сайту - таблица custon_sites, веб-хостинг - custom_webhostings и т.д..
У услуг таблица custom_ и подставляется тип услуги из таблицы с заказами.
Так делать правильно?
Получается, что для добавления услуги нужно:
создать миграцию с таблицей custom_TYPE
создать обработчик для этого типа услуги
Но чтобы можно было этот тип услуги добавлять к продаже, надо ведь сделать возможность его выбора при добавлении. Каким образом в laravel это можно упростить? Может в контроллере услуг сделать парсинг каталога с классами услуг, в каждом классе услуг добавить статический метод, который будет выводить имя услуги, чтобы было визуально понятно какая услуга добавляется на "витрину".
А в базе тогда что хранить, чтобы скрипт знал к какому классу-обработчику обращаться при заказе услуги? Хранить название класса и обращаться напрямую \App\Components\Handlers\Handler?
А хранить в таблице с заказами тип Handler? \App\Components\Handlers\ - этот путь будет статичным.
Не в сети
это какой-то сложный путь. по сути, насколько я понял, в базе нужно хранить набор записей, у которых есть тип, но у каждого типа свой набор полей. создадим две таблицы,
product
- increments('id')
- string('name')
- string('type')
product_meta
- increments('id')
- integer('product_id')->unsigned()
- string('key')
- text('value')
я выбрал название product, поскольку оно достаточно универсально для обозначения товаров и услуг. кроме того большинство екоммерса использует именно это слово, так что если кому-то придётся разбираться в твоим коде – это упростит ему работу.
теперь смотри что получается, ты можешь сохранить туда любую услугу с любым набором полей, достаточно назначить записи в основной таблице нужный тип. какие именно поля с идентификатором key ты назначишь этой записи во второй, дополнительной таблице – это уже ты определяешь в своём коде, сама структура базы не накладывает никаких ограничений. у тебя будут типы 'website', 'hosting', любые другие кастомы какие понадобятся
фактически ты получаешь нечто вроде NoSQL в структуре SQL – схожим способом хранят произвольный набор полей многие CMS, например тот же вордпресс или инфоблоки битрикса. при этом когда у тебя добавляется новая услуга со своей логикой обработки – тебе совершенно не нужно менять структуру базы, весь набор полей нового типа услуги и логика их обработки будут жить только в коде, который с ней работает
теперь смотри, в основной таблице можно и нужно завести поля, которые совершенно точно будут общими для всех услуг. например, я по своей воле добавил туда поле name. возможно у тебя будут поля типа price, is_available, какие-то другие – тут уже ты решай сам. добавляй их осторожно – только если уверен что они применимы именно к любым услугам вообще
Не в сети
constb, а как это на нагрузке и количестве запросов скажется? А вообще, вариант мне нравится.
Не в сети
constb, а как это на нагрузке и количестве запросов скажется? А вообще, вариант мне нравится.
Глупый вопрос задал и не могу удалить сообщение. Спасибо за наводку, мысль действительно очень интересная. Удивлен, как я сам не догадался.
Не в сети
Страницы 1