Нужен совет от опытных проектировщиков БД и программистов

это вы сейчас о чем?

максимальный размер таблиц(хотя фактически файлов данных) в innodb МЕНЬШЕ чем в myisam, в чем можно невозбранно убедиться ознакомившись с документацией :

http://dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html Storage limits 256TB
http://dev.mysql.com/doc/refman/5.1/en/innodb.html - Storage limits 64TB

При том что таблицы в myisam насильно разбиваются на файлы, а innodb по-умолчанию в одном файле хранит данные таблиц.

Насильно не насильно, а я разбиваю через конфиг. Это раз.

С размером немного лишка хватил - это да, просто раньше размер myisam ограничивался сильно, зависел от размера файла.

Что касается непосредственно работы с myisam и инодб, то могу сказать следующее. Если система здоровая. много связанных таблиц, то лучше использовать innodb. Во-первых внешние ключи поддерживает, во вторых транзакции. То есть в любой момент можно откатить транзакцию. Иногда это спасает от последствий. Что касается скорости записи в инодб, то её можно значительно ускорить, если несколько инсертов пихать в одну транзакцию.

Далее, что касается типа merge. А именно минусы.

Для создания таблицы MERGE можно использовать только идентичные таблицы MyISAM.

Столбцы AUTO_INCREMENT не обновляются автоматически при применении команды INSERT.

Не работает команда REPLACE.

Для таблиц MERGE используется больше дескрипторов файлов. Если применяется таблица MERGE, преобразованная из более чем 10 таблиц, к которым получают доступ 10 пользователей, то используется 10*10 + 10 дескрипторов файлов (10 файлов данных для 10 пользователей и 10 общих индексных файлов).

Ключи считываются медленнее. При чтении ключа обработчику MERGE необходимо прочитать все базовые таблицы, чтобы выяснить, какая из них больше всего соответствует указанному ключу. Если после этого выполнить команду ``читать следующий'', то обработчик объединенной таблицы должен будет просмотреть буферы чтения, чтобы найти следующий ключ. Только по завершении использования одного буфера ключей обработчику понадобится прочитать следующий блок ключей. В связи с этим ключи MERGE дают большое замедление при поиске eq_ref, однако не такое значительное при поиске ref.

Нельзя выполнять команды DROP TABLE, ALTER TABLE или DELETE FROM table_name без оператора WHERE по отношению к таблицам, которые размещены в таблице MERGE и открыты. Если это сделать, в таблице MERGE останутся ссылки на исходную таблицу, и полученные результаты будут совершенно непредсказуемыми.

мне сразу это злом каким то показалось )))

ладно, сколько блином комом будет еще на пути к прогрессу!

Я это давно читал, просто сейчас очень сильно пришлось моцк напряч и вспомнить где я это читал, ибо столько писать не очень горю желанием, так как за день написался :)))

:)

милая шутка под конец рабочих суток)

Thats right, мы рассматриваем решения применительно к конкретной задаче - хранению комментариев. Для этой цели некоторым неудобством можно считать разве что отсутствие autoincrement. Отсутствие поддержки реплейсов, дропов и альтер тейблов не представляю в каких ситуациях может сыграть роль именно для комментариев. Про ключи: вся канитель затевается при условии наличия большого количества записей, а при этом быстрее будет сперва выборка подходящей таблицы (физически), а уже потом выборка по этой относительно небольшой таблице. Подумал, выгоднее в плане быстродействия делать разбивку по разделу комментируемого топика, нежели по дате коммента.

я так же подумал, честно честно ))

bearman добавил 06.02.2010 в 23:56

а вообще, без тестов - все это просто флуд :)

А я что сказал ещё кажись на третьей странице - берем железку и гоняем по полной. :)))

я про болт подумал ...

мое дурное университетское воспитание сказалось :)))) там я часто болт гонял по полной :D

обычно в веб-строительстве транзакций НЕТ, поскольку в самом протоколе http и механизмах загрузки сайта транзакционности не предусмотрено. Есть просто серии никак не связанных запросов.

НЕТ. сервер открывает файлы сам. при подключении еще одного пользователя повторно файлы не открываются