Jump to content

ebmigue

Members
  • Posts

    196
  • Joined

  • Last visited

Everything posted by ebmigue

  1. I know that this is a forgotten topic by now, and I apologise for reviving it. But it was only recently that I had free time and I just have this impulse to share an alternative implementation. Here goes: http://www.reetudes.com/samples/ctg-fight-game.php The unique character of this implementation is that it uses re (http://www.reetudes.com), a library that I started months ago (sorry if this seems like a plug ). Thus, its approach is relational -- minimal use of loops through the use of relational operators; players and player types are treated as data (not classes and objects), and hence the implementation could easily be revised to accommodate the possibility of additional players and player types, while still maintaining the basic "gist" of the game. Further, the current implementation uses regular PHP variables; but it could be easily replaced by db table references (w/c are conceptually variables) by using the facilities provided by re. Hence, the need to integrate it w/ existing DBMS becomes a less daunting task -- w/c is desirable if we want to persist a gamer's data, or provide a feature for end-users to edit and save the basic settings of the game (such as the abilities of player types). P.S.: I admit that performance is peculiarly bad when both player types are "brawlers". IMO, this has something to do w/ re's "un-optimised" form. I am optimistic though that things could still be improved. Thank you and hope it interests you.
  2. You can query the INFORMATION_SCHEMA database, much like how you would query your own database. Google "information_schema mysql". Hope it helps.
  3. Try a book by Chris Date, titled Introduction to Database Systems (8e). It has been around for 30 years already (eight editions in all). So you are assured that a wide range of topics and problems are covered by that book when it comes to DBMS. As a bonus, the book has a chapter devoted to the discussion of "object-oriented programming" and how it translates to the relational model. Doubtful. I doubt that doubt.
  4. Change: SELECT Date, TempMax FROM wx_daily ORDER BY TempMax DESC LIMIT 0 , 10 To: SELECT Date, TempMax FROM wx_daily ORDER BY Date DESC LIMIT 1
  5. @OP Your problem is one of the "MySQL to PHP relationship" w/c I detest. It causes extra work. As a workaround, create a generic function that will "wrap" the need to query the results. In that function, you can use PHP's builtin casting functions or constructs, such as 'settype' or (<type>)$variable, respectively. For the metadata of the table (i.e., what are the respective types of the table's attributes), there are mysql_* functions available for use; please refer to the manual.
  6. I'd just like to note that: I understand that what were posted were mere examples. However, the use of some hypothetical class named 'SQL' may not be very "framework-minded." For there is the possibility that a database is not SQL-based. And there is some movement in just that direction --- there are attempts to replace SQL, making way for a more "relationally-oriented" database programming language. And if that happens, would that mean that we have to edit all code referencing/using the 'SQL' class? I hope not.
  7. Again, if being lazy translates to efficiency (saved time, money, effort) then I will go w/ it. There you have it. Remember that "SELECT *" is merely an innocent syntactic construct. It is the user who is responsible. Your comments are giving the impression that "SELECT *" is inherently "evil", where in fact it is the user's fault (not knowing when to use it). That is my issue: using SELECT * is not "bad/evil"; if you know what you're doing, of course, you'll be fine. But then again, IF there are optimisers who just can't optimise code that contains "SELECT *", well they are to be blame too. Again, NOT the problem of "SELECT *", as such, but of lack of code documentation and all such matters. This was addressed in my follow-up post, immediately before this. Please read it. I used the term "universe" because a pun was intended. However, it seemed not to work. Kidding aside -- but still, such scenario IS still possible, right? And besides, there are many scenarios (real) w/c are close to what was being conjured (say, 10 tables that needed to be modified, and 3 fields to be added to each). Read the article on wikipedia (relational algebra). You can also purchase a book by Chris Date (Introduction to Databases). Agreed. But my issue, again, is that it is often viewed that "SELECT *" in itself is "bad/evil/dangerous". But in reality it is the user who is to be blamed for misusing it. I hope that that point is made clear: not the syntax (SELECT *) but the user (and/or limited DB optimiser) is ultimately responsible for the undesirable side-effects of using SELECT *. The solution, therefore, is not to ban the use of "SELECT *" but to educate the user of its (SELECT *) proper use. It can still be used but only when it's applicable, rather than type the whole set of fields (w/c can be 20 fields w/ average of 6 characters each: daunting and inefficient!)
  8. Just to clarify. I am not suggesting to use "SELECT *" in all of your queries. If you need only 2 fields of a table w/ 150 fields, why would you do so, right? But, if you need all those fields (w/c is possible in many applications), it is not logically incorrect to use "SELECT *" rather than typing those field names one-by-one (w/c is a cumbersome undertaking). If there is a performance penalty in using "SELECT *", that is not the fault of "SELECT *" as such, but of the current optimizer of the database. "SELECT *" is a mere syntactic construct w/ is in the end processed by the DBMS's optimizer. Some DBMS might handle it alright, and some might not. So, the dogma that "SELECT * is evil (performance-wise)" is not absolute (i.e., it is false in many other instances). Caveat lector. Caveat emptor.
  9. Why exactly is it a "shock horror"? You see, the designers of SQL introduced "*" as a convenient shorthand to reference all the attributes of a relation (or table reference). As such, it is practically meant to reduce typing. No other benefit should be expected to be derived from it, as intended. If the optimizer of a DB is reliant upon such construct to improve performance, well that is it's "limitation", w/c ought to be improved in future releases. Any "dogma" w/c says to avoid the "*" construct is contingent upon the current state of affairs of optimisers. If in the future optimisers are improved such dogma will no longer be true. I understand of course that we are limited with what we have. Thus avoiding the "*" is justified for performance reasons; but only that, in essence they are not "evil" or some plague that ought to be avoided. Logically speaking. What exactly are you referring? The efficiency I was hinting is quantifiable. Thus I presented the "typing that can be avoided." Well, I was sorry for not stating my assumptions. IMO, such assumption is obvious. Why would you want to add a field if it will not be referenced (one way or another)? Why is it ludicrous? Did you experience all scenarios that every developer in this universe did experience to be able to say that such scenario is ludicrous? I doubt that. Again, Why would you want to add a field if it will not be referenced (one way or another)? You have not grasped what I meant, and thus it would be a waste to explain it again. Understand it first before making any opinions about it. That would be wise. Thank you and hope it helps.
  10. W/c means that it is not the fault "SELECT *" but of "incorrectly designed tables." Of course, avoiding "SELECT *" in those cases will make "sense". But that is merely a "workaround" w/c ought to be temporary. It's most practical if we do not address the effect of a problem but the cause of it (the problem itself). Because by then further problems are avoided because the main problem was addressed. In short, DB design also plays a role here.
  11. Ah, there was a fundamental error in my answer: It says: But really: Case 1: Using SELECT * a.) If you added a new field, you need NOT modify your query AND you will modify code that references such fields = 1 Edit b.) If you removed/changed a field, you need NOT modify your query AND you will modify code that references such fields = 1 Edit Thus: 2 "edits." all in all. Case 2: Not Using SELECT * (explicitly typing) a.) If you added a new field, you need to modify your query AND you will modify code that references such fields = 2 Edits b.) If you removed/changed a field, you will modify your query AND you will modify code that references such fields = 2 Edits Thus: 4 "edits." all in all. So Case 1 is more efficient by two units (2 edits) than Case 2. Now if you need to remove/modify/add fields of 100 tables, Case 1 is more efficient by 200 query-edits than Case 2 (100 queries X 2 edits). IMO, your question is adequately answered by now.
  12. Practical Argument Case 1: Using SELECT * a.) If you added a new field, you need NOT modify your query AND you will modify code that references such fields = 1 Edit b.) If you removed/changed a field, you will modify your query AND you will modify code that references such fields = 2 Edits Thus: 3 "edits." all in all. Case 2: Not Using SELECT * (explicitly typing) a.) If you added a new field, you need to modify your query AND you will modify code that references such fields = 2 Edits b.) If you removed/changed a field, you will modify your query AND you will modify code that references such fields = 2 Edits Thus: 4 "edits." all in all. So Case 1 is more efficient by a unit (1 edit) than Case 2. Now if you need to modify/add fields of 100 tables, Case 1 is more efficient by 100 units than Case 2 (100 X 1). IMO, your question is adequately answered by now. "SELECT *" is SQL's implementation of the relational PROJECT operator/project (again, SQL was almost successful in implementing it). Meaning "SELECT *" is an operator/function for type RELATION. "+" is most Programming Languages' implementation of the arithmetic ADDITION. Meaning, "+" is an operator/function for type RATIONAL (or REAL). Thus they are the same in the sense that they are operators for a certain data type. Thus, if they are used (PROJECT and +) in a computer program, in essence, they are the same: in the sense that they are operator/function invocation. They take an input and spits an output. In the case of "SELECT *"/PROJECT, it takes an input of type RELATION/TABLE, and spits an ouput of type RELATION/TABLE. In the case of "+", it takes an input of type RATIONAL(REAL), and spits an ouput of type RATIONAL(REAL). That is the sense in w/c I "likened" them, FYI. All this is because of relational algebra, not me. If you have a problem w/ that, you can always air your complaints to the authors of relational algebra. No I don't. I'm a technical guy, so I like being lazy. If there is an efficient way to do things, I will do it, so that my employer will be happy, and he will pay me more. If laziness == more profit then I like being lazy. I hope that is a better argument. Thank you and hope it helps.
  13. @OP SELECT * is just fine. SELECT * is equivalent (almost) to the PROJECTION operator in the original relational algebra. Advice that warns against its use, is like advice not to use the "+" operator. I don't see what is the basis (logical) of that advice. If in production SELECT * gives problems, it is not the fault of SELECT * per se, but the fault of non-updated existing code. Using it is not being lazy; it is about using features that were placed there because of its practicality.
  14. Sorry about that, if I took a part in it. Yes, I have an opinion. I assume that you want your code to still work, even if the underlying DB is changed from say MySQL to PostGre. That you do NOT want to modify your source code when you migrate from one DB to another? Is that right? If "no" stop reading. If "yes" I will explain my suggestion to you. So to answer your question: "Abstraction Layers?" My answer: Use a common language and data construct. Adopt what the pioneers did 40 years ago. You see, the main reasoning is this: The original intention of the pioneers in DBMS is to create an abstract programming language that is suited for data manipulation. Their idea was that instead of contenting ourselves w/ the usual data types (INTEGERS, STRINGS), why not add a data type that is suited for manipulating data? E.F. Codd then introduced the RELATION data type. Further, additional operators/functions are then introduced to manipulate values (including values in a variable reference) of the type RELATION: JOIN, UNION, MINUS, etc. Analogously, if there is a "+" operator for INTEGERS, there is a UNION operator for RELATIONs, and so on. Thus the relational algebra was developed (the relation data type plus the operators). The nice consequence of having an abstract language of manipulating data is that users/programmers are rid of technical details that are involved when manipulating data. Data manipulation then is practically "abstracted". For instance, if you want to compute the tuples/rows in relation variable (relvar/table) A that are not in relvar/table B, you simply: A MINUS B (Exercise for the reader: implement this in SQL) You need not worry on indexes, the kind of loop to use, the source of such data, etc, etc. ( Of course in practice you will concern yourself w/ performance; but that would be in administration/maintenance part; not on the actual product development and modelling. In practice, too, the DBMS optimizer will automatically help the programmer in optimizing his/her code In theory, if you want to improve performance, there is no need to adjust and recompile your source code! Simply adjust the settings "under the hood" so to speak, w/c is the Physical Layer of the DBMS ). So, how did they do it in the field of relational DBMS 40 years ago? They created an abstract language w/c is now usually referred as Relational Algebra. All you have to do is to implement such abstract language, say, in PHP (or in any language), and you will have an abstraction layer between/across databases or sources of data (say, one of the web services by Google) I posted this reply for future for your future reference.. Thank you and hope it helps.
  15. "Closest" branch to what? Being "close to something" is a relative relation. Thus, I would assume that you have a "base" location (serving as the reference point.) You can start by modeling all locations as three-attribute relation (table), say: name_of_place string, x_axis decimal, y_axis decimal The idea is to represent the possible as points in a Cartesian plane. Finding the closest location from a given reference point is probably solve-able using techniques in geometry. And application of geometric techniques can be achieved, IMO, in SQL. You might also want to look at existing algorithms for "The Traveling Salesman Problem" and/or "Shortest path problem". Hope it helps.
  16. That's what I had been stating all along, and I agree that 'nuff is said. But what is happening is that most replies to questions are only directed on performance and is product-specific, when in reality theory alone could put the nail in the coffin, so to speak. And the problem is, when I try to point that out, I am met w/ hostile comments, such as this: W/c is very unhealthy.
  17. And yet I am saying that the "proper" things are still "possibilities." And yet I am saying that if it is not clearly stated that a hammer is a hammer and a saw is a saw, there is that chance they will be misused. But we can do that, if we know theory, because by then we can avoid pitfalls and how to use the relational DBMS. Sure it's a bit demanding -- time and effort (maybe even money) -- but who says that it must be right now? I am merely suggesting things, putting some ideas. Whether or not they will be heeded to - I have no control.
  18. How will the builders know what _are_ the "materials they have", "what they _are_ for.."? Who will tell them? The vendors of DBMSes? But then who defined the basic components of a DBMS - namely, tables, views, and functions? Theory defined those things. The vendors implemented it. (But the story didn't end there. Some vendors actually mistakenly implement it. Thus confusion is now reigning. Some vendors implemented a hammer like a saw, and vice-versa.) That is the point: at least get a basic acquaintance of theory, then and only then, one can really see what are the potentials and the proper use of one's tools. If one does not, well there is the possibility that a hammer will be used like a saw and vice-versa. Imagine the resulting work of such a builder, who uses his hammer as a saw and the saw like a hammer. Why of course, yes. AFAIK, I did have some posts where I didn't "inject useless theories". BUT: there are problems/questions/posts where the _direct cause_ is lack of knowledge of relational theory. (say a user who wonders why joining a non-empty table and an empty table results to an empty table, and is very "frustrated" already.). That is where I will "inject theories." if "improve" is performance-wise, theory has little to say because by then the problem is product-specific. if "improve" is precision-wise / db-design-wise, theory has a lot to say.
  19. W/o Codd's theory about relations (i.e., the Relational Model), IBM could not have created the first DBMS. No first DBMS, no second, third, fourth DBMSes. No MySQL, no PostgreSQL, no Oracle, no SQL, etc. And this products now made our world turn. Did theory had something to do about it? Absolutely yes. The point is, we ought to know what should work (theory). If it does not equal to what we actually have, to the current technology - still, we must be aware of it lest we limit the possibilities of what we already have. Again all this is because of practicality - to save time, money, and effort. I know. Like I said, wouldn't it be nice if I too would provide the theoretical basis of my solution? If the OP is not concerned w/ it, he _can_ ignore it. I certainly will not force anyone - novice or experienced - to read them. You see, most questions here -- especially from the novice -- are like "I am dividing 1 by 0. It gives me an error. Please help...?". So, what is the best thing to do? Rather than tell him about compiler settings and details, why not tell him about the axioms in arithmetic? If there is an opportunity, wouldn't it be nice to "get matter straight, and get to the bottom of things?". It would save us some time and effort - a lot of it. The important thing is that s/he is informed, that there is now available "new material". All for knowledge and practicality's sake. I had read books because I am "in the real, working world, where the real, working problems actually exist," and I am from "where fenway is coming from." We just differ in methods. I understand it, really. I, too, had ignored theories for years. And yet when I "discovered" it, I realised the time time and effort I've wasted. There I was struggling w/ problems that could have been avoided had I applied what was in books for so many years. The point is this: I had no problem w/ the nature of most of the suggestions, w/c is DBMS-specific and has special emphasis on performance. I am fully aware that performance is a great feature and is a real requirement. Make no mistake about it. But it is not only performance that one should be concerned about. Conceptual integrity, precision are also very real requirements. So, sure, you guys can worry about performance, and I'd be posting the conceptual/theoretical basis of the solutions to their problems/posts.
  20. On the contrary! I am using theory to clarify my solutions, and not confuse users. If you noticed, I am dragged into "defending/ranting/theorizing" only because my suggestions are immediately deemed as "inefficient/non-parser friendly" - and all such implementation-related considerations. Avoid that, and this endless exchange will stop. I just want to help people, and if I had to argue w/ your posts, then so be it.
  21. Me, too. Though there were instances where I was called names and insulted, I don't mind really. But of course, I hope you won't mind too if I did retaliate a little. The opinions usually invoked by others do have counter-opinions, and thus accepting them will not lead to harmony and a fruitful discussion. That is the sense in w/c such ideas cannot be "verified." That is why they have to be dismissed as "unverifiable." Yes, I expect that my claims will be taken seriously, for the same reason that you want your claims regarding the "usefulness or uselessness of theory" should be taken seriously. In the end, it is the reader who will choose whose reasons are more coherent and sound, and thus to accept . Let them do their work. Again, I do not intend to be condescending. But sometimes the arguments given are not coherent and reasonable, that one must notify the arguer about it - albeit tactlessly. I apologise for the lack of tact. But only that. As far as the person in question is concerned, I treat him/her as an equal. That is why I preferred to discuss ideas here in the first place. I did not even intend that using theory will be "a magic proof of validity." Theory is not magic; it is science. It is verifiable and based on human reason and experiences. On the contrary, I am promoting, not a "dogmatic/religious/magical" mindset but a scientific one, based on reason and the scientific tradition. I don't know what you mean. A hammer and a DMBS are the same only in the sense that they are tools -- and only that. I was satisfied overall w/ the discussion. We cannot know if the OP did or did not get his solution - he ceased replying anyway. If this thread "went astray" that was only because I was defending the criticism of my suggestion, w/c is to learn theory (in this case, DB normalization). Had such suggestion not been criticized (dismissed as impractical), I would not have defended it. I don't think that would be a good idea, since there are many books that do that. And it is not "my theories." A lot of them had contributed to it - for 40 years now. I will content myself by noting relevant principles when it is very obvious that a problem/question posted is caused by lack of knowledge (or appreciation) of the applicable theory. When a user is complaining why he can't divide 1 by 0, surely, the wisest thing to do is to point him to axioms in arithmetic, right? I would like "to get to the bottom of things" so to speak. I hope you won't have a problem w/ that. Thank you and hope it helps.
  22. That is a subjective opinion. You are not the only IT professional in this field. Different situations call for different approaches. Maybe in your case you need not be acquainted w/ theory. But in general theory is still applicable to you - you just chose not to acknowledge such fact. The fact that you are using MySQL means that you DID NOT "build your own". Of course one can choose "not to go relational," but by then s/he will be missing its benefits. Really? Then why call something "relational" when in fact it isn't? Why call someone a "King" when he is in fact a "slave"? What is the motivation? To humiliate? To mislead people? To malign known useful theories? I doubt that. They named it as such, because they want to implement the theory. So far, they are doing good - but much is still needed to be implemented. A claim that cannot be verified, and thus must not be taken seriously.
  23. I get it. You choose tools according to your needs and purpose. Nobody can force you to use what you do not want to use, that is plain. The problem, however, is that people don't recognize that they have already a very powerful tool at their use (the relational DBMS). Why they didn't recognise it, is precisely because of lack of appreciation for relational theory. And the consequence of not recognising it is that people tend to misuse it. Worse, they tend to reinvent things, w/c could have already been addressed by the tool in question. Thus, inefficient and ineffective use and creation. Wasted time and money - in practical terms. Second, the tool they have is not yet perfect. It is not yet a "full-blown hammer", so to speak. Yes it can "hammer" things. The point is: it could have been a finer tool if the "theory on creating hammers" (in this case, relational model) was used in building and using it. Why they didn't recognise that, is again precisely because of lack of appreciation for relational theory. Thus, time and money could have been saved - in practical terms. You see, the situation you tried to "paint" is very broad, thus it is difficult to stay relevant. In this case - remember that the topic is about relational databases - we do not have a choice. Since MySQL (and most DBMSes) are labeled as relational databases then it follows that they are based on relational theory. Thus, we have no choice but to know the theory/science behind such technology. If we do not do so, again, inefficiency and ineffectivity of use and creation of such technology naturally follows, speaking from the point of view of relational theory. If most DBMS didn't label themselves as relational AND they didn't follow the principles of relational databases, then it is just right. But it is not the case. What we have here is basically like this: a product that is labelled as "A" but is actually "B". Now, people will start expecting that the product will behave like "A"; but then it cannot, so confusion arises, misinformation, and all the undesirable consequences that are derived from such. In practical terms, money and time wasted. That is what I was assuming all along. Sooner or later you will need theory. When there is still a chance to avoid that, why start late when one can start early, right? I don't think that "most theory-driven people never learn, because they never get to have those problems so close to them" is true. Most "theory-driven people" chose to be "theory-driven" because they have first hand experience with problems that are very practical and real.
  24. Yes, that is correct. If we substitute "bigger" w/ "theoretically sound" and "hammer" w/ "DBMS", then we are in agreement. No I do not agree. When you recognize that something is "bigger than something", literally, the sense of sight would suffice. But for DBMSes it requires more than that, namely, application of theory. If in one's experiences a tool breaks, of course, it is just natural to replace it w/ something that doesn't. And I am stating now, that relational theory alone would give us a high guarantee that some relational DBMS will not break. Since, according to your line of thinking the strength of hammer has its basis on its size; then I would likewise argue that the strength of a relational DBMS has is its basis on relational theory. And presently most DBMS, as relational theory would have it, breaks. And "why" you asked, read my previous posts. I have been stating the reasons repeatedly.
  25. Last time I checked, most beginners will like explanations of the suggestions given to them. And now...I just get the feeling that doing so is discouraged.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.