Finding records that do not match between two tables. CREATE TABLE bookreport ( b_id int(11) NOT NULL auto_increment, s_id int(11) NOT NULL, report varchar(50), PRIMARY KEY (b_id) ); CREATE TABLE student ( s_id int(11) NOT NULL auto_increment, name varchar(15), PRIMARY KEY (s_id) ); insert into student (name) values ('bob'); insert into bookreport (s_id,report) values ( last_insert_id(),'A Death in the Family'); insert into student (name) values ('sue'); insert into bookreport (s_id,report) values ( last_insert_id(),'Go Tell It On the Mountain'); insert into student (name) values ('doug'); insert into bookreport (s_id,report) values ( last_insert_id(),'The Red Badge of Courage'); insert into student (name) values ('tom'); To find the sudents where are missing reports: select s.name from student s left outer join bookreport b on s.s_id = b.s_id where b.s_id is null; +------+ | name | +------+ | tom | +------+ 1 row in set (0.00 sec) Ok, next suppose there is an orphan record in in bookreport. First delete a matching record in student: delete from student where s_id in (select max(s_id) from bookreport); Now, how to find which one is orphaned: select * from bookreport b left outer join student s on b.s_id=s.s_id where s.s_id is null; +------+------+--------------------------+------+------+ | b_id | s_id | report | s_id | name | +------+------+--------------------------+------+------+ | 4 | 4 | The Red Badge of Courage | NULL | NULL | +------+------+--------------------------+------+------+ 1 row in set (0.00 sec) To clean things up (Note in 4.1 you can't do subquery on same table in a delete so it has to be done in 2 steps): select @t_sid:=b.s_id from bookreport b left outer join student s on b.s_id=s.s_id where s.s_id is null; delete from student where s_id=@t_sid; But, functions do work in delete. For instance the following is possible: delete from student where s_id=max(s_id); It just a problem when joining the table where the delete will occur with another table. Another option is two create a second temp table and locking the first one.
Loading Data into Tables from Text Files.
Assume you have the following table.
CREATE TABLE loadtest ( pkey int(11) NOT NULL auto_increment, name varchar(20), exam int, score int, timeEnter timestamp(14), PRIMARY KEY (pkey) ); And you have the following formatted text file as shown below with the unix "tail" command: $ tail /tmp/out.txt 'name22999990',2,94 'name22999991',3,93 'name22999992',0,91 'name22999993',1,93 'name22999994',2,90 'name22999995',3,93 'name22999996',0,93 'name22999997',1,89 'name22999998',2,85 'name22999999',3,88 NOTE: loadtest contains the "pkey" and "timeEnter" fields which are not present in the "/tmp/out.txt" file. Therefore, to successfully load the specific fields issue the following: mysql> load data infile '/tmp/out.txt' into table loadtest fields terminated by ',' (name,exam,score);
To dump data into a comma separated file use this:
SELECT * INTO OUTFILE 'tablename.csv' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY 'n' FROM tablename;
Replace tablename with the tablename of the table you which to dump to a file.
Through the mysql client:
update mysql.user set password=password('NEW_PASSWORD') where user='USERNAME' and host='HOSTNAME'; flush privileges;
Through the command line:
mysqladmin -u USERNAME -p CURRENT_PWD password NEW_PWD Replace USERNAME, CURRENT_PWD and NEW_PWD with appropriate values.
While working with databases – especially Mysql – most people seem to ask the same question over and over again when it comes to Primary Keys. Here’s my typical answer to the question(s) above (and more).
Continue reading Do I need a primary key and should it be called id?
There are actually two ways to wipe a mysql table either using delete or using truncate – which is better and why?
Continue reading Emptying mysql tables
Mysql is usually pretty fast by default, but to keep performance to the max sometimes requires knowledge on how mysql works and how to write queries that does their job most efficiently. Today we ran across a simple example which illustrates that mysql’s ability to use an index depends on the way you write the query.
Continue reading Mysql: (date) functions and indexes
Most databases seems to be well designed when the systems needing them are launched in the first version – but the slowly as the systems evolve (often grow beyond their initial requirements) – the database design seems to go down the drain. Here are a few tips on what to think about when you design a database or alter it.
Continue reading A database styleguide
SQL is a common language implemented by most databases. While it’s a nice language it does lack some features available in some databases (which often differ from database to database). Some argue, that you shouldn’t go beyond the contrains and limitations in SQL because that removes your ability to switch to a different database. That’s just wrong (in my opinion).
Continue reading SQL and beyond
To write efficient Mysql-powered applications a little insight in how Mysql works is needed. One often overlooked example of this is Mysqls silent column changes features, which may cause your tables to look different than you specified.
Continue reading Mysql insider