11–20 of 354 posts
>what if we want to return the salary too? >the only solution is to change half of the lines in the query How about adding a second subquery for the salary.
This example seemed wrong to me as well. You can have a subquery, or CTE that returns as many fields as you want and can join on the manager key
There is an internal software where I work where to create a tmp table you just assign the result of the query to a variable. It is so much nicer. So for instance creating a tmp table becomes as simple as the below, no need to declare each columns, to do an insert, to drop the table in the end:
@t = select colA, colB from tbl
select top 10 * from @t order by colBThis example has same amount of semantic entities as in SQL. Also there is USING. Also why author needs a strict modeling over json when one can model in native types? It's a very strange article.
But I also feel that maybe they are asking a bit much from SQL. The complaint that complex subqueries are complex... Well then don't use them? I would use WITH constructs in that situation because I find them easier to read but that's beside the point. I think its perfectly fine to pull out multiple result sets from simple queries and then do the complex stuff in your host language.
One thing I don't understand in SQL is why creating a tmp table is so verbose, why we can't use type inference. There is an internal software where I work where to create a tmp table you just assign the result of the query to a variable. It is so much nicer. So for instance creating a tmp table becomes as simple as the below, no need to declare each columns, to do an insert, to drop the table in the end: @t = select…
One thing I don't understand in SQL is why creating a tmp table is so verbose, why we can't use type inference. There is an internal software where I work where to create a tmp table you just assign the result of the query to a variable. It is so much nicer. So for instance creating a tmp table becomes as simple as the below, no need to declare each columns, to do an insert, to drop the table in the end: @t = select…
This isn't just a matter of some constant programmer overhead, like SQL queries taking 20% longer to write. 20% longer to write than what alternative? And how is this being measured? And.. am I missing something? By far the most common case for joins is following foreign keys. SQL has no special syntax for this: select foo.id, quux.value from foo, bar, quux where foo.bar_id = bar.id and bar.quux_id = quux.id Why can'…
`from foo, bar, quux` is an inner join, it's a shorthand syntax. He's lamenting that he has to keep specifying and matching ids, when the database can figure it out on its own from the foreign keys.
I thought they where talking about the data not being able to compress, the actual queries don't need to be compressed. But you need to separate the data and the index so you can compress the data while still searching the index, and none of the SQL databases do that because they don't have one file per value (for obvious disk-size reasons). We need to approach the database as files, even add features to our filesyst…
One thing I don't understand in SQL is why creating a tmp table is so verbose, why we can't use type inference. There is an internal software where I work where to create a tmp table you just assign the result of the query to a variable. It is so much nicer. So for instance creating a tmp table becomes as simple as the below, no need to declare each columns, to do an insert, to drop the table in the end: @t = select…
> There is an internal software where I work where to create a tmp table you just assign the result of the query to a variable. It is so much nicer. So for instance creating a tmp table becomes as simple as the below, no need to declare each columns, to do an insert, to drop the table in the end:
> @t = select colA, colB from tbl
> select top 10 * from @t order by colB
Unless I am misunderstanding what you are looking for, 'SELECT INTO' works the way you want: https://www.postgresql.org/docs/9.1/sql-selectinto.html
It's on every RDBMS I've used, IIRC.
function(arg, arg, arg)
With full knowledge of SQL, the successful languages that followed it were C/Python/Java/Javascript that use lots of functions and a smattering of special syntax for control structures.