trevoga_su: Если у вас криво поставлен процесс работы, это не говорит обо всех компаниях. Я лично уже не первый год работаю в проектах с удалёнными сотрудниками. Проектах разработка которых идёт от полугода и выше. Друг работает начальником одного из отделов разработчиков американской компании, весь его отдел раскидан по миру, никого в офисе нету. В живую они только на корпоративах встречаются. Да, рабочий день у них по Ньюйорку, весь отдел в чате Скайпа, система контроля времени через софтину одеска, задачи через ЦРМ работодателя.
Как бы открою страшную тайну, уже давно отказались от голубей, для быстрого общения на большом расстоянии. А для программирования, инструментов и подавно полно, особенно для команд.
marazmiki: А вы правы. Я тупо просмотрел, для чего автор использует данное представление. В данном случае именно UpdateView правильно использовать. Я же думал он просто увеличивает счётчик просмотров объекта, без участия юзера.
un1t: За бред извиняюсь, погорячился. Цену выносить как и скажем название - не рационально. Ибо это основной параметр товара в магазине, который почти всегда нужно выводить. А если выносить в отдельную таблицу, это лишние запросы, пускай даже джоинами. Да и добавление/обновление усложняется из-за работы с двумя таблицами.
10к обновить это проблема. Сейчас просто пробег файла на 10к строк (товаров) с проверкой есть ли в базе, занимает 25 секунд. А вот попытка обновить только цену у 10к товаров пробегая файл, выходит за 10 минут. И это на локалке с 32гб оперативки, ssd и 4 ядрами i5, а на ВПСе где ресурсы не такие, вообще беда.
За bulk_create, спамибо. Совсем забыл про этот в джанге. А вот вариант с созданием новой таблицы - бредово. Ибо количество товаров в базе растёт. Старые не удаляются, а только помечаются как "удалённые" и отключаются на отображение в некоторых местах, но на сайте отображаются. В итоге каждый день добавляется сколько-то новых товаров, у скольких-то меняется цена, какие-то помечаются как "удалённые". Сайт за менее полу года набрал около 1кк товаров в базе, активных (отображаемых) около 80к. В обновлении может прийти всего 10к товаров на добавление/обновление/удаление. Вы же предлагаете 9,990,000 записей клонировать, ради добавления 10,000.
Дмитрий Энтелис: Да нет. Есть несколько типо заказчиков. Есть частники (физики, ИП), а есть юрики. Первые часто вообще договорами не обременены и налоговыми. Тупо переводят на счёт с левой пометкой или вообще наличкой платят. А вот вторые спокойно обходятся через договор подряда. Цена же для всех едина.
Дмитрий Энтелис: Не знаю как у вас, но у нас уже два года работает такая схема с заказчиками. При том поиск вообще не ведётся, все идут сарафанным радио. Цена всех устраивает как и +30%
А про налоги говорю не с потолка. Общались со многими заказчиками. Все нежелания работать с простым Васей, списывали на проблему вывода средств для его оплаты с счёта юр лица. При предложении работать по договору подряда, все соглашались.
С чего такие заблуждения? Самая главная причина, это списание средств со счёта юр лица. В налоговую нужно принести бумажное подтверждение траты этих денег. И просто вася с улицы, это геморрой списывания на левые траты этих денег. А ИП или ООО даст нормальные акты, договор. Всё с печатями. Налоговая довольна, заказчик не ломает голову, как снять со счёта юрика денег, для оплаты работы васи.
А вот Петя умный. Петя готовит типовой договор подряда на свои услуги. Договор подряда между физ лицом и ИП, физ лицом и ООО. И сразу говорит об этом заказчику. Тогда заказчик не ломает голову, как оплатить работу. Ибо договоры подряда "не привычны" многим заказчикам. Они привыкли работать с юрлицами и тупо забыли/не знают о договорах подряда.
Yeldos Adetbekov: Сейчас вы грузите только часть навигации, за год она растёт, через год у вас уже гигабайт, не нужной информации, висит где-то "в памяти". Тяните из БД и не заморачивайтесь. На флеше у вас была проблема работы не с БД, а с файлом и чтения его. Базы данных и созданы для обхода этой проблемы. Вы не поняв этого, проецируете проблему хранения данных в файлах и последующую обработку, на все типы баз данных.
Что вы подразумеваете под "локальной переменной/объектом"?
Замена запросов к БД на другие способы хранения данных, порой абсурдна. Ибо "а где данные храним"? Заменить на сессии? Ну так сессия хранится в той же БД или файле на диске, а БД это тот же самый файл на диске.
Пума Тайланд: Ну я с лобстерами так же обедал. Очень не понравились и стоили дорого. Но каждый день лобстерами питаться не интересно, да даже крабами которые нравились.
Пума Тайланд: Пума. Тут наверно всётаки накладывается ещё и место + образ жизни. Мы когда жили долгое время во Вьетнаме, так же работая удалённо как и в РФ. Так вот там, мы очень редко готовили, хотя и снимали дом с кухней. Чаще всего это вечерами с друзьями шашлыки всякие или морские гады на мангале. Нам проще было ходить в сотни местных кафешек-столовок, шаговой доступности, где за смешные деньги мы просто объедались (порой одну порцию бизнесланча съедали вдвоём - порции большие, за примерно 40 рублей российских). Но вот вернулись в РФ. Тут своя квартира, рестораны уже дороги, да и не столько много в спальном районе дешевых кафешек, а заказывать - ждать неопределённое время + дорого. В итоге дома в РФ мы готовим, с походами в магазин. И это в РФ удобнее нам. Ты же живёшь в Тае - жара, море, куча кафешек-ресторанов с культурой питаться "на улице" у местного населения. :-)