fenway

Why?

Please post the raw query -- by echo()-ing it -- without PHP variables.

Why is it depressing to suggest that visionaries are too busy to deal with mundane, day-to-day tasks? Why do you think that not working out the proof, or taking advantage of an edge case that breaks the rules of a theory, detracts in any way from the theory itself? That's like suggesting that using special relativity is an insult to general relativity. It's not -- it's easier, and that why we use it. Approximations are useful. So are hacks, workarounds, short-cuts, and hard-coding. Real-world solutions to real-world problems. Academia isn't subject to those constraints.

4NF, 5NF, BCNF, and often even 3NF is not necessary for working with real-world data. 3NF is designed to eliminate duplication of data (removing columns that are not dependent upon the PK)-- generally, elimination is too black-and-white, and reduction is sufficient. All NFs are on a spectrum -- whatever suits your needs is just fine -- though 1NF and 2NF are rarely sufficient.

How do you know that?

That's preferable.

Then perhaps I'm not understanding what you're trying to achieve.

thanks for trying, but nickname is already in the group by. I'm trying to get it so it excludes all duplicate ip/nickname's in the count(nickname). So basically, if there are two or more rows with the same nickname and ip address, only one is counted. Sorry, my bad. You'll need to do this in 2 parts -- first, get ALL usernames for unique IPs -- then filter out the top 10.

The only excuse for storing arrays is that (a) you'll never need to examine the individual array elements and (b) you and/or your application is/are lazy.

You mean AVG(), not AVE().

No, normalization in the sense of not having N columns for each same thing.

Sorry, I don't follow.

Taking DB normalization to it's logic end is often overkill. I see nothing wrong with phone_number and mobile_number together -- unless, of course, you plan on allowing 3 of each, in which case another table is most definitely required.

MIT is full of people who don't know how to program computers for day-to-day real-world scenarios -- that's not their job. Their job is to solve problems we're going to have 50 years from now, not program silly websites. Trust me, I've taken those computer science courses when algorithms needed formal proofs -- sure, it's a great mental exercise, but nothing more.

Sure -- but I'm not trying to judge it at all. I'm trying to help people USE it. That's where "ephemeral" knowledge becomes vitally important.

No, their responsibility is to provide a product that works in a consistent fashion with predictable output. Since you're not paying for it (presumably), you can't demand anything of them.

Sure -- just tell me what's unique about each set you want to combine.

Actually, the "best" way is to have a fourth table, as a parent, that contains all shared columns, and then use those 3 tables for extras, per type.

In this case, a sub-select with a LIMIT 1 should do the trick.

Well, the easiest way is to join this to a derived table on customer total sales for these 3 categories.

Then your GRANTs are incorrect.

Per customer? I'm confused -- I didn't see a GROUP BY. Please show sample output for the original query.

And when you tried to add this to the where clause, what happened?

Sorry, you want to add what?

Are you seriously trying to tell me that if I memorize that 5x5=25, with no underlying knowledge about "theory", I'm not allowed to use 25 as output in my application??? Sure, it helps to know where it comes from... but it's purely academic. I don't need to know how the registers of the CPU work in order to program a computer to do my bidding. I'd wager that 99% of the world has no clue. Same goes for a car. I'm not saying that the underlying theory isn't important in order to make huge gains or improvements. But if I'm happy with what I've got -- in this case, a NULL value -- you can't tell me that it's fundamentally flawed just because it violates some arbitrary theory.