我正在为一个事件登记系统设计一个模式，该系统将涉及来自不同地区的学校的学生。我的主要问题是将学校名称存储在数据库中的方法。
鉴于学生将单独注册，相同学校名称的拼写变体很可能会随着时间的推移而累积。我想要一个简单的方法来清除这些，特别是因为我们想要收集的统计数据之一是注册该活动的学校和机构的数量。
我正在讨论将school_name存储为Participant表中的额外列，或将school_id存储为引用School表的外键（可以'想到任何其他方式）。哪一个在存储利用率，清除重复数据的容易程度以及其他因素方面更有效？
答案 0 :(得分：2)
将ID作为外键存储到School表中是可取的，因为它可以减少重复。
答案 1 :(得分：2)
如果您想避免出错的可能性，您可以提供现有学校名称的清单（是的，可能很大）。如果他们选择一个，则存储该学校的ID。因为您可能无法预测所有学校，所以您可以为“其他”学校提供一个自由格式的文本字段，并将其作为文本存储在参与者记录中。您可能需要定期进行对帐以将新学校添加到学校列表中，或将参与者的“其他”学校链接到现有学校（可能是在列表中，但他们只是没有看到它或者他们可能会拼错它）。
答案 2 :(得分：2)
“哪一个会更有效率 当涉及到利用 存储，易于清除重复 数据和其他因素？“
存储便宜，时间不是。因此，选择这种方法可以最大限度地减少您在重复数据上花费的时间，并通过提供预先准备好的学校列表来保存用户一些打字，并强制执行外键。
当然，这意味着您必须获得这样的列表，并提供搜索它的机制，这比为用户提供免费文本框更不可避免。没有什么是容易的:)但自由文本是标准化的敌人所以尽可能避免它。
根据您的个人资料，您位于新加坡。如果这是您的应用程序所在的位置，您可能会发现this Wikipedia page为您节省了大量的打字（关于维基百科的常见警告适用）。还有许多其他国家的学者名单。 Find out more
'do“自动填充”字段用作 灵活的替代下拉？ “
他们可以做到。但它们可能会令人非常恼火，特别是如果它们难以保证我们选择了我们想要选择的价值。我发现SO tag功能在这方面令人困惑，我是一个技术类型。下拉菜单更容易理解。另一方面，大多数年轻人对预测短信完全感到满意，所以也许自动完成会更适合他们。
答案 3 :(得分：0)
学校名称做随时间而变化。经历过这样的事情之后，让名字不是主键是很有意义的，也就是说，你有一张表将它们映射到每个学校的ID，这对于学校来说并不会改变。然后，数据库的其余部分可以使用该ID，您可以设置适当的外键关系;完整的kaboodle。您需要将name列限制为唯一;即使学校改名，也不会有两个同名，因为它们在现实生活中以类似PK的方式在数月的时间范围内运行（这只是在多年时间尺度上，你必须处理变化）