3 ms·

I'm an expert on big mainstream web frameworks. It's not about what I like. It's about you being wrong. Orms are apis that are one to one with SQL queries. They

I'm an expert on big mainstream web frameworks. It's not about what I like. It's about you being wrong. Orms are apis that are one to one with SQL queries. They do not turn SQL database into key value stores. It's not even a surface level change. On the surface the orm API is designed at it's core to allow you to construct a SQL query in the form of an oop object. And the SQL query is clearly not a key value store API. Ask anyone. The primary usage of a SQL database is definitely not primary key queries to fetch one row at a time. Not at all not even close. The primary key thing is just a unique Id that orms could use for a shortcut method that returns a singular row. But make no mistake primarily orms return lists and you have to filter those lists. SQL is designed for relationships and sets. The mathematics behind it is all about creating a new set as a composition of other sets. Tables are sets, joins are relationships. The composition of tables results in a new table or aka set. >If you look at the ORM APIs and the way mainstream web frameworks use them, fetching an object by primary key is very much the primary supported way of using them. MySQL even added the option of querying via the memcached protocol after their benchmarks showed that for typical web services it was taking 3x as long to parse the SQL as actually running the query. It's one way of using SQL. It is not the primary way. You are utterly wrong. In your where clause "Id = 2" that would be what you're describing. The problem here is SQL obviously supports more complex where clauses. "Id > 2" "Id != 4" both of which will return lists and sets. And all orms should support features related to list filtering. Don't understand how memcache lends any weight to your point. What does parsing and caching queries have to do with your wrong point of sql being a key value store. You can cache parsing in things unrelated to key value stores. Again I don't think you get it.

lmm 3y ago
> Orms are apis that are one to one with SQL queries. Lol. No they aren't. Not even close. > The primary usage of a SQL database is definitely not primary key queries to fetch one row at a time. Not at all not even close. It is, MySQL did the benchmarks. It may not be what they're designed for or what theorists want them to be used for, but it's how they end up being used in a typical web setting. > In your where clause "Id = 2" that would be what you're describing. The problem here is SQL obviously supports more complex where clauses. "Id > 2" "Id != 4" both of which will return lists and sets. And all orms should support features related to list filtering. Perhaps they "should". But in actuality they have more limited support the more complex your queries get; a basic column filter you can probably do, but as soon as you want to select something other than '*' most ORMs break down. And they're like that because the users don't need or care about those use cases. > Don't understand how memcache lends any weight to your point. Then maybe you should put a bit more effort into trying to understand rather than piling on the insults and attacks. You might learn something. > You can cache parsing in things unrelated to key value stores. It's not about caching, there's no caching involved. The point was to make it easy to fetch a whole row by primary key without having to parse an SQL query, because for typical MySQL use patterns, it was spending more time parsing the queries than actually executing them. So they enabled using a protocol from a key-value store, because the most common queries were using it like a key-value store.
- corethree 3y ago
  >Then maybe you should put a bit more effort into trying to understand rather than piling on the insults and attacks. You might learn something. I did not insult you. Read carefully. You should put more effort into your replys because nobody understands what you're talking about. Up to you, but clearly everything you're saying sounds ludicrous otherwise. >MySQL did the benchmarks. MySQL is a database and databases don't do benchmarks and benchmarks don't tell you how databases are used. You probably mean some researchers measured how databases were used. Show me this source otherwise I have to assume you're making it up. Most of your argument hinges on this. >select something other than '*' most ORMs break down. And they're like that because the users don't need or care about those use cases. Even if what you say is true, and it isnt with the orms I dealt with, filters are a basic feature of all orms and basic column filtering is 100 percent for sets. Orms are nowhere near turning SQL into key value stores. >The point was to make it easy to fetch a whole row by primary key without having to parse an SQL query, because for typical MySQL use patterns, it was spending more time parsing the queries than actually executing them I can see this optimization happening. But this is drastically different from MySQL being a big key value store. The most frequent query may be a key value fetch but it doesn't make the databases primarily key value stores. For example on Google the most searched terms are for porn. Doesn't make Google a porn site and every user a porn enthusiast. Basically every user who searches for porn on Google likely uses Google for other things too. It's just the aggregate most used queries happen to add up to porn. Same with your basic website. The most frequent queries may be isomorphic to a key value fetch but clearly the websites utilize SQL databases for all the other features too. I find it highly unlikely that the majority of the web literally uses MySQL exclusively as a key value store. It is simply just the analytics showing that type of query as most frequent. There is a clear distinction here.
  - lmm 3y ago
    > I did not insult you. Read carefully. You should put more effort into your replys because nobody understands what you're talking about. So if I don't understand what you wanted to convey that's my fault, and if you don't understand what I wanted to convey that's also my fault? Lol. Note the only third party to comment here came down on my side.

lmm 3y ago

> Orms are apis that are one to one with SQL queries. Lol. No they aren't. Not even close. > The primary usage of a SQL database is definitely not primary key queries to fetch one row at a time. Not at all not even close. It is, MySQL did the benchmarks. It may not be what they're designed for or what theorists want them to be used for, but it's how they end up being used in a typical web setting. > In your where clause "Id = 2" that would be what you're describing. The problem here is SQL obviously supports more complex where clauses. "Id > 2" "Id != 4" both of which will return lists and sets. And all orms should support features related to list filtering. Perhaps they "should". But in actuality they have more limited support the more complex your queries get; a basic column filter you can probably do, but as soon as you want to select something other than '*' most ORMs break down. And they're like that because the users don't need or care about those use cases. > Don't understand how memcache lends any weight to your point. Then maybe you should put a bit more effort into trying to understand rather than piling on the insults and attacks. You might learn something. > You can cache parsing in things unrelated to key value stores. It's not about caching, there's no caching involved. The point was to make it easy to fetch a whole row by primary key without having to parse an SQL query, because for typical MySQL use patterns, it was spending more time parsing the queries than actually executing them. So they enabled using a protocol from a key-value store, because the most common queries were using it like a key-value store.

corethree 3y ago
>Then maybe you should put a bit more effort into trying to understand rather than piling on the insults and attacks. You might learn something. I did not insult you. Read carefully. You should put more effort into your replys because nobody understands what you're talking about. Up to you, but clearly everything you're saying sounds ludicrous otherwise. >MySQL did the benchmarks. MySQL is a database and databases don't do benchmarks and benchmarks don't tell you how databases are used. You probably mean some researchers measured how databases were used. Show me this source otherwise I have to assume you're making it up. Most of your argument hinges on this. >select something other than '*' most ORMs break down. And they're like that because the users don't need or care about those use cases. Even if what you say is true, and it isnt with the orms I dealt with, filters are a basic feature of all orms and basic column filtering is 100 percent for sets. Orms are nowhere near turning SQL into key value stores. >The point was to make it easy to fetch a whole row by primary key without having to parse an SQL query, because for typical MySQL use patterns, it was spending more time parsing the queries than actually executing them I can see this optimization happening. But this is drastically different from MySQL being a big key value store. The most frequent query may be a key value fetch but it doesn't make the databases primarily key value stores. For example on Google the most searched terms are for porn. Doesn't make Google a porn site and every user a porn enthusiast. Basically every user who searches for porn on Google likely uses Google for other things too. It's just the aggregate most used queries happen to add up to porn. Same with your basic website. The most frequent queries may be isomorphic to a key value fetch but clearly the websites utilize SQL databases for all the other features too. I find it highly unlikely that the majority of the web literally uses MySQL exclusively as a key value store. It is simply just the analytics showing that type of query as most frequent. There is a clear distinction here.
- lmm 3y ago
  > I did not insult you. Read carefully. You should put more effort into your replys because nobody understands what you're talking about. So if I don't understand what you wanted to convey that's my fault, and if you don't understand what I wanted to convey that's also my fault? Lol. Note the only third party to comment here came down on my side.