hVosttпросто интересно?Меня интересует природа этой таблицы? Откуда она вообще появляется?
При записи нового поста на форуме (к примеру) каким образом в таблицу соответствий заносятся значения?

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

либо заполняется по ходу дела в режиме кеша.
либо, при непреодолимом желании, хеши записываются в базу и считываются скопом.

зависит от задач, от природы данных, от требований, от технологических возможностей.
Ты вообще с дурдома пришел, признавайся? Попробуй в цикле пропусти сотню другую миллионов записей и запихни в кеш Да у тебя всё раком встанет. Срочно читать мс архитектурный гайд по кеши, где и как его использовать. У тебя ветер в башке.
А самое главное, пока твоя кеш будет наполняться пол дня, в это время у тебя юзеры будут отваливаться по битым ссылкам. Только упоротый из кеши будет делать БД.
Тебя к архитектуре нельзя допускать и на пушечный выстрел.

У тебя мозг засран какой-то шехулой из рекламы корма для поросят. У меня настроечная таблица, суть ее - расширение основной. Маппинг на живые урлы с указанием контроллеров и экшенов. Денормализация - для перформанса, уникальный индекс по урлу. Нашли урл, на лету взялм контроллер и действие, в путь. Всё прозрачно и просто. И то я противник использования такого подхода, только нативный роутинг мвц. Это быстро и нативно. И отлично индексируется поисковиками. Максимум, могу убложить сеошников и наложить сахар в урл. Но не более того.

hVosttмсущкоЭто быстро и нативно.
это далеко не быстро и очень наивно.
Это просто пипец как бысто и нативно, никаких промежуточных костылей не нужно. Ссылки честно генерятся через @Html.ActionLink, никакой дополнительной магии.

hVosttосновная задача с точки зрения СЕО -- это ЧПУ и отображение структуры сайта в URL. когда ты перемещаешься на уровень ниже (глубже) на сайте, к URL-у добавляется сегмент. когда возвращаешься "выше", последний сегмент убирается.
Я тебе десять раз уже сказал, URL - это указатель ресурса, а не деревья, структура или класс. Если нужна правильная навигация, для этого делается штатный сайт мап, краулеры его любят и отлично всё структурируется в иерархическом виде. Ты просто не умеешь это готовить. Не нужно в URL пихать какую-то логику.

hVosttу тебя же какое-то бестолковое строковое поле с FriendlyUrl, -- ни к селу ни к городу. никакой СЕО-шкин, даже на всю голову майданутый, не будет ручками прописывать каждому ресурсу свой личный URL. это абсолютно неюзабельно, следовательно просто никчёмный мусор. накуя?
Дурик, FriendlyUrl - это и есть тот "красивый" URL, который ты хешируешь и пихаешь в (о Боже!) кеш. Я тебе уже писал, ничего ручками не пишется, ссылки генерятся автоматом, например, "news/29/04/2014/{id}-{name}". Хотя если нужно ручками, то можно и ручками, в систему это легко ложится. Включи уже мозг, пионер.

hVosttможно удачно совмещать и "нативный" подход и структурный.
Если есть голова не плечах. Но это не твой случай, поверь.

просто интересно? 15953758 - оно высказало мнение!!!
Слушай, чучело, твои высеры вообще не несут никакой смысловой нагрузки. Особенно после твоего 15952747 ацкого отжига про "БД не моя, она в штатах" с тобой вообще не о чем толковать. Поржал.

hVosttпропустим на счёт структурных ссылок, у тебя это вопрос идеологии, я уж понел.

ну на всякий случай мыслишко:

"{id}"

нормальный URL? вообще ничего лишнего.
Ну серьезно, погляди на тот же крупнейший медиахолдинг РБК. Они нанимают себе 100500 сеошников, у них такие рейтинги, что тебе не снилось. И что мы видим?

http://top.rbc.ru/incidents/27/04/2014/920761.shtml

То, о чем я тебе говорил. "incidents/27/04/2014/{id}". Заметь, они даже сахар типа твоего любимого транслита не кладут в URL. И всё у них хорошо.

P.S. Если честно, немного бесит их ".shtml", какой-то костыль имхо.

hVosttмсущкоСсылки честно генерятся через @Html.ActionLink, никакой дополнительной магии.
а вот здесь по-подробней. как у тебя FriendlyUrl генерится из базы с помощью ActionLink.
У меня - никак, я же говорил, что не использую этот упоротый сеошный способ. Я просто тебе накидал архитектурный рецепт, как взрослые дяди делают такие вещи. А ссылки генерятся просто у этих дядь: в модель уже приходит собранный URL, так что собирать его через razor не имеет смысла.

просто интересно?а я с тобой и не толкую!!!

мне было просто интересно понять об чем спич!
хранение урлов\хэша с указателем на тип\контроллер\экшн ради вызова контроллер\экшн + ContentID где бы то нибыло - профит ещё тот!!!

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

hVosttне-не-не. ты говорил про ActionLink. у тебя где-то в базе хранится FriendlyUrl. ты сказал, что легко ссылку получить через ActionLink. интересно было бы посмотреть.
Ты не понял. Вот, что я говорил:

МСУЭто просто пипец как бысто и нативно, никаких промежуточных костылей не нужно. Ссылки честно генерятся через @Html.ActionLink, никакой дополнительной магии.

Имелось ввиду использование нативного (штатного) механизма MVC, без всех этих сеошностей. Ну то есть классика, без посредников. Такой способ самый быстрый и простой. Все эти базы и FriendlyUrl - от лукавого, всё это нам навязывают тупые сеошники. По возможности их нужно бить палками и не вестись на их уловки.

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

hVosttадмин просто перемещает ресурс в дереве и он меняет свой адрес. в таких случаях также необходимо проверить по логам не приходил ли по этому адресу один из зарегистрированных краулеров (яндекс, гугол, майл.ру), и если приходил, то обеспечить редирект со скользящим сроком на 1 мес. это ещё далеко не все из всех требований сео-группы. ты понимаешь?
Жуть. У меня нет слов

hVosttт.е. ID надо ещё превратить в расово правильную ссылку.
Да. Для этого нужно сджойнить таблицу сущностей и настроечную таблицу с урлами, джойн идёт как-раз по ID. На выходе мы получаем наш FriendlyUrl, который мы скармливаем в href. Такие вещи разруливаются только с помощью БД, никаких кешей и хешей. И обязательно сделать 2 индекса, на ID сущности и на FriendlyUrl. По второму индексу будет лупить, когда юзер ткнёт в URL. Только такая конструкция будет хоть как-то шевелиться. Но я против всего этого, я за натив!

hVosttв общем было сделано гибридное решение, в базе к ресурсу хранится не FriendlyUrl, а хеш от ссылки (просто хеш sha-256 считается оооочень быстро, коллизии практически исключены, и он короче полной ссылки, что для индекса очень хорошо).
Не нужно никакого хеширования, абсолютно лишняя операция, которая несёт в себе только вред.
1. Лишние преобразования - потери производительности на апп сервере.
2. Прозрачность данных. Как говорится все мы люди - зашёл, подправил.

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

hVosttв памяти никакой таблицы, конечно, не строится (это накладно по времени прочитать всю базу), просто ссылки по ходу дела кешируются по хешу с низким приоритетом, чтобы снизить нагрузку на БД, как для самой частой операции поиска.
Кешировать что-то типа топ-10 новостей - без проблем, это только на пользу. Но эти 10 записей можно кешировать и по ключу URL. Никаких хешей, у тебя навязчивая идея всё захешировать :) Будь проще.

hVosttсама идея с хешем успешно применяется в реализации MVC.
Это не говорит о том, что хеш нужно всюду сувать. В 99% случаев он нафиг не нужен.

hVostt, я заметил ещё одно нае..ово с твоей стороны :) 15941710
Ты уверен, что SHA1 будет работать в паре с гуидом? )) Может таки речь о MD5CryptoServiceProvider?
Либо если хочется именно SHA1, то только через Array.Resize(ref hash, 16)