4 ms·

With CouchDB you could have all that data in 1678 human readable files. Or 1678 password protected databases with one or more human readable files in them and

by oblib 7y ago

With CouchDB you could have all that data in 1678 human readable files. Or 1678 password protected databases with one or more human readable files in them and let CouchDB handle user auth, which CouchDB makes really easy. You could do the same thing with a simple flat file database using directories and files and system level user access, and it'd be very fast too. This is pretty much the kind of thing CouchDB is designed for though and has tools built-in to make it easy.

ars 7y ago
I have a feeling you haven't used SQL databases very often. This is exactly the kind of thing that SQL database is shine at and noSQL databases do poorly.
- oblib 7y ago
  > 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.
  - ars 7y ago
    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.
    - oblib 7y ago
      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.
  - nl 7y ago
    (Not the person you are replying to, but..) 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. [1] Since 2010! Wow that's a lot longer ago than it seems. https://mail-archives.apache.org/mod_mbox/couchdb-user/201011.mbox/browser https://mail-archives.apache.org/mod_mbox/couchdb-user/20101...
    - oblib 7y ago
      "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.
      - nl 7y ago
        > How is this data "relational"? Each precinct has 3 numbers to submit for each candidate The numbers relate to each candidate. It's that simple!
        oblib 7y ago
        That is just silly. Reminds me of the old saying; "When all you have is a hammer everything looks like a nail."
nl 7y ago
So... What happens when two people share authentication (which will happen!) and access the app at the same time. Maybe you are going to try and implement file-locking, yourself, badly? SQL has literally been used for this kind of app since the 1980s. It's simple to use, and easy to find developers who use it.
- oblib 7y ago
  >>What happens when two people share authentication (which will happen!) and access the app at the same time. If they both come from a different district and log into CouchDB they'll either only write to their file (one db, multi-user) or write to a file (or files) in their db (db per user). If two users write to same file in same the db at the same time the DB will note the conflict and decide which data gets stored in the file. https://docs.couchdb.org/en/stable/replication/conflicts.html https://docs.couchdb.org/en/stable/replication/conflicts.htm...
  - nl 7y ago
    > https://docs.couchdb.org/en/stable/replication/conflicts.html https://docs.couchdb.org/en/stable/replication/conflicts.htm... Yes, this is how I remember CouchDB working. It leaves the hard parts of conflic resolution up to the client app: Once you have retrieved all the conflicting revisions, your application can then choose to display them all to the user. Or it could attempt to merge them, write back the merged version, and delete the conflicting versions - that is, to resolve the conflict permanently. You do realize that SQL databases handle this automatically via locking schemes and transaction, right?
    - oblib 7y ago
      The window is pretty small to create a conflict in a well designed CouchDB interface because of the way revisions are used. You should get the latest revision when you load the data for editing. And it's trivial to set a "locked" flag in a file being edited to prevent others from overwriting it if you have it configured so others can do that. In this particular use case there really should only be one authorized user who can edit the data file for each precinct so race conditions like you describe just don't exist. You can also use CouchDB's live sync feature to push the latest revision to everyone viewing the file in close to real time. So conflicts are really a non-issue here. By design they just don't happen.

by oblib 7y ago

ars 7y ago

I have a feeling you haven't used SQL databases very often. This is exactly the kind of thing that SQL database is shine at and noSQL databases do poorly.

oblib 7y ago
> 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.
- ars 7y ago
  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.
  - oblib 7y ago
    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.
- nl 7y ago
  (Not the person you are replying to, but..) 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. [1] Since 2010! Wow that's a lot longer ago than it seems. https://mail-archives.apache.org/mod_mbox/couchdb-user/201011.mbox/browser https://mail-archives.apache.org/mod_mbox/couchdb-user/20101...
  - oblib 7y ago
    "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.
    - nl 7y ago
      > How is this data "relational"? Each precinct has 3 numbers to submit for each candidate The numbers relate to each candidate. It's that simple!
      - oblib 7y ago
        That is just silly. Reminds me of the old saying; "When all you have is a hammer everything looks like a nail."

nl 7y ago

So... What happens when two people share authentication (which will happen!) and access the app at the same time. Maybe you are going to try and implement file-locking, yourself, badly? SQL has literally been used for this kind of app since the 1980s. It's simple to use, and easy to find developers who use it.

oblib 7y ago
>>What happens when two people share authentication (which will happen!) and access the app at the same time. If they both come from a different district and log into CouchDB they'll either only write to their file (one db, multi-user) or write to a file (or files) in their db (db per user). If two users write to same file in same the db at the same time the DB will note the conflict and decide which data gets stored in the file. https://docs.couchdb.org/en/stable/replication/conflicts.html https://docs.couchdb.org/en/stable/replication/conflicts.htm...
- nl 7y ago
  > https://docs.couchdb.org/en/stable/replication/conflicts.html https://docs.couchdb.org/en/stable/replication/conflicts.htm... Yes, this is how I remember CouchDB working. It leaves the hard parts of conflic resolution up to the client app: Once you have retrieved all the conflicting revisions, your application can then choose to display them all to the user. Or it could attempt to merge them, write back the merged version, and delete the conflicting versions - that is, to resolve the conflict permanently. You do realize that SQL databases handle this automatically via locking schemes and transaction, right?
  - oblib 7y ago
    The window is pretty small to create a conflict in a well designed CouchDB interface because of the way revisions are used. You should get the latest revision when you load the data for editing. And it's trivial to set a "locked" flag in a file being edited to prevent others from overwriting it if you have it configured so others can do that. In this particular use case there really should only be one authorized user who can edit the data file for each precinct so race conditions like you describe just don't exist. You can also use CouchDB's live sync feature to push the latest revision to everyone viewing the file in close to real time. So conflicts are really a non-issue here. By design they just don't happen.