igruschkafox

5000 * 5000 = 25 000 000

раз в день обновляем все ссылки
25 000 000 * 365 = 9 125 000 000 000 в год

Да, для одной таблицы это пожалуй многовато
Рекомендую поступить так
хранить данные в двух таблицах
в первой 25 000 000
во второй (архивной) все записи которые были раньше - до обновления
то есть вся история изменений у Вас будет во второй таблице
Соответственно секционировать архивную таблицу примерно по 2 недели

Таким образом Вы добьетесь что актуальные данные будут доставаться быстро
Архивные подольше - но это и понятно

Потом данные за прошлые периоды можно бэкапить оставляя только последние записи изменений (например хранить в архиве только данные за полгода)

В случае необходимости - всё можно достать и посчитать,
но практика говорит что такие бешеные объемы если и доставать то они считаться будут очень долго, а ввиду давности времени зачастую бывают неактуальны. По прошлогодним ссылкам явно никто аналитику проводить не будет.

в MS SQL надо использовать Data Quality Service - в результате запроса будет колонка Similarity (подобие - в процентах) по ней можно и сортировать

что то подобное должно быть и в других СУБД

Сейчас буду ругаться :)

1) Выбор СУБД, т.е. что в каких случаях выбирать
Основываясь на своем опыте (22 - проекта) рекомендую так:
СУБД это всего лишь инструмент
- Если в организации есть хорошие специалисты которые могут эффективно работать на MS SQL знают все его возможности и понимают почему он так дорого стоит - тогда MS SQL
- Если в организации есть хорошие специалисты Ораклы - тогда лучше ставить Ораклу
- Если обрабатываются очень очень секретные данные - тогда тоже лучше что то отличное от MS SQL - например Ораклу (так как операционная система отличная от Виндовс) - но в большинстве компаний данные не представляют интерес для спецслужб :)

2) Выбор подсистем субд
- Было бы здорово понять что такое "Подсистема СУБД"

3) Освещение моментов выбора индексов
- Все зависит от запросов которые идут в базу, а так же от данных. На начальном этапе индексирования в MS SQL пригодится Помощьник по настройки ядра СУБД. Дальше уже надо исходить из анализа планов запросов (не обязательно всех, а хотя бы самых длительных). При этом надо учитывать что на тестовых данных будут оптимальны одни индексы, а через год эксплуатации имеющиеся индексы уже могут стать не самым лучшим способом поиска по таблицам .... это админить надо базу ...

4) Может быть какие-нибудь паттерны проектирования
- В моей компании только и делают что переучивают пришедших специалистов у которых в голове свои патерны! Честное слово - в институте такой Херни на вдалбливают в голову студентов что диву даешься (например: некоторые разработчики в каждой таблице вставляют поле идентети - хотя по нему поиск не производится,и еще на это же поле вешают кластерный индекс - "Мудацкое Российское Высшее Образование"(с))
- Патерны Хорошо! Замечательно! Но универсальных способов нет!
Ознакомится с ними стоит что бы не делать ошибок - но даже если сделали такую ошибку - то никто не мешает потом исправить :) разбить таблицу на несколько или объеденить пару таблиц в одну. Главное что бы апликушники (программисты клиентской части) пользовались принципами ООП (что бы сильно не переделывать код программы при изменении структуры базы)

Есть массив слов(с)

тогда все просто
сохраните этот массив во временную таблицу
и сделайте джойн своей таблицы с таблицей массива

ПС если массив большой - не забудьте для него на временной таблице сделать индекс