чего-то у левого чувака с правой ногой не то. Или с левой. То есть какое-то там искривление пространства наблюдается. И освещение тоже странным образом построено. Ну и детали на переднем плане немного неестественно смотрятся. А так картина вполне зачетная — если ее правильно спозиционировать, люди к вам потянутся.
если человек точно знает, что он ищет, он вколачивает на первой название или артикул, или, на худой конец, название товарной группы
Если не знает - лезет в расширенный поиск и ищет уже там
на первой странице - просто инпут + ссылка на расширенный поиск. Расширенный - как чекбоксы если это наличие признака, одиночные поля ввода, если это текст, двойные поля ввода - если это математический диапазон от и до, селект если это выбор из нескольких значений. Набор признаков для каждой товарной группы - свой.
В приведенном случае, если человек указал название агрегата, который он хочет регистрировать, представленный на картинке "2-й шаг" является преступлением против юзабилити. Если вдруг у них есть несоклько устройств разных типов под одним и тем же названием, можно было бы кинуть их списком с радиобуттоном.
Хотя, возможно цель у людей была другая - типа регистриует человек свою технику, а мы ему покажем, что у нас еще куча всякого разного есть - мож купит? Типа как пирожок в бигмачной...
Цель была, логики не было.
Грамотно (это слово очень существенно) заполненное дерево в определенных случая (это слово тоже очень существенно) делает поиск (пусть даже самый распрекрасный) излишним.
Например (из практики) - есть электронный каталог на 40000 позиций. В каталоге представлена куча всякого барахла - от сверел до электростанций - всего где-то 1000 товарных групп, каждая со своими характеристиками. Соответственно, на сайте установлен поиск, который позволяет искать как по названиям, описаниям, текстам, или артикулам, так и по отдельным характеристикам.
Когда-то очень давно каталог представлял собой практически плоскую структуру (уровень вложенности - 1). Правда, тогда и товарных групп было поменьше (кажется 10), и позиций тоже (вроде бы 800). Поиском в тот момент пользовалось в среднем около 25% посетителей.
Потом структура каталога стала древовидной (каталог организован в виде дерева с вложенностью где-то 8), количество товаров увеличилось, количество товарных групп увеличилось, количество товаров в каждой группе увеличилось, а количество пользователей поиска уменьшилось до с веселой цифры 0.69%.
получение патента - штука достаточно тормозная (во всяком случае, без дополнительных подмазок и близких контактов третьей степени (или третьего рода?)). Вобщем, конечно, не поленятся. Посему я и сказал о собственном хостинге. С ним как-то безопаснее.
Возможны и не столь радужные варианты. К примеру, ваш продукт в чем-то обгоняте конкурентов (а он скорее всего в чем-то да их обгоняет), потом у вас его тырят, потом стыренное появляется у кого-то, кто на вопрос зарабатывания всех денег смотрит иначе... Глядишь - и вы уже не имеете право пользоваться собственными наработками, поскольку они являются частью запатентованного другими. Илил какая-то подобная засада.
Nested sets не идеально подходят для веба. Единственный плюс - вывод дерева в правильном порядке одним запросом. На сравнительно больших ветвистых деревьях (25 - 30 КилоУзлов) выигрыш по сравнению с альтернативными алгоритмами (я не имею в виду рекурсию) - около 2 - 3 секунд. на небольших - значительно меньше.
Минусы - вставки и переносы. К примеру у нас есть древовидный форум - вроде текущего обсуждения, но с бошльшей интенсивностью - что-нить вроде обсуждения последнего апдейта яндекса на searchengines. Я пытаюсь добавить комментарий, к примеру, ко второму сообщению в таком обсуждении, всего сообщений 1000. При добавлении будет апдейт по крайней мере 998 строк таблицы. Я не скажу наверняка про MySQL (хотя мне приходилось чистать, что insert и update - не самые сильные его стороны), но PostgreSQL на подобных задачах начинает откровенно загибаться.
Правильнее сказать, что nested sets идеально подходят для деревьев, которые уже никогда не изменятся, либо все изменения будут происходить вне уже сформированных веток. На весь веб я бы не обобщал
слегка меняем принцип заполнения столбца all_parents - записываем туда id текущей рубрики. И лучше делать не массивом, а строкой. получаем запрос вида select * from table where all_parents like '[0][1][2]%', шлепаем индекс на all_parents (не скажу за MySQL, на PostgreSQL делается, хотя и довольно специфически) и все пашет очень даже быстро - запрос на выборку поддерева с 5 - 10 Килоузлами и вложенностью 8 - 10 занимает от 5 до 0.5 mc (5 - без кеширования, 0.5 - с внутренним кешированием БД).
От всех проблем на insert/update это не спасает, но заведомо быстрее nested sets.
nested sets - замечательная штука, пока не возникает задача вставки элемента куда-нибудь в серединку, или в начало такого дерева. или задача перемещения ветви такого дерева. Как только дерево мало-мальски разрастается, insert и update начинают вполне конкретно тормозить (у меня эффект начинал наблюдаться уже на 1500 узлах).
Проблема воровства подходов в PHP всегда была и, вообще говоря, всегда будет (во всяком случае пока он остается интерпретатором с нестрогой типизацией). Можно постараться закрыться зендом + внеджрив в ядро пару - тройку скомпилированных фрагментов - при здравом подходе затраты на взлом обгонят затраты на написание (был в свое время положительный опыт в этой области). Правда, от тыренья идей и воплощении этих идей под другим трейдмарком это не спасает (уже отрицательный опыт тоже имел место быть).
А вообще, если очень хочется закрыть какую-то часть кода, единственный, наверное, жесткий способ - делать свой хостинг. По нынешним временам покупка сервера под 20 - 30 (100 - 200 - тут, пожалуй, все зависит от качества кода и железяк) клиентских проектов вполне окупается где-то за год. При этом, ничего не мешает, оставив ядро закрытым для посторонних, открыть API, сделать общий репозиторий и наслаждаться всеми прелестями open-source подхода. В конечном итоге, 90% примочек, написанных под если не непосредсвтенно под unix, то под какую-нибудь юниховую фичу - юзают общий API и ни разу не заморачиваются на том, что в этот момент творится в ядре системы.
Публиковать, видимо, исключительно потому, что подобная информация (либо, что вернее) - публикация подобной информации - востребована рынком. Точнее - участниками рынка.
Суммы-то, кстати, по большей части похожи на правду, если посмотреть внимательно кто прислал и что они (те, кто прислал) собой представляют. Другое дело, что четкого не эмпирического подтверждения этим суммам сейчас, скорее всего, нет. Ну и выборка не полна, что, как раз вполне объяснимо - свои соображения я уже выссказывал - мелким студиям светиться резону нет никакого, середнякам публикация напрямую может повредить, крупным игрокам - в зависимости от игрока - либо может повредить, либо не актуально, с точки зрения позиционирования, либо (в случае actis или promo) - пофиг. Соответственно остаются "почти крупные", которые рвутся наверх, или пресловутые крупные + сколько-то середняков, которые считают свою нишу плотно заполненной собой любимыми. С одной стороны вроде бы как количественно доля не ахти, с другой, стороны по объему охват получается, навскидку, порядка 25 - 30% рынка, что для первого раза, пожалуй, неплохо.
Если посмотреть предыдущие посты на тему Теглайна (и здесь, и на роеме, и на webпланете), можно легко убедиться, что сам теглайн рейтинг по неподтвержденным оборотам в этом году проводить не то, чтобы стремился. Но отдельные игроки рынка (подозреваю, что именно те, кто, в результате, принял в этом рейтинге участие), напрямую, или через виртуалов, весьма агрессивно настаивали на необходимости публикации именно такого рейтинга. Возможно их расстраивает нежелание Теглайна ставить под такими данными свою подпись. Возможно им хотелось бы попиариться за счет авторитета первого рейтинга студий. Во всяком случае, в этих условиях брать ответственость за неподтвержденные результаты студий было бы нелепо и не профессионально. А критериев подтверждения (при этом стоит помнить - балансы таковыми являться не могут поскольку рейтинг рассматривает рынок создания сайтов (без SEO, без контекста, без PR, без хостинга), а деятельность практически всех студий заметно шире), которые студии готовы были бы опубликовать (подозреваю, надежным критерием был бы исчерпывающий список клиентов, с указанием состава, объема и стимости работ)) - вот стопудовый критерий - точно) в настоящее время нет, либо не разработано. Я поэтому и написал, что надеюсь, что в следующем году вместо (или наряду) с рейтингом по оборотам по данным компаний появится еще и внутренний экспертный рейтинг теглайна по оборотам. Хотя... Если вспомнить, что Икс-Проджект подал в суд на теглайн за слова про то, что искы в 2007 как-то притормозили, перспектива появления экспертного рейтинга тоже выглядит не самой радужной. К сожалению.
В этом случае надпись была бы другая. Не "не несет ответсвтенности", а "результаты представлены в соответствии" и т.д. Надеюсь, в следующем году так и будет. Подозреваю, что "угадайка" получится точнее.
предупреждая вопросы, зачем нужно многократное повторение одного и того же запроса - замечено дополнительное кеширование результатов запросов вида что-то-там=ANY(массив - вообще говоря большой или, вернее - растущий) - соответственно при расширении массива скорость его обработки растет нелинейно в случаях, если такое расширение происходит постепенно и каждый следующий массив (расширенный) включает в себя предыдущий .
В постгресе (8.3.1, AltLinux) замечена следующая штука - стандартное поведение запроса - первый раз он отрабатывает, к примеру, за 10 mc, последующие (пока сам запрос валяется в кеше) - 2 - 3. При использовании prepared statement поведение меняется - первый и все последующие запросы выполняются за те же 10 mc. Связано это, скорее всего, с тем, что prepared statement выполняется через команду execute - т.е. всегда выполняется и никогда не берется из кеша - сохраняется только план обработки запроса. Соответственно, при использовании постоянных соединений использование prepared statement может на отдельных задачах (когда в рамках одной сессии к базе идет несколько не просто сходных, но одинаковых запросов) не только не дать прироста производительности, но наоборот обеспечить просад.
Если не знает - лезет в расширенный поиск и ищет уже там
Хотя, возможно цель у людей была другая - типа регистриует человек свою технику, а мы ему покажем, что у нас еще куча всякого разного есть - мож купит? Типа как пирожок в бигмачной...
Цель была, логики не было.
Например (из практики) - есть электронный каталог на 40000 позиций. В каталоге представлена куча всякого барахла - от сверел до электростанций - всего где-то 1000 товарных групп, каждая со своими характеристиками. Соответственно, на сайте установлен поиск, который позволяет искать как по названиям, описаниям, текстам, или артикулам, так и по отдельным характеристикам.
Когда-то очень давно каталог представлял собой практически плоскую структуру (уровень вложенности - 1). Правда, тогда и товарных групп было поменьше (кажется 10), и позиций тоже (вроде бы 800). Поиском в тот момент пользовалось в среднем около 25% посетителей.
Потом структура каталога стала древовидной (каталог организован в виде дерева с вложенностью где-то 8), количество товаров увеличилось, количество товарных групп увеличилось, количество товаров в каждой группе увеличилось, а количество пользователей поиска уменьшилось до с веселой цифры 0.69%.
Минусы - вставки и переносы. К примеру у нас есть древовидный форум - вроде текущего обсуждения, но с бошльшей интенсивностью - что-нить вроде обсуждения последнего апдейта яндекса на searchengines. Я пытаюсь добавить комментарий, к примеру, ко второму сообщению в таком обсуждении, всего сообщений 1000. При добавлении будет апдейт по крайней мере 998 строк таблицы. Я не скажу наверняка про MySQL (хотя мне приходилось чистать, что insert и update - не самые сильные его стороны), но PostgreSQL на подобных задачах начинает откровенно загибаться.
Правильнее сказать, что nested sets идеально подходят для деревьев, которые уже никогда не изменятся, либо все изменения будут происходить вне уже сформированных веток. На весь веб я бы не обобщал
От всех проблем на insert/update это не спасает, но заведомо быстрее nested sets.
А вообще, если очень хочется закрыть какую-то часть кода, единственный, наверное, жесткий способ - делать свой хостинг. По нынешним временам покупка сервера под 20 - 30 (100 - 200 - тут, пожалуй, все зависит от качества кода и железяк) клиентских проектов вполне окупается где-то за год. При этом, ничего не мешает, оставив ядро закрытым для посторонних, открыть API, сделать общий репозиторий и наслаждаться всеми прелестями open-source подхода. В конечном итоге, 90% примочек, написанных под если не непосредсвтенно под unix, то под какую-нибудь юниховую фичу - юзают общий API и ни разу не заморачиваются на том, что в этот момент творится в ядре системы.
Суммы-то, кстати, по большей части похожи на правду, если посмотреть внимательно кто прислал и что они (те, кто прислал) собой представляют. Другое дело, что четкого не эмпирического подтверждения этим суммам сейчас, скорее всего, нет. Ну и выборка не полна, что, как раз вполне объяснимо - свои соображения я уже выссказывал - мелким студиям светиться резону нет никакого, середнякам публикация напрямую может повредить, крупным игрокам - в зависимости от игрока - либо может повредить, либо не актуально, с точки зрения позиционирования, либо (в случае actis или promo) - пофиг. Соответственно остаются "почти крупные", которые рвутся наверх, или пресловутые крупные + сколько-то середняков, которые считают свою нишу плотно заполненной собой любимыми. С одной стороны вроде бы как количественно доля не ахти, с другой, стороны по объему охват получается, навскидку, порядка 25 - 30% рынка, что для первого раза, пожалуй, неплохо.