ebmigue

Well, I have my reasons for not specfying that is a personal framework. AFAIK, the original admin. that warned me accepted such reasons. What do you mean "doesn't even support a second DB?" Well, actually, re only has two "drivers" for existing DBMS: mysql and mssql. If he wants to use PostgreSQL DBMS, he _can_ write his own "driver". I see no problem in that.

Yes, I'd agree. Not all problems need theory for its solution. Think of problems w/ regards to your wife/girlfriend, for instance. But we are talking about Relational Databases here people. If DBMS implementers didn't have an idea about relational theory, they wouldn't even have produced their products, their SQL-based products. DBMS vendors and users are like calculator manufacturers and users, respectively. If you want to effectively manufacture a calculator, you need knowledge of arithmetic. If you want to effectively manufacture a relational DBMS, you need knowledge of relational theory. If you want to effectively use a calculator, you need knowledge of arithmetic. If you want to effectively use a relational DBMS, you need knowledge of relational theory. They keyword there is "effectively". They need theory. Period. Again, if someone is able to manufacture or use a relational DBMS (or calculator) "effectively and efficiently", then it is because either of these causes: intuition (because of previous experience); pure luck/guess. And yet there is another way to use it: learn theory. By "learn theory" I do not mean that you turn yourself like a scholar and all the stereotypes associated w/ being a scholar. You only need passing acquaintance. Just the basics. Much like learning arithmetic will enable you to live in a practical world. Devalue and undermine such suggestion all you want, but I'm not writing for those people anyway. I am writing for people that might find these advices sensible. I don't understand that. You see, I don't want to go into that argument in the first place; I was dragged into it. It's a chicken and egg problem. (Why? Exercise for the reader) Yes, theory has its "formal" part. For the most part, it is not needed. But theory too has its "intuitive" parts. That is what is important. The basic axioms/definitions. The basic theorems derived from those axioms.

One way of providing an "abstraction layer" between databases - relational databases, for that matter - is to have a library that implements the Relational Algebra. I would recommend re (http://www.reetudes.com). Though currently, the 'driver' for PostgreSQL is not yet implemented. But it would be relatively trivial to do it yourself however, IMO.

If you are a clairvoyant, then maybe I will believe you. But you are not. So, your conclusions about the future are baseless; and it is a definite "no" that I'd believe you. I would claim that "now" would not even be possible if there was no "in the first place." "In the first place" is as important as "now." If it is not, why write things? Why commit things to memory? Present problems can only be solved if we looked at previous experiences of individuals, and how they approached a similar problem. Theory formalises such approach.

Maybe, maybe not. Would you kindly tell us what is theory's role, then?

Why not SELECT distinct `discipline` FROM `books` WHERE `year`='Pré-escolar' OR `year`='1' ? If that will not work, try: SELECT distinct `discipline` FROM `books` WHERE `year`='Pré-escolar' UNION SELECT distinct `discipline` FROM `books` WHERE `year`='1' But really, using the WHERE ...OR.. version should suffice. But the two queries are logically equivalent, so either of them should do. For current MySQL implementation, maybe the first version will fair well, performance wise.

did you try call GetAllProducts at PhpMyAdmin (or any other client)? What did it output? If it outputs as expected, then your PHP library is problematic. If it does not output as expected, then maybe both the mysql client program and/or PHP library your are using is problematic.

All your claims may be true. But then the internet and websites will not come into existence if there were no theories in the first place (comp. sci). One can go on claim that he doesn't need theory as one likes. I have no problem with that. Because whether or not one likes it, the fact remains: all developments in technology are impossible w/o theory. Perhaps you take my posts as asking people to be "relational theoreticians" through and through. No I am not asking that, nor am I asking anyone here. It would quite impractical to demand that, I agree. Besides, as you said, the costs of learning outweigh the benefits of delivering. But that is still an open question; perhaps in the long run discarding theory will prove to be costly. Maybe. I don't want to wager that possibility. I am simply stating my POVs w/c everyone of us has.

I don't consider it "background noise." They are facts w/c ensure us that what we are building will make sense. W/o them, all computing becomes guess-work, unreliable, incoherent - much the opposite of what it was originally intended 80 years ago. Yes, w/ or w/out theory, such truths already and will continue to exist; even before humans came to existence (at least that is, the prevalent and most sensical belief to assume.) But: had theory not existed, those truths will remain unrecognised, and will remain unused for practical purposes. The role of theory, w/c is to formalise and discover such truths, is thus very significant.

I am not suggesting that their websites should work "in 'theory alone'." That would be quite unrealistic. I'm suggesting that if theory could be used in building websites - and all the desirable consequences from it, then why not?

For the interested, here is wikipedia's entry for Relational Algebra (RA): http://en.wikipedia.org/wiki/Relational_algebra (Note: the RA described in that article might be Codd's original algebra, proposed about 40 years ago. Of course, many improvements have been done since then; consult the book by Date and Darwen (the Third Manifesto) for a detailed treatment of the topic.) It is not that difficult to learn really. Similar to arithmetic, but instead of numbers, we are dealing with relations. Similar w/ set-theory, but instead of sets we deal with relations. SQL of course has the operators that RA has, among them: UNION, JOIN, PROJECT (SELECT), RESTRICT (WHERE), TIMES (,), EXTEND (SELECT ,), RENAME (SELECT '' AS '') In fact there are many other operators w/c MySQL failed to implement: MINUS, SEMIMINUS, COMPOSE, SUMMARIZE, TCLOSE, etc, etc. W/c could have reduced the amount of code we are producing everyday had they implemented it. See the significance? So clearly, knowing them in an abstract basis will greatly help the novice user on how to use them in an actual basis (or maybe even the experienced user). Thank you and hope it helps.

I don't want to call it that way. War implies hostility. What we are doing is a typical exchange of ideas. If you do so (i.e., partition), ensure that the partition is non-loss. Meaning, when the partitioned tables are combined again (either by JOIN or by UNION) the original table - w/c is your requirement - is still achieved. Frankly, it is impossible to suggest a "smart" approach, since it is only you who know the complete story of your situation. Of course, if you'd go about them in detail here...well, someone might be willing to help still. But less likely - since that would mean they are doing most of the job that is originally intended for you. Thank you and hope it helps.

Of course, it is true that relational theory will not help the programmer of an application and implementer of a DBMS in certain very important matters. Such as the sort of network connection to use; the sort of data-storage to use. Etc., etc. Certainly, that is beyond the scope of relational theory as such. And it will be just natural to appeal to experience and intuition when confronted w/ such issues. But then again, at least there is that clear dividing line as to where theory ended, and day-to-day practice started. Which is a good thing, too. Why? Because only then we had clearly identified w/c parts of our jobs will remain true and constant (or must remain true and constant), and w/c might need maintenance, improvement, optimization, etc. W/c is the most desirable status quo? A chaotic and uncertain mixing of the two, or a nice and clear balance between them?

At least there is something to aspire to and serve as guide, rather than go about aimlessly, right? And no. There are theories w/c are applicable in each and every case. Remember that we are considering here relational theory, w/c is based on set-theory (mathematics) and predicate logic (symbolic logic). Such sciences are deductive by nature. Their findings are true, even if we recognize it or not. Whether we are on earth or on a different galaxy, math will tell us that 1 + 1 = 2; logic will tell us that NOT FALSE = TRUE. Relational theory will tell us that {} JOIN {} = {}. And there are many such axioms, theorems w/c theory could help us as we go about on our daily professional lives, and w/c are universally and absolutely true. If we don't accept them as true, well...

To me that is theory's merit. It encourages people to think and seek further. It broadens their perspective. It enables them to decide with good information. And not just accept some "dogmas and tenets" that might not be very wise considering their particular circumstance.

Yes, I understand your point of views. I myself "bumped with" theory after I've been messing with SQL (MySQL for the most) for relatively a long time now. I do not argue your stance. But. Clearly, the OP is lost on where to proceed. He has no idea on what he is doing. Yeah sure, manuals, examples, will help. But he is asking about the "relationship of SELECT and JOIN", w/c in itself is a phrase that is too ambiguous and misguided that I don't think a product manual exists to explain such question. For all we know, all those manuals and the SQL grammar specified therein have relational algebra as their basis. Wouldn't it be wiser to point him/her to its basis (relational algebra), rather than to the specifics (SQL as implemented by MySQL)? I am just pointing to another option, another path to take, w/c, IMO, is more productive long-term-wise as I have now come to realise. For what if he will encounter a different DBMS that is non-SQL? What then? If he knows the relational algebra, it wouldn't be that difficult to make a shift, so to speak. If you guys found it easy and manageable to understand SQL even w/o knowing relational algebra ("and all that bshit"), maybe it was because of your collective experience w/ another language; or maybe you were just gifted individuals. I do not want to take my chances with those "maybe's" w/ regards to this inquiry by OP; that is why I've pointed him to the conventional approach. If you want your kids to know how to use calculators, surely, you must teach them arithmetic first, right? Rather than play that dangerous wager that maybe your kid will turnout a genius; or maybe he will come to know arithmetic by himself. OP, if you'll learn relational algebra in two weeks. You'll save yourself of two years of mastering SQL's syntax. YOu'll understand SQL even if you only have a passing acquaintance w/ relational algebra. Trust me. That was the idea of my suggestion. Of course, I am not precluding the possibility that someone will help him the "non-theory" style; how could I? Just pointing him to a possibility. That's all. I am not forcing anyone here to adhere to my thoughts/suggestions. All I can do is convince and persuade. Thank you and hope it helps.

Ah, I didn't mean algebra or calculus (the "conventional" ones). I meant that the OP should learn relational algebra (and/or relational calculus). By "learn", I do not mean the extensive kind. A passing acquaintance might be enough. Surely, again, if he wants to speak a language, he must be acquainted w/ the concepts w/c the language was intended in the first place. Hope it helps.

And because theory is able to describe a consistent set of rules, it is therefore wise to know theory (and its rules) to have a high degree of assurance that one is in the "right way", so to speak. The derivation of such rules is non-arbitrary; it involves a high degree of examination, logical-mathematical thinking, and is of course performed by the best minds in the industry. That is why knowing their thoughts - even if in a simplified form - is always an advantage.

I am glad to know that. Yes, I am sorry, for such tone. I guess it is my writing style. And I guess I had my share of reproaching people in a not-so-nice way. I will work on it. But, I will always advice people of the relevance of relational theory, especially if their problem is a direct effect of a lack of acquaintance of such theory. Sure, I'd give working code. But always with theory as its guide; meaning, its possible pitfalls, the reasons for avoiding some features, etc - in short, hacks, workarounds, that might bring SQL (and MySQL) closer to the relational model. I hope you won't have a problem with that. Thanks.

Hmm... In short, there is something wrong with the server's setup (w/c PHP might not have involvement with). It would be wise to refer this to your hosting provider's tech. support. Hope it helps.

Thank you for allowing me to do so. This is may be off-topic, but... I'm a bit more careful of my posts now. If you read my other posts in other threads, I really sounded like a jerk (and yes I did, specially when I read them again). I was just provoked, I'd like to think, by some. And I didn't handle it well. But it's nothing personal. I guarantee. ---- Now, back to the topic. The nice thing about re, is that declaring classes to handle table manipulation (i.e., SELECT, INSERT, UPDATE), may not be anymore necessary. Simple solutions to such generic tasks could be easily be implemented by the user, according to his choice. Of course, classes can also be created, but it could be avoided if one wants. Not that classes are useless or bad, but time is saved in utilising them. If there is opportunity to save time, why not grab it? Secondly. re is bringing to PHP the power and expressiveness of relational technology. So database tables are treated as your typical PHP variables. Relations (and tuples) are treated as your typical PHP values (say, array, integer, boolean values). Operators are treated as your usual PHP functions. Result: simplicity, ease-of-use. Also, IMO, PHP's PDO could be still be improved. Or a similar-to-re class/package could be introduced natively in PHP. I hope someone would write a native/pre-packaged/built-in package(set of classes) or set of functions in PHP that is relational. We could save a lot more time.

Most probably you magic_quotes enabled. Thus, when you try to mysql_real_escape it, there is an additional backslash. In short, a double backslash. Disable the feature, and perhaps the problem will be solved.

Theory is practical and relevant.

Look. Sorry if it came that way. I sincerely respect your position here. My posts are nothing personal. They are not directed to the person, but to the posts themselves. If I am missing the point of these forums, then again, I apologise. But I am directed by conscience to at least remind some that there is also another way of doing things. IMO, if we don't do it that way, we restrain the possible growth of the community. I apologise for any misconduct. But I stress: I do not attack the person; I discuss the ideas and posts.

What will be the basis for those "steps"? How will we know that the solution is correct? Only theory (e.g, axioms, theorems, proofs) will tell us. No other. Yes, I agree that it is sometimes impossible to derive an explanation for a desirable solution. But by then, we can never be sure if the solution will work as we expected it to in other cases, all the time. That is the value of theory, research: to determine the feasibility, to investigate the truth of a proposed solution. It is a complete waste if we do not use the sound insights and findings of others. Following steps w/o any basis is similar to walking an unknown path. There is a very high chance of going nowhere, or worst, being entirely lost - as my example suggests. I'm sorry if I did, but I don't think I did it.