Можно использовать - опция игнорировать-таблицы . Таким образом, Вы могли сделать
mysqldump -u USERNAME -pPASSWORD DATABASE --ignore-table=DATABASE.table1 > database.sql
нет никакого пробела после -p
(это не опечатка).
, Если Вы хотите проигнорировать несколько таблиц, можно использовать простой сценарий как это
#!/bin/bash
PASSWORD=XXXXXX
HOST=XXXXXX
USER=XXXXXX
DATABASE=databasename
DB_FILE=dump.sql
EXCLUDED_TABLES=(
table1
table2
table3
table4
tableN
)
IGNORED_TABLES_STRING=''
for TABLE in "${EXCLUDED_TABLES[@]}"
do :
IGNORED_TABLES_STRING+=" --ignore-table=${DATABASE}.${TABLE}"
done
echo "Dump structure"
mysqldump --host=${HOST} --user=${USER} --password=${PASSWORD} --single-transaction --no-data --routines ${DATABASE} > ${DB_FILE}
echo "Dump content"
mysqldump --host=${HOST} --user=${USER} --password=${PASSWORD} ${DATABASE} --no-create-info --skip-triggers ${IGNORED_TABLES_STRING} >> ${DB_FILE}
Вам определенно следует избегать AJAX, если вы уверены, что ваши клиенты будут использовать браузеры без поддержки JavaScript
Я обычно вижу это на сайтах автомобилей, где есть марки и модели. Их обычные
(без JavaScript) включают в себя
как таковые:
<select>
<optgroup label="Ford">
<option value="21">Escape</option>
<option value="21">F-150</option>
</optgroup>
<optgroup label="Toyota">
<option value="51">Corolla</option>
<option value="52">Yaris</option>
</optgroup>
</select>
Затем обычно затем скрывают это
и создайте 2 новых выбора, один для марок и один для моделей.
На этом этапе все в порядке. Здесь они начинают путаться.
Затем они обрабатывают запрос к серверу, чтобы получить список производителей, а затем выполняют другой запрос, чтобы получить список моделей, когда они могут просто проанализировать исходный элемент и попытаться получить свою информацию. Затем каждый раз, когда вы меняете make, выполняется другой запрос ...
Вышеупомянутое - отличный пример того, когда НЕ использовать AJAX. Учти это: запрос длиннее, чем анализ доступных данных, поэтому они заставляют пользователя ждать. Они, вероятно, каждый раз запрашивают свою базу данных, поэтому это сказывается на использовании ЦП сервера. И это требует большей пропускной способности. Ужасная трата ресурсов.
Им следовало просто проанализировать попытку DOM под
, чтобы получить соответствующую информацию. Каждый
- это элемент в процессе создания
, а каждый дочерний элемент
из
является элемент в моделях
.
Фактически, AJAX должен использоваться для улучшения взаимодействия с пользователем. Если нет, то Flash или что-то еще.
Естественно, если нет возможности улучшения, нет причин идти по этому пути. Я считаю это маловероятным. Если вы найдете такой случай, напишите об этом в блоге: вероятно, будет интересно прочитать.
Конечно, бывают ситуации, когда AJAX противопоказан. В основном, когда у вас нет людей, использующих сайт. Если вы ожидаете, что сайт будет работать с ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ, управляющим запросами, вы должны убедиться, что он работает нормально без AJAX.
А если вы этого не сделаете. Не ожидая, что программное обеспечение будет управлять запросами, я очень надеюсь, что у вас есть для него альтернативный API, который может делать все, что может сайт. В противном случае вы просто обманываете себя и подводите своих клиентов.
Если ваше время разработки ограничено или ваша команда не имеет достаточного опыта, вы можете убедительно отказаться от программирования AJAX.
[вызовы AJAX] не более или менее безопасны чем выдан обычный запрос HTTP POST браузером, как в -form -.
"Исправление" для этого - то же самое "исправление" для запросов, отличных от AJAX, используйте SSL.
Я часто слышу это - просто потому, что вы можете сделать это красиво с помощью Ajax, не означает, что вы должны.
Я не Я не думаю, что вам обязательно следует отложить UI на второй план. Это не должно быть последним, о чем вы думаете, особенно в определенных случаях.
Пользовательский интерфейс - это то, что видит пользователь - они не видят никакой сложности, стоящей за ним, поэтому они будут судить о качестве вашего сайта / application в зависимости от того, насколько легко им пользоваться и насколько это важно для них.
Имея это в виду, выберите Ajax на основе точки зрения пользователя. Имеет ли смысл, что когда я нажимаю на эту кнопку, страница скользит влево, открывая новый раздел? Будет ли меня утешать или сбивать с толку, когда страница отображается серым цветом, а перед ней отображается изображение «Работает ...»?
При перенаправлении пользователя на новую страницу, которую пользователь может захотеть добавить в закладки, т. Е. Если щелчок по ссылке вызывает контент, который нужно обновить с помощью AJAX, пользователь не может добавить страницу в закладки.
Возможно, AJAX подвергает больше угроз безопасности сайту / приложению из-за UX. Может быть, у вас есть другие причины не использовать AJAX.
Как? Какие угрозы безопасности?
Следует избегать использования AJAX, если та же функциональность может быть реализована полностью на стороне клиента без дополнительного обращения к серверу.
Например, это может быть больше Эффективно заполнить клиента списком почтовых индексов для всех штатов США и выбрать соответствующий набор почтовых индексов вместо обращения к серверу за списком действительных почтовых индексов для данного штата.