这是开始从以前以其他方式存储的数据（例如在日志文件中）构建数据库时的典型情况。有一个解决方案 - 像往常一样 - 但它不是一个非常快的解决方案。也许您可以编写一个日志消息处理程序来处理传入的消息；如果通量（消息/秒）不太大，您不会注意到开销，特别是如果您忘记将消息写入平面文本文件时。
首先，关于规范化的问题。是的，您应该始终规范化并使用所谓的第三范式 (3NF)。这基本上意味着任何类型的真实世界数据（例如您的 event_type）都只存储一次。 （在某些情况下，您可以稍微放松一下并转到 2NF - 通常仅当实际数据需要很少的存储空间时，例如 ISO 国家代码、M/F（男性/女性）选择等 - 但是在大多数其他情况下，3NF 会更好。）
在您的具体情况下，假设您的 event_type 是 char(20) 类型。十个这样的事件及其对应的int 代码很容易放在单个数据库页面上，通常是 4kB 的磁盘空间。如果您有 1,000 条 event_type 为 char(20) 的日志消息，那么您需要 20kB 来存储该信息，或者五个数据库页面。如果您的日志消息中有其他此类项目，则存储减少会相应变大。其他项目（例如 date 或 timestamp）可以以其原始格式（分别为 4 和 8 字节）存储，以获得更小的存储空间、更好的性能和更多的功能（例如比较日期或查看范围）。
其次，你不能告诉数据库创建这样的表，你必须自己做。但是一旦创建，存储过程就可以解析您的日志消息并将数据放入正确的表中。
对于日志消息，您可以执行以下操作（假设您想在数据库中进行解析，而不是在 python 中）：
CREATE FUNCTION ingest_log_message(mess text) RETURNS int AS $$
DECLARE
parts text[];
et_id int;
log_id int;
BEGIN
parts := regexp_split_to_array(mess, ','); -- Whatever your delimiter is
-- Assuming:
-- parts[1] is a timestamp
-- parts[2] is your event_type
-- parts[3] is the actual message
-- Get the event_type identifier. If event_type is new, INSERT it, else just get the id.
-- Do likewise with other log message parts whose unique text is located in a separate table.
SELECT id INTO et_id
FROM event_type
WHERE type_text = quote_literal(parts[2]);
IF NOT FOUND THEN
INSERT INTO event_type (type_text)
VALUES (quote_literal(parts[2]))
RETURNING id INTO et_id;
END IF;
-- Now insert the log message
INSERT INTO log_message (dt, et, msg)
VALUES (parts[1]::timestamp, et_id, quote_literal(parts[3]))
RETURNING id INTO log_id;
RETURN log_id;
END; $$ LANGUAGE plpgsql STRICT;
您需要的表格是：
CREATE TABLE event_type (
id serial PRIMARY KEY,
type_text char(20)
);
和
CREATE TABLE log_message (
id serial PRIMARY KEY,
dt timestamp,
et integer REFERENCES event_type
msg text
);
然后您可以将这个函数作为一个简单的SELECT 语句调用，它将返回新插入日志消息的id：
SELECT * FROM ingest_log_message(the_message);
注意函数体中quote_literal()函数的使用。这有两个重要的功能：（1）字符串中的引号被正确转义（这样“不是”之类的词就不会弄乱命令）； (2) 防止日志消息的恶意生成器注入SQL。
显然，以上所有内容都需要根据您的具体情况量身定制。