Булево поле против отдельной таблицы

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

Я хочу разрешить организаторам также вводить пользовательские ключевые слова, которые будут загружены в мою базу данных для модерации.
Лучше ли создать логическое поле в существующей таблице (fieldname = active) или создать отдельную таблицу для пользовательских ключевых слов?

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

Логика подсказывает мне, что все они объединены в общую таблицу «ключевых слов», но с точки зрения производительности лучше создать отдельную таблицу.

Что ты думаешь?

редактировать основываясь на ответе Гордона Линоффа:

Во-первых, ключевые слова не являются специфичными для организатора, хотя их идентификатор также будет сохранен (так же, как и время, указанное вами).
Ключевое слово customer никогда не может переопределить встроенное ключевое слово, потому что оно будет разрешено только тогда, когда модераторы (мы) посчитаем его хорошим.

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

И ключевое слово не является специфичным для организатора, но будет специфичным для деятельности. Но это будет осуществляться с помощью отношения «многие ко многим» (таблица соединений), так что это не проблема.