Никаких TCP/IP-портов «1С-Битрикс.Кассы» не открывает — он подключается к серверу «1С-Битрикс: Управление сайтом» как обычное клиентское приложение
А для подключения к серверу какие порты/протоколы используются?
У нас, например, выход в интернет по протоколам http/https возможен только через прокси с авторизацией. Все, что сверх этого — требует согласования с админами и постановки им детальной задачи, чтобы они сделали пропуск нужных соединений на маршрутизаторе.
В «1С-Битрикс» поддерживается отправка только на электронную почту.
Планируется ли реализация отправки через СМС?
Службы доставки требуют телефон, Битрикс теперь будет требовать почту. А покупатели не любят вводить много информации. Увеличение требований приведет к снижению конверсии.
Если же у вас смешанный режим работы — оффлайн- и онлайн-торговля
Т.е. кассовая программа 1С-Битрикс сможет работать с одним кассовым аппаратом совместно с уже имеющейся кассовой программой (которая работает для пробития чеков живых покупателей)?
Яндекс.Браузер до сих пор не умеет обновляться через прокси с авторизацией. Странички показывать/файлы закачивать может, а собственное же обновление — нет.
Реальность email-а можно проверить подключившись к SMTP серверу и якобы пытаться отправить письмо.
Далеко не всегда.
Например, у нас на работе тот сервер, который отвечает по MX-записи, не является конечным сервером и не содержит список всех адресов домена, а лишь принимает и передает все без разбору письма следующему серверу, который уже и занимается сортировкой писем по ящикам.
Такая схема была распространена во времена диалапа, когда связь с интернетом была эпизодической. Собственно, с тех времен она у нас и сохранилась.
Пользователь с гораздо большей вероятностью введёт неправильный и действительный адрес, чем недействительный.
Вероятно, это зависит от аудитории. По моей практике — точно наоборот. Неправильный и действительный адрес был едва ли один за несколько лет. А вот недействительные каждый день вводят.
Вот что стоит, имхо, проверять, так это опечатки самых распространенных доменов. У нас это самая популярная ошибка, примерно четверть от всех недействительных адресов.
А вот индекс (calldate, src) особо помогать и не должен.
Да, там по key_len видно, что использовано только первое поле из индекса.
И литерал во фрагменте src=***** должен быть того же типа, что само поле src, т.к. иногда MySQL ошибается с направлением неявного преобразования типов.
После создания индексов очень желательно делать ANALYZE TABLE.
Если индекс все равно не подхватывается, а должен, то надо попробовать указать его явно в запросе.
Завтра постараюсь более подробно предоставить EXPLAIN запросов, которыми тестировал базу.
И укажите, пожалуйста, кардинальность полей и диапазоны значений.
Это облегчит понимание причин неиспользования формально подходящих индексов.
Например, если залиты данные всего за трое суток, то при отборе данных за сутки от индекса, скорее всего, толку будет мало.
Первый в силу того, что при ежесекундном добавлении записей, размер индекса будет равен количеству записей в самой базе.
Странный аргумент. В MySQL у любого индекса размер в записях будет равен количеству записей в таблице (а не в базе, кстати) и независимо от интенсивности вставки.
Выполним запрос:
SELECT * FROM CDR WHERE src=***** AND calldate>'2016-06-21' AND calldate<'2016-06-22';
/* Affected rows: 0 Найденные строки: 4 Предупреждения: 0 Длительность 1 query: 00:09:36 */
Почти 10 минут ожидания.
План запроса смотрели?
Имхо, хватило бы индекса (src,calldate). Поля в индексе должны быть именно в таком порядке, чтобы диапазон по calldate работал.
У нас, например, выход в интернет по протоколам http/https возможен только через прокси с авторизацией. Все, что сверх этого — требует согласования с админами и постановки им детальной задачи, чтобы они сделали пропуск нужных соединений на маршрутизаторе.
Службы доставки требуют телефон, Битрикс теперь будет требовать почту. А покупатели не любят вводить много информации. Увеличение требований приведет к снижению конверсии.
Есть ли какие-то существенные технические требования?
Ведь большинство чиновников — это обычные рядовые сотрудники, у которых есть свое начальство, которое боится как бы чего не вышло.
http://www.vedomosti.ru/business/articles/2017/01/30/675426-krupneishii-prodavets-zapchastei
Например, у нас на работе тот сервер, который отвечает по MX-записи, не является конечным сервером и не содержит список всех адресов домена, а лишь принимает и передает все без разбору письма следующему серверу, который уже и занимается сортировкой писем по ящикам.
Такая схема была распространена во времена диалапа, когда связь с интернетом была эпизодической. Собственно, с тех времен она у нас и сохранилась.
Вот что стоит, имхо, проверять, так это опечатки самых распространенных доменов. У нас это самая популярная ошибка, примерно четверть от всех недействительных адресов.
И литерал во фрагменте src=***** должен быть того же типа, что само поле src, т.к. иногда MySQL ошибается с направлением неявного преобразования типов.
Если индекс все равно не подхватывается, а должен, то надо попробовать указать его явно в запросе.
Это облегчит понимание причин неиспользования формально подходящих индексов.
Например, если залиты данные всего за трое суток, то при отборе данных за сутки от индекса, скорее всего, толку будет мало.
Как минимум, см. http://dev.mysql.com/doc/refman/5.7/en/index-merge-optimization.html
Не игнориуются, если поля в индексе в правильном порядке для конкретного запроса.
http://dev.mysql.com/doc/refman/5.7/en/range-optimization.html
План запроса смотрели?
Имхо, хватило бы индекса (src,calldate). Поля в индексе должны быть именно в таком порядке, чтобы диапазон по calldate работал.