MiksIr

У меня планшетик от них. Лучше и дешевле чем аналоги брендовые.

mouseover срабатывает один раз при появлении мышки над элементом. Логично предположить, что вам нужно другое событие, правда?

Не вижу причем тут размер кода "да еще через SVN". Причем тут SVN вообще? Причем тут размер кода? Вы находите нужный элемент, сдвигаете на нужное число пикселей и тому подобное, переключаетесь в IDE, проверяете в каком файле какое место он хочет изменить и принимаете изменения. Вот то, на что ссылку дали, с изменением файла неким "независимым" софтом, это не удобно, да, ибо проходит мимо редактора. А css-x-fire - вполне себе рабочее _удобное_ решение, ибо полный контроль над изменениями.

Ага, я уже вижу

Адская поделка. Такую и правда лучше не использовать. Сравните с тем, на что я ссылку дал =)

Наш верстальщик тут нашел такое http://code.google.com/p/css-x-fire/ Это то, о чем я несколько лет назад просто мечтал, но не нашел. Устанавливается плагин в firefox и phpstorm и все изменения в css сделанные в firebug-е транслируются в IDE, а там одним нажатием кнопочки переносятся в css файл.

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

А, ну тогда поясню. Внутри плагина this - это коллекция, которую вы выбрали селектором, т.е. в вашем случае все P. Если можете работать с коллекцией - цикл делать необязательно. Т.е. bind вполне можно вызвать на коллекцию, он сам разберется уже. А если вам нужно что-то персонально сделать с каждым элементом коллекции (например, поменять текст внутри каждого P) - тогда делаете цикл по всем элементам. jQuery дает простую возможность делать цикл через коллекция.each(функция). Еще по коду - функцию send можно вынести за цикл, нет нужды в данном случае ее объявлять столько раз, сколько элементов в коллекции. Ну и замечание по стилистике - крайне рекомендуется использовать внутри плагина подное обращение к jQuery, т.е не $(this) а jQuery(this). Если хочется краткости, то можно в начале плагина написать var $ = jQuery; Это свзязано с тем, что пользователь вашего плагина может отключить короткий синтаксис (это бывает нужно из-за проблем с другими библиотеками).

http://dev.1c-bitrix.ru/api_help/main/general/menu.php

1. $('this') - опечатка. 2. $.fn.plug=function(otions){ - опечатка в options 3. Это тестовый пример или вы реально что-то делать пытаетесь? Ибо в вашем случае this.each не нужен даже, можно просто $.fn.plug=function(otions){ var options=jQuery.extend({color:'red',background:'blue'},options) $(this).bind('click', function() { $(this).css('color',options.color); }); return this; }

Можете написать расширение меню (.ext.) и там читать файлы меню подразделов и добавлять в текущее.

У меня есть стойкое ощущение, что вы спорите сами с собой, вернее со своими фантазиями. Ясно, т.е. все же вы не очень в курсе. Почитайте про HandlerSocket. И насколько увеличивается время выборки. Вот эта "дельта" и есть затраты на SQL парсер. Если парсер и все накладные отрабатывают 5 мс, выборка по ключу 1мс, а джойн.. пусть 3 мс, сколько процентов будет? Это был вам легкий намек, что без noSQL ваше решение смысла не имеет. Он дорогой по причине написания собственных аналогов индексирования, парсера запросов, служебных утилит. Кэш в памяти еще быстрее, да впридачу гораздо дешевле при хранении в удобном виде в базе. Так что связка кэш+СУБД для меня предпочтительнее собственноручно написанных поделок. Лолчто? Речь идет о хранении кеша в ФС. Какое тут индексирование, какой парсер запросов... о чем вы. Вы что, статический кеш никогда не делали? В память ваша база не влезет, забудьте. 1й способ - переписываем генератор кеша или запрос во вьюхе, сбрасываем весь кеш, перегенерируем весь кеш. Причем в огромной транзакции, так как нам после обновления кеша на новый формат нужно очень быстро переключить на новую версию софта... ах, софт - это ajax на клиенте... ну извините, клиенты, которые в этот момент работают. 2-й способ - а запрос зачем переписывать? он делает ровно то, что нужно, т.е. достает данные, меняем только формат хранения, что бы генератор json сделал новую структуру. В обоих случаях переписывается код. Большой вы фантазер, я погляжу. - требует повторного тестирования другого участка, да и вообще тесты выполняются всегда перед деплоем - требует код обновления на продакшн системе или что еще хуже, требует обновления вьюх - тупейший джойн имеет предсказуемую скорость выполнения, в отличии от плавания вашего метода в моменты перегенерирования кеша, который меняет огромные объемы данных, а значит база выходит из стабильного прогнозированного режима. Сами сказали - исходные данные сотни гигабайт. Ваша денормализация увеличит минимум раз в 10, не меньше, но запросто больше. Винты, к слову, тоже куда-то втыкать еще нужно. Будут. Ни одни прием XP не подразумевает бацать год монстра в котором все заложено заранее под супер-пупер нагрузки, которые даже не в плане, а гипотетически выдуманы разработчиком. XP вообще не об этом, а то что и есть - нацелено на быстрый выпуск рабочего прототипа и плавное наращивание короткими итерациями. Резюмируя: советую вам свои фантазии держать при себе. Идея кеширования стара как мир, но основная и очень важная идея, которая проходит через подавляющее большинство систем кеширования - система должна работать с отключенным кешем. С другими параметрами нагрузки, но работать должна. И самое главное - создается тогда, когда нужен. А не тогда, когда разработчику что-то спросонья почудится и он начнет создавать монстра оправдывая "а вдруг завтра 10 миллионов уников придет несмотря на то, что сейчас всего 15 человек". Но вы можете фантазировать дальше, только людям не советуйте или помечайте "когда вам одного сервера станет мало". Даже тогда такие советы вредны, ибо до конца не продуманы, но хоть "в тему" будет. На сим тему можно считать закрытой, устал уже спорить о конях в вакууме, предпочитаю более реальные проблемы решать.

Я все же не верю, что вы что-то серьезное создавали уже сами. Претендуя на знания хайлоада выкидывать такие вещи, как SQL парсер и планировщик, из-за которого вы даже 20% прироста между этими двумя запросами можете не получить, ибо сама выборка быстра по сравнению с накладными запросами. Или говорить что-то про "дорогой экспорт в фаловую систему" (интересно с чего бы это), забывая, что файлы можно отдавать напрямую веб-сервером и даже минуя userspace, за счет чего можно обслуживать огромное число запросов. А вот это вообще детский сад. Начиная с того, что более сложный код сложнее модифицировать и обслуживать. Ну и заканчивая вопросами бизнеса, о которых тут тем более не стоит спорить. Спасибо, посмеялся тут отличное решение "не в лоб" - сделать из сотен гигабайт десятки теробайт ради нопределенных целей "что бы было круто". Т.е. вы уже выбросили по штуке баксов за каждый теробайт ради непонятно чего, что бы хранить кучу дополнительных данных, которые, может, никогда и не будут востребованы. Отличная архитектура, чего уж =)))

> Эффективнее по каким параметрам? Как вы вообще эффективность посчитали? По тем же самым, что вы посчитали эффективность запихивания 100500 данных в таблицу. > Легко. Контент-анализ Зачем для контент-анализа синонимы? Или вы про генерацию сеошных говнотекстов? И что, там большине нагрузки? Лол. > Т.е. бесконечно переделывай архитектуру? Бугагашеньки. Хайлоад архитектура - это фикция. Она просто имеет возможность масштабироваться либо горизонтально, либо вертикально. Не только. Спорить с вами смысла не вижу. У меня только одна спроектированная с нуля архитектура, все остальное мелкие подкладки падающих под рекламщиками проектов, может спроектировав десятки я как вы обрету такое же видение, что нет никакой архитектуры. Пока же у меня другое мнение, и я делаю ровно то, что необходимо, ибо есть стоимость часа работы программистов, есть стоимость обслуживания, есть вероятность возникновения человеческой ошибки при том или ином решении и ее стоимость. Вот ваше решение - очень дорогое. Примера, когда в данном конкретном случае это окупится - не вижу. Равно как и причины при таких адских нагрузках, о которых вы рассказываете, хранить этот кеш в базе, а не выкладывать в файловую систему. А вообще, советую почитать, как работает поиск по индексу, как работают джойны, куда лезет база для выковыривания text полей и т.п. А так же на что тратится время в обычной реляционной базе. Ну и попробовать эти ваши запросы. У меня нет базы в миллион слов, есть в 2 тысячи - выборка по слову и джойн показывают одинаковое время. Ну, я понимаю почему, только опять спорить? А то передете сейчас с редисам всяким... бедный топикстартер. Спросил как сделать примтивную вещь, а ему целую архитектуру под высокую нагрузку в ответ

Да блин. Для того, что бы думать о докупках серверов нужно хотя бы один купить и убить его. Не нужно тут сферических коней гонять. Если уж у вас голова от прочтения всяких "архитектур" съехала - сфинкс будет эффективнее вашего "сторажда". Основное правило разработки хайлоад архитектур не "кешируй все что можно", а ищи узкие места и ищи решение как их ускорить. Это может быть кеш, а может быть другое хранилище или другой алгоритм. Сейчас слушать о каких-то 20-50-100% просто смешно. Для начала придумайте мне такой сервис, у которого проверка синонимов будет насколько узким местом, что ее нужно оптимизировать, потом доведите посещаемость до таких величин, а потом уже думайте. А до тех пор нет никакого оправдания, что вы вместо часа потратили два дня на создания и проверку системы актуализации кеша (а если она при этом еще работает как приложение, а не как триггеры в базе - то написание документации что как запускать), который реально нужен этому проекту как машине 5-е колесо.

Да быстро join будет работать, быстро. Нужно очень быстрое решение - берите сфинкс, скармливайте ему статьи с синонимами и ищите. А то, что предлагает s0rr0w - это на пустом месте родить сотни мегабайт ненужных, дублированных данных ради неопределенной экономии.

Таблицу можно джойнить саму на себя SELECT t2.slovo FROM table t1 INNER JOIN table t2 ON (t1.group = t2.group) WHERE t1.slovo='квасить';

Ну хорошо хоть перестали убеждать, что данные нужно прямо так и хранить. Теперь осталось научится рассказывать человеку как хранить данные, а потом, если нужно, рассказать как кешировать. А не рассказывать, что данные нужно сразу хранить кешированные (для понимания - денормализованные в данном случае = кешированные), не упомянув о том, как же их хранить изначально. Ибо решение о кешировании принимается исходя из архитектуры проекта, а не из задачи "как мне сделать". Да, тогда или вторая таблица, как я писал выше, или дублирование слов в одной таблице как омонимов.

Так в доке по плагинам написано - юзайте .data

А что я там дожен увидеть? Ткните пальцем. Интересует именно денормализованное неконсистентное хранение с многократно дублированной информацией в качестве основного хранилища, а не кеша. Речь идет не о выборке, а об обслуживании - нарисуйте алгоритмы замены слова, удаления слова, добавление нового слова. О том, что у вас будет отстутствовать хоть какая-то проверка консистенции данных, можно и не говорить, вы же понимаете это, да? Да, в отличие от вас я прекрасно понял, что автор вообще нихрена не смыслит. И не стал показывать крутость знаний хайлоада, а объяснил на классическом SQL. Ваш вариант - всего лишь кеш. Вас спросили как данные хранить, а вы рассказли, как их кешировать. Да еще с отсылками на гипотетический хайлоад. Сначала нужно научится задачи классически решать, а потом уже читать про архитектуры хайлоадов и сувать их куда не попадя. Испугался одного джойна и засрал таблицу тоннами говна "денормализованных данных"... классика. Не нужна там таблица связей, LunatiK давно уже увидел самое простое решение, и выборка из него будет в один джойн таблицы на себя. Спорить больше не о чем.

Если затраты на обновление кеша у вас первышают работу с базой, значит пора уволить архитектора и пригласить того, кто хоть немного в этом понимает. И в создании кеша, и в его актуализации. Искать вы это слово как будете в хранимом JSON-е? Скан всей таблицы без индекса, ага. У вас же хайлоад, миллионы записей данных... Еще раз, не мешаейте в кучу кеш и работу с данными. Хоть для этого найдите соображение. Что сначала проектируются данные и работа с ними, а потом, если это место становится узким - реализуют заранее продуманные заглушки по кешированию. По-этому нефиг лезть с кешированием данных в тему о структуре исходных данных и работе с ними. В 100% случаев обсуждаемых на этом форуме трудозатраты по созданию нормального кеша и обслуживание усложненного кода никогда не оправдают копеечный выигрыш, который тут предлагается.

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

Да, точно, так проще.

Это будет говнокод.

Значить, стандартное один ко-многим, но только внешне. CREATE TABLE words ( id integer NOT NULL, word text, CONSTRAINT words_pkey PRIMARY KEY (id ) ) CREATE TABLE word_syn ( word_id integer NOT NULL, syn_id integer NOT NULL, CONSTRAINT world_syn_pkey PRIMARY KEY (word_id , syn_id ), CONSTRAINT world_syn_syn_id_fkey FOREIGN KEY (syn_id) REFERENCES words (id) MATCH SIMPLE ON UPDATE CASCADE ON DELETE CASCADE, ) word_id тут или счетчик группы синонимов, а лучше, что бы не путаться - id первого слова группы В таблице прописываем эти группы синонимов. words: 1;"синоним А 1" 2;"синоним Б 1" 3;"синоним А 2" 4;"синоним А 3" 5;"синоним Б 2" word_syn: 1;1 1;3 1;4 2;2 2;5 Ну и запрос SELECT syn.word FROM public.words src INNER JOIN public.word_syn link ON (src.id = link.syn_id) INNER JOIN public.word_syn link2 ON (link.word_id = link2.word_id) INNER JOIN public.words syn ON (link2.syn_id = syn.id) WHERE src.word = 'синоним А 1';