Вадим Шандринов

Посмотри на https://github.com/barneygale/quarry

Сейчас прикручиваю оплату к джанге, сервис https://www.walletone.com/ru/wallet/ Апи понятнтый, есть примеры для пайтона. Насчет адекватности - вам решать.

m.habrahabr.ru ?

В команде обязательно используют систему контроля версий - GIT, Mercurial - и трекеры задач - Jira, Redmine. Тебе нужно это знать. Как писать код - смотри чужие исходники, спрашивай у коллег, по хорошему должен быть стайл гайд, но его ленятся делать - просто попроси рассказать тимлида как надо.

Как запускаете сервер? какая версия джанги?
Статику в нужные директории положили?
Надо понимать, что статика и медиа файлы - разные вещи. Статика это css+js+icon - то что отображается всегда на сайте, хранится это обычно на файловой системе и в проде отдается веб-сервером (nginx или apache)
Медиа файлы - могут загружаться пользователями, метаинформация для них лежит в базе, а сами файлы - тоже на файловой системе.
Подробнее - djbook.ru/rel1.9/howto/static-files/index.html и djbook.ru/rel1.9/topics/files.html

Вам для чего? И индексы для какого движка вы хотите видеть - innodb/myisam/etc?
Штатных средств кмк нет, но спросите у экспертов тут sqlinfo.ru/forum

"Отображается не сразу" - очень субьективно. Сервер на локальной машине?
Как настроили python окружение для mod_wsgi? конфиг в студию.
Что в логах апача?

ИМХО кривая архитектура - как можно давать перестартовывать сервер клиенту? а если вас хакнут и поставят в цикле рестарт?
Можно подробнее про "Так сложилось, что в одном из приложений после обновление данных нужно перечитать все настройки через рестарт сервера" - копать нужно тут. Может нужно переменную часть хранить не в настройках, а в базе, к примеру?

Могу посоветовать изучение основ промышленного программирования на Python с наставником. Для работы помимо знания самого языка нужно уметь работать в команде, а это - git/mercurial, трекеры задач, проф средства разработки, тестирование кода, ревью, рефактор и деплой. Знание библиотек конечно же важно, но по опыту могу сказать, что общее понимание приходит быстро, а вот тонкости работы - только в процессе разработки и эксплуатации. Тем более что заранее сказать, что придется изучать - невозможно. Джанго - да, но вдруг поставят задачу, к примеру, интегрировать с рекламной сетью фейсбука - и вперед, изучай библы :)
В итоге - я собираюсь вести такие курсы. Цель: базовые навыки для пром.разработки на пайтон. Опыт преподавания у меня по интернету есть + прочитал курс пром.программирования в МШП. Собирём группу из 7 человек и запилим какой-нить проект django/mysql/git/redmine :) Пишите, отвечу.

У нас так: есть два приложения на джанге - фронт и бэк. Стоят на разных серверах. Из фронта нужно иногда лазить в БД бэка. Оба проекта под mercurial, сделали субрепо, в который положили модели бэка к которым нужен доступ с фронта. При разработке допиливаем бэк, коммитим, идем в код фронта, подтягиваем новую версию субрепы, встраиваем, коммитим, релизим. Да, с фронта ходим через .using() - написали простой менеджер - и настройки в settings для удаленной БД.
Не сказать что простое решение, но возможное.
Как альтернатива была - некое API (rpc, http) но его сложнее поддерживать, кмк.

Конечно же мало данных для ответа. Что за сайт, какие роли пользователей, какие действия для ролей?
По опыту джанго-админка идет в осномном для разраба (для тебя), что бы быстро создать/отредактировать что-нить в БД, узеры в ней путаются когда неочевидные связи между сущностями БД.
Она всех привлекает по началу - три сточки и работает - но расширять/урезать сложно, лучше делать нужные формы для разных ролей пользователей.

Надо пересоздать базу:
CREATE DATABASE `##DATABASENAME##` /*!40100 DEFAULT CHARACTER SET utf8 */;

Зачем на каждого? Если один воркер отработал одного клиента, то пусть обработает следующего :) Гасить/поднимать - тоже ведь жрущая ресурсы задача.
В celery есть авто-балансировка количества воркеров - docs.celeryproject.org/en/latest/userguide/workers... можно указать сколько держать в памяти на всяк случай и до скольки добавочных можно поднимать при необходимости.

Я делал так: есть абстрактная сущность счет, и абстрактная сущность - проводка. Проводка имеет две ссылки - счет откуда и счет куда. Так же проводка имеет поле сумма.
Потом делаем систему счетов: внешние источники денег - один счет, внешние потребители денег - другой счет. Все внутренние хранилища денег - сотрудники, материалы, склады - тоже счета.
А потом получается так: если нам капнули деньги от клиента - проводка снаружи внутрь на счет "сейф" с пометкой "от клиента". Надо начислить ЗП - делаем Н проводок со счета сейф на счета "Иванов"/"Петров" и так далее.
Что бы понять баланс счета "сейф" - нужно сосчитать суммы проводок входящих минус сумма проводок исходящих.
Внутренних счетов может быть сколько угодня. По внешним счетам баланс считать можно, но они односторонние - или источник, или потребитель - лучше не смешивать.
Как-то так.

Одна табличка с категориями, другая - из трех полей: тайтл, текст и ссылка на первую табличку с категориями.
Почитайте про внешние ключи в базах данных yandex.ru/yandsearch?text=%D0%B2%D0%BD%D0%B5%D1%88...

С MS не знаком, но общее решение такое: повесить триггер, который будет обновлять текущим временем специальное поле modified_at типа DATETIME на инсерте и апдейте строки.
Потом можно будет отфильтровать по этому полу все записи, которые были изменены/вставлены за период.

видно что происходит попытка перекодировать из любимой винодовой cp1251 :) а файл видать в UTF8...
попробуй открыть как 'rb' и конвертировать построчно

f = open (filemane , 'rb')
for line in f:
     print(line.decode('utf8'))

а вообще хорошо бы знать, в какой кодировке файл.

print '{}{}{}'.format(a,b,c)

1) ну, можно сказать что SELECT * создает нагрузку, если таблица широкая - тогда мускуль все колонки копирует в область памяти для сортировки. надо выбирать только то что нужно.
2) еще нужно посмотреть есть ли B-tree-индекс для id - помогает для сортировки иногда.
3) еще хинт - иногда, для больших (от сотен тысяч записей) таблиц лучше вытянуть только айдишники записей
SELECT id FROM post ORDER BY id DESC LIMIT 5
- тогда при наличии B-tree-индекса сортировка вообще не будет производится - все уже отсортировано в индексе. А потом тянуть остальные поля отдельным запросом.
SELECT ... FROM post WHERE id in (...)
и сортировать на клиенте :)