时间戳

首页 > 解决方案 > 使用用户的个人首选自定义属性扩展表

mysql - 使用用户的个人首选自定义属性扩展表

问题描述

允许最终用户将自定义属性添加到应用程序使用的核心表的最高效的方法是什么。

例如，核心表FRIENDS具有列ID、FIRST_NAME、LAST_NAME和BIRTHDAY。

用户 1 还想跟踪其他属性FAVORITE_COLOR和LUCKY_NUMBER，但用户 2 还想跟踪不同的附加属性ZODIAC_SIGN、MARRIAGE_ANNIVERSRY_DATE和GOLF_HANDICAP。

我已经实现了两种测试方法：

  1. 第一种方法：添加一个新表FRIENDS_CUSTOM_PROPERTIES，其中包含一个 FK 指针和FRIENDS两列用于值对（例如FAVORITE_COLOR、YELLOW）。这种方法可能需要许多查询来检索给定朋友的所有属性。KEYVALUEFRIENDS_CUSTOM_PROPERTIES

  2. 第二种方法：在FRIENDS表本身上添加不同数据类型的扩展列，如CUSTOM_1, CUSTOM_2, ...CUSTOM_64等。如果用户需要比列更多的自定义属性，我的设计将“溢出”到方法 1。这种方法是更蛮力但很容易导致许多行上的许多 NULL 列值。

我可以使两者都起作用，但不确定确定哪个更好的最佳方法（或者是否已经有明确的最佳实践）。

谢谢。

标签： mysqldatabasedatabase-designentity-attribute-value

解决方案

正如 Rick James 在评论中指出的那样，方法一被称为它可以完成这项工作，但是您牺牲了 SQL 的许多有用特性，例如数据类型和约束。请参阅EAV FAIL了解我对此的一些文章。

你写了一些关于运行“许多查询”的东西，但这样做没有任何好处。您应该计划在一个查询中为用户获取一组自定义属性，并将其保存到客户端应用程序中的地图对象中。

后一种方法二是不完整的。您还需要存储某种元数据，以便您知道对于用户 1，CUSTOM_1表示“最喜欢的颜色”和CUSTOM_2“幸运号码”等。您计划将每个用户的每列的含义存储在哪里？

至少在 EAV 设计中，每个属性都带有一个键，因此您确切地知道它的含义。EAV 允许无限数量的属性，因为每个属性都有一个新行。

最终，任何允许“用户定义属性”的设计都与关系数据库的原则相冲突。您的列不再有任何类型的概念。阅读SQL 和关系理论之类的书以了解更多相关信息。

推荐阅读