我是这个主题的新手，我所做的就是为一个用户建立数据库连接，所以我不熟悉多个用户访问数据库。
我的情况是：10个工厂将使用我的程序进行记录，当工人来来往往时，数据库将在主服务器上，而我所做的只是一个用户，而我正在编程/测试该程序。我的问题是：多个远程位置可以使用一个用户进行数据库连接（应该没有冲突，因为它们都是写不同的东西，但是在同一个表中）如果不是这样的话，我该怎么办？
答案 0 :(得分：2)
良好的关系数据库处理得非常好，它是关系数据库中事务的所谓ACID属性中的“I”;它代表隔离。
保护并发进程不会同时通过阻止其他事务的 locks 写入相同的表行，直到一个事务完成写入。
通过 multiversion concurrency control （MVCC）保护读者免于并发写作，MVCC保留旧版本的数据，为读者提供服务而不会阻止任何人。
如果您将所有属于一起的数据修改包含在一个事务中，那么它们就会发生 atomically （ACID中的“A”），并且您的事务简单而简短，您的应用程序可能会工作得很好。
如果不满足这些条件，可能会出现问题：
如果您的数据修改不受事务保护，则并发会话可能会看到不同会话的中间不完整结果，从而处理不一致的数据。
如果您的交易很复杂，事务中的后续报表可能会以间接方式依赖先前报表的结果。可以通过修改数据的并发活动来打破此假设。有三种方法：
悲观锁定：第一次使用<td><input type='text' class="percentage" value='0'></td>
$("#percentage_input").keyup(function(){
$(".percentage").val($(this).val());
});
时锁定所有数据，以便在交易完成之前没有人可以修改它们。
乐观锁定：不要锁定，但每当您第二次访问数据时，请检查其他人是否同时修改过它们。如果是这种情况，请回滚事务并再次尝试。
使用高SELECT ... FOR UPDATE和REPEATABLE READ等高事务隔离级别，可以更好地保证您正在使用的数据不会同时被修改。如果数据库无法保证，您必须准备好接收序列化错误，在这种情况下，您必须回滚事务并重试它。
这些技术以不同的方式实现相同的目标。讨论何时使用哪一个超出了这个答案的范围。
如果您的事务很复杂和/或需要很长时间（尽可能避免长事务，因为它们会导致数据库中出现各种问题），您可能会遇到死锁，这是两种以“致命的拥抱”相互锁定的交易。 数据库将检测到这种情况并以错误中断其中一个事务。
有两种方法可以解决这个问题：
通过始终按特定顺序锁定资源来避免死锁（例如，始终先使用较低的帐号更新帐户）。
遇到死锁时，您的代码必须重试该事务。
与普通人相反，死锁不一定是个错误。
我建议您阅读PostgreSQL文档中的the chapter about concurrency control。