3 ms·
You can't do that with a plain array I can do that with hash arrays. The primary key is my primary hash, other keys are just extra hash maps pointing to the ma
by mojuba 19y ago
You can't do that with a plain array
I can do that with hash arrays. The primary key is my primary hash, other keys are just extra hash maps pointing to the main array.
I understand, perhaps none of the existing languages can fully replace the DB functionality, but I suspect nobody is even thinking about that because - hey, there are plenty of nice DBMSs around, why bother reinventing them?
but then what you have isn't a simple array any more
True, but again, it's a matter of having an infrastructure that handles sharing for you. Windows Registry, however awkward and Microsoft'ish, does just that, as as example.
- nostrademons 19y ago"I can do that with hash arrays. The primary key is my primary hash, other keys are just extra hash maps pointing to the main array." A.k.a an in-memory table with hash indexes. MySQL has them. ;-) You're still missing out on a lot of functionality (even besides transactions/persistence/concurrency). For example, what if you want all records where the creation date is between a certain range of days? Or how about the maximum value of a certain column? How about joins? A conventional database can retrieve these from the indexes, but your multiple-hashes system would require a full table scan.
- mojuba 19y agoAll you just said is map/reduce, possibly optimized for large data chunks internally. In fact if we create a proper infrastructure, "indexing" can be done automatically and transparently. And I never said arrays should be in memory entirely, even though I declare them as arrays in my language.
- brlewis 19y agoSQL indexes work transparently. Creating them automatically would not be good, since they have a cost for write operations.