таак же не запишется в реквест да $request->input('category_id', $category->getKey());

$request->setCustomInput('category_id', $category->getKey());

$request->setCustomInput('category_id', $category->getKey());

Method setCustomInput does not exist. у меня 5.2

у меня 7.1

ладно, не буду жирнить — ты не написал где именно у тебя это не работает, симфони, юи, твоя кастомная поделка

если каждый шаг отдельная страница - храни сразу в таблице заказа

заказ ещё не существует как правило. обычно там есть только корзина

ладно, не буду жирнить — ты не написал где именно у тебя это не работает, симфони, юи, твоя кастомная поделка

ларавед если что 5.2

https://laravel.ru/docs/v5/requests в этом реквест вписать кастомные данные

Нету доступа доступа через sftp і по ssh. Кто то знает как через ftp символьною ссылку зделать?

Нету доступа доступа через sftp і по ssh. Кто то знает как через ftp символьною ссылку зделать?

не уверен что ftp такое поддерживает. sftp подразумивает ssh.

winscp вроде как умеет привелегии себе повышать, но опять же тут ...они регулируются ftp

Нету доступа доступа через sftp і по ssh. Кто то знает как через ftp символьною ссылку зделать?

А не проще - http://php.net/manual/en/function.symlink.php ?

А не проще - http://php.net/manual/en/function.symlink.php ?

о, круть)

точно же, php испольняется же от рута вроде

ну можно еще получить ssh доступ)

Ребят, всем привет Нужно сделать таблицу tasks в CRM, подскажите, пожалуйста, а то не понимаю таблица tasks содержит в себе поля id, title, text, add_date, task_date. Как сделать связь между клиентом/продажей/лидом и задачей? Думал сделать промежуточную таблицу tasks_has_entities (id, task_id, entity, entity_id), где entity - это название сущности (clients, sales, leads), а entity_id - это id строки в таблице entity. Но вопрос - как правильно построить запрос? Уже пробовал просто написать, но не понимаю. Это же нужно делать циклом, правильно понимаю? Чтобы вытаскивать данные по каждой сущности

о недавно на stackoverflow читал его)

хотел даже по отвечать но понял насколько он там затянится

ну смотри давай пока отбросим crm

и поговорим чисто за бд

то что ты говоришь это ER диаграмма

и Entity между ними соединяются 3 разными типами связей: 1x1, 1xN, NxM

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

то все зависит от того как у тебя это хранится

условно с точки зрения проектирования там есть такая фишка как нормальнизация и нормальные формы

поэтому твой подход с tasks_has_entities с точки зрения нормальных форм не правильный

лучше сделать отдельно task_has_orders, task_has_leads и тд

и содержимое таблицы будет task_has_orders: task_id, order_id

И таким образом уже делать объединения?

ну и для лидов task_has_leads

это называется связь многие ко многим

это с точки зрения теории

такой поверхностной

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

но чтобы понять тип связи

тебе надо ответить

может ли быть такое что у одно таска несколько ордеров например

а у одного ордера несколько тасков

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

это с точки зрения теории, в жизни может быть иначе)

и во всяких crm как раз практикуется способ что ты описал

у таска несколько ордеров быть не может, а у ордера может быть несколько тасков)

но обладает как плюсами так и минусами)

у таска несколько ордеров быть не может, а у ордера может быть несколько тасков)

значит тип связи между ордером и таском, 1 к N

она реализуется добавлением атрибута(колонки) в сущность order (таблицу orders)

в котором будет указан task_id

тогда уж наоборот у ордера может быть несколько тасков, поэтому в таблицу тасков вставлять атрибут sale_id)

а ну да

мой косяк я имелл ввиду это, просто написал бред

ну и может быть такое что таск не связан не с одним из sale ?

если да то колонка nullable если нет, то not null

и так каждую связь отдельно лучше в начале сделать

потом подумать будут ли еще новые связи динамически появляться?

и нужно ли это

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

если это нафиг не надо то и не придется делать over enginiring

а это только тебе известно

твой вариант как бы более гибкий

но денормализованный и с дополнительной сущностью

и соответственным усложением надо ли это?

во многих crm так делают засчет этого получают базу

в которой без бутылки не разберешься

зато все гибко

и потом лапшу в backend складывают

это имхо, работал с несколькими crm

и потом к вертикальным таблицам приходят

забыл как это правильно называется

https://ruhighload.com/db.vertical.table.jpg

Всем привет! Ищем php разработчика в Ситимобил – онлайн-сервис заказа такси. Область ответственности – разработка систем, API и web-интерфейсов, используемых компанией для обеспечения работы сервиса по онлайн-заказу такси. Задачи: - Разработка API (РНР, Node.JS, MySQL, Redis, Git); поддержка и непрерывное развитие существующих решений, поиск и устранение проблем производительности; - Проектирование архитектуры информационных систем; - Участие в сode-review. Требования: - Нацеленность на результат; - Опыт разработки онлайн-проектов, реализующих сложную логику и оперирующих большими наборами данных; - Опыт разработки средствами PHP с использованием современных фреймворков; - Опыт разработки асинхронных приложений с использованием Node.js; - Не энциклопедическая, но практическая инженерная грамотность; - Опыт промышленной разработки и эксплуатации онлайн-проектов, оказывающих реальные коммерческие услуги; - Навыки или образование в области системного программирования; - Инженерный подход к решению технических задач. Крайне желательно: - Живой интерес к результатам своего участия в общем деле, сопереживание пользователям; - Способность конструктивно работать с несовершенными решениями, понимая особенности подхода KISS; - Опыт поэтапного внедрения микросервисной архитектуры в существующих проектах; Понимание устройства реляционных БД; - Опыт успешной работы с использованием Agile; - Гибкость, ответственность и точность в действиях, не сопровождаемые стрессом для себя и коллег. Условия: - Команда профессионалов, у которых действительно есть, чему поучиться; - Работа в коллективе единомышленников, в котором нет случайных людей; - Белая заработная плата, вилка до 180к нетто; - Официальное оформление по ТК; - Удобный и светлый офис в 10 минутах ходьбы от метро Новые Черемушки; - Оплачиваемые обеды; - Возможность посещать профильные конференции за счёт компании. Жду резюме на ks@city-mobil.ru или пишите в личку Всем хорошего дня! #вакансия #офис #Москва #fulltime #php

сейчас ксения вакансию покажет)

опередили)

Отошел тут на минуту, а ты уже столько всего написал, сейчас все прочитаю))

к

сейчас ксения вакансию покажет)

Показала:)

Отошел тут на минуту, а ты уже столько всего написал, сейчас все прочитаю))

tdlr все зависит от того что требуется

Если я правильно понял, то: Если не нужно будет добавлять новые сущности, то хватит всего этого: Создание таблиц со связью М-М (task_has_sales, task_has_clients и т.д.) Если же нужно будет добавлять сущности, не трогая таблицы, то нужно сделать вертикальную таблицу

ога

на добавление такой таблицы нужно идти осознанно

если возникнет необходимость в этом

желательно если она уже есть

потому что зарефакторить бд от первого состояние во второе проще

Если я правильно понял, то: Если не нужно будет добавлять новые сущности, то хватит всего этого: Создание таблиц со связью М-М (task_has_sales, task_has_clients и т.д.) Если же нужно будет добавлять сущности, не трогая таблицы, то нужно сделать вертикальную таблицу

только мы пришли к выводу что task_has_sales не нужно таблицу