2.1.2 每个DBMS Worker一个线程
在每个DBMS Worker一个线程模型中(图 2.2)，一个单独多线程进程负责所有的DBMS Worker的活动。一个调度员线程(或者少量的此类线程)坚挺新的DBMS客户端连接。每个连接都被分配一个新的线程。当每个客户端提交请求时，每个请求都会完全的被对应的跑着Worker的线程接管执行。这个线程在DBMS进程中运行这，一旦完成，结果会返回给客户端，并且线程等待来自相同客户端的下次请求。
Thread per DBMS worker model: each DBMS worker is implemented as an OS thread.
在这个架构中出现了常见的多线程编程困境：系统并不保证线程之间的内存溢出或者是指针迷路。debug也变得困难，尤其是存在竞态条件的情况下。并且由于线程接口和多线程伸缩性的不同，软件难以移植到其他操作系统。因为额外的共享内存的使用，可以在每个Worker一个进程的模型中找到这些多线程的编程困难。
尽管近年来操作系统之间的线程API区别已经被减小了，但是平台间细微的差别仍然会引起调试和调整的麻烦。忽略这些实现应用的困难，每个Worker一个线程模型可以伸缩至大量的并发连接，并且在很多当代数据库产品中被使用，包括：IBM DB2， Microsoft SQL Server， MySQL，Informix， and Sybase。
2.1.3 进程池
这个模型是每个Worker一个进程的变体。回想每个Worker一个进程的优势是它的实现的简易性。但是每个连接都请求一个完整的进程的内存花费是个清楚的劣势。有了进程池(图 2.3)，不是给每个Worker分配一个完全的进程，它们由一个线程池掌管。一个中心进程持有所有的DBMS客户端连接，并且当每个SQL请求从客户端进来时，请求被发给进程池的一个进程。SQL语句被执行到完成，结果被返回给数据库客户端，进程被退还给进程池并且等待下一个请求。进程池的大小是固定的。如果一个请求进来，并且所有的进程已经在服务其他的请求了，新的请求必须等待进程可用。
Process Pool: each DBMS Worker is allocated to one of a pool of OS processes as work requests arrive from the Client and the process is returned to the pool once the request is processed.
进程池具有每个Worker一个进程的所有优势，但是如果仅有很少的进程被请求，更应该考虑内存的效率。进程池通常被设计的拥有动态可调整的大小，当大量并发的请求到来时，进程池可以默默地增长。当请求负载变轻量，进程池可以减小到更少的等待进程。对比每个Worker一个线程模型，进程池模型也被些许现代DBMS系统支持。