When I started working with SQL Server we had the pubs database. This was in SQL Server 4.2, and I only used it because code samples from the Internet used it. It wasn't a great database, but it was consistent and known. When Northwind came along, it was a welcome improvement. The schema was larger and a better fit for showcasing various features. However those two samples were superseded by AdventureWorks.

AdventureWorks (ADW) was a fictional bicycle company, and we got a much larger, more complex schema. Perhaps overly complex, but many of us have learned to work with AdventureWorks for our sample code and demos through the years. This sample was released with SQL Server 2005 and then expanded and grown with 2008, 2012, and 2014, including newer features like Filestream and Memory-optimized Tables. However the complexity sometimes caused issues for people that didn't want those features.

There are multiple versions of ADW from MS, a script to make it larger, or even larger, a workload generator, a version for Azure, and more. It seems as though lots of time and effort has been put into building demos and tests against the ADW database. However that might need to change. I saw a note that Microsoft has a new sample database, Wide World Importers, on Github. It's for SQL Server 2016+ as it includes a number of items that are only available on that version. So far, it's bare bones (31 tables, many of them System-Versioned), and MS is looking for comments for improvement. There isn't a lot at Github yet, but I'm expecting that to change over time.

The idea of having sample database is good, but there's effort to maintain them. We've had a few over the years at Redgate for demos, but we may move to using a Microsoft one so we don't have to maintain it. Our preference is AdventureWorks, and maybe we'll end up keeping it alive over time. I'm not sure I want a new database, but I also disliked the confusion of which AdventureWorks database versions would work with which SQL versions. Over time the database was named to include the version year, but it could still be confusing. 

Perhaps we should get a new sample every version, but not completely new. Let's have a core schema that's always available, with some tables that are normalized, some not. Some with PKs and FKs, somewithout. We can add new objects for new features. Let's ensure that older scripts work by leaving old objects alone, but new items covering all aspects of database development, are included. Let me know what you think today.