Это эффективный дизайн базы данных MySQL?

Question

Я работаю над проектом, в котором у меня есть набор ключевых слов [abc, xyz, klm] `.У меня также есть куча текстовых файлов с содержимым [1.txt, 2.txt, 3.txt] .

То, что я делаю, наталкивает ключевые слова на текстовые файлы, чтобы найти строку, где встречается ключевое слово, и это может быть сделано несколько раз.Поэтому я хочу хранить ID (text file name without .txt), Extracted_Data, Line_Number, Spwaned_Across (keyword may be spread across 2 lines) для каждого случая.

Я решил создать таблицу для каждого ключевого слова для хранения этих данных.

Таблицы: abc, xyz, klm

Образцы данных abc таблицы:

ID Extracted_Data                         Line_Number Spawned_Across
12 MySQL is wonderful. What is 'abc'      34          1

Итак, я получаю таблицу для каждого ключевого слова.В моем проекте около 150 ключевых слов, и он может расти.Итак, 150 таблиц.

Почему я выбрал такой способ?

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

Правильно ли я принял решение?Ваш вклад высоко ценится.

Answer 1

Не делай этого.Ни одна библиотека базы данных не оптимизирована для динамических имен таблиц, и вам придется создавать запрос с нуля каждый раз, когда вы захотите получить доступ к таблице.Кроме того, как бы вы ответили на вопросы типа «какие данные я нашел в строке 34 файла 12»?

Вам понадобятся три таблицы.В синтаксисе PostgreSQL [*] это будет:

CREATE TABLE source (sourceid SERIAL, filename VARCHAR NOT NULL);
CREATE TABLE keyword (keywordid SERIAL, keyword VARCHAR NOT NULL);
CREATE TABLE location (locationid SERIAL,
    sourceid INTEGER NOT NULL REFERENCES source(sourceid),
    keyword INTEGER NOT NULL REFERENCES keyword(keywordid),
    data VARCHAR NOT NULL,
    line INTEGER NOT NULL,
    span INTEGER NOT NULL);

Когда вы начнете обрабатывать новый текстовый файл, создайте новый кортеж source и запомните его sourceid.Когда вы встречаете ключевое слово, либо вставьте для него новую запись и запомните его ключевое слово, либо найдите старую запись.Затем вставьте этот sourceid, keywordid и другие соответствующие данные в location.

. Чтобы ответить на вопрос, который я поставил ранее:

SELECT * FROM
    location JOIN source ON location.sourceid = source.sourceid
    JOIN keyword ON location.keywordid = keyword.keywordid
WHERE
    source.filename = 'foo.txt' AND
    location.line = 34;

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

[*] Синтаксис MySQL будет похожим, но я не помнюэто на макушке моей головы, и вы довольно легко можете определить разницу.

Answer 2

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

ID  Keyword  Extracted_Data  Line_Number Spawned_Across
12  abc      Abc or xyz?..   31337       1
12  xyz      Abc or xyz?..   31337       1
12  xyz      just xyz here   66666       1
13  xyz      xyz travels!    123         1

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

Также не очень популярно называть «ID» что-либо кроме первичного ключа.

Answer 3

Это определенно очень плохое решение .

Миллионы строк лучше, чем миллионы таблиц.

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

Меня попросят показать, где и как это произошло в файле.

Это еще можно сделать в 2 таблицах

Answer 4

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

Новые ключевые слова будут означать больше таблиц.Это не масштабируется.

Ключевые слова и файлы заставляют меня думать об индексации и неструктурированном поиске.Я бы подумал о Lucene до реляционной базы данных.