When I clone a production database to a development database, I always need to empty the development database first. I could never find an SQL command to completely purge a database, bur, recently, I learned something about MySQL that surprised me: MySQL doesn’t lose the user rights for a database when you drop it. So, purging a MySQL database (without losing any access data meta data about that DB) is as simple as issuing the following statements:
DROP DATABASE my_development_db;
CREATE DATABASE my_development_db;
Happy cloning! 🙂
This afternoon, I had to add a unique index for some table in the Sicirec PostgreSQL database. I had already assumed that I needed to use CREATE UNIQUE INDEX to create my new unique index until I noticed, thanks to pgAdmin‘s clear GUI, that some tables clearly had unique constraints and unique indexes while one table lacked a unique constraint and only had an unique index defined.
This motivated me to take a closer look at PostgreSQL’s documentation on unique indexes:
Note: The preferred way to add a unique constraint to a table is ALTER TABLE ... ADD CONSTRAINT. The use of indexes to enforce unique constraints could be considered an implementation detail that should not be accessed directly. One should, however, be aware that there’s no need to manually create indexes on unique columns; doing so would just duplicate the automatically-created index.
CREATE UNIQUE INDEX in our migration history quickly revealed that the index which lacked an accompanying constraint was indeed created by CREATE UNIQUE INDEX instead of by ALTER TABLE ... ADD CONSTRAINT. So, now I know that, indeed, I have to use ALTER TABLE ... ADD CONSTRAINT instead of CREATE UNIQUE INDEX to add unique constraints with accompanying indexes to existing tables.