Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

hoolygan

Користувачі
  
  • Публікації

    788
  • З нами

  • Відвідування

Усі публікації користувача hoolygan

  1. Неблагодарная затея. Удалять нужно из многих таблиц. + они могут быть завязаны в заказах. Я бы не удалял, а ставил бы признак "удалён".
  2. @toporchillo, ну Вы же не первый год что-то делаете не для себя, а для кого-то. И можете отличить бизнес ,когда нужно под ключ, и обычного человека, когда он занимается конструктором. И точно также, когда делается по ТЗ под ключ, то разработчик делает на текущий момент. Если потом второй разработчик что-то будет делать, то гарантировать работоспособность невозможно. Это я на счет сделал и забыл. А так всегда и есть, если буду переделывать после всех других - то точно ничего не заработаю, так как это будет занимать много времени. Но это офтоп. На счет фрилансить и работать по контракту - спорить можно больше чем любители пепси и колы, ios и android. Но это сферический конь в вакууме. Плюнул в лицо - нет, перегнули сильно. Я прекрасно помню разговоры, когда зарубежные решения брались, добавлялся перевод, кубился и выкладывался. Вспоминаем пользователя панда-какая-то, и о том, что он взял у Снастика его фильтр, и продавал как свой. Или когда Софорп взял бесплатное решение связи с 1с, закубил и продавал как своё. Хотите продавать решения - никто не против, я против шифрования, что потом никто изменить ничего не может. Вот это как раз бОльший плевок другим разработчикам и бизнесу, которые либо вынуждены лепить кота-в-мешке либо завышать цену. Но это на вашей совести.
  3. @AWARO, я, как и многие, продаю себя бизнесу на время разработки с потрохами, потом продаю себя другому бизнесу. В этом между нами разница. Я не призываю отдавать бесплатно, иначе разработка потеряет смысл. Но всегда будет 2 категории покупателей - бизнес и школьник, условно. Я со школьниками не работаю принципиально, поэтому и не страдаю от нищих бизьнесьменов, как Вы красиво выразились А по опенкарту, ну пришлось учить, банально, жена захотела магазин
  4. @chukcha, Вы как раз из тех разработчиков, которые продают себя, а не свои поделки. Именно о таких я и писал, как и Снастик, Йода и подобные. Начали продавать себя как спеца, а не свои модули как предел мечтаний. Мне, например, вообще чуждо php, ну не люблю я его, пишу на .Net но однозначно против кубления. Еще могу понять, когда в юнишопе закодирована админка настроек модуля, но весь функционал открыт. Но блин, когда тыжпрограммисты кодят всё и вся, чтоб же упаси Господь никто не догадался, что 2 его строчки стоили ему бесовских усилий - то это вызывает лишь сочуствие к последнему.
  5. Пора признать, что разработчики в большинстве своём лукавят. И вот почему. Разработка функционала почти всегда начинается не просто от того, что "ну вот прикольно так сделать", а с конкретной задачи от конкретного бизнеса на необходимый функционал. И зачастую бизнес оплачивает его в полном объеме (упустим школьников с 5 долларами в кармане и понимаем, что сайт-магазин нужен бизнесу для продаж, читаем зарабатывания денег). Так вот, разработчик, зная себе цену, выполнил заказ и получил свои денежки. А потом начинает его жаба давить, что эту же разработку можно продавать и другим, и много раз, и заработать еще больше. В этот момент и начинается дикий запад с аргументами "они воруют" и "они кубят". Хотя оба из них лукавят. А есть еще и лицемеры, которые взяли бесплатное, добавили 2 строчки кода и закубили, выдавая за своё детище. При этом я поддерживаю таких разработчиков как Марк, который продает тип лицензии, что позволяет устанавливать на любое количество сайтов. Т.е. я как (представим) разработчик, купил у него, поменял 2 строчки как мне нужно, и ставлю клиентам, и не бегаю/вымаливаю у Марка, чтобы он изменил под меня. На лицо - человек продаёт не модуль, а, по сути, себя, как разработчика. Да, работа программистов должна оплачиваться, но пора уже вырасти и понять, что вы, разработчики, продавать должны себя, а не 5-100-1000 своих строк, держась за них как за уши свои, при этом часто лукавя, и говоря, что ничего с этого не имеете, кроме продаж на форумах ( не всегда, но очень часто именно так и происходит).
  6. Я бы на Вашем месте оставил primary key такой какой он был, а просто добавил бы этот индекс составной отдельно. Не бойтесь добавлять индексы к таблицам. Они плохо влияют на быстродействие при добавлении информации, так как каждый insert в таблицу требует от субд добавить строку в каждый индекс, и удаление требует удалить строку индекса, поэтому получается фрагментация индексов. Но в случае селектов - дефрагментированные индексы оказывают незаменимую пользу. Я просто не в курсе именно этого фильтра, у меня его нет, но нужно смотреть, какие именно запросы он делает, и строить индексы исходя из этого.
  7. Неверно, нагрузку на хостинг не увеличили. Даже наоборот. За счет составного индекса Вы увеличили дисковое пространство, занимаемое БД, но уменьшили время соединения таблиц внутри БД.
  8. 1. Индекс на имя производителя. 2. Проверить индексы на айдишки производителя в таблице товаров и производителя 3. Where exists (select 1 from oc_manufacturer where oc_product.manufacturer_id = oc_manufacturer.id and oc_manufacturer.name like %'word'%
  9. При большом количестве товаров в категории это нормально так увеличит время загрузки последней. И фильтр по цене переделывать придется. При засилии кубленых фильтров - почти нереально. Проще написать задание в крон, которое будет запускаться, считать цену и апдейтить, если цена на товары меняется или меняются сопутствующие товары.
  10. Спарсить откуда? А модуль да, есть - автоматическая обработка прайс листов
  11. Советую искать специалиста 1с-ника. Разобраться с парой табличек опенкарта ему не сложно будет, а вот специалисту по опенкарту раскладывать товары в 1с, не зная её структуры практически нереально. Дешево это не будет, точно больше чем в 10 раз цены минималистических модулей синхронизации, которые поддерживают минимальный функционал. Но и результат будет адекватный. Потому что сегодня хотите товары, потом захотите заказы, потом покупателей.... и т.д. А так - привяжете себя только к одному модулю, который и поправить не сможете при желании, так как закубленый.
  12. Просто для образования. Что дадут внешние ключи? В чем сакральный смысл их использования с точки зрения производительности запросов. Я их использую в качестве ссылочной целосности БД, но никаким образом к производительности они не относятся. Или я не прав?
  13. Однозначно дешевле будет синхронизацию сделать с 1с. Потому что хотелки будут только расти, а синхронизация - единоразовый процесс при адекватном ТЗ. Но не ведитесь на модули-шмодули, которые на массы рассчитаны, потому что их доработка обойдется дороже полноценной синхронизации. Требуйте синхронизацию таблиц, а не кнопок в админке опенкарта. Это не дешево, но в перспективе однозначно дешевле будет. И думаю, хороший 1с-ник будет более необходим, чем спец по опенкарту.
  14. Не могу утверждать, так как не читал документацию по mysql. Но, например, в ms sql в оптимизаторе запросов больший приоритет имеет оператор ON, т.е. сначала from потом ON(собственно джойн) и только потом where. Поэтому зачастую используя inner join можно добиться значительного увеличения быстродействия за счет уменьшения внутренней выборки, и потом на неё наложить where. Но всё равно каждый раз приходится курить планы выполнения А индексы - это уже отдельная тема. Да и if exists работает на порядок быстрее джойнов, но это тоже отдельно. В общем - каждый случай разный. Но это так, поговорить на досуге ))
  15. В данной теме это оффтоп, вопроса Вашего не касалось, а вообще - один из способов сопоставления таблиц в БД в котором отбираются записи с правой таблицы и подходящие по условию соединения записи с левой таблицы, это если в 2-ух словах.
  16. Если пользоваться только left join постоянно - получите в итоге периодические потери в производительности в разы. Сразу одновременно нужно учить индексы, смотреть планы выполнения и пробовать, бесконечно пробовать )
  17. Главное, чтобы в прайсе отображались позиции количества и цена на них. Остальное допрограмить можно не очень сложно. Сложнее найти "модуль" под все случаи жизни. А на форуме зачастую продают модуль "для масс", что накладывает много ограничений. Задача с заливками прайса - довольно тривиальна с точки зрения распарсивания екселя и заливки в БД, намного тяжелее организовать быструю работу сиквела при одновременных запросах пользователей, например, "живого поиска" или фильтрации. Тут модулями не обойдешься, нужно брать напильники и пилить.
  18. Ручное есть. Вам дали 2 бнсплатных мода на посмотреть. Перенесите вручную эти изменения - и получите результат, если так уж сильно не нравится модификатор. Кнопочка "сделать зашибись" есть только в платных решениях. В остальных случаях нужно понимать что и как делается.
  19. Волшебной кнопочки нет, и не планируется. Хотите CRM - будьте готовы выложить енную сумму на соединение, и не 1 раз, а то и не 1 десяток раз. Так как бизнес-процессы постоянно требуют доработок.
  20. Для грамотной связи с 1с - абсолютно не нужен программист опенкарт. Достаточно грамотного 1с-ника, которому нужно дать структуру таблиц опенкарта. Всякие модули-шмодули - это только головняк. Толковый спец через коннектор к mysql сделает такую синхронизацию, что ни один модуль не сможет при всем своем желании.
  21. @chukcha просто интересно, если человек не регается, то какими полями групируете? Я тоже думал себе такое сделать, но у меня 90% клиентов даже почту не оставляют. Думал разве что по номеру тел - он обязательный. Разве что маску сделать. А вообще - неплохое решение, спасибо за скрин-подсказку.
  22. Если финансы позволяют - то модуль автоматического обновления прайслистов. Если нет - проще вручную запросами в БД делать через phpMyAdmin
  23. Т.е. хотите типа '2017-09-04-2' вот так? Тут будет нужно немного править модель и контролле, возможно и вьюшку, но не помню. Но нужно добавлять поле в БД, и потом по всем связанным формам, и в админке и во фронте менять отображение номера, чтобы был одинаковый. А можно схитрить - увеличить номер в БД в автоинкременте - и заказы пойдут начиная с 7000 номера, к примеру.
  24. 1. Это точно в опенкарте нужно? 2. Если 3 раза недоступен - удалять. А потом по волшебству - получить их в архиве. Недопонятно получилось. Много слов, а четких действий алгоритма почти ноль. Еще раз обдумайте, и потом опишите.
  25. Что значит номер иначе? А по поводу 5 рублей - идите в админке в оплаты - и отключайте доставку с фиксированной стоимостью.
×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.