(no subject)

[dikayasobaka]

Не понимаю, какого хуя огромное количество новостных и информационных сайтов трет свои же страницы. Покопался в старых заметках - половина ссылок показывает "в никуда". Главное, там же все что было - это максимум пара-тройка килобайт текста. Им что, жалко? Или переадресовку поставить тяжело?

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

Comments

[polittechno.livejournal.com]

уверен, что материал нужно представлять полностью. Частично опубликованные статьи девольвируют контент, случись что с сайтами, на которых хранится полный вариант статей. Просто ссылки нужно ставить. На неё всё равно клацнут, если читателя заинтересует реакция форума на сайте - хранителе оригинала

[dikayasobaka.livejournal.com]

Речь идет о цитатах.
Тут получается - нужно статью скопировать к себе, целиком, затем ссылаться уже на ссылку у себя на сайте. Куча никому, по сути, не нужной работы.

[polittechno.livejournal.com]

ну как - если сайт для Вас - это лучше - ифа всегда на месте

если для людей - тоже. Но вот битые ссылки - криминал

ненавижу битые ссылки

[dikayasobaka.livejournal.com]

Что такое "ифа"?

А битые ссылки я и сам не особо люблю, если честно признаться:)

[suricat.livejournal.com]

Нужной, на самом деле. Многих из статей потом не доищешься. Я некоторые по особенно нужным мне темам копирую в "подзамочное" в ЖЖ, потом их можно доставать при необходимости и давать ссылки уже к себе. Вам на сайте было бы это делать удобнее.

[dikayasobaka.livejournal.com]

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

[z-podkolodnaya.livejournal.com]

потомушто кругом жыды, пидарасы и фашысты с феминистками...

[dikayasobaka.livejournal.com]

И еще масоны!!! :))))

[z-podkolodnaya.livejournal.com]

эти то вообще везде влезут! )))

[dikayasobaka.livejournal.com]

Жил он тихо, мирно, незлобиво
Но в саванну прибыл как-то раз
С гнусною ухмылкою дебила
Европейский садопидорас

[z-podkolodnaya.livejournal.com]

ыыы)))) а стих про афро-африканца вообще нечто))))

[malaya-zemlya.livejournal.com]

www.archive.org и кэш гугля сильно помогают.

[dikayasobaka.livejournal.com]

Да, спасибо:)
Хотя тоже вопрос - как долго код там держится.

[malaya-zemlya.livejournal.com]

Про гугль не знаю, а в архиве теоретически вечно.

[emdrone.livejournal.com]

Есть специальный сайт - Internet Time Machine, если верно помню - на него ссылается Гугл, если страница отсутствует - в котором сохраняются старые версии страниц.
Если вы знаете точный URL (and you do if you kept the link), он вам выдаст варианты по времени

[dikayasobaka.livejournal.com]

О!!!
Это мысля!
Спасибо:)

Хотя зачем хозяева изначального линка его трут - до сих пор толком понять не могу. Т.е., если это какой-нибудь фильм на 50 мегов, то это еще логично, но статья на пару страниц? Зачем??? :)

[poluzhivago.livejournal.com]

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

[dikayasobaka.livejournal.com]

А чем это засоряет? Если разработать систему, которая по датам сортирует - то в чем проблема-то?
Да и переадресовку поставить несложно.

[poluzhivago.livejournal.com]

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

[dikayasobaka.livejournal.com]

Какой учебник?

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

[poluzhivago.livejournal.com]

Учебник по администрированию баз данных. Любой. Базы данных (включая новостные) растут быстро и в среднем около 80% данных в базе остается невостребованным. Поэтому их время от времени и архивируют, чтобы поддерживать рабочую базу данных более компактной и простой. Кроме того, старые данные удобнее классифицировать по несколько отличным от оперативных данных принципам, поскольку это уже данные несколько иного рода. В общем, это common practices.

[dikayasobaka.livejournal.com]

База данных к URL имеет в лучшем случае косвенное отношение. И все озвученные тобой задачи легко решаются "под капотом" - в-основном, с помощью индексации и оптимизации физического размещения баз данных. И вообнще ты зря думаешь, что никто, кроме тебя, баз данных в глаза не видел:)

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

[poluzhivago.livejournal.com]

Я не считаю, что кроме меня никто не видел баз данных. И не сомневаюсь, что задачи, о которых мы говорим, можно решить и без деления на архивы и перенесения туда устаревших статей или картинок. Однако существуют т.н. common practices, и они взяты не с потолка, и не назло тебе. И с поисковиками они умеют координироваться тоже.

[dikayasobaka.livejournal.com]

> Однако существуют т.н. common practices, и они взяты не с потолка, и не назло тебе.

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

[poluzhivago.livejournal.com]

Ну, ты считаешь это тупорылым, а я нет. Вижу в этом прямой смысл. Частично уже объяснил, в чем, частично лень - мне работа и так надоела, даже думать о ней противно. Этой ночью припиздки из Калифорнии забыли, что время на час переводится и засандалили на все наши серверы forced update, требующий рестарта, во время database back up. Все полетело к ентой матери. Если не впечатлило - это конец квартала - все данные бэкапа за квартал got corrupted. Восстанавливал до 6-ти утра.

[dikayasobaka.livejournal.com]

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

[poluzhivago.livejournal.com]

Нет, она подтверждает правильность common practices, о которых я говорил: архивная база данных полетела, а на работе это не отразилось, поскольку "живая" база с ней никак не связана. А если бы полетели "живые" данные, было бы намного хуже: они еще не архивированы, бэкапов нет, восстанавливать неоткуда - пропали бы данные на миллионы долларов, а это бы даром не прошло (у нас в конце 1-го квартала каждый день поставки на $25-30 млн). Это еще один плюс разнесения данных на "живые" и архивные: меньше запросов к живой базе данных, меньше и проблем.

[dikayasobaka.livejournal.com]

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

[poluzhivago.livejournal.com]

Это внесет неразбериху, мы так пробовали - в какой-то момент становится непонятно, что откуда берется.

[dikayasobaka.livejournal.com]

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

[poluzhivago.livejournal.com]

Не, нахрен работу - опять в детали углубляемся.
:)

[dikayasobaka.livejournal.com]

Работу - на, в и к!!! :))))
Согласись только, что - особенно в корпоративном мире - очень многое на самом деле делается не по логике и даже, я бы сказал, вне логики.

[poluzhivago.livejournal.com]

Это да. Я вот жду, кому завтра выпишут за вчерашний shutdown.
:)

[dikayasobaka.livejournal.com]

А не один ли хуй? :)
Почти наверняка - не тому, кому надо, и не так, как надо(

[poluzhivago.livejournal.com]

Я позаботился о том, чтоб кому надо - он не в первый раз из-за своего пофигизма нам авралы устраивает. Жопа - другого слова у меня для него нет.

[dikayasobaka.livejournal.com]

Ну если не в первый раз, и он все еще не перемещен туда, где у него не будет подобной возможности - то, согласись, система сбоит.

[poluzhivago.livejournal.com]

Ну, ошибки у всех бывают, всем дают second chance. Он тоже не нарочно. Надеюсь, что теперь у него "ключик" отнимут.

[dikayasobaka.livejournal.com]

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

[poluzhivago.livejournal.com]

Скорее всего его как раз перепрофилируют туда, где он не будет иметь доступа к модификациям - у нас один такой уже сидит и в режиме read only пишет SQL queries для отчетов.
:)