UPDATE db SET host='FQDN' WHERE db='database_name';
UPDATE user SET host='FQDN' WHERE user='user_name';
FLUSH PRIVILEGES;
GRANT ALL PRIVILEGES ON database_name.* TO 'user_name'@'FQDN' IDENTIFIED BY 'the_password';

Static format is the default for MyISAM tables. It is used when the table contains no variable-length columns (VARCHAR, VARBINARY, BLOB, or TEXT). Each row is stored using a fixed number of bytes

Very quick.

Easy to cache.

Easy to reconstruct after a crash, because rows are located in fixed positions.

Usually require more disk space than dynamic-format tables

Fixed-length row format is only available for tables without BLOB or TEXT columns

Dynamic:

Dynamic storage format is used if a MyISAM table contains any variable-length columns (VARCHAR,VARBINARY, BLOB, or TEXT), or if the table was created with the ROW_FORMAT=DYNAMIC table option.

Dynamic format is a little more complex than static format because each row has a header that indicates how long it is.

Much less disk space usually is required than for fixed-length tables.

More difficult than static-format raw to reconstruct after a crash, because rows may be fragmented into many pieces and links (fragments) may be missing.

Null and Zero do not stored in disk but there key marked in bitmap

Compressed

Each row is compressed separately, so there is very little access overhead. The header for a row takes up one to three bytes depending on the biggest row in the table. Each column is compressed differently. There is usually a different Huffman tree for each column. Some of the compression types are:

Numbers with a value of zero are stored using one bit.

If values in an integer column have a small range, the column is stored using the smallest possible type. For example, a BIGINT column (eight bytes) can be stored as a TINYINT column (one byte) if all its values are in the range from -128 to 127.

If a column has only a small set of possible values, the data type is converted to ENUM.

While a compressed table is read only, and you cannot therefore update or add rows in the table

COMPACT and REDUNDANT Row Formats

Previous versions of InnoDB used an unnamed file format (now called “Antelope”) for database files. With that format, tables were defined with ROW_FORMAT=COMPACT (or ROW_FORMAT=REDUNDANT) and InnoDB stored up to the first 768 bytes of variable-length columns (such as BLOB and VARCHAR) in the index record within the B-tree node, with the remainder stored on the overflow page(s).

To preserve compatibility with those prior versions, tables created with the InnoDB Plugin use the prefix format, unless one of ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED is specified (or implied) on the CREATE TABLEcommand.

Fedrated:->The FEDERATED storage engine enables data to be accessed from a remote MySQL database on a local server without using replication or cluster technology. When using a FEDERATED table, queries on the local server are automatically executed on the remote (federated) tables. No data is stored on the local tables.

I’d say that if you aren’t dealing with objects there’s little point in using an ORM.

If your relational tables/columns map 1:1 with objects/attributes, there’s not much point in using an ORM.

If your objects don’t have any 1:1, 1:m or m:n relationships with other objects, there’s not much point in using an ORM.

If you have complex, hand-tuned SQL, there’s not much point in using an ORM.

If you’ve decided that your database will have stored procedures as its interface, there’s not much point in using an ORM.

If you have a complex legacy schema that can’t be refactored, there’s not much point in using an ORM.

So here’s the converse:

If you have a solid object model, with relationships between objects that are 1:1, 1:m, and m:n, don’t have stored procedures, and like the dynamic SQL that an ORM solution will give you, by all means use an ORM.

Decisions like these are always a choice. Choose, implement, measure, evaluate