Кропивницкий форум (Кировоградский форум)Кропивницкий — новости и сайтыИскать: все сайты e-mail'ы::Как искать?
Детальный поиск
Например:
Каталог сайтов Кропивницкого :: Новости Кировоградщины new! :: Опросы :: Фото :: Карта Кропивницкого :: Погода :: Поиск :: Знакомства :: Форум :: Вехи Кирнета

Нужна оценка стоимости не большого пректа

Автор
Сообщение
Ответить с цитатой
СообщениеЧт, 14 Апр, 2011 9:34

мое мнение ненужна никакая джумла и прочее. тут скрип написать несложно, импорт-сравнение-вывод, дизайн неважен, автоматический поиск по бд, с привязкой к имени товара.
Ответить с цитатой
СообщениеЧт, 14 Апр, 2011 9:38

Да мы тут про две коровы в одном стойле говорим.

Анализ цен нужен как раз для интернет магазина и заливки его. В общем и то и другое делается параллельно.

Игрушка на джумле стояла, но она поломалась когда залили каталог из 10 тыс. позиций. Smile
Ответить с цитатой
СообщениеЧт, 14 Апр, 2011 18:21

Друпал это CMF из него можно сделать все что угодно в том числе и магазин
В друпале есть и кроме ОСКомерце достойные магазины, например, Уберкарт. А вот например, даже сборка есть на Друпал + Уберкарт http://drupal.ua/groups/openstore да еще и сборка украинского товарища Smile

Друпал и Джумла не сравнимые вещи Wink
На Джумле серьезный сайт сделать очень тяжело как и писать модули, удовольствие ниже среднего.
А насчет того что легче Друпал или Джумла или что-то еще — нужно уметь готовить Wink
Guard говорит:
Игрушка на джумле стояла, но она поломалась когда залили каталог из 10 тыс. позиций. Smile
это только подтверждение всего самого хорошего про Джумлу
Ответить с цитатой
СообщениеЧт, 14 Апр, 2011 18:36

Ну, в случае Guard, однозначно нужно написать модуль - поиска\сравнения\вывода и прикрутить его на магазин, неважно на какой.

логика модуля: импорт нового прайса в бд, или просто импорт файла, выборка в цикле построчно имени товара, сравнение с строками действуещего прайса, если совпадение имени - сравнение ячейки "цена", дальше или замена сразу цены или вывод двух позиций цен, написать все реально, НО 10 000 например позиций - это кхм, сложно будет циклам, неуверен в том что создание такого скрипта именно на php + бд, есть единственно верным решением. мне кажется что лучше написать програму (не веб), а в магазин импортировать готовый прайс.

хотя я не знаю, я не сталкивался с такими большими таблицами никогда, может будет все нормально работать, нужно пробовать. Можем тут совместно на форуме такой модуль написать, ради спортивного интересу Smile
Ответить с цитатой
СообщениеЧт, 14 Апр, 2011 18:49

orb говорит:
парсинг файлов екселя не сложное дело, есть библиотеки для этого дела есть возможность концертации в CVS


парсить экспортированный cvs - да, можно, а вот парсить файлы оффиса - я бы не стал. хотя бы потому, что неизвестно, насколько стабильна библиотека, и как она себя поведет при попытке скормить ей немного некорректный/неизвестной версии/etc файл. cvs хотя бы нагляден, элементарно парсится без лишних библиотек и легко проверяется ручками.

orb говорит:
Берите Друпал Smile
Правда к Друпалу тоже нужен специалист в комплекте которому денег вы все же заплатите.
Друпал самая гибкая система на сегодняшний день и одна из самых безопасных Smile


ИМХО друпал тут - из пушки по воробьям. как и джумла (которую по неизведанным причинам большинство девелоперов жутко любят - хотя из хорошего в ней разве что только комьюнити), и прочие монстры. я бы обратил внимание на мелкие CMS. возможно - что-то блогоориентированное (как maxsite cms) для новостей + отдельный модуль магазина/прайса.

That говорит:
но у разных поставщиков, этот код товара, на одну и ту же позицию - разный, название также может незначительно отличаться и скрипт не сможет в таблице правильно сравнить цены.


правильно. если в каждом новом прайсе будет меняться код (и описание). иначе - новая позиция поставщика вносится ручками, и привязывается к текущей, и успешно живет месяцами - до исчезновения из прайса. да, не 100% автоматизация, но не нужно каждые несколько дней/неделю вручную лопатить прайсы.

That говорит:
Если постоянно прайсы одного поставщика - тогда да, все кода-имена одинаковые, можна сравнивать, а если разные поставщики-разные прайсы-разные коды(имена), то админу придется вручную делать привод всех позиций прайса к общему знаменателю, тоесть указывать что этот товар - соответствует товару в действующем прайсе в БД.


угу.

That говорит:
В автоматическом режиме, можна привязать к названию товара, примерно так, как работает "поиск по сайту", тоесть поиск по таблице БД действующего прайса, максимально выявляя совпадения в названии товара


большая ресурсоемкость, низкая эффективность. писать свой движок контекстрного поиска - занятие на любителя. + ложные срабатывания будут.
Ответить с цитатой
СообщениеПт, 15 Апр, 2011 8:07

orb говорит:
это только подтверждение всего самого хорошего про Джумлу

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

И ее косяки так же известны, сео через задницу и если руки кривые она очень тормознутая получается. Но для сайта обычного можно допилить ее руками и новичку если погуглить хорошо.

That говорит:
мне кажется что лучше написать програму (не веб), а в магазин импортировать готовый прайс.

Примерно к этому решению и пришли. Сейчас дорабатываем то, что забросили, в общем монотонная работа в ковырянии прайсов поставщиков и указании им того какой товар куда кидать в наш прайс с ихнего.

That говорит:
Можем тут совместно на форуме такой модуль написать, ради спортивного интересу

Smile спортивный интерес это хорошо. Smile

NiTr0 говорит:
+ ложные срабатывания будут.


Отож то и оно, уже были и вылавливать потом ложное и править руцями куда сложнее, чем править сразу и помещать в нужное. Еще больше времени забирает - поэтому отказались от одного проекта именно по этой причине и начали развивать по другой логике о которой уже выше писали. Думал может кто знает еще варианты до которых мы не додумались. Но смотрю актуальный пока только один.

Была так же идея по привязке к парт номеру товара - к международному. Но не все его указывают, не везде он одинаково пишется - у некоторых в скобках у некоторых без у некоторых в скобках есть пробел а у некоторых нет и по этой причине так же ложные срабатывания, а так же не все товары имеют этот парт номер и все равно приходится ручками. То есть двойная работа и больше времени чем сразу ручками и не мучать себя дважды.
Ответить с цитатой
СообщениеПт, 15 Апр, 2011 9:51

делать десктопное приложение и отдельно для ВЕБа - это удваивание цены как минимум, а я бы сказал даже учетверение при качественном исполнении Smile
какая разница сколько парсить 10 строк или 10 000 строк. Оно реализуется без лишних проблем в несколько этапов, сначала закидываем весь прайс в мускул, а потом пачками парсим данные. Я таким образом закидывал файлы по 10Мб и проблем не было, отличие десктопного приложение от веба тут только в компиляции интерпретации и временного ограничение на исполнение скрипта и в данном случае оно не существенно, т.к. хостинг будет покупаться не за доллар в месяц Smile Нормальный хостинг скушает прайсы екселя и не подавится, да еще и в один прием.
Обновление прайсов как я понимаю будет раз в неделю, это всего 5 минут нагрузки на сервер в неделю. остальное время он будет отдыхать Smile

»»что-то блогоориентированное (как maxsite cms
категорически не согласен, брать левую CMS для серьезного проекта это закладывать материальные затраты на будущее (со временем упретесь в перенос сайта на другой движек)
Друпал тут самое оно, что значит из пушки по воробьям???
У нас есть: магазин, статьи, регистрация пользователей, товар 10000+ наименование, кучу ролей пользователей, парсинг прайсов, ... — какие блогоориентированые движки? об чем вы бредите?
Для этого случая однозначно серьезная CMS нужна и однозначно качественный хостинг, не менее 200$/год — при этих условиях сайт будет отлично работать
Ответить с цитатой
СообщениеПт, 15 Апр, 2011 10:07

orb
как по вашему решить проблему ложных срабатываний? и вообще критерии выборки нужных позиций. Вы же понимаете что ни одна CMS не даст вам нужного результата, модуль то однозначно нужно писать, ничего супер серьезного нет в этом проэкте, просто с помощью php действительно трудно решить эту задачу, из-за большого количества строк + ложные срабатывания, тут я так понимаю "приблизительный" результат не канает. А если вручную готовить прайсы, то их можна залить на любой интернет магазин на абсолютно любом движке и всё.
Ответить с цитатой
СообщениеПт, 15 Апр, 2011 17:02

orb говорит:
Для этого случая однозначно серьезная CMS нужна и однозначно качественный хостинг, не менее 200$/год — при этих условиях сайт будет отлично работать

жжёте Cool у меня самопальный движок на PHP каждый раз при поиске лапатит +30к строк менее чем за секунду, а если делать выборку точную (что и нужно в прайсе) так это вообще в рамках 0.1 секунду, всё это без какого либо кэша и на простеньком хостинге за 15$

P.S: когда-то за вечер под пиво написал редактор таблиц аля Excel с драг-н-дропом и прочими плюшками на jQuery+PHP+MySQL. А вы тут гоните...
Ответить с цитатой
СообщениеПт, 15 Апр, 2011 17:21

0baka0 твой самопальный движок по функционалу и рядом не лежит с друпалом, поэтому скорости сравнивать смысла нету Wink
перебор 30к+ строк тоже дело туманное их можно парсить по разному и перебирать, вообщем это тоже не важно Smile

That я выше писал как решить проблему ложных срабатываний.
1. Прайсов всего несколько видов и можно вручную сортировать, а сайт запомнит для каждого вида прайса соотношения кодов и товаров
2. Можно еще делать сравнение по 70% названию товара (т.е. из 100 букв названия товара, сравнивать первые 70), обычно в конце идут коды товаров
3. У каждой фирмы код товара расположен или в начале в отдельной графе или после запятой в конце товара, поэтому при импорте прайса можно указать где стоит код товара

Вообще вариантов уйма. поэтому первым сообщением я советовал определиться с бюджетом, эта цифра и будет определять количество ручной работы менеджера Smile Чем больше заплатят программисту тем меньше будет менеджер делать ручной работы, вот такая вот закономерность
Ответить с цитатой
СообщениеПт, 15 Апр, 2011 17:34

orb говорит:
0baka0 твой самопальный движок по функционалу и рядом не лежит с друпалом, поэтому скорости сравнивать смысла нету

1) ...
2) я не сравниваю.
3) Я говорю что если иметь прямые руки то всё можно замутить на простом PHP. Как вариант модулем к CMS.

orb говорит:
Вообще вариантов уйма. поэтому первым сообщением я советовал определиться с бюджетом, эта цифра и будет определять количество ручной работы менеджера Чем больше заплатят программисту тем меньше будет менеджер делать ручной работы, вот такая вот закономерность

тут полностью согласен
Ответить с цитатой
СообщениеПт, 15 Апр, 2011 18:06

0baka0 говорит:
orb говорит:
Для этого случая однозначно серьезная CMS нужна и однозначно качественный хостинг, не менее 200$/год — при этих условиях сайт будет отлично работать

жжёте Cool у меня самопальный движок на PHP каждый раз при поиске лапатит +30к строк менее чем за секунду, а если делать выборку точную (что и нужно в прайсе) так это вообще в рамках 0.1 секунду, всё это без какого либо кэша и на простеньком хостинге за 15$

P.S: когда-то за вечер под пиво написал редактор таблиц аля Excel с драг-н-дропом и прочими плюшками на jQuery+PHP+MySQL. А вы тут гоните...


вопрос не в скорости парсинга количества строк за один присет, а в количестве обращений к бд, смотря как написать циклы, нужно не просто найти, а еще сравнить с действующим прайсом (который тоже нужно выбрать из бд) внести корректировки в бд, или вывод двух позиций, вообщем это поиск перелопатит быстро, но тут не только простой поиск.

orb говорит:

That я выше писал как решить проблему ложных срабатываний.
1. Прайсов всего несколько видов и можно вручную сортировать, а сайт запомнит для каждого вида прайса соотношения кодов и товаров
2. Можно еще делать сравнение по 70% названию товара (т.е. из 100 букв названия товара, сравнивать первые 70), обычно в конце идут коды товаров
3. У каждой фирмы код товара расположен или в начале в отдельной графе или после запятой в конце товара, поэтому при импорте прайса можно указать где стоит код товара

Вообще вариантов уйма. поэтому первым сообщением я советовал определиться с бюджетом, эта цифра и будет определять количество ручной работы менеджера Smile Чем больше заплатят программисту тем меньше будет менеджер делать ручной работы, вот такая вот закономерность


1. Вручную можна сортировать, зачем тогда скрипт, и за что платить програмеру.
2. По названию - единственный вариант выборки, верно. Но есть куча товаров с практически одинаковым названием, поэтому скрипт будет выдавать их как один и тот же товар, или же один и тот же товар, у разных поставщиков, незначительно будет отличаться в названии, будет читаться скриптом как разный товар, то есть точности выборки из бд не будет, и это главная проблема, которую даже всемогущий друпал нерешит Smile
3. Коды у разных поставщиков на один и тот же товар разные. По коду отпадает сравнивать.

Насчет количества денег програмеру, я согласен тут частично, но всеже php хоть и крут, но невсемогущ))
Ответить с цитатой
СообщениеПт, 15 Апр, 2011 22:08

Блин от хоть бери и на спор сваргань прототип Rolling Eyes
Ответить с цитатой
СообщениеПт, 15 Апр, 2011 22:31

...ляяяяя... какой несусветный бред на две страницы... писькомерянье, шапкозакидательство, и никто толком не согласился СДЕЛАТЬ.
робятки, честно, ваше програмерство закончилось тогда, когда изобрели пхп. Потом изобрели цмс и самые ленивые решили, что это - вершина.
а нормальные пацаны сели, написали алгоритм гугла и гребут миллионы. например.
абисняю на пальцах: сначала поймите, шо вам нада делать, потом напишите математический алгоритм, потом реализуйте его в прикладной программе неважно на каком языке, главное - десктопный вариант, потом експорт в цсв и лейте его, родного, в ЛЮБОЙ движок или магазин.
Какой несусветный бред нагружать сервак, который должен обслуживать клиентов, задачами сравнения, выборки и упорядочивания десятка прайсов, какой неуёмный тупица будет выкладывать прайсы всех своих поставщиков на сервак, который каждый день будет пытаться сломать сотня самых захудалых хацкеров?
А если ляжет шось? А если этот магазин уже не будет устраивать по каким-либо причинам и захочется нового, другого или более навороченного? опять вызывать мегапрограммера мегадрупала и платить мегаденьги за мегахостинг? а потом, например, мегапрограммера мегаджумлы?

логику можно глянуть здесь:
http://www.price-guru.com/
и здесь:
http://soft.cnews.ru/windows/business/trade/analiz_prays_listov_viberi_sebe_2/
и здесь:
http://uastar.net/ad.php?id=31631
бери-не хочу. Ясен пень, шо малёхо не то, шо нада, но хлопцы хоть алгоритм какой-никакой наклоцали.
берёте, ставите, работаете. потом ставите ТЗ: от хачу такоя жо, но фивалетавае! бабла - скока-то. Срок - вчера. Хто?
а то развели тут...
Ответить с цитатой
СообщениеПт, 15 Апр, 2011 22:39

That, 3 варианта не обязательно рассматривать отдельно их можно смотреть как единое целое и опять таки это не все варианты

>> а в количестве обращений к бд
а вы бекапы когда-то распаковывали в 40-100Мб через PHPMyAdmin?
там делается 5тизначное число запросов иногда и шестизначное и если за раз не получается. то есть счетчик что бы потом продолжить с места на котором закончили
Показать сообщения:   
Страница 2 из 9
Перейти:  
Каталог сайтов Кропивницкого :: Новости Кировоградщины new! :: Опросы :: Фото :: Карта Кропивницкого :: Погода :: Поиск :: Знакомства :: Форум :: Вехи Кирнета
bigmir)net TOP 100 Кировоград — новости и сайты
Информация:
» О проекте
» Реклама в Р.К.С.
» Подсказки / ЧаВо
» Родственные ресурсы
 Владельцам ресурсов:
» Добавить свой ресурс
» Изменить информацию
» Напомнить пароль
» Опубликовать новость
 Дополнительно:
» Правила и условия
» Свяжитесь с нами
» RSS, информеры и кнопки
» Кировоградские юзербары
Copyright © 2018 студия dela design
Сайт размещен в dela link