freenode/#lisp - IRC Chatlog
Search
4:04:57
beach
z3t0: [Looking at the channel logs] A few days ago, fbmnds showed up here to announce the intention of using EQL5 with ECL on Android etc. Not sure whether you are still interested in that stuff.
4:12:48
beach
If things will fit in RAM, then I am guessing it will always be faster than a traditional relational database manager.
4:14:10
seok
To search for a row with a integer field between x and y, a traditional db still loops through the entire table doesn't it?
4:15:22
beach
But whatever optimization tricks a database manager can do, you should be able to do as well, and faster.
4:45:39
beach
Try the channel logs. I don't know anything more than that. Or perhaps jackdaniel knows more.
5:55:22
phoe
minion: memo for seok: traditional DBs often use indices to speed up searches and avoid full loops over tables, so it is possible that an in-memory linear iteration over a whole table is going to be *slower* than database access that is logarithmic or better - that's a data structure problem
6:17:56
fbmnds
z3t0: afaik, there is not much published around EQL5 - I can recommend though the examples on https://gitlab.com/eql/EQL5
6:19:35
fbmnds
beach: I am checking the logs every once and a while - I am using the chat more like a black board
6:25:53
z3t0
fbmnds: thanks, I have a project in mind where I want to write a kitchen sink android app for capturing tasks and notes temporarily. Didn't want to touch java... Hopefully EQL suits my use case
6:31:33
fbmnds
z3t0: you may want to read https://common-lisp.net/project/ecl/posts/Lisp-ECL-and-QML-Qt5-on-Android.html
6:32:27
fbmnds
z3t0: there you also find the download link for the Android apps which work fine; see also https://gitlab.com/eql/EQL5-Android
6:53:13
fbmnds
I guess, some traffic has been generated https://gitlab.com/eql/EQL5-Android/-/issues/17
8:32:10
minion
seok, memo from phoe: traditional DBs often use indices to speed up searches and avoid full loops over tables, so it is possible that an in-memory linear iteration over a whole table is going to be *slower* than database access that is logarithmic or better - that's a data structure problem
8:33:46
phoe
seok: I just found an article on Hacker News yesterday that sounds really related - https://blog.dbi-services.com/the-myth-of-nosql-vs-rdbms-joins-dont-scale/
8:34:31
phoe
tl;dr you can define where indices should be created by the database, and that allows the DB to avoid full table scans. that's off-topic for #lisp, but that article should give you pointers and search keywords for future digging up
8:35:05
phoe
this article also compares SQL databases to NoSQL databases a little bit, and in-memory key-value stores are a form of NoSQL - hence further relevance to your topic