Решил немного расширить предыдущую статью про ASP.NET MVC и MySQL. В ней речь шла про работу с MySQL в ASP.NET MVC не через практически стандартный ORM Entity Framework (EF), а с помощью прямого доступа к СУБД через ADO.NET. И была приведена реализация этого метода доступа. И хотя метод устаревший и не рекомендуемый к использованию, но иногда полезен: например, в высоконагруженных приложениях или когда разработчик сталкивается с ситуацией, когда ORM не может сгенерировать корректно работающий SQL-запрос. И иногда можно совмещать в приложении оба способа — и через ORM и через ADO.NET. В итоге я подумал, и решил дописать приложение: добавив в него реализацию репозитория для Entity Framework и сделать выбор из них зависимым от параметра приложения с помощью Dependency Resolver.

Весь код можно взять вот по этому адресу, ниже этот код будет частично презентован с небольшими ссылками и пояснениями по отношению к предыдущему проекту. А здесь можно посмотреть на работу приложения.

Уже, наверное, раза три подбираюсь к ASP.NET MVC. После десяти лет с ASP.NET WebForms немного сложно переходить именно к технологии MVC, поскольку отличий столько, что скорее проще перечислить, что у этих технологий общего – это разве что библиотеки .NET Framework. Я не буду писать тут – лучше или хуже MVC чем WebForms, просто они обе хороши, и на обеих технологиях можно построить хорошее приложение. Свои мысли по поводу необходимости TDD я тоже пока оставлю при себе, хотя их есть у меня.

А сейчас я буду говорить о стандартнейшей задаче – обычной работе с данными: просмотре в табличном виде списка записей, добавлении, изменении и удалении данных (операции CRUD). Однако практически во всех книгах и во многих решениях в интернете для ASP.NET MVC почему-то рассматривается вариант исключительно через ORM (Object Relation Mapping): или Entity Framework (EF) или LINQ для SQL. Технологии отличные, спору нет, наконец-то программист может и не разбираться – а как вообще эта самая реляционная СУБД (которой он, скорее всего, пользуется) вообще работает, и даже SQL, по идее, знать уже необязательно: прокладка в виде EF и коннектора для СУБД разберутся между собой. «Вот оно счастье – нет его краше». Но тем программистам, которые не боятся прямой работы с базой данных через механизм ADO.NET, зачастую непонятно – а с чего вообще начинать в ASP.NET MVC и надо ли.

Дважды с проектом Hattrick Portal попадал в ситуацию «потери» файлов собственной базы MySQL (mysql) — СУБД переставало работать и рапортовало о том, что в первом случае таблицы innodb_index_stats, innodb_table_stats, slave_master_info потеряны, а во втором, что таблицы servers и plugin. Объединяет эти два случая одно — эти таблицы на движке InnoDB. Если раньше все таблицы системной БД mysql были на движке MyISAM, то постепенно MySQL переводит все в InnoDB. С чем связаны были проблемы выяснить не удалось, но нужно было срочно восстанавливать работу СУБД. Быстрое гугление показало один простой вариант — прибиваем все файлы данных, запускаем СУБД с пустыми каталогами данных (она создает их по умолчанию), затем восстанавливаем всё из бэкапа. Но восстановить из бэкапа 10 Гб данных — это долгий процесс. И причем ещё — нужные данные-то у меня все на месте и не пострадали!

Продолжу описывать конкретные ситуации, с которыми доводилось сталкиваться при работе с MySQL, и эта статья про резервирование БД на сервере под управлением Windows для проекта Hattrick Portal. Не буду подробно останавливаться на всех существующих инструментах резервирования MySQL, просто вкратце обозначу мои причины выбора утилиты mysqldump:

• я использую движок MySQL InnoDB (а значит mysqlhotcopy не подходит);
• она бесплатна и входит в поставку СУБД («горячее» снятие снэпшотов для InnoDB я не видел в бесплатном варианте, да и нужно оно в основном для быстрого переноса данных);
• я снимаю бэкап всей БД (для отдельных таблиц есть операторы SELECT INTO OUTFILE и LOAD DATA INFILE);
• может работать при работающей СУБД;
• отставание бэкапа на день для меня не принципиально (т.е. инкрементные бэкапы не требуются);
• даёт вполне понятный и разбираемый текстовый файл, который может пригодиться не только для восстановления БД.

Хочу сделать несколько заметок по MySQL, чтобы сохранить для себя информацию, а заодно ей поделиться со всеми. Информации в интернете по этим темам, конечно, полно, пусть будет ещё.

Я надеюсь, что все кто использует MySQL как реляционную СУБД для больших и нагруженных баз данных использует движок InnoDB. MyISAM я бы не стал для этого использовать, всё-таки скорость обновлений (из-за блокировки таблицы вместо строки) и отсутствие транзакций не подразумевает использование этого движка для чего-то кроме мелких проектов. Единственный плюс, из-за которого для системы электронного документооборота «Визирь» я использовал базу данных на движке MyISAM — это полнотекстовый поиск, в InnoDB он штатно не был предусмотрен.

Для перевода таблиц на движок InnoDB можно выполнить команду (но перед этим лучше прочитать статью целиком):

ALTER TABLE tablename​ ENGINE = InnoDB;