Роман Романов, надо попроще - используй контейнеры STL и нечего лохматить бабушку.
Оптимизация попроще не бывает, она, наоборот, требует очень глубокого понимания, что происходит, будет происходить и может происходить.
Александр Воробьев, я не ставлю клеймо на Битрикс за легаси своего проекта.
Я ставлю на нем клеймо за то легаси, которое написано за эти годы самими битриксоидами и уже никогда не будет вычищено, так как они этим и не занимаются, а налегают на Б24. Ну, и за то, что сама архитектура этой CMS просто-таки навязывает говнокод.
Но это, конечно, совсем другая история, не имеющая к данному вопросу уже вообще никакого отношения.
Александр Воробьев, "битрикс" и "без проблем" в одном предложении? Вы с ним точно работаете? ;)
У меня сайту на Битриксе 15 лет, и я таки умный вещь скажу.
Если Битрикс еще "голый", без легаси - можно в нем забить на документацию и полагаться на то, что есть сейчас. Если сайт пожил на разных версиях - на нем может быть код, который полагается на старую логику. А раньше мыло было обязательным.
Александр Воробьев, да, у меня так же. Однако документации самого же Битрикса это противоречит.
Что, впрочем, для этой 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, тем не менее даже последняя Зубунта из коробки требует смены темы с дефолтной на Адвайту или КлиарЛюкс и обоев на не пропагандирующие суицид.
