Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I understand that using a SELECT * FROM table is considered a bad practice. One reason behind this is that you are select ALL columns from the table , and in case a the table is modified in future and there are extra columns added, you will be fetching those too, and perhaps will not need those.
Assuming that at the time of writing the SELECT * , first time, there indeed was a need to select all columns.
My Question is : Is there any other reason why it might be a bad practice ?
First thing that comes to my mind is the projection the Wikipedia covers that part pretty nice. And in DBA website you have a nice question about it.
You not only miss control over the columns you will present, you also miss the control over the order of the columns. By specifying them you get to have the full control over the resultset + you optimize its size by the elements you really need.
To answer your question, you also miss the possibility to control the location of each column.
SELECT * FROM table; # it would depend of the table internal order
['Surname','Office','Name','Irrelevant']
SELECT Name,Surname,Office FROM table; # you decide which column to show the element
['Name','Surname','Office']
Another reason could be the bandwith consumed : if you only need one or two informations, it is useless to get all the informations.
The application which receives the data is also slower because it has to get a large amount of data whereas it only need a few.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
1.insert into demotable1(list_of_all_columns) select * from demotable2 where some_condition;
2.insert into demotable1 select * from demotable2 where some_condition;
note: Table structure of demotable1 and demotable2 are same.
Which one of the above query statement is optimal?
"Optimal" -- They are the same.
MySQL will expand * into a list of columns as part of the parsing of the query. If you have a list of columns, it will verify that they are valid. So, no significant difference in performance. In general, performance of a query is dominated by fetching rows, not the details of what goes on inside the row.
"Desirable" --
On the other hand, * should not be used in most situations. What if you later added or deleted a column? Suddenly most queries with * in them would break. The main exception: You are simply dumping the data to see what is in the table.
Hence, option 3 is the only desirable version; it is unfortunate that it is not available.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I must to make a decision if I split my table in more tables or I keep all in one table. According to my calculation if I will keep all in one table my table will have estimated 300.000 rows per year. Some people say to me to split table for every year. example 2019_table..
Some people say to split table in 4 tables(subcategories). I need an advice how to do it.
This is my current table https://ibb.co/jfZMKQJ
300K records is not really a large amount, and even over a decade, it is only 3 million records, which also is not very large. Assuming you can tune your database with appropriate indices, I don't see any reason to split into multiple tables. Even if you did have the need for this, you could try something like partitioning the table first (see the documentation).
300K records is not a large amount. Instead of splitting the tables, you better have to put an index on your datetime field assuming it is one of the fields you will use to filter your data.
See this answer for more details: Is it a good idea to index datetime field in mysql?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am wondering if I have a table of whose size and content I dont know, and I want to manipulate its data, is it bad practice to add unique id's to each element?
For example lets say the table is representing information from a database.
Is it bad practice to have
<li id= ${database_element.id}>
A better example using this for loop, this displays a list of elements from a table in a database named files
<g:each in="${files}" var="d">
<a id = "${d.unique_id}" class = "file" href="somelink.com" ><image id = "iconImage" src="img/iconImage"/>
</a>
</g:each>
So now each element of the table has its unique id from the database.
Is this a good or bad idea, especially when it comes to file storage i.e file/folder ids?
The reason I am asking is I cant see any other way of manipulating individual elements of the table without this?
It's usually fine.
There would really need to be some good reason for it to be bad. I'll start a list of things...everybody feel free to add to this list...
There are weird characters in your database IDs and they didn't get converted well or HTML escaped properly.
The same thing as above, but going the other direction (from HTML ids to database IDs).
Your database IDs change for some odd reason, and then you send data back to the database using the old ID.
You pollute your ID namespace with these IDs, and then can't use numbers for other IDs (this could be solved by adding some prefix to your database ids, such as db-).
It really depends on your specific situation and I would just wait until you actually run into a problem before worrying about it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I like to use tables as it will allow me to organize the data in a better manner. But now inside my application I am using tables to represents different data which can give misleading meaning. for example I am displaying the list of all record in a table such as:-
Then I am also displaying the details of each record in a table where rows will have different context:-
For me the tables seems clear ,, but am I using tables in the right context?. Or usually table rows should represents the same type of objects (for example different organizations, not different properties about an organization )? ?
Well. Most systems show information using tables. Look at any forum software, for instance. In terms of user-friendliness, you could emphasize your header rows on your top table. On your bottom table, you could emphasize the left row (a darker background or stronger font).
In my opinion using tables in this scenery is ok. All data is exhibited in simple and clear way.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Our code is using create/drop table, while generating VR4 queue orders in our database.
When number of websites is less than 250, code is using IN operator and generating reports. ce.website_id in (" . (join ",", #{$website_id}) . ")
When we have more than 250 websites, our code is creating tables (name like Temp_tablename) and using table joining instead of IN operator. Can I replace this code to use IN operator as well? Will there be any performance issue, if IN operator is used with more input values?
As mentioned by Stan, using a temporary table rather than a large IN is the preferred way to go.
When MySQL gets a large data block from the user it stores it in a temporary table and uses a JOIN to look through it. This is easier for MySQL to do than to actually look for each of your values in the IN SQL part.
You can skip this temporary table, by first storing in a table your web site list:
REPLACE INTO tblWebSitesToHandle
(Session_ID, WebSite)
VALUES
('**unique_number**', '**website_id**'),
('**unique_number**', '**website_id**'), ...
Where unique_number will be some number you chose, and then toss away once the query ends - but it will help you manage the list of websites to handle for your query
Then in your SQL that you are currently using instead of IN (...) you will do a JOIN to this table and select from it the relevant Session_ID record.
After that is done, just remove from tblWebSitesToHandle the Session_ID data, it is no longer needed (I believe).