i don't wanna talk about no sql..
Key-Value
for me, keys and values is easy to understand. a dictionary. json.
json pretty much is a dictionary, and doesn't look gross like xml
javascript is pretty gross.
json should change its name to something-else-on
anytrain, let's look at different databases.
Tables
addicted to base
when i was about 14, i got an amiga. i tried a database for the first time.
maybe it was just a spreadsheet and they called it a database… i'll have to research that.. it's a long time ago to recall..
i typed in all my comics. i had started collecting quite a bit, and i even put each comic in a special bag with a backing board. later on, at 15, i'd go on to work at the comic store.
i enjoyed having each comic in the database, with its details like writer and penciller and inker.. i started to appreciate the other creators of a comic too. i still remember ranking the letterers. todd klein is totally the best ever. and i give my special mention to stan sakai. groo is my favourite comic.
being able to sort the comics was cool. and the different ways of sorting. i really dug it. and it made it easy to see the holes in my collection. which issues i needed. without having to look at the comics themselves.
i haven't really found much use for databases since then though. spreadsheets are good enough, or text files, or python dictionaries. i've done data entry for work, and i've played around with connecting python with sql.. mainly to just try it.. and to avoid learning sql.
now i want a database. and not sql.
i don't want a headache thinking about JOINs and stuff.
i want to change the schema willy-nilly.
i want to try something new.
and the data that i'm going to fill all your base up with is documents..
it's suited.
so, no sql.
i'm leaning toward that odd one out in the picture above.
pretty much in the centre of the picture.
humongous..
Document-oriented database
orientated
sounds good to me already
there are two or three branches here..
eg. xml.. well, we can scratch that one anyway..
we could talk about graph-databases.. they seem cool
they are nodes and connections.. edges..
i might have a couple contenders.
i think i want an embed-able database..
each player with their own in their game..
lite db and polo db
these 2 were candidate 1
UnQLite is pulling me closer..
unqlite.org
and just learned about jx9..
Jx9 is a Turing-Complete, dynamically typed programming language based on JSON and implemented as a library in the UnQLite core
looks like we have a winner!
for today anyway
what's today.. saturday.
2 days later..
i had another look, and there's a package for python called unqlite-python
i don't think i'll bother with that Jx9 thing.
i found it interesting that the unqlite-python team complains about there not being an update to the unqlite in a long time. isn't that meant to be good? that it's great software?
>>> from unqlite import UnQLite
>>> db = UnQLite() # Create an in-memory database.
UnQLite can be used as a key/value store.
>>> db['foo'] = 'bar' # Use as a key/value store.
>>> db['foo'] # The key/value store deals in byte-strings.
b'bar'
>>> for i in range(4):
... db['k%s' % i] = str(i)
...
>>> 'k3' in db
True
>>> 'k4' in db
False
>>> del db['k3']
>>> db.append('k2', 'XXXX')
>>> db['k2']
b'2XXXX'
For finer-grained record traversal, you can use cursors.
read more here: https://github.com/coleifer/unqlite-python