Алий Кунашев, да, но во-первых я не уверен что автору это нужно, во-вторых я за использование подходящих инструментов для разных задач.
Битрикс даже не лучший конструкторов, главное его преимущество в данном случае - встроенная интеграция с CRM.
А действительно сложные вещи лучше вообще на конструкторах не делать. Выбрать по фреймворку для фронта и бэка. Выбрать подходящую под задачу СУБД и вперёд.
Ну исходя из запроса, могу предположить что выполняется он не часто, и можно забить на 5 секунд. Если проблема в блокировке таблицы во время его выполнения, можно попробовать разбить его на части, или даже таблицу на партиции.
Если планируется существенный рост этой таблицы и количество данных попадающих под выборку станет мало относительно общего количества строк, то есть смысл создать индекс на 2 колонки flag и datetime_b (именно в таком порядке).
Сергей Хлопов, при таком подходе решить чисто через ORM наверно не получится. Либо использовать \DB::select(); с прямым запросом который у вас рабочий получился, либо для таблицы связей определить модель, связь будет https://stackoverflow.com/questions/35306242/larav... такого вида.
соответственно можно будет от этой связующей модели ОРМ запрос построить
SEOD, у нас вообще весь дизайн в фигме, кстати) Так что фронтенды фш тоже не используют)
А я там бывает смотрю какой будет функционал, чтобы понять какие поля в БД создавать, или пометки от дизайнера, как должна работать определённая кнопка.
Игорь Сафронов, а, я понял, интеграция в смысле магазина.
Насколько я знаю нет такой возможности. И вообще часто на неё жалуются.
Но направления сделок в Б24 точно есть. Не уверен что их можно использовать со стандартной интеграцией, но они есть.
Видимо всё-таки пилить.
Дмитрий Бойцов, именно. Скажем в обычной таблице ID строки (primary key), ID формы, позиция поля в этой форме, тип поля, и название.
А в другой таблице, Primary key, ID формы, дата ответа, и JSON объект со всеми остальными данными, ключи - PK из первой таблицы. Или для удобства чтения и написания поисковых запросов лучше в первой таблице добавить поле с символьным кодом (slug) этого поля, уникальным в рамках этой формы.
Соответственно в JSONB писать объекты вида
То есть алгоритм хэша будет виден на фронт? Ну лучше чем ничего, но такое себе всё же.
А упомянутый выше OAuth
Это хороший метод когда нужно из приложения авторизоваться в другом приложении. А если из браузера, то не вижу особого смысла. Всё равно OAuth токен надо где-то хранить, а надёжнее куков в браузере ничего нет.
И на бэке надо определять по OAuth токену что это за юзер, а это уже похоже на сессию)
ince, если данные идут без шифрования значит их можно перехватить, тут ничего не поделать. И шифровать идентификатор сессии смысла нет, ибо пароль с логином так же могут быть перехвачены.
Генерить на бэке любую уникальную строку, есть всякие разные стандартные библиотеки, но если ими не пользоваться, то проще всего взять uuid.
Битрикс даже не лучший конструкторов, главное его преимущество в данном случае - встроенная интеграция с CRM.
А действительно сложные вещи лучше вообще на конструкторах не делать. Выбрать по фреймворку для фронта и бэка. Выбрать подходящую под задачу СУБД и вперёд.