fenway

Except no one who posts on this forum wants their website to work "in theory" alone.

@ebmigue -- this is exactly what I'm talking about. Theory has no use without practical application. The only problem with this is that you won't be able to join easily, since MySQL won't let you use dynamic table names.

Well, not being able to see the dates in the output, it's hard to assess.

Well, if your value has a backslash, you'll need to escape it, too.

Yes, but the theory describes an ideal, something to aspire to -- it's just not applicable in its entirely to each and every case.

What "issue"?

Well, what is the max set to?

Actually, the _results_ of theory have "practical relevance". The theory itself was just a convenient way to describe a consistent set of rules.

Not at all -- just balance your responses and people won't see you as a "preacher".

Not to worry -- I don't take them as personal -- but, in general, your posts tend to have a "holier than thou" tone that often neglects to address the OP's objective -- getting the problem solved. If you review most of my post over the last few years, I'm the first to object when OP's have put forward suggestions or code or designs that are counter-intuitive, counter-productive, or down-right flawed. But if they insist, I'll reluctantly provide them with a solution to their issue. I can't make anyone listen -- no one can -- so I can offer advice, nothing more. The rest is either utter silence or a workaround.

Well, you could store a record with (orderID, date, type).

Are you certain that it is not returning the correct result set?

That's not EXPLAIN output -- I mean post mysql's query plan using EXPLAIN.

No, not TO the views -- when you QUERY the views.

Any step-by-step instructions, giving you the entire solution as-is, etc. -- the correct way is the one that yields a solution, not one that yields an explanation to the solution. As an aside, let's keep the name-calling to the schoolyards -- that's a violation of the ToS.

What's more, you should never be storing the data is that way -- you've got it backwards. What's more, you posted your DB credentials to the world -- so I'd change them ASAP.

Look, maybe you've missed the entire point of these forums. No one is looking for a proselytizing theorist -- they're looking for real answers to real-world solutions. If you want to suggest they continue to read up on their theory to improve their understanding of the underlying situation -- by all means, go ahead. A fundamental grasps of basic concepts and tenets is always valuable. But to call my replies "unintelligent" -- when you can't even grasp the basis of the OP's question -- is a bit much.

State your reliable basis/reference for saying that. Things as crucial as this should not be based on mere baseless opinion. Opinion, yes -- baseless, no. Besides, why will you acccept someone else's opinion as a "reference", but not mine?

Not importance, practical relevance.

Show us the EXPLAIN output.

So why not add the WHERE clause when querying the views? I'm confused.

This topic has been moved to PHP Coding Help. http://www.phpfreaks.com/forums/index.php?topic=338923.0

You really shouldn't store date & time separately -- nor should you omit the field names. CONCAT( date1, ' ', date2 ) > NOW() - INTERVAL 2 DAY

Let me be clear. Think of a calculator. Can you really use it w/o knowledge in arithmetic? Of course not. W/o such knowledge all you can do with the calculator is type silly words. You can -- if someone else shows you how to use it correctly.

Now, is their product like that? No, I would claim, with theory as my guide. Yeah I know. But you have to wonder why people are actually paying it. The point is, I'll start paying them, when the product is already right. Hence, my criticisms. Your "theory" simply suggests that perhaps the inputs/outputs could be improved, or entirely changed -- but the current I/O is entirely predictable, in the sense that I know what's going to happen, time and time again. Sure. SELECT a.* FROM main_table a LEFT JOIN some_table b ON ( a.id = b.id ) WHERE b.id IS NULL