(no subject)

[dikayasobaka]

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

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

Comments

[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 для отчетов.
:)