Александр Воробьев, да, у меня так же. Однако документации самого же Битрикса это противоречит.
Что, впрочем, для этой CMS является стандартным случаем.
Ну, и в базе поле EMAIL вообще nullable, так что при желании можно творить с ним все, что угодно.
Вопрос только, какие куски кода, уже существующие на сайте, полагаются на документацию.
Ипатьев, я имел в виду ситуацию, когда и такие INSERT-ы придется разбивать на несколько (у ТС 16 тысяч строчек). Или вставка по итогам разбора идет в несколько таблиц.
Для одного оператора, конечно, транзакция смысла не имеет.
Cheizer, CMS тоже должна иметь возможности массовой вставки, это частая задача.
Просто надо погуглить решение для нее и понимать, как это реализуется реальными запросами к БД.
В реальности их десятки. Потому что "XL", "52", "50-54" и далее везде могут описывать буквально одну и ту же шмоть.
Вообще, прежде, чем обсуждать алгоритм сортировки размеров в каждом конкретном случае, стоит попытаться составить их список и подсунуть его для сортировки товароведу. И вот только когда он родит то, как оно должно выглядеть со стороны работающих с этими размерами - тогда и алгоритмизировать.
Лучше всего 10 тысяч запросов в секунду обрабатывает голый веб-сервер.
А если вам нужно что-то еще сделать во время обработки - так от этого и нужно плясать.
Буквально один запрос к БД нивелирует любую практическую разницу в работе "быстрых" и "медленных" языков.
Павел, прямо под рутом необязательно, можно прописать --rsync-path="sudo rsync".
Доступ юзера банальным ls из-под ssh стоит проверить.
И кстати, а зачем в команде -e "ssh -p 22"?
Павел, тут бы более конкретно, что пишет rsync насчет "не могу получить доступ".
Может, проблема в чем-то другом.
А может, внутри папки с правами 770 лежат файлы с правами 600.
Владимир, повторяю: вы и делаете то же самое, что с базой, только не храните это в базе, а отдаете клиенту и требуете предъявить при каждом запросе. Как у вас происходит удар - вам же виднее. В примитивном варианте браузер сообщает серверу, что удар был, а сервер рандомом навешивает ущерб. Хранить, собственно, нечего, только поменять состояние (хиты босса) и вернуть их браузеру.
Владимир, а как вы это собираетесь делать, читая из БД?
Разжевываю: вы пускаете юзера к боссу, передавая браузеру "у босса 20 хитов, дата, подпись".
Юзер бьет босса, браузер сообщает серверу: "ты мне вот докУмент давал про 20 хитов с подписью, и учти удар".
Сервер проверяет подпись, просчитывает удар, отдает браузеру "у босса 18 хитов, дата, подпись"...
И никаких баз.
Владимир, где "там"? Какие "данные"? Дьявол в деталях. Для пользователя вы "все равно" храните данные и проверяете авторизацию, вопрос, требуется ли для вот этой конкретной задачи хранить что-либо еще. По описанному мной сценарию творить отдельную таблицу под здоровье боссов - не потребуется. Секретный ключ может тупо генерироваться из ID юзера, например.
shurshur, тем не менее даже последняя Зубунта из коробки требует смены темы с дефолтной на Адвайту или КлиарЛюкс и обоев на не пропагандирующие суицид.
Зачем вообще так извращаться в один запрос?
UPDATE WHERE id (обновить те из записей, которые уже существуют) и INSERT IGNORE (добавить те, которых нет).
Так разрабатывайте. Смысл MVP не столько в том, чтобы показать, что что-то работает. а в том, чтобы посмотреть самому разработчику, как оно может работать и где именно на практике появляются узкие места. То, что у вас для проекта, требующего MVP, на старте нет понимания, во что вы упираетесь - это совершенно естественно ;)
А грубая математика про 445 - это ни о чем. В идеальном варианте обработка 445 задач - это один запрос 445 записей из БД, одно обращение к внешнему API со списком из 445 идентификаторов и один цикл обработки результатов на 445 итераций.
Что, впрочем, для этой CMS является стандартным случаем.
Ну, и в базе поле EMAIL вообще nullable, так что при желании можно творить с ним все, что угодно.
Вопрос только, какие куски кода, уже существующие на сайте, полагаются на документацию.