// array with filenames to be sent as attachment
update TABLE_NAME set FIELD_NAME = replace(FIELD_NAME, ‘find this string’, ‘replace found string with this string’);
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 (
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
Dynamic storage format is used if a
MyISAM table contains any variable-length columns (
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
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
BIGINTcolumn (eight bytes) can be stored as a
TINYINTcolumn (one byte) if all its values are in the range from
- If a column has only a small set of possible values, the data type is converted to
- While a compressed table is read only, and you cannot therefore update or add rows in the table
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=REDUNDANT) and InnoDB stored up to the first 768 bytes of variable-length columns (such as
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=COMPRESSED is specified (or implied) on the
InnoDB :–> on transactional tables,slower,row-level blocking
uses n financial and banking application
MyISAM =>on non transactional table,faster,table -level blocking
uses in normal application
Blackhole :-> returns empty dataset everytime
Archive:-> for larger data, truncate or delete do not work on it.
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
- Speeds-up Development – eliminates the need for repetitive SQL code.
- Reduces Development Time.
- Reduces Development Costs.
- Overcomes vendor specific SQL differences – the ORM knows how to write vendor specific SQL so you don’t have to.
- Loss in developer productivity whilst they learn to program with ORM.
- Developers lose understanding of what the code is actually doing – the developer is more in control using SQL.
- ORM has a tendency to be slow.
- ORM fail to compete against SQL queries for complex queries.
kindly read above artical
nested hierarchical operation on database is very simple and gives more strength to parent child relation queries