[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/sci/ - Science & Math


View post   

File: 9 KB, 358x285, SQL.jpg [View same] [iqdb] [saucenao] [google]
2431757 No.2431757 [Reply] [Original]

So, /sci/, newbie SQL question here.

Is there an easy to remove something from an output when even one of the outputs match something? ie;

A - 2002/02/02
A - 2001/04/05
B - 2003/02/05
B - 2002/11/11

Now, let's say since A and 2001 are linked, I don't want A in my output at all. Can this be done easily?

>> No.2431783

Have a better where clause.

>> No.2431793

>>2431783
Well, obviously my first try was

AND date BETWEEN "2002-01-01" AND "2003-01-01"

but that just removes 'A - 2001/04/05' , and not the other A.

>> No.2431816

Subqueries?

select * from table where foo not in (select foo from table where date BETWEEN "2002-01-01" AND "2003-01-01");

>> No.2431823

>>2431816
Can't say I've heard of foo, but I see what you're doing.

Let me just try it out.

>> No.2431830
File: 57 KB, 397x600, kristen_bell.jpg [View same] [iqdb] [saucenao] [google]
2431830

>>2431823
> never heard of foo
check wikipedia

>> No.2431845

>>2431830
Ah.

Of course.

>> No.2431862

Hm.

Still seems to be not working as intended. It just removes the 2001 instances, but not the letters (A, in my first post)

>> No.2431935

Not that very fucking stupid "foo bar" crap in examples again.

And what, are A and B in a separate column from the dates, or are those lines entire strings? And do you just want to exclude all entries with A? Why not just select the ones that are not like "A%" or something?

>> No.2431956
File: 27 KB, 779x402, sql.png [View same] [iqdb] [saucenao] [google]
2431956

>>2431862
Works for me.

>> No.2431974

>>2431956
Figured it out already, thanks.

>>2431935
It's like this. If an entity in the first column is related to any date in 2001, it can't be in the output. Does that make sense?

>> No.2431976
File: 78 KB, 582x456, rage.jpg [View same] [iqdb] [saucenao] [google]
2431976

I fucking hate when people use that "foo-bar" shit in programming. Seriously, I'm raging everytime.

>> No.2431993

>>2431935
>Not that very fucking stupid "foo bar" crap in examples again.
>>2431976
>I fucking hate when people use that "foo-bar" shit in programming.

ITT: COBOL programmers

>> No.2432003 [DELETED] 

Now that we're on the subject anyway, this should show the price of the total sales from the chairs, no?

SELECT SUM( (
price * amount
) )
FROM `sales`
LEFT JOIN `product` ON product.art = sales.art
WHERE product.srtc = 'chair'

>> No.2432031

>>2431993
nah, just scrubs

>> No.2432052

>>2431956
That will work right up until there isn't a row containing the date 2001-04-05
Or the foo associated with that date isn't A

>> No.2432055
File: 34 KB, 289x300, 1281298869859.gif [View same] [iqdb] [saucenao] [google]
2432055

So it's entries that aren't both A and 2001? Why not use something like >>2431816 except have the "not in" statement select the A 2001 rows.

Except for the foobar shit. Gahahaha

>> No.2432062

>>2432052
I don't think you really understood the OP's request.

>> No.2432063

>>2432055
A is just a name for a variable, could have been anything.

I just didn't want the output to have a name (ie A) in the left column if that was 'connected' to a date in 2001.

>> No.2432085

>>2432062
Oh, I see now.
My first statement is still true and still points out a flaw in the statement.

>> No.2432089

So you still select the ones with both A and 2001?

Do they have to be in the same query? Or can you just make two queries - one where you only select the date, and the other one where you select everything?

>> No.2432104

>>2432089
Well, my final solution was to make a sub-query:

SELECT sales.customer
FROM `sales`
WHERE `date` >= "2003-01-01"

To select the costumers that DID bought stuff in 2003, and in the main query I just added

WHERE customer.customer NOT IN
{subquery here}

And that did the trick.

>> No.2432133

Gahahaha, good... maybe.

Well, you might not have to do all that if you can modify the program or script that uses that database.

>> No.2432150

>>2432133
Purely writing queries at the moment to practice.