Chances are if you're reading this blog you've likely created at least a handful of quick and dirty data driven web sites. If you're a Microsoft technologist, you usually throw together something using SQL Server Express. This always poses a problem for me, because I don't have hosting that includes SQL Server, and if I want it, it's a bit cost prohibitive.
One thing I've been investigating is using Google Spreadsheets as my database for these simple quick applications. I thought I'd give it a whirl.
Luckily for us .NET developers, there's a .NET library available on Google Code that wraps the spreadsheet API. This API allows you to authenticate and get to protected spreadsheets, or you can access your publicly shared spreadsheets without the need to authenticate.
To get started, make references to the Google.GData.Spreadsheets.dll, Google.GData.Client.dll, and the Google.GData.Extensions.dll. In my case, I want to leave my spreadsheet as private, so I'm going to need to authenticate.
I'm not sure of the significance of the application name. Looking at the request in Fiddler, it gets passed in as the UserAgent header. I looked around to see if you needed to register your application name with Google, but didn't find anything, and this seemed to work. If anyone knows if there's anything special to do, chime in.
Next thing you need to do is get the spreadsheet and worksheet you want to work with. In this case, I only need to work with one sheet.
From here I can do all the stuff I need to do with a database.
To bind data to a GridView:
Now, you can choose to add some Add/Edit/Delete functionality if you'd like, it's all possible through the .NET API here, but I'd prefer to keep it simple, and just use Google Spreadsheets to do that.
Obviously, the con to using spreadsheets as your database is that when it all boils down, it's still a spreadsheet. You need to decide how important it is to you that the things you've come to love about relational databases won't be available.