How I name my data tables.

I always name my SQL data tables with the prefix "tbl." When you are documenting your project, and you see the word tblDogs in writing, then everyone knows that you are referring to a SQL table containing info on dogs.
If you name your SQL table Fred or George, a person reading your documentation cannot tell if you are referring to a data table or that guy from the third floor.
I always name my "In Memory" / ADO tables with the "dt" prefix (for Data Table). Sometimes I enhance the prefix further, like "mdt" or "gdt" for tables with Module level scopes or tables that are Global level scoped.
I like my table names to be plural. i.e. I use tblDogs because the table contains a list of dogs. More than one dog. If your table is designed to only hold ONE item, then you probably don't need a table.

My chat-bot has three main data tables:
tblNGrams (like a dictionary), tblFacts (like an encyclopedia) and tblCommonOutput.
tblCommonOutput holds a bunch of "Output Phrases" that are keyed by a "Phrase Type" i.e., "Hi," "Hello", "Howdy", "Hey" are in the table with a "phrase type" of "Greeting".
When you say a greeting to the chat-bot, the chat-bot runs a query to pull up a numbered list of all of the common output phrases that are greetings."
I have a Random Number Generator (RNG) pick a number between 0 and the number of phrases in the list, and the chat-bot uses this number as an index to pick a reply to your greeting, with its own greeting.
Also, my RNG keeps track of the last number it picked, and if it tries to pick the same number twice, it picks another number until it picks a different number. This keeps the chat-bot from repeating itself.

I'm thinking about renaming some of my data tables.
tblNGrams holds data like you would find in a dictionary. The primary key is usually a single word (sometimes two or three) and you can look up a word's "part of speech," synonyms, and related verbs.
If the primary key is a command, it is marked in this table with the name of the command. Because the primary key can be unique, this table can be indexed for fast retrieval.
tblFacts holds data like you would find in an encyclopedia. It contains a sentence or two, or a paragraph about a subject. This paragraph of words is what is spoken by the chat-bot
when it is matched with the input it receives.
Very common words like "a", "the", "and" and "of" are not used when trying to retrieve a reply for an input. This keeps the list of potential replies to a manageable size.
Because different combinations of words from the input are
used in the SQL "WHERE" clauses to retrieve the potential replies, this table cannot be indexed. A "full table scan" is run for every query.
Every input to the chat-bot consists of a number of words. These words are converted to a number of N-Grams (combinations of words) and each N-Gram is used as a SQL "WHERE" clause in a SQL query.
If an input contains 4 words, then 10 N-Grams are generated, so 10 SQL queries must be run. If the input contains 6 words, then 21 N-Grams are generated and 21 SQL queries are run. This can grow very quickly.
Longer inputs mean that it takes longer to find a response.

The more words there are in an input to the chat bot, the more N-Grams are created, and when these are used in SQL queries, the more Potential Replies may be found. The more Potential Replies there are, the longer it takes to scan through them, apply points to them, and pick the winner. This causes a delay in the time it takes for Zoe to come up with an answer.