MySQL Forums
Forum List  »  Newbie

Re: Count the records from a Join
Posted by: Phillip Ward
Date: August 26, 2016 05:12AM

Quote

... the use of Wild cards (*) being a "bad idea"
At this point, you are the only person setting up data [table] structures in your database.
In my experience, that's a rare and privileged position.

Databases are inherently shared entities. That includes the structure(s) inside them.

Today, you build a table with, say, 5 fields, all of which are numbers and, for what you need today, that's absolutely fine. Your application makes use of all five fields as well, so "select *" seems a natural and obvious choice.

Then, in a few months time, someone comes along and, to satisfy some new Business Requirement, adds three dozen, hefty Text columns into your "little" table. Or, perhaps, you come along in a few years time to do the same thing.

Now, suddenly, your application performance falls through the floor because that innocuous "select *" is suddenly pulling back all of that new data - that you may well not need for this bit of the program.

As a Rule, only ask for the fields that you actually need.

Does this make for a "Big" query?

No. Not even close.

OK, it makes it a bit "bigger" and it will take MySQL an infinitesimal fraction of a second longer to parse it's way through the query (but only the first time it sees it) but that is hugely outweighed by not pulling back all of that extraneous data, across the network.

MySQL will cope with queries way bigger than that, which is just as well given the current prevalence amongst Developers for SQL-generating frameworks like Entity Framework - I have one application, albeit running against full-blown Oracle Database, where the SQL - not the data, mind you, just the SQL - extends to hundreds of kilobytes!

Regards, Phill W.

Options: ReplyQuote


Subject
Written By
Posted
Re: Count the records from a Join
August 26, 2016 05:12AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.