Дмитрий: Просто, если бы вы разделили код своего приложения, использовали бы модели, потихоньку пришла б мысль, что нужно бы еще и маппер какой-то. Оглянулись бы, увидели, например эктив-рекорд, разобрались. И вопросы, типа "как обновить разные таблицы" даже не мог бы появиться.
Дмитрий: я Вам посоветую ознакомиться с тем, что такое ORM, ActiveRecord, DataMapper. И в работе использовать фреймворки и опробованные подходы. Безусловно, разбираться в том, что под капотом необходимо. Но, на мой взгляд, уже после того, как можете "тупо-на-фреймворке-сделать-что-то-лишь-бы-работало"
$db->query("UPDATE ?n SET ?u WHERE id=?i",$table, $data, $_POST['id']);
Нахрена этот код ? Пишешь новый дата-маппер или эктив-рекорд ? Это не чистый sql? без каких-либо валидаций и коллбэков. Или тут бизнес-логика, в будущем, будет реализована в mySQL ? :)
Я вообще молчу о том, что приведенный код предлагает лупануть переменную пользователя прямо в sql. Хрен с ними со всем разделением кода, паттернами и т.д.. Давайте сделаем из php "скриптовый язык" (где все делается в скрипте в 1000 строк), что б дальше его считали говнокодерским :)
Бред, товарищ, бред. А совет, что вы дали человеку - в народе называется "медвежья услуга".
FanatPHP: да я не спорю, что оно не совсем в тему. И написал, что надеялся, что путь пдо->миграции натолкнет на схемы, и все это каким-нибудь боком заденет один из паттернов доступа к базе через модели, т.к. подход чистого sql - в корне неверный (понимание - да, использование - нет).
Аналогии в мире пхп могу приводить хреновые, да, слабо в нем шарю. Но вот то, что в первую очередь нужно бить по рукам за такой подход в веб-разработке, а не поощрять - это верно для любого языка
FanatPHP: Ты тоже щас сделал аналогичное)
Суть тех двух строчек со ссылкой, что я написал в ответе, что на самом деле вопрошающему нужен не формат запроса INSERT.
FanatPHP: только объясни, пожалуйста, тупому, в каком страшном сне, кроме "сайтов-визиток" и "домашних страничек" нужно писать чистый sql для прямого доступа в базу в обход моделей?
FanatPHP: я просто стараюсь ответить полезно. и не знаю, как можно таким образом ответить на вопросы такого формата. Так же часто вижу, что люди совершают кучу ошибок просто из-за того, что не знают, что то или иное - существует.
Познакомится с пдо, миграцией, глядишь, до схемы дойдет. И многие вещи станут на свои места.
Описать все в одном посте врядли получится. А уход от чистого sql - хорошее начало, на мой взгляд.
Да и тем более, привязываться к какой-то конкретной субд - это лишнее. Лучше, на мой взгляд, понять, что процесс вообще фуфло (создавать собственный класс доступа к "объектам" базы.
FanatPHP: Главным образом для того, что б не гуглить аббревиатуру.
Мало ли что из этого en.wikipedia.org/wiki/PDO может выбрать юный велосипедостроитель
nbekseitov: у вас в вопросе вообще какая-то мешанина из studen, balance, payment, money, history... Ничего не понятн.
Если предполодить, что есть модель Student
class Student << ActiveRecord::Base
serialize :balance, Array
end
Тогда добавить значение можно, например, так:
value = 1
student = Student.find(params[:id])
balance = student.balance
balance << value
student.save
Обновил вопрос.
Товаров - десятки тысяч. Не менее 5ти и, ориентируемся, что не больше 100 000.
Обновлять нужно часто. Не реже, чем раз в час, например. В идеале - сразу же при изменениях, но на данном этапе это не так важно.
Насчет модулей импорта, стоит ли выбирать из существующих ? (платных, бесплатных). Из каких ?
Желательно - минимум кода на стороне опенкарта. И необходимо строго по расписанию без каких-либо действий вручную создавать новые (несущетсвующие) товары и обновлять цены у существующих. Не меняя логики работы всего опенкарта (там, может,акции, скидки, удаленные товары, фильтры и т.д.)
Если это важно, то создавать товары нужно из названия, описания, изображений и характеристик вида название: значение (в фантастическом случае, еще и связать их с фильтрами как-то)
Главное интересует, с чьей стороны лучше начинать синхронизацию? От опенкарта или от Приложения?
Обновил вопрос.
Что интересует главное:
1. С чьей стороны инициировать обновление\импорт - от приложения или от опенкарта?
2. Как именно добавлять? Крон-таски+фтп, создавать метод контроллера, делать дамп базы в SQL ?
Если метод контроллера, то наверное, нужно воспользоваться модулем импорта\єкспорта? Каким лучше?
Если делать дамп, то где посмотреть, в каком именно формате?
wal0vari: ну, третью тоже кое-как осилил с третьего раза. Перед этим возвращался к старому конфигу второй из указанной статьи, которая работает на множестве приложений.
wal0vari: руками не надо
И капистрано - хорошая вещь, когда ее настроишь. Третья, правда, мне не нравится.
Вот отличный мануал по второй - habrahabr.ru/post/120368
Сам чаще пользуюсь второй. Третью только тыкаю, что б не отставать от жизни.
Есть еще Mina. Тоже довольно удобная вещь, когда не нужно деплоить на много серверов. И работает быстрее.
Ну а вообще, по-хорошему все должно разворачиваться с помощью ansible/puppet/chief и докера (или сразу докку). Но, время на понимание и настройку - конечно превышает лимит в мелких проектах.
Вручную точно не советую. Потратьте время на капистрано (наверное, лучше все-таки начать со второй) - и оно окупится.
protasovmikhail: страница с html, head, link, script - уже совершенно полноценна.
Ваше решение просто кишит костылями.
Самый простой вариант - инлайнить стили.
Если вы загрузите строку респонса в переменную, ничего не изменится - стили начнут грузиться только после того, как добавите элемент в DOM
Задача интересная, но отчасти бессмысленная. documentFragment может не хватить. Тогда Shadow Dom habrahabr.ru/post/180377