Я и не холиварю, я стараюсь использовать оба типа таблиц.
MyISAM хорошо подходит для материализованных представлений, которые обновляются раз в n-ное количество минут/часов/дней.
InnoDB отлично подходит для таблиц с конкурирующими чтением/записью, а также там где нужна надёжность и удобство поддержания целостности (то есть почти везде).
P.S. COUNT(*) не намного меньшее зло чем SELECT *. COUNT надо делать по используемому оптимизатором ключу (полю находящимся в этом ключе на первом месте, если ключ составной).
Про класс никто ничего и не говорил, расширение mysql достаточно старое и не тысячу лет не обновлялось, о транзакциях, как и о много другом, оно даже не догадывается.
P.S. Из мануала:
If you are using MySQL versions 4.1.3 or later it is strongly recommended that you use the mysqli extension instead.
.
Сколько лет версии PHP 4.1.3 можно посчитать самому.
Для уменьшения места, надо убить все таблицы InnoDB из всех баз и файл idbdata*, после чего заимпортить их снова. А для разбиения одной базы на несколько файлов (со сменой режима) достаточно убить только выбранную базу, AFAIK.
MyISAM фрагментируется в основном от DELETE и изредка после UPDATE; MyISAM можно дефрагментировать командой OPTIMIZE, которая работает быстрее чем ALTER TABLE `name` ENGINE = InnoDB;
С Ораклом работать не довелось, а вот горький опыт на ИнноДБ есть. Особенно печален тот факт что для перевода БД из режима «один файл» в режим «много файлов» помимо переключения настройки, нужно делать полный дамп базы дропать её, и восстанавливать из бекапа, что сделать на живом сервере весьма проблематично ибо базы данных нельзя переименовывать :(
Лучше TINYINT, ибо у ENUM всегда есть крошечный, но всё-же оверхед на выбор значения соответствующего строке.
Еще можно добавить что если нужно хранить много полей типа булеан, то их можно объединять в один *INT* и выбирать по битовой маске сразу несколько значений, например, те же правда на чтение/запись). В случае с ENUM это уже неудобно, а тип SET имеет очень много ограничений и неудобств в работе.
Еще рекомендую не экономить на спичках (еще один холивар?), давать запас IDшкам на следующие много-много лет и не надеятся на то, что лимит MEDIUMINT будет достигнут не раньше чем через 3 года.
Практика показывает, что за 2-3 года про ограничение уже никто не помнить (а может уже и некому будет помнить) и начинаются непонятные проблемы, причину которых найти не всегда просто, да и данных можно потерять вагон с небольшой тележкой.
Что действительно стоит добавить, так это:
Для таблиц InnoDB надо добавлять --single-transaction, это гарантирует целостность данных бекапа. Для таблиц MyISAN это не актуально, ибо они не поддерживают транзакционность.
Сомневаюсь, что кто-то из них читает хабр.
P.S. Как скоро на хабре появятся пятничные сиськи?
Если нужно сделать дам нескольких таблиц
MyISAM хорошо подходит для материализованных представлений, которые обновляются раз в n-ное количество минут/часов/дней.
InnoDB отлично подходит для таблиц с конкурирующими чтением/записью, а также там где нужна надёжность и удобство поддержания целостности (то есть почти везде).
P.S. COUNT(*) не намного меньшее зло чем SELECT *. COUNT надо делать по используемому оптимизатором ключу (полю находящимся в этом ключе на первом месте, если ключ составной).
P.S. Из мануала:.
Сколько лет версии PHP 4.1.3 можно посчитать самому.
Еще можно добавить что если нужно хранить много полей типа булеан, то их можно объединять в один *INT* и выбирать по битовой маске сразу несколько значений, например, те же правда на чтение/запись). В случае с ENUM это уже неудобно, а тип SET имеет очень много ограничений и неудобств в работе.
Практика показывает, что за 2-3 года про ограничение уже никто не помнить (а может уже и некому будет помнить) и начинаются непонятные проблемы, причину которых найти не всегда просто, да и данных можно потерять вагон с небольшой тележкой.
Вариант с TINYINT(1) самый удобный.
Для таблиц InnoDB надо добавлять --single-transaction, это гарантирует целостность данных бекапа. Для таблиц MyISAN это не актуально, ибо они не поддерживают транзакционность.