ComodoHacker

1. Внесение изменений в структуру, т.к. система развивается

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

2. Создание дампов

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

Какие варианты еще есть?

1. LogParser. Синтаксис примерно тот же, SQL-ный, это большой плюс, позволяет задавать хитрые условия и формировать отчеты. Насчет производительности — уверен, что будет быстрее. Насколько помню, он работает не через WMI, а напрямую с WinAPI. Помню, поиск всех недавно измененных файлов на диске C: (домашняя система) занимал не больше пары минут.
2. Команда ForFiles. В 2008 есть штатно, в 2003 можно скопировать. Быстродействие собственно поиска, думаю, не сильно отличается от dir /s. Другое дело, что для выполнения действия над каждым отобранным файлом создается новый процесс, это может замедлить.
3. PowerShell. Про быстродействие ничего не скажу, опыта нет. Но думаю, что все в порядке (если не через WMI работать).
4. Ну и наконец, банальный dir c обработкой результата в батнике или на js.

Хранилище должно потреблять по возможности меньше оперативной памяти и работать быстро.

Если «быстро», значит все данные должны находиться в оперативной памяти. Сколько ее потребуется? Примем, что средняя длина доменного имени 30 символов (уверен, это с большим запасом). Если их хранить просто как текст, нужно 30 байт. Еще 3 байта на число, 1 байт на длину строки, итого 33 байта на запись. Для двух миллионов записей потребуется около 63 Мб. Столько оперативной памяти придется выделить для быстрой работы. Значит мы можем минимизировать только оверхед по памяти, обусловленный выбором того или иного «движка» для нашего хранилища. Отсюда вывод: лучшее хранилище — простой массив, загружаемый из простого текстового файла. Генерируем последовательность псевдослучайных чисел и делаем выборку из массива по индексам.

Если память действительно критична, то можно подумать о более компактном представлении доменных имен (словарь TLD, точки и т.п.)

Помимо уже упомянутых подводных камней (размеры таблиц и индексов, производительность) и других по мелочи, не назвали самый главный — использование естественного ключа для PK вместо суррогатного. На эту тему написано много умных статей и глупых холиваров на форумах, я тут расписывать не буду, просто приведу одну ситуацию:

«Ой, не ту картинку загрузили! Надо срочно исправить!… Ой, это было месяц назад, на нее уже куча ссылок в куче таблиц… Ой, там такие констрейнты, простой UPDATE не прокатит… Ой, часть данных уже в архиве, что с ними делать?..»