| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Базы Данных > Алгоритм синхронизации данных формы с таблицей |
| Автор: maxipub 3.3.2016, 18:05 |
| Добрый день! Есть таблица с первичным ключом (ключ на самом деле составной: user_id, some_key) и неким набором данных (десяток int полей). Скрипт получает произвольное количество наборов в виде: some_key => some_data (по сути каждый такой набор - это одна строка в таблице). Эти входные данные могут как на 100% соответствовать данным в таблице, так и иметь некоторые различия: - могут появиться новые строки; - могут пропасть существующие; - для существующих ключей могут поменяться данные. По какому алгоритму лучше актуализировать таблицу, чтобы в ней сохранилось ровно то, что мы получили на входе? У меня два приоритетных варианта. 1. Добавляем в таблицу поле `updating` TINYINT NOT NULL DEFAULT '0', при получении скриптом запроса на актуализацию данных, устанавливаем для записей нашего user_id поле updating=1, затем делаем INSERT ODKU с установкой updating=0 в обоих случаях, и в финале удаляем все, где updating=1 для нашего user_id. 2. Тупо удаляем все, и сразу же заносим все полученные данные в таблицу, т.е. DELETE всех записей пользователя, и затем INSERT всех данных. Как лучше быть? Может быть, есть более цивилизованный вариант? Как бы поступили вы? В таблице 1млн строк. Около 90% всех запросов скрипту приходят без изменения данных, каждый из них содержит 10-20 наборов данных (строк в таблице). |
| Автор: ksnk 3.3.2016, 18:56 | ||||
| Тоесть, приходит запись, на объект (objectID) со свойствами, каждое свойство занимает одну строку таблицы? Таблица, грубо говоря, состоит из строк [objectID, propertyID, Value]. objectID + propertyID - составной уникальный ключ. Перед записью нужно прочитать список свойств изменяемого объекта и вычислить, какие свойства будут удалены. Мастерим запрос, если надо, примерно такой
Для каждого свойства мастерим запрос insert-update
Итого - нужно прочитать список старых свойств и выполнить пачку запросов. Так можно избавиться от временного поля, правда за счет дополнительного ума при расчете удаляемых полей. |
| Автор: maxipub 4.3.2016, 11:59 |
| ksnk, спасибо за вариант. Честно говоря, надеялся что есть все же какое-то системное, а не алгоритмическое решение. Буду думать. Тоже вариант, но мне мой первый ближе по пониманию происходящего. |
| Автор: DavidBelov 4.3.2016, 20:10 |
| Так если ближе, чего его и не использовать? |
| Автор: maxipub 7.3.2016, 12:05 | ||
DavidBelov,
|