

Dropbox-as-a-Database - cedrics
http://blog.opalang.org/2012/10/dropbox-as-database.html

======
tarr11
It is a fun exercise to do these kinds of things. Obviously, they are very
inefficient. But that is not the point! Perhaps there's some residual value
related to some Dropbox feature (such as automatic replication) that makes
this useful . But that is countered by getting your account rate-limited by
Dropbox.

I wonder, is there some way to create a key-value store out of any physical or
virtual object that can store state? I know there is a lot of work done with
quantum computing to store state in quarks. I can see that has value.

But, what is the most inefficient data storage mechanism you can come up with?
Here are a few I can think of:

Instagram-as-a-database - You issue a request to save your data, we encode it
using some visual encoding scheme, take a picture, and then upload it
somewhere. You get returned a URL, and can then decode it or update it.

MTurk-as-a-database - The possibilities are endless here. Someone could write
down your request on a piece of paper and then you could send another request
where they type it back.

Twilio-as-a-database - Encode your data as an audio stream. Store it in random
voicemail boxes. Retrieve it later by calling up, listening to your voicemail,
decoding the messages.

~~~
plaguuuuuu
A Minecraft game would make a hilarious database. The fact that it's probably
pretty trivial to CRUD it programmatically outside the Minecraft client by
manipulating save files is a great bonus.

Start using the DB. If you get bored enough you can examine the data
physically in-game.

~~~
fiatpandas
Why not go full-hilarity and not touch the save files? The DB API simply
performs clicks, keydowns, and mouse movements on the game client, so you see
the character moving on the screen. I guess you would have to initially read
the save file though, to know what you start with. Would be hilariously slow.

~~~
akx
You could start with the Flat world generator...

------
MatthewPhillips
I've used .json files in place of a database before on a read-only site. It
worked very well. I do believe that we over-engineer some times and use
databases when flat files will do just fine.

~~~
codewright
Using sqlite as the "this is just an idea" phase positions you better for
scale-out/build-up if it becomes necessary. Helps keep your head straight but
doesn't slow you down.

I say this as someone who worships Crockford for inventing JSON.

I've seen too many projects get fucked hard because they used flatfiles.

Edit: Seriously though, managing synchronization/atomic changes to flatfiles
manually is a Bad Idea (TM).

It's somewhere up there with, "I have a performance problem. I'll use
pthreads!" Now you have 1,02-SEGMENTATION FAULT problems.

~~~
MatthewPhillips
Like I said, in my case there were no changes, I only read from them. So I let
the server cache the hell out of them and the entire site was fast because of
it.

------
gdp
It seems rather generous to call this a database. It's files on a filesystem.
The lack of any kind of transactional consistency guarantees (Dropbox is
notoriously awful at this), and the lack of any sane mechanism for querying
this "database" means that it's just "data", not a "database".

~~~
mistercow
Transactions are not a requirement for databases, and querying is the domain
of the DBMS, not the database itself.

~~~
gdp
You're quite right. I think my complaint was that it reduces the definition of
"database" to "anything that is used to store data", rather than the database
being the json file(s) themselves, at which point we have degenerated to about
the same terminological point where it would be reasonable to call saving CSV
or MS-Access files into a Dropbox folder "Dropbox-as-a-Database", which seems
an unhelpful label, if nothing else.

------
formatjam
Actually I have the exact same idea like a few weeks ago. The potential for
this idea is big. It can be widely used by small web apps (Chrome App).
Instead of hosting a server and a database, every thing can be done and stored
in the client, isn't that neat?

~~~
yefrederic
You should have a look at filepicker.io then

------
taskstrike
Dropbox as a database is a actually great idea. It takes away scaling problems
from the developer and puts the data control back to the user.

I'm actually working on NimbusBase, a product that allows you to write
clientside javascript applications where there is no server code and data is
stored inside of Dropbox. It also integrates with backbone.

Shameless plug: sign up for our beta! <http://nimbusbase.com>

------
sehugg
Reminds me of the GMail filesystem: <http://www.viksoe.dk/code/gmail.htm>

~~~
trevorcreech
Ha, I remember using this for backups before I had even heard of ftp.

------
shykes
"update: Heroku is down [...] the demo in now on dotCloud."

:)

------
pencilcode
is this part of the app open-sourced? it's a great idea.

~~~
yefrederic
You can find the source code here : <https://github.com/cedricss/server-
monitor/>

~~~
hbbio
The list of commits is interesting: <https://github.com/cedricss/server-
monitor/commits/master>

And also shows its really a one-day app!

------
mattmanser
Your blog design is bad btw, popout at side overlays scroll bar in
Windows/Chrome.

~~~
yefrederic
It's one of the design proposed by Google, blame them :)

~~~
bduerst
Google isn't the one using it to demonstrate their work as a developer ;-)

