[bcRIPster]

A spreadsheet is NOT a database! Argh!

As a person who gets asked to fix these kinds of projects once they hit a wall (performance/concurrency/etc) and then have to migrate them to a proper DB platform, just stop it! Put it on in a DB up front and save some poor developer their sanity.

Please.

[crdb]

Thank you! I was thinking exactly the same thing!

Want a cheap database? A Postgres RDS micro instance costs $51 a year upfront or $0.018 per hour. Medium is $200 or $0.073, and that medium instance will probably be more than enough for a dozen projects.

You get the solidity and ease of use of PostgreSQL with all the admin details abstracted away by RDS, and you can be up and running in 10 minutes or less. Get AWS account, spin up DB, write to DB.

Should one of your projects take off and require more, it's a one click upgrade. Or you can pg_dump in seconds, and rebuild it on a separate instance and account and point your app at it. And you get backups and all kinds of nice things out of the box.

I seem to be in the minority in this thread, but I personally much prefer using UPDATE/INSERT/DELETE in the command line to modify data, than clicking on a cell and typing the modification.

[bcRIPster]

High-five. I like your thinking!

[hbhakhra]

He mentions that its explicitly for quick prototyping. I've started a few projects but stopped when setting up the infrastructure became too tedious. For the quick and dirty prototype, this seems perfect.

[bcRIPster]

I understand, but every time I get handed one of these it's because someone who didn't know what they were doing was rapid prototyping something and woops they have 200 hundred users and it's crashing, it's corrupting data, etc...

At one job I'm like "people, just use Access, it's installed on your computer" and they look at me like I'm talking dark wizardry shit with their fingers itching on their pitchforks because they don't know if I'm going to eat their babies.

Arrrrgh!

[camhenlin]

I normally use nedb for that, works great. I'm sure there's probably something similar for whatever other platform you might be using as well

[spinlock]

I'll admit right away that I haven't looked at the API OP posted so this is a little off the cuff, but .... this is exactly the way you want to do it. If you have a well defined API, you don't care what's on the other side of it. The migration of an app from this library to a proper DB is as well defined as the API.

Imagine if you had a Google Sheets adapter for ActiveRecord. You could start any project this way and it would be super easy to then migrate it to another supported DB.

[cdcarter]

Wouldn't that put you out of work, then? ;)

But in all seriousness, using a spreadsheet for prototyping makes perfect sense. Why waste a ton of time setting up a database when you're still figuring out what you are doing, and a spreadsheet works just fine? Yes, there's some hassle when you have to migrate, but that's compared to the hassle of setup. The amount of time to get the first iteration launched is a LOT more valuable than time down the road.

[bcRIPster]

No, it wouldn't, there's more than enough stuff like this that goes around that taking one slice off the stack isn't really going to change the stack. ;)

The thing is these solutions all sounds great on paper, but in practice for the common person? Not so much. For those people that know what their doing it really doesn't matter because they know what they are doing and update as they scale.

It's the 99% of the rest of the people who see "how easy that was" and suddenly they're over their head. And they are the same people who tell you that you can't change anything about the broken ass interface bolted onto the spreadsheet while you're fixing it.

"Can't you just fix it so it will stop crashing? Why do you want to change all of this? We don't have approvals to change this, the spreadsheet is what was approved by change control. Just make it work."

IT WILL NEVER WORK. Go away. =D