Boolean field vs separate table

Question

I have a keyword table where I will store all possible keywords that may be related to events (activities).

I want to allow organisers to enter custom keywords as well that will be uploaded to my database for moderation.
Is it a better idea to create a boolean field on the existing table (fieldname=active) or to create a separate table altogether for custom keywords?

An important note is that I will create a tool that will allow moderators to extract a list of inactive keywords from the table on a regular basis.

Logic tells me that they belong all together in a general "keywords" table, but performance wise it would appear better to create a separate table.

What is your thought?

Edit based on answer of Gordon Linoff:

First, the keywords are not specific to an organiser, although their id will be stored as well (just as the time as you mention it).
A customer keyword can never override a built-in keyword, because it will only be allowed when the moderators (we) consider it good.

Note: There will also be a more complex keyword management with parents - child elements that we will take into account when moderating. The purpose is to create a search engine where organisers can add keywords, and where users can access activities based on these keywords (or their parent keywords).

And the keyword is not specific for an organiser, but will be specific for an activity. But this will be managed with a many-to-many relationship (junction table), so this is not a problem.

Answer 1

This is too long for a comment.

You question doesn't provide enough information for answering this question. For instance, are the custom keywords specific to a given organizer? If so, merely having a boolean "isactive" flag is not sufficient. Can a customer keyword -- in any way -- override a built-in keyword?

I suspect that the "custom" keywords have fields that are not naturally part of the built-in keywords, such as:

• Who created it?
• When it was created?

And perhaps some other information, such as who has access to it.

Performance can only be judged based on the queries used to access the data. However, I doubt that putting the keywords in a single table would have a big impact on performance.