Unlock, спасибо.
Единственное замечание - глюк, воспроизводимый на большом количестве сайтов, тяжело назвать глюком :)
Бэклинков гугль не показывает. Ничего хорошего это не сулит.
Я склоняюсь к тому, что сумма всех PR равна единице и при увеличении количества известных Гуглю страниц PR отдельно взятой страницы уменьшается при неизменном количестве ссылок. Т.е. даже при неизменной шкале TBPR страница может выпасть из одного диапазона в другой. В результате можем получить цепную реакцию: менялся с кучей 5-к и у тебя была 5-ка, после апдейта многие из тех с кем менялся, получили 4-ку, и ты тоже получил 4-ку.
В этом смысле более интересен предыдущий апдейт, когда морды сайтов вдруг стали иметь PR меньше, чем на внутренних страницах. В этот раз я такой картины не наблюдаю, т.к. те, кто подверглись такой напасти в прошлый апдейт и за кем я наблюдал, уже успели попасть в бан до этого апдейта. Посему любопытен такой вопрос: как изменилась ситуация у тех, кто наблюдал перекос в прошлый апдейт на своих сайтах.
Стоп, стоп, стоп. Судя по данным утверждениям, твое решение неправильное. Из соображений безопасности, производительности и т.д. у тебя должна быть одна база, обслуживающая онлайн-транзакции (OLTP), и вторая - для всего остального. Если тебе станет легче - подобный вопрос в ходит в сертификационный экзамен MS для разработчиков БД :)
Смотри: для того, чтобы клиент выбрал товар и оформил заказ, тебе нужно минимальное количество таблиц: прайс-лист (с рубрикатором), таблица для идентификации клиента, корзина. Все изменения складских остатков (в другой базе) производятся только в момент окончательного оформления заказа, а ещё лучше, когда заказ поступает на обработку к менеджеру и он жмёт пимпу "принять к исполнению".
Тут часто появляется возражение, а если товар в прайсе есть, а на складе его нет? Будут неприятности. Неприятности как раз возникают при одновременных конкурентных выборках из таблицы и одновременных изменениях записей в этой же таблице. Т.е. что получается: запрос на изменение данных сначала ждёт, пока ему освободят страницу данных, где он будет проводить изменения, а потом все ждут пока он закончит проводить изменения. Если запросов на изменение мало, то ничего страшного. А вот если много, то будут выстраиваться огромные очереди запросов. Особенно если к простым запросам от клиентов добавятся тяжеловесные запросы от бухгалтеров и прочих манагеров. Проблема решается наращиванием компьютерных мощностей. Но всегда есть риск уткнутся в потолок. Так что лучше делать разделение. Что же касается неприятностей с отсутствием товара на складе при наличии в прайсе, то данная проблема решается административными мероприятиями. Есть такой термин в нашей бухгалтерии: "неснижаемые складские запасы". Т.е. в прайс, изменяемый раз в сутки, попадают те товарные позиции, которые заведомо не будут проданы за один день.
Так вот, OLTP база может вполне обслуживаться и mySQL. Твой аргумент - гомогенность.
P.S: я немного утрировал ситуацию, т.к. множественные запросы к одной и той же таблице на изменение данных и на чтение можно разрулить, допустив грязное чтение данных, т.к. всё равно пока клиент оформляет свой заказ картина мира несколько раз изменится, но вот тяжеловесные запросы (OLAP, online analytical processing, т.е. сбор аналитики за большие промежутки времени, которые по определению не допускают грязного чтения) точно твой магазин введут в ступор, если будут выполнятся на OLTP базе.
Здесь был бы очень длинный пост, если бы я вовремя не вспомнил Антон Палыча :)
Поэтому коротенько: Гугль сейчас №1 именно потому, что они не читали чужие идеи, а реализовали свою.
Я к тому, что практика - критерий истины.
vmegap,
моя программерская специализация аккурат работа с БД :). Поэтому могу сказать, что сравнение MS SQL с MySQL из разряда "религиозных войн". Т.е. что-то вроде из сравнения Unix vs Windows. Или, более жизненный пример, вопрос из серии что лучше микроавтобус или двухэтажный рейсовый автобус. Т.е. у человека "в теме" даже не возникает мысли об абстрактном сравнении. Сравнивать можно MS SQL c Sybase ASE, Oracle и DB2. Или MySQL с Interbase, PostgreSQL, Sybase ASA и т.д. Но не их между собой.
Если говорить про задачи, то на пальцах примерно такое объяснение: если тебя не шибко заботит целостность данных в нештатных ситуациях и разграничение прав доступа к этим данным, т.е. у тебя в БД хранится к примеру содержимое форума и ты легко переживёшь при случае откат к предыдущему дампу, а все пользователи обращаются к БД под единым логином (админским :D), то твой выбор - mySQL из-за более высокой производительности и доступности. Если же у тебя в БД хранится бухгалтерия предприятия, т.е. ты хочешь быть уверенным, что даже разработчик клиентского приложения зная логин и пароль (секретарши :D) не сможет увидеть то, что видеть ему не положено, или, если какая-нибудь дура секретарша удалит чего-нибудь лишнее, а ты хочешь откатить БД в состояние за секунду до этого необдуманного действия, чтобы всё предприятие не встало до того момента, пока секретарша повторно не введёт то, что она удалила, то твой выбор MS SQL (или любая другая СУБД из списка выше).
Да, если есть желание посмотреть серьёзные замеры производительности промышленных RDMS, то тебе сюда: http://www.tpc.org/information/benchmarks.asp
Гм. Посмотрим на выдачу гугля. По запросу роман Война и мир самого романа на первой странице нет. Потому как слово роман встречается чаще во всяких сочинениях и рецензиях. И чем дальше углубляться в анализ текста, тем меньше будет шансов у собственно романа пробиться наверх.
Я скажу больше. Чем менее чётко сформулирован запрос, тем чаще в выдаче будут попадаться именно главные страницы сайта. Вполне справедливо между прочим. А там зачастую вообще никакого связного текста нет. Следовательно нет и смысла его анализировать. Подавляющее же число запросов - нечётко сформулированы.
Анализ текстов безусловно нужен. В специализированных поисках. Во-первых, там специально отобраны коллекции документов по теме, а во-вторых, ищущие правильно формулируют запросы. Под правильностью подразумевается древнее утверждение: правильно сформулированный вопрос содержит в себе половину ответа.
Рекомендую на досуге прочитать Р.Шекли. Правильный вопрос.
Посмейтесь. Может быть это поможет. На форуме это обсуждалось с самого начала его существования: на основании сколь угодно глубокого и совершенного анализа текста невозможно определить, что по запросу Война и мир, на одном из первых мест просто обязан присутствовать роман Толстого. С войной всё просто - в романе хотя бы батальные сцены присутствуют. А как быть с миром?
Подобные конструкции невичисляемы в принципе. Т.е. ты либо знаешь, что данный текст имеет название Война и мир, либо вынужден ориентироваться на какие-то другие критерии оценки. Т.о. в очень многих случаях поисковик будет вынужден полагаться на заголовок документа и текст (и авторитетность) ссылок. Следовательно всё, чего можно добится совершенствованием методов анализа текста - это отсечение текстов, сгенерированных машиной. И то, далеко не всех.
Доктор, у меня ЭТО. :)
Какой браузер, какая ОСь, сервиспаки?
И как может что-то виснуть постоянно, если всё "полетело нафик"? :D
А вот теперь и мне пришло. Видимо проблема сама собой рассосалась :)
