On 18-2-2019 14:51, Simon Slavin wrote:
On 18 Feb 2019, at 1:33pm, Rocky Ji wrote:
Here's the new thing: https://pastebin.com/raw/pSqjvJdZ
Again, can we get rid of them sub-query?
The "sum()" with the "group by" in the subquery make it difficult.
There's nothing wrong with that query just
create table coaches (
coachID integer primary key autoincrement,
coach_name text
);
create table players (
playerID integer primary key autoincrement,
playerName text not null,
salary integer,
fk_coach integer,
constraint abc foreign key
On Monday, 18 February, 2019 02:27, Rocky Ji :
>Awesome, thanks for the detailed analysis; this is why I love mailing
>lists.
>It seems you jumped to the meat directly, in the opening of my
>question,
>notice the words "scenario" and "given".
>I am sure you know what they mean, but for record:
On 18 Feb 2019, at 1:33pm, Rocky Ji wrote:
> Here's the new thing: https://pastebin.com/raw/pSqjvJdZ
>
> Again, can we get rid of them sub-query?
The "sum()" with the "group by" in the subquery make it difficult.
There's nothing wrong with that query just as it is. In that form SQLite will
Whoa! Big revelation. I didn't know foreign keys were disabled by default.
And my code just ran in sqlite3 shell, and this made me think text and
rowid and etc foreign keys "just worked".
Sorry for the ruckus.
Here's the new thing: https://pastebin.com/raw/pSqjvJdZ
Again, can we get rid of them
On 2019/02/18 11:24 AM, Clemens Ladisch wrote:
Rocky Ji wrote:
But everyone advices against nested select statements.
Who?
I've heard rumors that older version of the Oracle query optimizer did
worse with subqueries than with joins, but such advice is not necessarily
correct for SQLite.
+1
Awesome, thanks for the detailed analysis; this is why I love mailing lists.
It seems you jumped to the meat directly, in the opening of my question,
notice the words "scenario" and "given".
I am sure you know what they mean, but for record: the links I gave help in
"reproducing the problem" in a
Rocky Ji wrote:
> But everyone advices against nested select statements.
Who?
I've heard rumors that older version of the Oracle query optimizer did
worse with subqueries than with joins, but such advice is not necessarily
correct for SQLite.
SQL is set-based language, and queries that are
create table coaches (coach_name text);
create table players (
playerName text not null,
salary integer,
fk_coach text,
constraint abc foreign key (fk_coach) references coaches (coach_name)
);
create table matches (
playedAgainst text not null,
@Keith
Thanks. I am new to SQL and DB in general; please clarify what *is it
valid* means. How do I check validity of schema?
On Mon, Feb 18, 2019, 1:17 AM Keith Medcalf
> Nice schema. Do you have a valid one?
>
>
> ---
> The fact that there's a Highway to Hell but only a Stairway to Heaven
@Luuk
that was my initial approach. But everyone advices against nested select
statements. Can we do it without that sub-query?
On Sun, Feb 17, 2019, 11:04 PM Luuk
> On 17-2-2019 17:46, Rocky Ji wrote:
> > Hello everyone,
> >
> > How can I prevent group by clause from reducing the number of
Nice schema. Do you have a valid one?
---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a
lot about anticipated traffic volume.
>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Rocky Ji
>Sent:
On 17-2-2019 17:46, Rocky Ji wrote:
Hello everyone,
How can I prevent group by clause from reducing the number of rows without
affecting accuracy of what aggregate functions provide?
Scenario:
My club has-many coaches.
Each coach trains a team of players.
Of course, a player has-many matches
Hello everyone,
How can I prevent group by clause from reducing the number of rows without
affecting accuracy of what aggregate functions provide?
Scenario:
My club has-many coaches.
Each coach trains a team of players.
Of course, a player has-many matches and a match has-many players.
Given the
14 matches
Mail list logo
