Когда вы должны использовать InnoDB в MySQL?
Вы можете использовать инструментарий, то есть следующий код, вызванный onCreate вашей активности, заставит меню открываться и закрываться несколько раз:
new Thread(new Runnable() {
@Override
public void run() {
try {
Instrumentation inst = new Instrumentation();
for ( int i = 0; i < 10; ++i ) {
inst.sendKeyDownUpSync(KeyEvent.KEYCODE_MENU);
Thread.sleep(2000);
inst.sendKeyDownUpSync(KeyEvent.KEYCODE_BACK);
Thread.sleep(2000);
}
}
catch(InterruptedException e){
}
}
}).start();
... но я не уверен, что это что вы после
9 ответов
InnoDB - это механизм хранения в MySQL . Их довольно много, и у всех есть свои плюсы и минусы. Самые сильные стороны InnoDB:
- Поддержка транзакций (поддержка свойства ACID ).
- Блокировка на уровне строк. Наличие более детализированного механизма блокировки обеспечивает более высокий уровень параллелизма по сравнению, например, с MyISAM .
- Ограничения внешнего ключа. Позволяя вам позволить базе данных обеспечивать целостность состояния базы данных и взаимосвязи между таблицами.
Всегда. Если вам не нужно использовать полнотекстовый поиск MySQL или InnoDB отключен на вашем общем веб-хосте.
В вашем примере вы создаете внешние ключи. Внешние ключи поддерживаются только для таблиц InnoDB, но не для таблиц MyISAM.
Везде! Устарели myisam, innodb - лучший вариант. Речь идет не только о производительности, но и о целостности данных и важных транзакциях.
В целом для меня наиболее важным моментом является то, что InnoDB предлагает блокировку по строкам, тогда как MyISAM ищет по таблице. На больших таблицах с большим количеством операций записи это может вызвать большие проблемы с производительностью.
С другой стороны, таблица MyISAM имеет более простую файловую структуру, копирование и восстановление таблицы на уровне файла намного проще.
В комментарии есть команда для преобразования ваших баз данных в InnoDB здесь.
Вам может быть интересна эта статья из базы данных Журнал, в котором обсуждается тип таблицы InnoDB в MySQL.
Выдержка:
В прошлом месяце мы рассмотрели таблицу HEAP type, тип таблицы, который выполняется полностью в памяти. В этом месяце мы смотрим на настройка типа таблицы InnoDB, тип наиболее интересный для серьезных пользователей. Стандартный тип таблицы MyISAM идеально подходит для использования на сайте, где есть много чтений по сравнению с пишет, а транзакций нет. куда эти условия не применяются (и кроме веб-сайтов они не применяются часто в мире баз данных) Таблица InnoDB, скорее всего, будет таблицей тип выбора. Эта статья предназначена у пользователей, знакомых с MySQL, но использовали только MyISAM по умолчанию тип таблицы.
Другой вопрос меня бы не отпустил. Сохраняйте надлежащие резервные копии вашей базы данных любого типа - и не удаляйте таблицы случайно ;-) - и все будет в порядке, какой бы тип таблицы вы ни выбрали.
Дополнение к Machine и ответ knoopx о транзакциях:
MySQL по умолчанию тип таблицы MyISAM не поддерживает транзакции. BerkeleyDB и InnoDB безопасные для транзакций типы таблиц доступно в MySQL с открытым исходным кодом, версия 3.23.34 и выше.
Определение транзакции и пример банковского обслуживания
Транзакция - это последовательность отдельные операции с базой данных, которые сгруппированы вместе. -- Хороший пример, когда транзакции полезны занимается банковским делом.
Я думаю, вы запутались в двух разных вопросах, когда использовать InnoDB вместо MyISAM, и когда использовать ограничения внешнего ключа (FK).
Что касается первого вопроса, было много ответов, которые отлично объясняют различия между MyISAM и InnoDB. Я просто повторю, что, согласно цитате tvanfosson из статьи, MyISAM лучше подходит для системы с преимущественно чтением. Это потому, что он использует блокировку на уровне таблиц, а не на уровне строк, как InnoDB, поэтому MyISAM не может справиться с высоким параллелизмом, плюс ему не хватает функций, которые помогают обеспечить целостность данных, таких как транзакции и внешние ключи (опять же, уже упомянутые другими).
Вам не обязательно использовать FK-ограничения в вашей модели данных. Если вы знаете, какие отношения существуют между таблицами, и в вашем приложении нет ошибок, то вы прекрасно обойдетесь без FK. Однако использование FK дает вам дополнительную страховку на уровне базы данных, потому что в этом случае MySQL не позволит вашему приложению вставить некачественные данные, основанные на созданных вами ограничениях.
Если вам не ясно, зачем использовать первичные ключи (PK), то если сделать столбец, например id_order, PK таблицы orders, то MySQL не позволит вам INSERT одно и то же значение id_order более одного раза, потому что каждая строка в столбце PK должна быть уникальной.
FK будет использоваться в таблице, которая имеет зависимость от другой таблицы, например, order_items будет иметь зависимость от orders (ниже). id_order_items является PK таблицы order_items, и вы можете сделать id_order_items FK таблицы orders, чтобы установить связь один-ко-многим между orders и order_items. Аналогично, id_item может быть FK в таблице order_items и PK в таблице items для создания отношения "один-ко-многим" между order_items и items.
**Тогда ограничение FK не позволит вам добавить значение id_item в таблицу order_items, которого нет в таблице itemsили добавить значение id_order_itemsв ordersкоторого нет в таблице order_items.
Все, что делает FK, это обеспечивает целостность данных, а также помогает передать отношения между таблицами другим разработчикам, которые не писали систему (и вам самим спустя месяцы, когда вы забудете об этом!), но в основном это для целостности данных.**
Дополнительный кредит: так зачем нужны транзакции? Ну, вы уже упомянули цитату, в которой говорится, что они полезны для банковской системы, но они полезны в гораздо большем количестве ситуаций, чем это.
В принципе, в реляционной базе данных, особенно если она нормализована, рутинная операция, такая как добавление заказа, обновление заказа или удаление заказа, часто затрагивает более одной таблицы и/или включает более одного оператора SQL. Вы даже можете в конечном итоге коснуться одной и той же таблицы несколько раз (как в примере ниже). Btw операторы языка манипулирования данными (DML) (INSERT/UPDATE/DELETE) задействуют только одну таблицу за раз.
Пример добавления заказа:
Я рекомендую создать таблицу orders и таблицу order_items. Это позволит вам иметь PK на id_order в таблице orders, что означает, что id_order не может повторяться в orders. Без отношения "один ко многим" orders - order_items вам пришлось бы иметь несколько строк в таблице orders для каждого заказа, с которым связано несколько товаров (для этой системы электронной коммерции вам также нужна таблица items). В этом примере мы добавим заказ и затронем при этом 2 таблицы с помощью 4 различных операторов INSERT.
(без ключевых ограничений в целях иллюстрации)
-- insert #1
INSERT INTO orders (id_order, id_order_items, id_customer)
VALUES (100, 150, 1)
-- insert #2
INSERT INTO order_items (id_order_items, id_item)
VALUES (4, 1)
-- insert #3
INSERT INTO order_items (id_order_items, id_item)
VALUES (4, 2)
-- insert #4
INSERT INTO order_items (id_order_items, id_item)
VALUES (4, 3)Итак, что если запросы insert #1 и insert #2 выполнились успешно, а insert #3 - нет? В итоге вы получили бы заказ, в котором не хватает товара, и это были бы мусорные данные. Если в этом случае вы хотите откатить все запросы, чтобы база данных была в том же состоянии, в котором она была до добавления заказа, а затем начать все сначала, то именно для этого и нужны транзакции. **Вы объединяете запросы, которые вы хотите либо выполнить все, либо, в случае исключения, вообще не выполнять, в транзакцию.
Так же, как и ограничения PK/FK, транзакции помогают обеспечить целостность данных.**