Что лучший способ состоит в том, чтобы обновить (или замена) всю таблицу базы данных на живой машине?

Question

Что лучший способ состоит в том, чтобы обновить (или замена) всю таблицу базы данных на живой машине?

Чтобы получить все элементы формы:

$.each($('form').serializeArray(), function(index, value){
    $('[name="' + value.name + '"]').attr('readonly', 'readonly');
});

8

mysql database postgresql

задан pts 23 May 2009 в 21:26

6 ответов

BEGIN;
DELETE FROM TABLE;
INSERT INTO TABLE;
COMMIT;

Пользователи сразу же увидят переключение, когда вы нажмете фиксацию. Любые запросы, запущенные до фиксации, будут выполняться для старых данных, все последующие запросы будут выполняться для новых данных. База данных фактически очистит старую таблицу после того, как последний пользователь закончит с ней работу. Поскольку все "статично" (вы единственный, кто когда-либо меняет это, и только раз в неделю), вам не нужно беспокоиться о проблемах с блокировкой или тайм-аутах. Для MySQL это зависит от InnoDB. PostgreSQL делает это, а SQL Server называет это «моментальным снимком», и я не могу вспомнить подробности, потому что я редко использую эту вещь.

Если вы погуглите «изоляция транзакции» + имя любой базы данных вы найдете соответствующую информацию.

3

ответ дан 5 December 2019 в 12:12

Мы решили эту проблему, используя механизм наследования / ограничений таблиц PostgreSQL. Вы создаете триггер, который автоматически создает подтаблицы, разделенные на разделы на основе поля даты.

Эта статья была источником, который я использовал.

2

ответ дан 5 December 2019 в 12:12

Какой сервер базы данных вы используете? SQL 2005 и более поздние версии предоставляют метод блокировки под названием «Снимок». Это позволяет вам открыть транзакцию, выполнить все ваши обновления, а затем зафиксировать, пока пользователи базы данных продолжают просматривать данные до транзакции. Обычно ваша транзакция блокирует ваши таблицы и их запросы, но в вашем случае идеально подойдет блокировка моментальных снимков.

Подробнее здесь: http://blogs.msdn.com/craigfr/archive/2007/05 /16/serializable-vs-snapshot-isolation-level.aspx

Но для этого требуется SQL Server, поэтому, если вы используете что-то еще ....

1

ответ дан 5 December 2019 в 12:12

Некоторые системы баз данных (так как вы не указали свою, я оставлю это общее) предлагают стандартный оператор SQL: 2003 под названием MERGE , который в основном позволит вам чтобы

вставить новые строки в целевую таблицу из источника, которого там еще нет
обновить существующие строки в целевой таблице на основе новых значений из источника
, возможно, даже удалить строки из целевой таблицы, которые не больше не отображается в таблице импорта.

SQL Server 2008 - первое предложение Microsoft, в котором есть этот оператор - подробнее см. здесь , здесь или здесь .

Другая система баз данных, вероятно, будет иметь аналогичные реализации - в конце концов, это стандартная инструкция SQL: 2003.

Marc

1

ответ дан 5 December 2019 в 12:12

Используйте разные имена таблиц (mytable_ [yyyy] _ [wk]) и представление для предоставления вам постоянного имени (mytable). После того, как новая таблица будет полностью импортирована, обновите ваше представление, чтобы оно использовало эту таблицу.

1

ответ дан 5 December 2019 в 12:12

Другие вопросы по тегам:

mysql database postgresql

Похожие вопросы:

score 6 · Accepted Answer

Я не могу говорить о MySQL, но PostgreSQL имеет транзакционный DDL. Это замечательная функция, и это означает, что ваш второй вариант, загрузка новых данных в фиктивную таблицу и затем выполнение переименования таблицы, должен работать отлично. Если вы хотите заменить таблицу foo на foo_new , вам нужно только загрузить новые данные в foo_new и запустить сценарий для выполнения переименования. Этот сценарий должен выполняться в отдельной транзакции, поэтому, если что-то с переименованием пойдет не так, как foo , так и foo_new останутся нетронутыми при откате.

Основная проблема с этим подходом состоит в том, что обработка внешних ключей из других таблиц, имеющих ключ на foo , может стать немного запутанной. Но, по крайней мере, вам гарантировано, что ваши данные останутся согласованными.

Я думаю, что в долгосрочной перспективе лучший подход - это просто выполнять обновления данных напрямую (ваш первый вариант). Еще раз, вы можете поместить все обновления в одну транзакцию, так что вам будет гарантирована семантика «все или ничего». Еще лучше было бы онлайн-обновления, просто обновляя данные напрямую по мере появления новой информации. Возможно, это не вариант для вас, если вам нужны результаты чьего-либо пакетного задания, но если вы можете это сделать, это лучший вариант.

Я думаю, что в долгосрочной перспективе лучший подход - это просто выполнять обновления данных напрямую (ваш первый вариант). Опять же, вы можете поместить все обновления в одну транзакцию, так что вам будет гарантирована семантика «все или ничего». Еще лучше было бы онлайн-обновления, просто обновляя данные напрямую по мере появления новой информации. Возможно, это не вариант для вас, если вам нужны результаты чьего-либо пакетного задания, но если вы можете это сделать, это лучший вариант.