Arrays vs databases
ambassador at fourthworld.com
Fri May 20 22:52:14 CEST 2016
Bob Sneidar wrote:
> If there were a way to "query" an array which returned another array
> with matching keys, that would be okay. But I cannot search an array
> right now, so as a database for finding information, it's not all
> that great. Oh sure, I can write repeat loops to go through every
> single key to find the ones I need, but I would have to write the
> logic for all that. Ick! Why not just use a memory based database,
> or even an sqLite database? I just do not see the point to using
> arrays as a database when there are single and multiuser solutions
> all over the place.
A key-value store is a specific type of database, usually used when
aggregate operations (like collection-wide search) are relatively
uncommon compared to retrieving a single element.
Still, any aggregate operation takes time. With an RDBMS is means
slogging through chunks of memory-mapped blocks pulled up from disk,
sifting through fairly complex structures to find the IDs you're looking
for and then deeper to find the return values you want.
Fortunately you only need to do most of that work on unindexed fields,
and indexes can be made for any data storage mechanism. In fact,
MongoDB's index is structurally very similar to MySQL's.
Relational DBs are great, but there are many ways to work with data.
In addition to MongoDB and CouchDB, memcached, Cassandra, Neo4J and
others are worth studying to appreciate the scope of data management
options we have at our disposal.
And for simple things, simple structures work great. Arrays have a
valuable role in many data tasks, as do humble chunk expressions.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode