应用程序的sql触发器

k0pti3hp  于 2021-07-26  发布在  Java
关注(0)|答案(1)|浏览(344)

关闭。这个问题需要更加突出重点。它目前不接受答案。
**想改进这个问题吗?**通过编辑这篇文章更新这个问题,使它只关注一个问题。

昨天关门了。
改进这个问题
我有一个sql server数据库连接到一个应用程序。就像日程表。有没有一种方法可以在一个用户进行更改时在应用程序中获取触发器(在我的例子中是update),以便连接到数据库的所有其他应用程序都更新到update触发器调用?只是为了让所有的应用程序更新到最合理的数据。我正在使用sql连接字符串。

Public Shared Sub Load(ByRef MyCollect As List(Of PAPaintSchedule), Filter As String, OrderBy As String)
        MyCollect = New List(Of PAPaintSchedule)

        Dim CMDValue As String = $"SELECT * FROM {TableName}"
        If Filter IsNot Nothing Then CMDValue &= $" WHERE {Filter}"
        If OrderBy IsNot Nothing Then CMDValue &= $" ORDER BY {OrderBy}"
        CMDValue &= ";"

        If SQLCon.State = System.Data.ConnectionState.Closed Then SQLCon.Open()

        Dim CMD As New SqlCommand(CMDValue, SQLCon)
        Dim reader As SqlDataReader = CMD.ExecuteReader()
        Try
            If reader.HasRows Then
                While reader.Read()
                    Dim LF As New PAPaintSchedule With {.Id = reader(0),
                                            .PaintDate = reader(1),
                                            .Total = reader(2),
                                            .Notes = reader(5)}

                    LF.HasChanges = False
                    MyCollect.Add(LF)
                End While

            End If
        Catch ex As Exception
            If Not SQLCon.State = System.Data.ConnectionState.Closed Then SQLCon.Close()
        Finally
            reader.Close()
            CMD.Dispose()
            If Not SQLCon.State = System.Data.ConnectionState.Closed Then SQLCon.Close()
        End Try

        If Not SQLCon.State = System.Data.ConnectionState.Closed Then SQLCon.Close()
    End Sub
ee7vknir

ee7vknir1#

有一句谚语有时被误认为是笑话:在计算机科学中只有两个困难:缓存一致性和命名事物。你的问题是关于前者的。
让客户机了解最新数据的问题实际上并不是一个数据库问题。一些客户机库确实提供了一些机制,但一般来说,问题与更新数据库是正交的。它是关于通知对等方的,这是一个消息传递问题(例如,你可以通过自动发送电子邮件来解决这个问题。)同龄人的数量越多,分布在世界各地的范围就越广,时间、空间和光速就越是阻碍了“最近”的定义。
在数据库中,问题得到了更好的定义:您通常不希望出现最后一次写入成功的情况。如果两个客户机读取同一条记录,其中一个更新该记录,然后另一个更新该记录,则不希望第二个更新成功,除非它包含第一个更新。不是读写,而是读写,读写。
在sql中,这通常通过隔离级别来解决。在最简单的情况下,作为事务的一部分,第一个读卡器可以阻止第二个读卡器,直到他完成。问题是,什么是“完成”?午饭后?因为这通常是不可接受的,交互应用程序的程序员被建议在用户有控制权的情况下永远不要保持事务打开。
在数据库革命初期开发的解决方法是乐观并发:允许多次读取,但每次写入都要小心,不要覆盖中间的更新。这通常是有效的(因此是乐观的),因为通常情况下,用户不会竞相更新同一条记录。
一个实现不需要dbms支持。读取发生在事务外部(无阻塞)。用户将修改后的数据输入到应用程序中。应用程序还保留原始记录的副本。为了更新数据库,应用程序首先再次读取记录——这次是在事务中,阻塞其他记录——并将新读取的记录与原始记录进行比较。如果它们匹配,则应用更新的值并关闭事务。
注意,这个读比较更新过程不能简单地使用dbms的默认隔离级别先选择后更新。相反,它作为update语句的一部分发生在dbms内部,update语句将更新限制为“行”(通常只有1行),其中原始数据仍然存在于数据库中。dbms报告有多少行受到影响,如果答案为零,则应用程序推断该行同时被更改。恢复依赖于应用程序,但一个明显的策略是向用户显示当前的记录,然后重试。
为了促进乐观并发,许多dbms提供了一个内置的并发控制数据类型,比如sqlserver中的timestamp,每当行被更新时,它就会自动更改值。然后可以通过比较单个值(而不是整行)来回答“是否更改了?”问题。
如果这一切看起来都是无望的笨拙或理论性的,那么考虑一下:这就是股票市场的运作方式。如果你下订单以y的价格购买股票x,其中y是你屏幕上当前的价格(无论“当前”和“现在”是什么意思),没有人在等你,也没有人在等你。你甚至不共享一个系统。除非你支付巨额费用,否则你可能收到的任何价格更新都会被故意延迟。您的订单到达时,所有其他订单都被挤爆了,与通常的情况不同,许多其他订单很可能在竞争相同的x@y。买卖订单在到达时按时间和价格排列。只有在最底层,远离人手的触摸,事务才能确保每个更新只使用“最新”的数据。

相关问题