Алий Кунашев, да, но во-первых я не уверен что автору это нужно, во-вторых я за использование подходящих инструментов для разных задач.
Битрикс даже не лучший конструкторов, главное его преимущество в данном случае - встроенная интеграция с 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.
