sim3x

Для обучения - используйте сначала чистый драйвер, а потом алхимию

Попробуйте написать код на чистом, так чтоб не наделать sqlinj

https://github.com/sqlalchemy/alembic

вообщем боюсь что на орм будет долго работать.

кодить вообще страшно, потому никто не боится и делает нагрузочные тесты

ПС: бд не большая, а средненькая

Приведи свои модели к 3 нормальной форме
Потом кешируй ответ

Потом "разгоняй орм"

Цель:
Меньше обращений к БД, быстрее обрабатывается файл, меньше нагрузка на железо

напротив - тебе нужно максимум передать в бд пусть сама разруливает

В постгресе есть механизм транзакции. Грубо говоря, внутри транзакции коммит проходит только после твоей четкой команды.
Что дает: индекс не пересобирается, пока ты внутри транзакции твои данные не видны для запросов за пределами транзакции (при факапе делаешь роллбек и как ничего и не было)

Те делаешь https://docs.djangoproject.com/en/1.8/topics/db/tr...

@transaction.atomic
def do_stuff():
    # This code executes inside a transaction.

и в функции делаешь get_or_create
Делать список на 40к позиций не стоит - работай с каждой строчкой-товаром отдельно
40к селектов >>> список из 40k

Все проверки и чистку данных из цсв вынеси в отдельные функции, чтоб у тебя основная функция выглядела просто как набор вызовов

Очень-очень советую проводить добавление в модель через ModelForm с валидацией - мало ли какой цсв тебе дадут
Не используй евал и/или исполнение чего-либо из таких файлов
Чисти от js дескрипшены и тайтлы и вообще все что ты можешь в шаблоне случайно показать без фильтрации ака {{ foo|safe }}

Помести код в managed commands

используй профайлер и time ./manage.py do_stuff

Сергей Еремин: ты меня убиваешь названием переменных в камел кейсе sUserPhone
и префиксами
перепиши как надо, с андескорами и без префиксов

и не надо сокращать имена переменных

posts = BlogPost.objects.\
        order_by('-dPostDataCreate', 'kBlogAuthorUser__id').\
        select_related()

for post in posts:
    print post.kBlogAuthorUser.kDjangoUser.username

и унаследуй своего юзера от AbstractUser и не мучайся с кучей моделей

хотя скорее всего нужно
https://docs.djangoproject.com/en/1.8/ref/models/f...

images = models.ManyToManyField(Image, related_name="auto_list")
main_image = models.OneToOneField(Image, related_name="auto")

Related_name naming
stackoverflow.com/questions/2642613/what-is-relate...

Ты бежишь впереди паровоза

Вот такое не надо
id = models.IntegerField ( primary_key=True )
оно само делается ОРМ

OneToOne это не про то. Это поле, которое связывает две модели, которые по некоторым обстоятельствам были разделены. Раньше их часто употребляли для связи захардкоженной модели User и UserDetails с доп полями, которые нужны были разрабу

FullName
CamelCase - для классов
under_score - для переменных, полей модели и тд

class Person(models.Model):
    full_name = models.CharField( default=u"Иванов И.И.", max_length=256 )
    # ...
    parent = models.ForeighKey('self', blank=True, null=True)
    # or
    # parent = models.ForeighKey("Person", blank=True, null=True)

то это перестроение всего одного индекса

Но как и раньше - решаешь проблемы, которой еще нет