使用“或者”类型字段创建数据库表

我有一个数据库，通过他们在游戏中的尝试来跟踪玩家。为了实现这个目标，我保留一张用户表并将这些尝试存储在一个单独的表中。这些表的模式是：使用“或者”类型字段创建数据库表

CREATE TABLE users (
    id BIGINT PRIMARY KEY, -- the local unique ID for this user 
    name TEXT UNIQUE, -- a self-chosen username for the user 
    first_name TEXT, -- the user's first name 
    last_name TEXT, -- the user's last name 
    email TEXT, -- the user's email address 
    phone TEXT -- the user's phone number 
); 

CREATE TABLE trials (
    timestamp TIMESTAMP PRIMARY KEY, -- the time the trial took place 
    userid BIGINT, -- the ID of the user who completed the trial 
    score NUMERIC, -- the score for the trial 
    level NUMERIC, -- the difficulty level the trial ran at 
    penalties NUMERIC -- the number of penalties accrued in the trial 
);

现在我需要能够存储来自“瞬态”用户的尝试。这些尝试不应该链接回现有的用户。但是，这些临时用户仍然可以输入显示在结果中的名称。该名称并不要求在表中是唯一的，因为它不代表“真实”用户。

我的第一个想法是在名为name的trials表中创建一个新字段。如果userid为空，我会知道它是一个临时用户，但我仍然可以在结果中显示name字段。这种方法并不完全正确，它似乎会让我的查询更加复杂一些。另外，从某种意义上来说，我似乎在复制数据。

另一个想法是将userid替换为useref文本字段，该文本字段可以是表示用户的某种格式化字符串。例如，如果该值用大括号括起来，我会知道它是一个ID，即{58199204}。如果该值未被包含，我会将其视为一个临时用户。这更准确地表示了我试图在概念上做什么（即它是一个ID还是一个瞬态用户字符串），但它确实会使我的查询复杂化。

我使用SQLite作为后端...它缺少一些SQL Server或MySQL的扩展功能。

对这些问题或其他解决方法有何看法？

来源

2009-11-04 jheddings

如果没有，为什么一过，用户可以使用，但在系统中不存在更多的信息，我同意你的想法：

添加NAME列到TRIALS表
充分利用USER_ID列TRIALS表可以为空或可选，以指示瞬态用户状态

如果您可以允许系统中存在瞬态用户，我会建议：

创建USER_TYPE_CODE表
更新USERS表包括USER_TYPE_CODE柱（W /外键参考USER_TYPE_CODE表）

来源

2009-11-04 07:23:45

我同意你的意见。我看不出有什么理由为什么你不能有一个基本的（不完整的）用户（有点像即时注册）。如果规范化规则需要应用，则关闭不需要的项目（第一个/最后一个等）。我不知道类型是否真的有必要，这些短暂的用户有账号，但不是完整的账号。 – 2009-11-04 07:59:50

选项2也将遵循大多数系统使用的“未验证”帐户的模型。 – Myles 2009-11-04 18:15:03

您可以在users表中创建一个UserType字段，并向Users表中添加“transient”用户，但这可能会增加Users表的大小，或者在Trials表上创建一个UserType字段并创建一个额外的TransientUsers表。

这将允许您区分userid与UserType字段的区别。

来源

2009-11-04 06:15:24

“创建额外的TransientUsers表” - 这是经过验证的测试方法，在SQL世界中称为“子类”。绝对要走的路。 – onedaywhen 2009-11-04 08:45:18

-1

SQLite让你混合字段中的类型。我建议你按照你的想法去做，但没有大括号。禁止数字名称。如果用户标识是一个数字，这恰好与用户表中的某个标识相匹配，则它是一个用户标识。如果不是，则是临时用户的名称。

来源

2009-11-04 06:26:07 Grumdrig

混合数据类型是一个非常糟糕的主意...... – 2009-11-04 07:17:35

只是让事情被允许并不是一个好主意。允许的原因是保持SQLite简单，而不是让你的生活更难。 – 2009-11-04 08:01:20

我想指出的是，你真的不该不使用格式化的字符串方法。如果用户在您的数据库中发现一个窃听输入端口并输入“{8437101}”（或他们想要的任何用户ID），会发生什么？

来源

2009-11-04 07:36:26 RCIX

是的，我也在质疑。虽然它符合问题的心理模型，但看起来很麻烦。 – jheddings 2009-11-04 15:02:24

使用“或者”类型字段创建数据库表

回答

相关问题