andrejk,

как вариант три таблицы:
1) таблица файлов с полями:
id_file
file_name

2)таблица слов :
id_word
word_name

3) таблица связей:
id_file
id_word

andrejkЕсли сократить идентификаторы и оставить только имя и слово (они по условию уникальны, т. е. грубо говоря могут сами быть идентификаторами), то разве не получится таблица связей в виде «file_name, word_name» вместо «id_file, id_word».

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

Все можно, но числовой ключ на мой взгляд все-таки лучше чем varchar.
Если делать "file_name, word_name" - то в других таблицах нет необходимости.

На мой взгляд таблица с именем файлов может содержать и др. инфу (размер, дату, кто предоставил...)
Со словами - одно слово может относиться к разным файлам.

Дело вкуса.

andrejkПолучается, что для обозначения принадлежности к одному файлу сразу нескольких слов, в таблице связей придётся либо айди/имя файла повторять для разных слов либо айди/имя слова повторять для разных файлов? Это нормальная избыточность? Использование идентификаторов в этом случае только ускорят процессы, но для логики они не нужны (повторюсь, что имена файлов и слова по условию уникальны).

Ну почему же это избыточность?
Есть такое понятие как нормализация.

andrejkДа, в таблицу с именем файлов будут помещены ещё и пути к ним. Это добавляет жизни третьей таблице связей.

Я отолько учусь (самостоятельно. Кстати почитал только что про нормализацию, спасибо:-)), поэтому переспрошу ещё раз — вот такое наполнение таблицы связей нормальное получается?:

id_file_1 — id_word_34
id_file_1 — id_word_35
id_file_1 — id_word_31
id_file_1 — id_word_98
id_file_1 — id_word_56
id_file_1 — id_word_42
id_file_1 — id_word_12
id_file_2 — id_word_54
id_file_2 — id_word_22
id_file_2 — id_word_34
id_file_2 — id_word_11
id_file_2 — id_word_09
id_file_3 — id_word_22
id_file_3 — id_word_23

Это нормально, что так много id_file одинаковых? Их как-то можно сократить?

Хочешь ты этого или нет, но связь файл - слово должна быть (или id_файла - слово или id_файла - id_слова).
Или использовать другой подход: "файл" - 'слово1;слово2;... словоN' - одна строка, где слова приведены через разделитель.
Все подходы имеют право на жизнь, их нужно учитывать при поиске. (для другого подхода последовательность слов - важна и искать like '%слово1%слово2%' вернет результат, а искать like '%слово2%слово1%' - нет).

andrejk* мы запрашиваем ФАЙЛ


Ну да, можно одним запросом:

andrejkПредположим, что будет 100,000 пользователей,
у каждого пользователя по 100,000 файлов,

Гы, мене нравятся цифры - тогда нужно вопрос задавать как оптимизировать хранение и поиск в большом объеме данных.
100 тыс - прогнозируемая заполненность из реальной жизни?

andrejk,

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

ТриггерманЕсли вы разработали правильную продуманную структуру БД, то вопросы оптимизации и поиска за вас будет решать уже программа (она называется СУБД).

Разработка продуманной структуры - первый шаг оптимизации, да и поиски должны быть продуманы перед заполнением таблиц.
Как СУБД будет решать проблему оптимизации когда данные перестанут влезать в кэш?