| >I don't like to use SQL engine because I don't understand how they work, I never really know if my query will be O(1), O(log(n)), O(n), etc, or what kind of algorithm will optimize my query. Unless you're generating totally dynamic queries that's a moot point. You can always try it and measure it -- just like you know, you would profile a program in any programming language. And you can trivially have the database show you the query plan as well. Do you also not use APIs because you don't know a priori if a call is O(1) or O(N) or O(Nlog(N)) etc? >I think SQL was designed when RAM was scarce and expensive, so to speed up data access, it has to be properly indexed with a database engine. I really wonder who, today, have data that cannot fit in RAM, apart from big actors. That's really orthogonal. Speed and indexes still matter today with big data (or plain "tens of thousands of web users" loads), where we often have to denormalize or use indexed non-sql stores just to get more speed for the huge data we still need to be able to query fast. Besides, something indexed will be faster whether they are in disk or in RAM compared to something in the same storage that's not indexed. So unless we're coding something trivial, server side we still want all the speed we can get from our data than plain having them as simple structures RAM provides. You wouldn't use a linked link as opposed to a hash table just because your data "fit in RAM". Even in RAM ~O(1) vs ~ O(N) matters [1]. SQL was invented and caught on because: companies had tried and were burned by no-sql stores with incompatible storage standards, lax reliability guarantees, no interoperability between client programs, no over-econmpassing logical abstraction (compared to relational algebra) but ad-hoc reinventions of the square wheel, and so on. Ancient issues the wave of Mongo fanboys brought back all over again. [1] unless the linked list is so tiny as to fit in cache and avoid the hash table inderection, but I digress |