ebmigue

Telling us that something exists, where we have evidence of the contrary, will not prove your point. If you really want us to learn something, teach us about it, by pointing us to the first step. Otherwise, you are misinforming us.

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? What is the basis then? Please post here. I accepted theirs, because they have their basis. Their basis's basis also has their basis - w/c brings them back again to the leading authors. Why accept the views of the leading authors? No, you just don't accept it. We have to examine it too. That's why we need your basis. Your reasons, in detail.

I have no problem with you suggesting the use of a library you've obviously put a lot of time and thought into, but I think you should make it really clear that it's your library. For example: "You might consider my library: for these reasons....". vs. suggesting it in a thread like this. Yes it could be inferred from the link in your signature, but I think you need to come right out and state it, whenever you are suggesting people use it, or risk the appearance that you're not being entirely forthcoming about the potential for bias. Noted. I thought that stating it explicitly that is is "my library" would be a bit immodest. I would like to give the impression that it is a library that is for everyone, and could be modified by anyone (it's released as a FOSS). Hence the avoidance of the term "my library." I will try to improve my phrasing on the next opportunity.

@OP Enumerate the fields/attributes of each view that you want JOINed. Enumerate the fields/attributes of the resulting JOINed views. Tell us about the candidate keys of each views, and the resulting view. Tell us about the criteria/predicate in your WHERE clause. Most of the time, posting the actual source-code of views is not helpful since it will just produce confusion and too much information. From a conceptual perspective the attributes of the views/table and result in question would suffice (w/ the their keys of course.) Thank you and hope it helps.

To save time, and to end this senseless bickerings with you, I will reply to your posts only if you provide us your sources/references/materials that will help us with "erline tables," w/c will hopefully shed light on the discussion about NULL. Otherwise, replies to your posts will be fruitless and ill-conceived. Thank you.

There it is again. Blurting nonsense. We are adults here. Let us be.

Men of science are not visionaries, like the "prophets." They deal with very real scientific problems. Such can not be inferred from my posts. Yes. Hacks, approximations, work-arounds are useful. No question. But only if the instances on w/c they are applied are still the state-of-affairs. Fix a certain bug, and the workaround goes away. Refine an implementation, and the hack becomes needless. Implement a certain DBMS according to the principles of the underlying theory it professes it implements - in this case Relational Theory - then all those things goes away. The unacceptable thing is that a certain DBMS labels itself "relational" where in fact it is not; it is a network model; or "table" model. That's misleading people. We should start calling things as they are; and implement things as it should be. It is not an easy task of course. Unintelligent replies makes it harder even more.

All right. Completely irrelevant to the discussion. And somewhat ridiculous.

State your reliable basis/reference for saying that. Things as crucial as this should not be based on mere baseless opinion.

@fenway I have no say to your professional opinions/decisions. If you undermine the importance of theory, of the basis of your technology (for technology is applied science, and science is theory) - if you forget that basis, well, I cannot anymore do anything.

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. How will they show you the correct way? Only if they use theory. That's how.

Ah, I will correct that. This can be achieved using LEFT JOIN and NULL, as fenway suggested above. Sorry for the wrong info.

Oh, come on, man. Don't be like that. I'm sorry if I didn't fare well with google. So can you state the name of the author/proponents of the "erline table"? I am genuinely interested in learning about it. Please? Can't understand, and non-analogous. I am advising others to learn theory, to avoid mistakes. There is no guarantee however that you will not be mistaken if you knew theory. So why learn theory? That is for you to answer. I didn't offer code because I think the OP is already satisfied with what others had given. Or perhaps he solved it on his own. I did not understand those string of words. Sorry.

I've googled "erline" and not found any significant results. That's my "basis" for dismissing it as nonsense. Perhaps you could share your references to me, to us? Your disappointment and surprise are of no relevance to me. So why state it? What is your basis for saying that? Ah, the erline table. Is my example/analogy on calculators not clear enough? I have not understood what you meant or imply by that string of words. Please clarify. I am aware of the "cost" of my advice. It's free. If "my advice" means undervaluing existing DBMS, so be it. I have the backing of the leading authors. Certainly, I have no personal acquaintance w/ them but I had given the links to where you could read their papers. I'm not doing anything w/ my knowledge? Wow. What do you call this? I am sharing it. But many people may not be comfortable it. I don't care. I have nothing personal against them. I came here to share and talk about useful ideas, not about emotions and preferences of people. Of course, experience is the best teacher. If you created a device 99 times wrong, 1 time right, the 99 times you failed is valuable in-itself. But that is if you don't have existing theory - if you are a pioneer in your field of invention. Are you the pioneer? No you're not. Maybe I am. So why waste your time telling me things that I might not understand, since, I am a very boring and dull person? Again, why send your kids to school, if in the real world you are telling people to ignore their teachers? How can you live with that? I am interested in knowing. Save your money by not sending them to school. That could apply to you, too. Thank you for wishing me luck, though.

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. The same thing for a DBMS. The DBMS is a calculator - a very powerful, complex calculator. Its input are not only numbers, but, primarily, sets. Now, can you use it w/o knowledge of set-theory, of relational theory? No, sir, you cannot. Imagine a kid who has no knowledge of arithmetic. Then his lazy math teacher gives him a defective calculator. And the teacher says, "this device will perform addition for you. Just type the numbers." And when the kid does input 2 + 2, it gives 5. Now he goes on telling the world that he knows addition by heart. He does 2 + 2 = 5. What's wrong with the story? He didn't know arithmetic. That's what's wrong with it. He didn't bother checking his calculator. How can he check his calculator - how can he evaluate its effectiveness or defectiveness? Knowledge about theory. That is the only way. To be sure, yes, you can use a DBMS w/o formal knowledge. Relational theory also relies on intuition (as mathematics and logic do) - we can know it "by nature" so to speak. But if you want to effectively use it - and not just use it - you have to do more than intuition.

That is a depressing opinion, considering that most users here are web programmers. Also depressing for folks there since what you said implied that they are useless (at least now). Again, you are degrading useful knowledge. You are practically saying that Pythagoras's theorem was "just a mental exercise - nothing more." A typical preposterous opinion. Sure we don't need formal proofs everyday. Someone already, most likely, took care of it for us. But without that someone, we can never be sure of what we are doing. We owe the reliability of the enterprise of computer programming to them, whether you recognise it or not.

@fenway Please refer us to your basis for saying that. Otherwise, you are misleading people -- and that is irresponsible. @OP Actually, no one can help you w/ regards to database design but the science of db normalization, your knowledge of the requirements, and some amount of experience (or intuition as some would call it). All we can do is suggest. There is hardly a "right" suggestion. You alone will determine it, if it is within your requirements. And the science of db normalization is usually a helpful guide in achieving your requirements. I'm saying this because you might get the impression that we are giving "absolute answers." Just to be sure, so that I won't run risk of misleading you. Hope it helps.

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.

What you really wanted is the SEMIMINUS relational operator. That operator is neglected by MySQL, and thus the different "workarounds" being suggested here. Actually, what you want could not be achieved by a LEFT JOIN (w/o using a subquery)! And using a subquery, in general, in today's state-of-affairs is generally non-optimal. Someone can suggest to you the LEFT JOIN version of course, but it pays to research it on your own. =)

@fenway Oh. I thought if you want to learn to drive, surely you must have a working car. You need not know mechanics. But at least you must have some basic idea - your judgement - about the car in question. Otherwise, "using" the car becomes a ridiculous enterprise. I will not deny that implementation issues are important. They are vital as theory. They may be ephemeral, but they are still vital. But: IMO, people do not care anymore about theory. They always concern themselves with implementation, with product-specific facts and quirks. They do not anymore question the product itself. They treat the product as the last say about relational theory, where in fact there is still more; and that the community, aided with theory, could pressure the leading vendors - the ones with great resources - to create a more stable, useful, theoretically-sound product. That's the whole point. ---------------------------------------------------------------------------------------- @holophrastic Stop blurting nonsense, please. I may agree on this. But at least what we are discussing was not nonsense.

I was confused. What is it that you worry about? The security of your data? Or the structure or your data? If security: you can always try the conventional encryption/decryption functions/operators available in PHP. Or write your own. If structure: I suggest you use the relational structure. That is, tables. They are better documented. Of course, deciding on a structure might involve performance considerations. But if using an arbitrary structure only has negligible improvement in performance, then using a better-documented structure is more advantageous.

@OP Perhaps, SELECT SUM(IF(increment_day < '2010-06-01',SUM(detail.counts),SUM(detail.clicktositeindicator))) as CTS FROM ( SELECT * FROM vdat_2874 WHERE increment_day >= '2010-06-01' UNION SELECT * FROM vdat_2992 WHERE increment_day <= '2010-06-01' ) detail WHERE campaignid IN (1633605) will do? Hope it helps.

Why would you want to use a loop when using SQL UPDATE? The whole point with SQL UPDATE is not to use loops anymore, because the DBMS will take care of it for you. Of course, there are cases, that it is necessary to use loops. But still, use UPDATE, use CASE WHEN in the SET clause if necessary, and refine your WHERE clause. That ought to do it.

@OP Did you try what I suggested? Using stored procedures, and transactions? Or using try catch and transactions?

Your columns are: SALES_PD_1, ..., SALES_PD_9, SALES_PD_N Did you consider normalising this?