关于数据库事务,应该教给学生什么?[关闭]

首先:您的重点是使用事务还是实现事务?学生的背景是什么——特别是,他们了解并发性吗?

作为一名非数据库专家,我的意见是,他仍然需要一直使用这些工具:

• 我认为事实上 SQL语句只是一个细节 ;它们值得包括在实践中减少它们的威胁,但是让它们自己查找语法。您可以故意使用各种语法(例如,使用API)简单地说明,重要的不是名称,而是事务所代表的思想和API契约。
• -至少在某种程度上,他们应该明白生活并不总是可串行化的,为什么人们(几乎总是)会选择这种障碍,以及要注意什么样的问题。哦,应该包括各种各样的快照(我要明确地提到这一点,因为这些快照并不总是出现在课堂上,而是被广泛使用)
• 锁定(或缺少锁定)显然是 与隔离级别相关 以及它们的优缺点。特别是,对事务的微小的看似不相关的更改可能会影响获取锁的顺序,从而影响死锁的存在与否。在这方面可能很重要;但是 否则这是一个实现细节 (从我的角度)最好忽略。
• 在ACID方面,一种理解,即它不是一个“全部”或“无”的事情,并且放弃部件以换取其他(特别是性能)好处是非常有用的。
• 也许指出这一点是明智的 太多了 ,部分原因是数据库的简单、健壮的保证使持久化(例如,firefox或adobe reader中的sqlite)比原始I/O更容易实现。任何正在编程的人都可能偶尔接触数据库;几乎无法避免这一点:即使在非并发环境中,原子性和一致性保证也是很有价值的(如果你的电脑崩溃,你的lightroom数据库也不会损坏)。
• 另外,应该清楚的是,在数据库中(通常) 全部的 语句在隐式事务中执行 ;您并不是通过避免显式事务语句来避免事务,而是使用更多更小的事务,这些事务仍然会死锁并导致锁定或fsync开销。换言之,如果学生们想和一个数据库一起工作(这几乎是不可避免的,他们必须也会希望),他们根本无法避免事务。

背景:我在工作中写网络应用和其他有趣的东西。

在“事务”的上下文中,我经常提到的一件事是,这个概念完全不局限于数据库。

以包含在事务中的打印机资源为例,在该资源中打印“确认表”,以及此类事务的ACID属性意味着:

• A: 要么更新数据库并打印确认表,要么不打印确认表而不更新数据库。
• c: 没有两份来自不同交易的确认单被混淆。
• 一: 在事务结束时,进纸始终位于页面顶部
• D: 交易结束时,确认单可供实际使用,无卡纸等情况发生。

另外,我还没有看到任何提到过两阶段提交之类的事情。也许你认为这是“等等”的一部分,但我认为它本身就值得一提。

在我看来,这正是不该教的,我读的时候能听到学生们打鼾的声音。

什么是重要的事务-数据完整性。演示如何为多个语句设置显式事务,并在没有显式事务的情况下编写相同的语句。告诉他们如果不使用显式事务,数据会变得多么混乱。在示例的过程中,包括ACID之类的内容,但在实际示例的上下文中使用它,说明如何使用ACID 更重要的是 ,如果你做错了会发生什么。

然后了解不同用户的事务如何相互冲突,以及为什么这会成为一个问题。讨论人们如何经常使用脏读来解决锁定问题,以及为什么这是一件坏事。使用实际的数据例子而不仅仅是枯燥的演讲。让他们努力得到答案而不是告诉他们。

但总是回到数据库中的数据,它是完整的。用实际例子而不是课堂讲稿和要点进行教学,让学生在查询数据后告诉你坏例子的问题所在,而不是告诉他们(根据我的经验,当你强迫他们去解决问题时,他们会学到更多)。

顺便说一句,你不是先教这门课,然后再教查询技巧吧?数据库操作(包括规范化)的技术讲座不应在查询技能被测量之前教授,除非他们能够查询数据库,否则他们不具备理解其他任何东西的能力,如果你开始使用一些深奥的东西,他们将停止听,整个学期都听不到任何东西。他们比任何其他人更需要查询技巧,这应该是第一堂课。可悲的是,教科书并不是这样写的,在我看来(是的,我教过数据库),这是导致学生离开学校对数据库一无所知的唯一最重要的因素。