MySQL

This article is a stub. You can help the IndieWeb wiki by expanding it.

MySQL is open source database software that is often used to store data in several indieweb CMS's like Known, and various other CMS's, e.g. WordPress and MediaWiki.

IndieWeb Examples

IndieWeb community members that use MySQL as some primary storage on their personal site:

Kartik Prabhu

Kartik Prabhu's Bundle uses MySQL as the primary storage for data except for Article content which is stored in hand-authored Django-template files.

Gregor Morrill

gRegor Morrill uses MySQL (ProcessWire and previously Nucleus CMS) as the primary data store on gregorlove.com

Regarding database-antipattern: By and large, I have not experienced the downsides documented there. It did take me some time to correctly migrate my database from latin1 encoding to UTF-8 (character encoding is hard, yo), but I did not find that process prohibitive to continuing to use MySQL. gregorlove.com's content has resided safely in MySQL since 2002.

Ben Roberts

Ben Roberts uses MySQL as primary storage in Postly but caches queries to flat files.

Secondary Data Store

IndieWeb sites that use MySQL to store secondary data, i.e. not content that they authored, but content from elsewhere.

cweiske

cweiske's stapibas uses MySQL as primary linkback storage

Caching Examples

Aaron Precki

p3k uses MySQL to query posts by different meta data, but does not store any post content in the database.

Criticism

Lack of timezone in date columns

MySQL date columns can only store YYYY-mm-dd HH:MM:SS precision. There is no way to specify the timezone along with a date. This means unless you create a second column to store the timezone offset or name, you will have no indication of the timezone of your date in the database.

DATE, DATETIME, and TIMESTAMP types

The MySQL DATE and DATETIME types do not store timezone values. It is recommended to use the TIMESTAMP type for maximum flexibility, because these values are converted to UTC before storage, and converted from UTC to the current timezone on retrieval.

MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.) By default, the current time zone for each connection is the server's time. The time zone can be set on a per-connection basis. As long as the time zone setting remains constant, you get back the same value you store. If you store a TIMESTAMP value, and then change the time zone and retrieve the value, the retrieved value is different from the value you stored. This occurs because the same time zone was not used for conversion in both directions. The current time zone is available as the value of the time_zone system variable.

— http://dev.mysql.com/doc/refman/5.5/en/datetime.html

Fulltext Search ignores words shorter than 4 characters

This restriction [1] makes searches for TLAs not possible using fulltext searching. If the length of the entire query is less than 4 characters the fulltext search can be replaced with a case-insensitive LIKE match, but this still lessens the accuracy of queries longer than 4 characters with significant terms shorter as they will be ignored.

Stopwords

MySQL has a default list of stopwords that will not be used in full-text searches. This can and has caused problems with the IndieWebCamp wiki search when searching for simple words.

List of MySQL stopwords

How to disable stopwords

Stopwords can be disabled in a MySQL server by doing the following:

Add the following to your /etc/my.cnf file (or wherever that file is)

ft_stopword_file = ""
ft_min_word_len=3

Restart mysql. Usually something like sudo service mysqld restart
Rebuild the index for any tables you are searching. In the case of MediaWiki, this is the "searchindex" table: mysql -u root -e 'REPAIR TABLE searchindex QUICK;'

Lacks Full UTF-8 Support

MySQL's utf8 character encoding only partially implements UTF-8. It can only store one- to three-byte characters and cannot store four-byte characters. Instead, the utf8mb4 encoding (available since MySQL 5.5.3) should be used. See How to support full Unicode in MySQL databases for more information.

Unhappy with non-ASCII input

unfortunately mysql doesn't seem to happy with my kanji input

- Ben Roberts[2] (2014-10-16)

fwiw I had a similar MySQL encoding problem and it barfed on a emdash! luckily only 1 entry needed to be re entered. [...] it refused the emdash as an entry in the DB because it could not be encoded in latin whatever

- Kartik Prabhu[3] (2014-10-16)