Arrays vs databases

Richard Gaskin ambassador at
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.

  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  Ambassador at      

More information about the use-livecode mailing list