我正在开发一个应用程序，其主要目的是根据他们的偏好和他们的个性推荐其他用户（每个推荐都是单独处理的）。
什么被认为是一种好的做法？要将信息存储在3个单独的表格中 <?php
$token = 'user-token';
$sandbox = true;
$china = false;
$client = new \Evernote\Client($token, $sandbox, null, null, $china);
$Note = $client->getNote( 'note-guid' );
$tagNames = $Note->getTagNames();
echo '<pre>';
var_dump( $tagNames );
echo '</pre>';
?>
，users和user_preferences），还是使用包含两个user_details列的单个表users？
答案 0 :(得分：1)
1]将您的交易视为OLTP（在线交易处理），您应该计划3个单独的表。在使用各种连接来检索表数据时，它将为您提供更好的性能。始终规范化您的架构。
答案 1 :(得分：1)
首先，需要注意的一点是，根据你要做的事情，jsonb可能会破坏第一个正常形式。我们来讨论1NF以及为什么这是一个好主意：
当且仅当：
时，存在第一范式现在，前两个很容易被理解，但第三个实际上是有争议的。这是否意味着一切都必须最大程度地分解？只要允许使用datetime列，就不能表示....
在我的视图中考虑原子性要求的最佳方法是表中的每个值代表域中的单个值。因此，有两件事打破了原子性要求1NF。第一个是集合（使用排序无关紧要的数组，例如博客帖子上的标签），第二个是存储具有内部功能依赖性的数据。
为什么这两个都很重要？列中的mamanging集为数据库中的大量额外工作创造了大量机会。传递依赖也会产生问题，例如，您不能在jsonb中的字段中引用外键来引用另一个表中的内容。
就性能而言，如果您所做的只是存储首选项和应用程序blob，您可能看不到太多差异，因此附加功能非常重要。请注意，PostgreSQL（不能代替其他dbs）将TOAST大字段。 TOASTed字段在某些情况下会产生额外的开销而不会在其他情况下产生额外的开销，并且测量它对查询的影响要比连接更难。这是另一个反对它的标志。 TOAST是一项伟大的技术，但它不是免费的午餐。因此，您可能会有相同的性能影响，但其透明度要低得多。