ebmigue
-
Posts
196 -
Joined
-
Last visited
Posts posted by ebmigue
-
-
You can query the INFORMATION_SCHEMA database, much like how you would query your own database.
Google "information_schema mysql".
Hope it helps.
-
thanks, I think I will invest in a book. Served me well before when I got one on php and css.
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.
Collages and Universities can help.
Doubtful.
I doubt that doubt.
-
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
-
@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.
-
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.
-
The only reason to use * is to be lazy with your coding.
Again, if being lazy translates to efficiency (saved time, money, effort) then I will go w/ it.
It's not the fault of optimisers, it's primarily the fault of those who are new to SQL,
learn using * from the beggining and then cause problems because there is no controlable ferrerence to the existing fields in the table that they are using for the query
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.
So when that code then get's passed onto someone else to "make it better" there is no reffernce point to work with. It's grossly harder to manage code that uses a * than the explicit field names. It's the same problem with the single letter aliasing of table names - it starts off simple, grows, then someone else gets landed with it and has to keep scrolling back up to see what bloody table "d" was.
Again, NOT the problem of "SELECT *", as such, but of lack of code documentation and all such matters.
I was reffering to the performance degridation of selecting fields that are not required, as well as the time and wasted while other developers work trying to exact the relevent code from a clearly non modular style.
This was addressed in my follow-up post, immediately before this. Please read it.
Universe? Seriously? I don't think we need quite so much drama thanks. Obviously no I have not come anywhere close to dealing with even a fraction of every possible permutation of "What could happen if". But the scenario was ludicrous in the effect that if it was an accurate representation of what was expected, it was clearly done wrong to start with. In which case a ground up review would be needed and the use of * would fall somewhere into meeninglessness (is that even a word?) in comparison to the rest of the work that would need to be done.
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).
You'll find that happens quite a lot with me I had assumed that you were reffercing algebra for something more that "what goes is comes back out".
Read the article on wikipedia (relational algebra). You can also purchase a book by Chris Date (Introduction to Databases).
My issue with the use of SELECT * isn't as eclectic as I have probably made it seem.
It's more like how I veiw high grade explosives - should only be used by people who know exactly
what they are doing with it.
Too many people pick it up early and run with it forever more regardless of whether it is the right thing to do.
I meen come on, how many times have we all seen SELECT * used in a user login script on this forum alone?
Then how many times when people want to see a list from table1 that reffrences a join on table2,
looking for a single pair of matched fields but wind up using select * to pull everything out of both?
If someone is in the position where they know exactly what they are doing and how it is being done, then sure use SELECT * - otherwise you are probably doing it wrong
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!)
-
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.
-
so your practical benefit is...saving typing. shock horror.
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.
Efficiency is measured by more than how many words you need to change during design.
What exactly are you referring? The efficiency I was hinting is quantifiable. Thus I presented the "typing that can be avoided."
And it's invalid to assume that by adding a field to a table you are going to want to refference that information in all pre existing code.
As for having to update 100 tables at once...Really? You had to add 1 single field to 100 tables at the same time and then refference that field with every single pre existing query?
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)?
dont make ludicrous scenarious just to keep from seeming quite such an opiniated fool.
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.
Likely you would update 100 tables and then waste your dear efficiency by using * to pull that field irrelivently into your pre existing queries that were never designed to refference them into variables anyway.
Again, Why would you want to add a field if it will not be referenced (one way or another)?
It's not the fault of algebra: + performs an arithmetic action, * just cuts corners.
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.
-
For those of you with incorrectly designed tables, with images/files stored in the row or tables laid out like spreadsheets or tables with duplicated data in them, don't automatically use * because you will be retrieving unnecessary data that will add overhead to your script.
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.
-
Ah, there was a fundamental error in my answer:
It says:
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
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.
-
Really? well my question still stands - what practical benefit does it actualy give you over explicit field lists?
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.
Oh, and to liken it's use to the + operator is just stupid and petty
"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.
I have to assume you take offence at being grouped as lazy, but you really need a better argument than that.
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.
-
@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.
-
This little discussion with / about user:ebmigue is interesting and all that, but has essentially HIJACKED my thread which is asking a question.
Sorry about that, if I took a part in it.
I'm assuming people here have personal opinions about the completeness, design, and usability of ADOdb and similar libraries?
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 will look at it because it looks interesting, but it's NOT what I'm looking for today...
I posted this reply for future for your future reference..
Thank you and hope it helps.
-
"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.
-
is this argument really still going on? there needs to be a combination of theory and reality in all aspects of life..nuff said
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:
ebmigue, you have already proven yourself an idiot. No need to further convince us.
Thanks!
W/c is very unhealthy.
-
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.
-
...but rather focus on the materials they have, what they are for, and get to building.
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.
You can easily spot the difference between someone wanting a solution to a problem vs. Someone looking for better ways to do things, by what they ask.
Why of course, yes.
"I need a query that will give me xyz" == "I need a solution to a problem"
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."
"I have this query that gives me xyz, but what can I do to improve it?" == gimme theory
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.
-
ebmique, the problem is that theory is great as a tool to help you get your bearings straight, but it isn't what makes the world turn. What should work (theory) does not always equal what does work (reality).
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.
We know you're just trying to help, but most people on forums like these aren't here to learn principles per se, but to figure out how to solve their real working problems.
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.
Spend less time in the classroom or with your nose in books and more time in the real, working world, where the real, working problems actually exist, and you will see where fenway is coming from.
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.
-
I'm just trying to suggest that there are various ways of being helpful, and confusion isn't one of them.
On the contrary! I am using theory to clarify my solutions, and not confuse users.
At any rate, I'm exhausted by my ongoing attempts at rational explanations with you -- I will no longer contribute to any thread in which you have posted . Feel free to lecture the general public about theory to your heart's content. I'm done.
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.
-
@ebmigue: we're really trying to have productive discussions with you.
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.
But, for some unknown reason, you reject any and all of our opinions just because they cannot be "verified" -- but you expect us to take your "claims" seriously.
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.
That's not how a discussion works -- everyone is on equal footing -- no one should cry foul, or wield theory as a magic proof of validity.
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.
When you said "I get it. You choose tools according to your needs and purpose." -- I thought that this discussion would come to a fruitful end. But yet to don't seem to be able to extrapolate from a hammer (tool #1) to a database (tool #2).
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.
At this point, the OP's thread has been severely hijacked -- remember, the initial comments & remarks were on-topic -- so I'm going to close this thread in due time. For all we know, the OP didn't even get a solution and has abandoned their request.
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.
If you'd like to have a discussion on your "theories", then perhaps start your own thread instead.
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.
-
"why start late when one can start early, right?" -- because it costs to start early, and you may never need to go all the way.
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.
we can choose not to go relational, or we can choose to build our own. I do that.
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.
...just because it's named, doesn't mean we need to care. And it can be named after a goal that wasn't achieved, or after a plan that wasn't accomplished, or even after something that it isn't. it's just a name.
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.
most theory-driven people have been taught by people with first hand experience. most theory-driven people have nothing but other people's stories.
A claim that cannot be verified, and thus must not be taken seriously.
-
but I'm not saying that the strength of the hammer is based on its size. I just grabbed another hammer. It could have been a smaller one. BUt I originally chose the smaller one because it was easier to swing -- I'm a wimp. When it didn't work, I moved to the next easiest option. You'll recall that I started with my own shoe, so I wouldn't need to go and find the tool box.
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.
But I do agree with you (wow) that had I considered the hammer's size, and intentionally chose a bigger and "therefore" more suitable hammer, that we'd be in agreement regarding a database. But I didn't consider the hammer's size.
Instead, I just went for random arbitrary choice. And I think most people do in most situations. In fact, I think everyone does in every situation when it comes to problems with what they believe to be not the core thing that they are doing. So a painter would choose the correct paint brush using theory, but someone using a paint brush as a door-stop would not care which paint brush they used -- even as it pertains to being a door stop. They'd just grab any brush and hope it worked.
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.
So when a web-site programmer grabs a database to house 10 kilobytes of data, he really doesn't care about the database in any real way -- it's all about the html to him -- so he doesn't do any theory effort at all. When he later starts storing thousands of records, then that becomes the real job, and theory starts to be beneficial. And when it grows further, then theory is required.
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?
That's the road that I took with my business. And it actually allowed me to get really creative and very innovative quite early-on, because I didn't get trapped by common mistakes just because they were common, nor by techniques that weren't known to be mistakes for another couple of years. I wasn't trapped in the same box as everyone else. It opened many doors for me. I also learned exactly which elements of the theory applied to precisely which problems I was having as I resolved them -- something that most theory-driven people never learn, because they never get to have those problems so close to them.
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.
-
Grabbing a bigger hammer is the a valid technique.
Yes, that is correct.
If we substitute "bigger" w/ "theoretically sound" and "hammer" w/ "DBMS", then we are in agreement.
And it requires zero theory of any kind.
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.
-
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.
struggling graduate
in Miscellaneous
Posted
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.