Запросто, существует некий сайт который живет за счет републикации новостей. Первоначальная структура его была sitename/news/phone/2005-12-02/ nokia_62336234_klassika_v_finskom_ponimanii/1594/, при этом никакой оптимизации под поисковики не проводилось, все новые поступления кратковременно публиковались на первой странице потом уходили на третью по вложенности, или еще дальше в зависимости от давности. В таком виде сайт просуществовал 4 месяца, каких либо работ по оптимизации или продвижению не проводилось. За это время количество уникальных посетителей с гугля выросло да 200 в сутки и замерло на этой отметке. Затем структура ссылок сайта была пересмотрена и они приобрели вид sitename/news/phone/1594/, все старые ссылки редиректом бросались но их новое представление и о чудо, за неделю сайт был полностью переиндексирован гуглем, а это уже более 4000 страниц, и посещаемость резко подскочила до 700 уникальных в день, последующий месяц она продолжала расти до отметки примерно 900 посетителей на чем и замерла. выводы делайте сами.
к чему вы это? и почему ваш сайт www.belwebsite.com использует краденный «дизайн»?
не только, тот же гугль реагирует на длину ссылки и на количество «переменных/уровней» в ней. проверено опытным путем. причем реакция на длину ссылки у него намного более ярко выражена чем реакция допустим на ассоциативность ссылки
В некоторой степени будет влиять глубина вложенности документа
чем короче, тем лучше, но сильно сомневаюсь что поисковики обижаются именно на адрес страницы
Некоторые базы умеют с сырыми дисками работать, так там файлов нет вообще – умеют, не спорю, лотус например, правда по моему только когда он на сервере домино висит а вот на паче не умеет или db2, насчет остальных не знаю. В остальном вы опять же упираетесь в интерфейс доступа к данным который во многом унифицирован и вам вовсе в данном случае не нужен
терабайт в одной таблице? интересно db2 с этим справится? интересно будет попробовать. Для примера моя рабочая база хранится в мускуле и занимает 360 Гб, пользуется правда только во внутренней сети, это всего полтора десятка пользователей, но комп на котором она висит древний, семпрон 2500 кажется, тормозов нет никаких.
любая база данных это всего лишь набор файлов, а сама «база» лишь интерфейс доступа к ним, блобы, варчары, какую размерность поля вы зададите для варчара? Пять, десять, сто символов? А как индекс по ним? Чем больше размерность поля, тем больше места будет занимать индекс, а в большинстве случаев он будет избыточен. Тупик? Разрабатывать свой интерфейс доступа к данным?
З.ы. по объемам и производительности на мускуле, мускуль прекрасно работает с базами до терабайта, другой вопрос если вы начнете сегментировать базу тогда он уходит, но точно также тут пасует и оракакел, что остается, db2? Или все же своя база данных? или просто файловая система?
Думаю что все будет зависить от поставленных задач и их окупаемости.
при такой экономии и при указанных вами объемах выигрыш будет в пару десятков килобайт, но при этом вы затратите больше процессорного времени и скорее всего будете делать большее количество обращений к базе данных, смысл?
не совсем понял вашу логику, вы хотите страницы отвечающие поисковому запросу но принадлежащие одному сайту исключить оставив одну наиболее релевантную? или хотите сгруппировать их?
