MySQL – Database Naming Convention Best Practices

1. Pick a standard, make sure it makes sense, and document it. There have been plenty of debates about this (e.g. whether the identity column in the contacts table should be called ID or ContactID, or whether the contacts table should be called dbo.Contacts or the unnecessarily verbose dbo.tblContacts), and you're never going to find agreement among your peers. Which standard you choose is not important; what is important is that you use it consistently, make it well-known, and get agreement from your colleagues that this is the way.

2. Your columns should be self-documenting (and not cryptic, abbreviated or obfuscated) where practical. I would NOT rely on the extended properties, but that's just me (google/bing for problems with extended properties and you will see plenty of complaints I would guess). External documentation / data dictionary is much more valuable to me - if your database goes south and so does your backup, it makes it that much easier to rebuild. It also makes it easier to describe your schema to junior developers etc. without giving them direct access to everything.

There is a reason you cannot touch the innodb database.

This is where Amazon stores the system tablespace file ibdata1

If you run

SHOW GLOBAL VARIABLES LIKE 'innodb_data_home_dir';

you might see something like this

/rdsdbdata/db/innodb

It will point to this folder as the base of InnoDB.

If you run

SHOW GLOBAL VARIABLES LIKE 'innodb_log_group_home_dir';

you might see something like this

/rdsdbdata/log/innodb

This is where ib_logfile0 and ib_logfile1 live.

If you run

use innodb
show tables;

you will see nothing because there are no .frm files in it.

Even though the innodb database contains no storage engine data files (.frm or .ibd), you cannot drop the innodb database because the folder /rdsdbdata/db/innodb is not empty.