вставка новых записей
типа отак pole1 NOT IN (select pole1 FROM <таблица основной БД>) AND
pole2 NOT IN (select pole2 FROM <таблица основной БД>);
Вопрос касается dotNET?
Мой шар телепатии никак не может дать информаци о Вашей СУБД.
В общем случае можете вопользоваться репликацией или изобрести велосипед..
-это касается dotNET потому-что прогу пишу на С#
- Вставлять надо новые записи. Грубо говоря в основной БД есть старые записи, а в промежуточной БД есть и старые и новые записи, нужно вставить в основную БД только новые записи.
У Вас, товарищ, что-то с архитектурой...
У Вас, товарищ, что-то с архитектурой...
Та ясное море что лучше было б MS использовать. Но просто с этой базой потом другая прога работает, поэтому и приходится исп. My.
В смысле "что-то с архитектурой" ? с архитектурой чего ?
:rolleyes:
С архитектурой БД, и не MySQL тому виной.
Попробуйте ответить на следующий вопросы:
1) Почему нельзя использовать одну БД
2) Если нельзя, то нужно разработать схему распределённого хранилища.
Больше ничего сказать не могу - попробуйте сформулировать вопрос менее абстрактно.
начения ключа будет сгенерированна ошибка которую обрабатываете
с помощью блока try{}catch{}
С архитектурой БД, и не MySQL тому виной.
Попробуйте ответить на следующий вопросы:
1) Почему нельзя использовать одну БД
2) Если нельзя, то нужно разработать схему распределённого хранилища.
Больше ничего сказать не могу - попробуйте сформулировать вопрос менее абстрактно.
Дело в том что:
1) структуру БД разрабатывал не я
2) эту БД и до и после моей проги использует другое ПО, которое заточено имеено под архитектуру этой БД... так что работать приходится с тем что есть.
Насчет того что нельзя использовать одну БД:
Просто в ту БД, что находится на сервере тоже могут приходить данные по gps. И что бы (а) повысить скорость работы (б)ничего сулчайно не запортить в базе на серваке (в) чтоб не ... себе мозг лишними сложностями :) (если вдруг одновременно данные будут приходить и по gps и из клиентских баз). А так получается все просто и красиво:
- данные с клиентов пришли в промежуточную базу;
- удалили однинаковые записи в промежуточной базе;
- из промежуточной базы удалили записи, которые уже есть в основной;
- и потом все что осталось вставили в основную базу.
таким образом вставка в основную базу происходит только один раз...
1) структуру БД разрабатывал не я
2) эту БД и до и после моей проги использует другое ПО, которое заточено имеено под архитектуру этой БД... так что работать приходится с тем что есть.
С этим ясно. Вопросов нет.
- удалили однинаковые записи в промежуточной базе;
- из промежуточной базы удалили записи, которые уже есть в основной;
- и потом все что осталось вставили в основную базу.
таким образом вставка в основную базу происходит только один раз...
Интересно, как ты будешь проверять разность множеств (Кл. БД - Сер. БД), если использовать подобную схему, это здорово скажется на производительности.
Почему нельзя сразу на сервере в процедуру вставки добавить логику проверки существования аналогичной записи?
Интересно, как ты будешь проверять разность множеств (Кл. БД - Сер. БД), если использовать подобную схему, это здорово скажется на производительности.
Почему нельзя сразу на сервере в процедуру вставки добавить логику проверки существования аналогичной записи?
Не совсем понял фразу "проверять разность множеств (Кл. БД - Сер. БД)" Это всмысле как происходит удаление записей которые содержаться в основной БД из промежуточной ? Делаю INNER JOIN по двум полям, а потом из INNER JOIN'a удаляю записи из промежуточной таблицы в которых значения полей по которым делается INNER JOIN совпадает с таковыми в основной БД
DELETE tmp.datagps_1 FROM tmp.datagps_1 INNER JOIN mca_dispatcher.datagps ON
mca_dispatcher.datagps.Mobitel_id = tmp.datagps_1.Mobitel_id
AND
mca_dispatcher.datagps.UnixTime = tmp.datagps_1.UnixTime;
А из клиентской БД в промежуточную БД (которая как и основная находится на серваке, за один сеанс переписываю только записи в которых некоторый ID > определенного числа например переписал за один сеанс 10 записей, пришло еще 10, при следующем сеансе буду копировать только записи с ID>10) по другому никак... главная задача максильно разгрузить клиента.
добавить логику проверки существования аналогичной записи можно, даже есть идеи, но мне кажется что это будет еще медленее... + к этому я еще и не знаю как это реализовать... :( так что приходится делать как умею :)