можно через импорт синхронизаровать и две одинаковые базы. При этом, будут добавляться только те операции, которых в базе нет. Но, откровенно говоря, пока стремаюсь
Какой-нибудь бы механизм проверки бы... Наверное, в его качестве может выступать общая сумма по всем счетам, приведенная к какой-то валюте.
Мастер импорта позволяет...
Dervish
24/01/2007 17:15
#
...выбирать не только файлы excel-я, но и базу данных AbilityCash. При импорте, на самом деле, выполняется что-то вроде половинной синхронизации: программа догружает только те операции (классификаторы), которых еще нет в текущей базе данных. Подгружаемая база, конечно же, не изменяется.
В отличие от настоящей синхронизации:
1. во время импорта записи только подгружаются, если в подгружаемой базе какая-то операция была удалена, это останется незамеченным.
2. если какая-то операция была изменена, то в текущую базу допишется дубликат,
3. подгружаемая база данных не изменяется никак.
Не уверен что это поможет, но не сказать об этих отличиях не мог.
Насчет полноценной, настоящей синхронизации: я просто не знаю как правильнее ее реализовать. Это очень трудный идеологический вопрос. Потому что, по уму, надо бы тогда сделать какой-нибудь удостоверяющий сервер, который управлял бы синхронизацией. В общем, нет у меня такого решения, которое было бы стопроцентно правильным. Потому и не делаю пока ничего в этом направлении.
Угу...
IF
25/01/2007 09:16
#
К сожалению, подгружаемая база не изменяется никак (Проверено %-) )
Уже столкнулся с рядом проблем, когда в базе-IMPORT были сделаны какие-то изменения: операции, классификаторы особенно изменения в них, порядок счетов.
Поэтому после импорта и возникают проблемы, когда в исходной базе уже всё, вроде бы подправил, а в результирующей все старые косяки остались да ещё и новоимзменонное появилось - запутывает в момент!
Да, согласен,...
Dervish
12/02/2007 16:24
#
...синхронизацию пока наладить очень сложно. И, честно говоря, мне никак не приходят никакие достойные мысли в этой части. У любого подхода есть свои минусы.
Но ведь не только минусы! =)
IF
15/02/2007 17:11
#
Есть же ведь ещё и неоспоримые положительные моменты! Вот именно ими и надо оперировать.
Со своей стороны могу предложить, как вариант - серверное исполнение синхронизаии. (То есть наличие в сети одной - главной базы данных, имеющей в своём распоряжении ВСЕ данные, а все остальные общаются исключительно с ней, в зависимости от используемых счетов, валют...). Вариант известный, но мне кажется, его целесообразно использовать, когда пользователей программы переваливает за десяток. Всё таки, при централизации порядка больше.
А вот для домашнего или мелкобизносного формата учёта должен подойти распределённый вариант синхронизации по мере необходимости. Синхронизацию проводить можно как, и на автомате по расписанию, и в ручном режиме (как в данный момент).
Главное, чтобы программа смогла понимать именения в именах, реквизитах счетов и классификаторов! (может быть, для этого необходимо присвоить каждой позиции уникальный скрытый номер и проводить сравнения по нему?).
В любом случае, это направление определённо будет востребовано, обсуждать и реализовывать надо.
если я правильно понимаю
Loki
19/02/2007 18:01
#
то в этом случае должен быть некий репозитарий, который отслеживает все изменения?
И если в случае с добавлением операций, примерно понятно как это должно обрабатываться, то как будет происходить изменение и удаление?
Необязательно...
IF
20/02/2007 08:29
#
Я полагаю, вполне, может хватить именно спецметок, скажем, такого формата: W-ХХХХХХХХ-VV-DD-MM-YYYY.
где
W-метка вида операции(приход, расход, перевод). Не знаю нужно это будет или нет, но сделать можно.
ХХХХХХХХХ-UIN номер операции.
VV-метка номера версии операци при её изменениях.
DD-MM-YYYY - дата внесения последних изменений в операцию.
Конечно, это всего лишь попытка, причём человека не совсем опытного, но всё же думаю трудности преодолеть возможно.
Проблема не в том как это хранить,
Loki
01/05/2007 23:34
#
а в том как урегулировать конфликты. Если два пользователя меняли одну и ту же операцию, то что должен делать репозитарий? Обычно, подобные системы выводят различия и предлагают выбрать один из вариантов. Если дело касается классификаторов - тут довольно просто. А если разные суммы? Как пользователю в уме проследить как изменение суммы повлияет на итоговый результат?
Еще одна сложность: условно, пользуется три человека. Двое свели остатки и все у них сошлось. Но вот приехал третий из коммандировки и где-то у него вылезла операция месячной давности из-за которой поплыли остатки. В системах контроля версий обычно хранится вся история изменений. Значит и тут придется реализовывать нечто подобное. А это нетривиальная задача... хотябы даже интерфейсно.
Насчет достойных мыслей...
Дим(м)
16/02/2007 19:04
#
... может быть, стоит попробовать посмотреть, как сделана синхронизация в распределенных системах контроля версий? Таких, например, как
darcs,
Bazaar-NG,
Monotone,
SVK.
За тем же darcs, насколько я помню, даже какая-то специальная теория стоит.. Вот: unique algebra of patches -
http://darcs.net/DarcsWiki/PatchTheory.
А вообще, мне кажется, уникальные идентификаторы + временнЫе метки - и все должно решиться.
Хм...
Дим(м)
16/02/2007 19:07
#
А что я не так сделал со ссылками? Круглые скобки помешали?..
Не знаю. Но...
Dervish
27/02/2007 17:28
#
...ссылки я поправил.
Ключ при синхронизации
Юрий
29/04/2007 15:53
#
Есть предложение ввести ключевое поле с уникальным ID операции. Тогда все информационные поля будут вестись как атрибуты и перезаписываться, например, по более позднему времени изменения. Синхронизацию осуществлять исключительно по этому ID.
Такое поле уже есть. (+)
Dervish
07/05/2007 17:12
#
Уникальный ID операции (уникальность на уровне одной базы данных). И время изменения тоже ведется. Вот только, увы, это не решит проблемы, которая может возникнуть при попытке синхронизации двух совершенно различных баз данных. Скажем, если синхронизировать мою базу данных с вашей, то в итоге получится полная чушь.
надо два поля ID
Юрий
13/05/2007 18:04
#
Можно вести два ключевых поля:
- ID базы;
- ID операции.
Таким образом, синхронизация будет происходить по этим полям и по времени изменения/добавления операции. Причем операции удаления не должна физически удалять запись из базы, а просто устанавливать индикатор сторно. И отфильтровывать эти удаленны записи для отображения пользователю.
Синхронизация
Rost Poleshko
16/05/2007 13:23
#
Я когда-то разбирался всерьез с алгоритмом работы activesync-апри синхронизации баз appointment`ов, контактов, событий и пр.. Алгоритм там очень простой и как ни странно, в 99% случаев дает результат, правильно воспринимаемый человеком. Реализовано это примерно так
1. Смысл опреации очень сильно зависит от структуры классификаторов. Если структуры классификаторов различны для одной и той же базы, то пользователю придется сначала решить этот вопрос вручную. Разные базы сиинхронизировать вообще нельзя. Точнее, это другой процесс, импорт-экспорт.
2. Перед началом синхронизации надо обязательно выяснить, кто имеет приоритет. В основном это надо для корректного удаления "лишних" операций.
3. При синхронизации операций обычно возникают три варианта
- дополнение - операция есть в приоритетной, но отсутствует в синхзронизируемой базе - просто дописываем
- замещение - операция есть в обоих базах - в зависимости от даты-времени опреации, можно с запросом пользователю, можно жестко по времени, можно жестко по приоритету баз
- удаление - операция есть в синхронизируемой, но отсутствует в приоритетной базе - просто удаляем
Это все замечательно
Loki
16/05/2007 17:16
#
при наличии "сервера". То есть некого хранилища. А если нужно синхронизировать две или более равноправных БД? Например, у мужа и у жены... Тут уже дата операции ни о чем не скажет.
А если структуру классификаторов править все равно руками, то такая синхронизация есть и сейчас: при импорте одинаковые операции не дублируются.
Все поля есть.
Dervish
17/05/2007 16:46
#
И ID базы есть. И ID операции есть. И флажок "сторно" тоже присутствует. А вот четкого алгоритма, честно говоря, придумать не могу. Потому что возможна уйма вариантов. Потому что сделать синхронизацию корректной только на основании указанных данных не представляется возможным.