假设我有一个食谱页面，其中食谱可以具有许多与之相关的成分。用户可以编辑配料表并更新/保存配方。数据库中有这些表：配方表，配料表，Ingredients_recipes_table。假设某个配方具有成分a，b，c，d，但是用户将其更改为a，d，e，f。有了对服务器的请求，我是否仅发送新成分列表，并让后端确定需要将哪些值删除/插入数据库中？还是我在有效负载中明确指出需要删除哪些值以及需要插入哪些值？我猜可能是前者，但是这是在数据库查询之前或期间处理的吗？我先从表中读取，然后在计算出差异后写吗？还是查询只是处理这个？
我进行了搜索，发现涉及INSERT IGNORE ... + DELETE ... NOT IN ...或使用MERGE语句的解决方案。该项目没有使用ORM，我是否可以假设使用ORM可以轻松完成此任务？
答案 0 :(得分：0)
您可以分享用户界面的样子吗？您可以将一种新成分发布为一项操作，也可以删除一项作为一项操作，这是一种非常标准的做法。您只需在配料旁边有一个按钮即可发起DELETE请求，并在下面有一个用于POST的表格。
让用户输入列表会带来不必要的复杂性。
答案 1 :(得分：0)
常用的模式是将其视为远程创作问题。
远程创作的基本思想是我们要求服务器提供资源的当前表示形式。然后，我们（对客户端）对表示形式进行本地编辑，然后请求服务器接受我们的表示形式作为替换。
因此，我们可以GET表示一个包含成分的JSON数组的表示形式。在我们的本地副本中，我们删除了不再需要的成分，然后添加了新的成分。我们会将PUT的本地副本退回到服务器。
当文档很大且具有易于描述的更改时，我们可能不是将整个文档发送到服务器，而是发送PATCH请求，其中包含描述我们在本地所做的更改的“补丁文档”。 / p>
当服务器只是文档存储时，在服务器上的实现很容易-您可以查看更改以确定它们是否有效，计算新的表示形式（如有必要），然后将其保存到文件中，等等。
使用关系数据库时？然后，服务器实现需要弄清楚如何进行自我更新。 ORM库可能为您节省了很多工作，但是并不能保证-人们往往会纠结于“对象关系映射器”的“对象”端。您可能需要退后一步来滚动自己的SQL。
远程创作的另一种方法是将问题像网站一样对待。在这种情况下，您将获得某种形式的表示形式，该形式允许客户端描述应进行的更改，然后提交该表单，从而生成描述所要更改的POST请求。
但是您在服务器端遇到了相同的映射问题-您需要做多少工作才能将POST请求转换为正确的数据库事务？
遗憾的是，REST并没有告诉您有关如何将请求中提供的表示形式转换为关系数据库的任何信息。毕竟，这是 point 的一部分-REST旨在允许您在不破坏现有客户端的情况下，使用替代实现替换服务器，反之亦然。
也就是说，是的-您的基本想法是正确的；您可以只替换数据库中现有的整个表示形式，也可以优化以仅发出必要的更改。 ORM可能能够为您有效地执行转换-众所周知，像惰性加载这样的优化会使事情变得很复杂。