> I have a feeling you haven't used SQL databases very often.
No, I've not. I just never liked the way it worked so I have to honest and open about my prejudice.
> This is exactly the kind of thing that [...] noSQL databases do poorly.
That's really not true. I've built web apps that do pretty much exactly what that voting apps does and I use CouchDB to do it because it was built specifically for this kind of thing, and it makes it very easy.
That's not the same as saying SQL won't work. Or even that it's a bad choice by design if it's what you're familiar with and good at using it.
How much time have you spent with CouchDB?
I do know that those coming from a long history of using SQL dbs often have a hard time using CouchDB. I had a hard time with SQL, so maybe it's a right brain/left brain kind of thing. Or maybe it's just not really wanting to learn a different way to do what you already know how to do with a different tool.
I chose to use a hand rolled flat file database early on (around 2000) as a backend for my web apps. When CouchDB hit v1.4 I switched to it because it worked very much the same as my db and offered a lot of advantages. It's gotten a lot better over the years since too.
So yeah, my view comes from a different perspective.
I've used CouchDB on and off for some years[1], although I've used SQL databases for longer. I've also used NoSQL databases ranging from MongoDB to Cassandra, Hadoop, BDB (and variants), DynomoDB, etc.
CouchDB (or any other NoSQL database) just isn't the best choice here. The application is literally tables of relational data with multiple simultaneous users which is pretty much the perfect use case for a SQL Database Server.
"The application is literally tables of relational data with multiple simultaneous users"
How is this data "relational"?
Each precinct has 3 numbers to submit for each candidate, that's not a big task for one person, and none of those precinct's candidates numbers are related to anything else in the db except the grand total of all precincts numbers and that's a one way relationship. The grand totals never change any of the data they're derived from.
If you want to give each candidate's precinct representative access to the precinct's db in CouchDB than you just limit their access to one file for their specific candidate in a db for their specific precinct, so by design it's purposely not related to any other candidate or precinct.
That's why CouchDB is a good choice for this kind of app.
You're right, I have not used CouchDB, but from my understanding it shines on unstructured data, where you might need to store slightly different things from different places.
But in a voting application structuring the data is actually very very helpful, it keeps bad data out, and helps with auditing.
Your response implies that structured data, including numbers, are a somehow a problem for CouchDB, but that's just not the case.
Validating data is something you can and should do before saving it in the DB and with CouchDB that would be done with a "design document" using javascript.
In this case validating that user input is a positive number or a zero should be done on the client side before even submitting the data as well.
No, I've not. I just never liked the way it worked so I have to honest and open about my prejudice.
> This is exactly the kind of thing that [...] noSQL databases do poorly.
That's really not true. I've built web apps that do pretty much exactly what that voting apps does and I use CouchDB to do it because it was built specifically for this kind of thing, and it makes it very easy.
That's not the same as saying SQL won't work. Or even that it's a bad choice by design if it's what you're familiar with and good at using it.
How much time have you spent with CouchDB?
I do know that those coming from a long history of using SQL dbs often have a hard time using CouchDB. I had a hard time with SQL, so maybe it's a right brain/left brain kind of thing. Or maybe it's just not really wanting to learn a different way to do what you already know how to do with a different tool.
I chose to use a hand rolled flat file database early on (around 2000) as a backend for my web apps. When CouchDB hit v1.4 I switched to it because it worked very much the same as my db and offered a lot of advantages. It's gotten a lot better over the years since too.
So yeah, my view comes from a different perspective.