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