Large amounts of data and database design operations in the area
using the operation of the database, there are many restricted area, which is the area that we do not even think, not lay a finger once to do these things, the consequences are absolutely catastrophic of.
1, the primary foreign key
primary foreign key in not more small applications, or persons, can be controlled within the range can be definitely used, but once the data volume up, and then using the foreign key constraints lead to poor performance, in general the Internet should be Do not even going to think this kind of thing the foreign key, because then spend a lot of performance when reading and writing to the query constraints, and when a large amount of requests to go to a query constraint to consume performance, cost and consequences can be imagined .
And no matter when or post-test data maintenance, you will find, hey? The table with the table attached to it? who am I? I was there? I asked what the three in philosophy.
2, the cursor
that you can not do anything more databases, because the cursor will perform the entire table into a line execution, you can imagine, a one million of 100-level or database, you let him go line by line execution, Well , performance overhead even more horrible, your server basically anything not to do it, CPU and IO buckle down to this whole thing go.
3, trigger
this thing really, no matter who wrote it, sometimes you want to know what triggers change is really in trouble, and difficult to debug, not good control, which requires us to decide whether to use a trigger when the need to be very cautious.
4, stored procedures,
stored procedures and sometimes cool, when you go back changes to the project, the entire class with him related to rewrite all, it feels quite cool sour, do not say, will go to cry.
5, the use of DROP, and DELETE
on this matter what, you can delete from the library to the foot and following the links under reference:
http://www.sohu.com/a/256357612_104421
So DROP, and DELETE use the time to pay attention conditions and tables, it is best not to move the production library, in the non-action can not, we must pay attention to back up, they should be careful, to be deleted from no less a person on foot library is to you.
6, with TRUNCATE replace the DELETE:
TRUNCATE data in empty a table, DELETE is a DML operations, TRUNCATE is DDL operation; therefore, deleting data of the entire table with a delete, will generate a lot of the Rollback, take up a lot Rollback Segments, and TRUNCATE will not.
In memory, delete data with the delete, tablespace which data to be deleted is still space occupied by the table, to facilitate later use, it is removed further "illusion", corresponding to windows with delete data to delete the data put to the Recycle Bin, you can also recover, of course, if this time to reboot the system (OS or RDBMS), it will not be restored! And with truncate clear data, memory table space, which is occupied by deleted table space data will be released immediately, the equivalent of Windows using shift + delete to delete data, can not be restored!
7, try not to use in the query keywords
or, like% at the beginning, if the column type is a string, not in quotes,! = Negative inquiry.
Because these types of situations that will not go, then hit the index but to the whole table scan, it will waste a lot of resources and time.