Как лучше сделать во второй версии?

Сохранение настроек Dervish 08/08/2003 21:13 #

Первый вопрос о том, что довольно давно обсуждалось на форуме, но не потеряло своей актуальности и поныне: о сохранении настроек страниц.

Ситуация такова: в первой версии программы все страницы имеют предустановленные, "зашитые" в программу настройки, которые пользователь не может изменять. Это касается и страницы операций (например, фильтр по датам - он всегда показывает текущий и предыдущий месяц) и страницы графиков (там по умолчанию все поля, кроме фильтра дат, сброшены и их всегда надо устанавливать заново), страницы отчётов...

В общем, настройки не сохраняются нигде, что очень неудобно.

Чуть раньше уже звучало предложение сохранять настройки страниц, и я было начал делать это во второй версии, но тут у меня появились сомнения: а правильно ли это?

Допустим, я зашёл на страницу операций, которая настроена так, как мне обычно удобно с ней работать. Но, вдруг, мне потребовалось сделать какой-то нетипичный запрос к списку операций. Я его делаю, смотрю на результаты и закрываю программу. Проходит пару дней, я снова открываю программу и в ней захожу на страницу операций. После этого я долго-долго пытаюсь понять (уже успел забыть, что изменил настройки), что это такое мне показывает программа.

У меня есть другое предложение: а что если сделать так, чтобы программа запоминала не текущие настройки, а default-установки каждого фильтра, каждого поля? Тогда, если я изменю значения фильтров для нетипового запроса, то при следующем входе в программу я уже не буду путаться и вспоминать, что же такого я натворил во время прошлого сеанса работы.

Итак, есть два подхода к сохранению настроек:

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

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

Какой вариант на ваш взгляд лучше?

Сохранение настроек SZ 08/08/2003 22:32 #

Второй вариант нужен. Т.е. пользователь однажды определил как он хочет видеть страницу при открытии и по закрытии настройки не сохраняются. Старница всегда в привычном виде и есть возможность этот вид менять. Правда возможно ситуация, когда пользователь захочет иметь две, три (и т.д.) предопределенные настройки страницы. Тут уж по настроению разработчика

Dervish: Мнение понятно. Спасибо.

Вообще, была такая идея: зачем ограничивать пользователя одной единственной закладкой "Операции"? Очень удобно было бы создавать несколько закладок этого типа, но если для каждой из них будут свои собственные настройки, пользователь сможет сделать например закладку "Операции по личному счёту" или "Операции по счёту жены".

Совершенно аналогично для закладки "Графики" или "Отчёты".

Settings Lapa 14/08/2003 21:53 #

Считаю что необходимо сделать по образу и подобию MS Outlook. Есть неограниченное количество настроек, из кот. пользователь может выбрать текущую, добавить новую, изменить, удалить и т.д. При переходе из тек. окна и при условии что настройка была изменена пользователю надо предложить сохранить настройку.

Dervish: Понятно. Спасибо.

Настройки Bavlion 09/08/2003 15:37 #

Как по мне, так лучше второй вариант! Как минимум функциональности или, так сказать, гибкости, уж точно добавит.

Dervish: Спасибо.

ИМХО Explorer 15/08/2003 16:03 #

команду в настройки - сохранить текущие настройки как "настройки по умолчанию"

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

Dervish: Довольно сложно работать с темплэйтами. Лучше (для решения разных задач) иметь несколько закладок одного и того же типа. Например, несколько закладок "Операции". Правда, при таком подходе может оказаться неудобным TabControl, но тогда можно будет переключиться на какой-нибудь другой способ управления закладками.

Как вам такое предложение?

ИМХО громоздко Explorer 17/09/2003 19:49 #

ИМХО не нужно трогать табы...

имхо сделать закладку "настройки"

в которой пользователь устанавливает нужные ему варианты (темплэйты) и потом выбирает их из списка...

Dervish: Понятно. Спасибо.

Сохранение настроек o-st 18/09/2003 18:38 #

Я не вижу особых противоречий между первым и вторым вариантом сохранения настроек. Чем плох вариант, при котором можно явно указать файл конфигурации при старте (с помощью опции-ключа), а в нем предусмотреть опцию "Auto Save Setup = Yes" ?

Неплохо только учесть, что (пройдено на собственном опыте) может оказаться желательным реализовать что-то вроде отдельного менеджера настроек, поскольку "Load Settings"/"Save Settings" с линейным списком NNN настроечных файлов (только имя, без комментария) будет запутывать.
Слово линейный в противовес, например, древовидному - здесь ключевое.

Все варьируемые настройки программы - должны быть сведены в один "файл", можно вести ссылки на другие файлы (например - цветовой палитры), но так, чтобы одной иконки на рабочем столе для запуска было достаточно :-)

И ещё - работа программы с минимальным использованием реестра - с моей точки зрения безусловно лучше, чем хранение всех настроек в реестре.

Спасибо. Олег

Dervish: В реестре будут храниться только настройки, связанные с компьютером, например, список последних вызванных файлов (MRU - most recently used). Настройки же, связанные с данными (например, настройки фильтра страницы операций) в реестре хранить просто нельзя иначе получится (а) разглашение закрытых даных и (б) поведение программы непредсказуемо при работе с несколькими базами данных. Поэтому часть настроек (включая настройки страницы) будут храниться в самой базе.

Мало того, идти по пути усложнения количества настроек, имхо, надо очень осторожно: как бы простая в использовании программа не превратилась бы в труднопроходимого монстра. И потом, это вряд ли принесёт много пользы. За примером далеко ходить не надо: сколько процентов от всех возможностей Excel-я вы реально используете?

Сохранение настроек(1) o-st 19/09/2003 19:38 #

Давайте будем разделять вопросы представления данных (положения окон, фильтры, и пр.) и операции над данными (добавить/удалить/изменить запись, установить/разорвать связь). Первое - это настройки сеанса работы с программой. Второе - собственно работа с базами. Меня пугает жёсткая связь представления с данными. Хотелось бы ослабить это утверждение. Хотя бы заведением типа записи "настройки сеанса" с возможностью импорта/экспорта настроек в другую базу.

По поводу усложения количества настроек:
Переформулирую по другому - увеличение количества настроек без продуманной структуры представления приводит к усложнению понимания пользователем взаимосвязей внутри программы.

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

).
Касательно необходимости автосохранения настроек для разных сеансов. Это, насколько я понимаю, можно реализовать (при наличии "отдельных" настроек) комбинацией поля "Auto Save Setup = Yes/No" с опцией запуска программы "Use configuration file" или пунктом меню - "Load/Save configuration"

Dervish: А в каком виде хранить данные в файле настроек? Вот так просто записать на всеобщее обозрение название счёта? А конфиденциальность?

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

Сохранение настроек(2) o-st 19/09/2003 19:40 #

Вопрос насчет Excel - не совсем корректен. Лично я, не будучи офисным работником, использую Excel только как средство представления табличных данных. Не более. С другой стороны - моя жена пытается

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

Мне совершенно непонятно утверждение "поведение программы непредсказуемо при работе с несколькими базами данных". При одновременной работе с несколькими базами данных? Или при последовательной работе с несколькими базами? Тема, как я помню, прекрасно проработана в литературе. Или имеется в виду, что при работе программы с несколькими базами, а настройки хранятся в реестре - поведение непредсказуемо? Но так как я абсолютно не понимаю процитированное утверждение - не обсуждаю.

С уважением,
Олег.

Dervish: Поясню утверждение: на компьютере открывается база с некоторыми данными. На странице операций в фильтре выбирается счёт, и пользователь устанавливает режим, что при открытии базы всегда на странице операций выбирать в фильтре именно этот счёт. Эта настройка записывается в реестре... (Кстати, а как именно записывается? Названием счёта? А если у пользователя очень и очень конфиденциальные данные?) Пользователь закрывает базу данных и выходит из программы.

А через полчаса (час, день, неделю, нужное подчеркнуть) пользователь открывает на том же самом компьютере другую базу данных... И что программа видит в реестре? И какой счёт она должна выбирать в фильтре на странице счетов? Счёт из другой базы данных?

Сохранение настроек o-st 22/09/2003 13:01 #

Спасибо, что объяснили вопрос. Наконец до меня дошло. Виноват невнимательностью. :-(

Я уже так привык к интерфейсу, что названия областей ("Фильтр операций") не удосужился просмотреть. :-(

За словом "фильтр" для меня скрывается вся совокупность параметров отображения - не только "По_счёту" + "По_счёту/агенту/статье/проекту", но и "За_период", и "В_валюте", и действие "После открытия базы открыть страницу _Отчёты_ и показать ...."

По-моему, Вы (почти) всё очень логично решили. Все настройки, имеющие отношение к конкретной базе/ счету/ проекту/ агенту/ хранить связанными с ними, а не в глобально доступном месте. Вопрос конфиденциальности решается просто - не раскрывать. Даже вопрос раскрывать/нет ставить излишне.
Все общие настройки - вроде периода, за который отображается информация - от данных отвязать и сохранять в _файле_настроек_. Файл, в отличие от ветки реестра, может мигрировать с компьютера на компьютер с большей легкостью. Для общности - в параметрах настроек отчетов/операций/графиков иметь возможность выбора "Use_default" (период - текущий месяц) | "Use_current" (из файла настроек) | "Use_settings_for_this_file" | "Use_specified_on_current_page" .

Если специфичные настройки хранить непривязанными к сущностям - получается чепуха. Не очень правильно требовать от пользователя называть различающиеся агенты для разных баз по разному. Например - некто ведет финансовый учёт для своей семьи, для семьи родителей и свекрови/тёщи. Структура потоков может быть очень близкой, но настройки (типа "фильтр_операций") совпадать не обязаны.

Большое спасибо.
С огромным уважением, Олег

Dervish: Ваше мнение понятно, спасибо.

Но мне кажется, что работа с дополнительными файлами настроек, это лишнее усложнение программы. Вряд ли это будет востребовано большинством пользователей, а для тех, кому это не нужно, это добавит лишних проблем и хлопот. Поэтому, скорее всего, я вынесу в реестр только общие настройки для всей программы (положение окон и всё такое), а настройки каждой из страниц буду сохранять в файле базы данных. Замечу, что в программе будет возможность создавать несколько экземпляров одной и той же страницы, например, страницы операций. Думаю, что это поможет сделать работу с программой удобнее и решит основные проблемы.

Список операций по группе счетов Dervish 08/08/2003 21:38 #

Несколько раз в форуме звучал вопрос, о том, как посмотреть операции по нескольким счетам одновременно. Первая версия программы не позволяет этого делать, но во второй версии (из-за того, что счета теперь организованы в виде дерева) этот вопрос становится ещё более острым.

Вначале немного о том, почему я не стал в первой версии делать просмотр операций по нескольким счетам.

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

Если показывать операции по нескольким счетам, то в программе надо создавать очень много дополнительных колонок, и это может стать просто неудобным. Чтобы получить представление о том, какие колонки будут нужны, попробуйте сделать экспорт в Excel операций и посмотрите, какие колонки получатся в результате экспорта. Мало не покажется.

Во второй версии, как я уже говорил, счета можно будет организовывать в виде дерева. А если так, то возникает соблазн сделать возможным выбирать в фильтре операций счёт, у которого есть подсчета (в том числе в разных валютах). Но что при этом делать с колонками списка?

Вариантов несколько:

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

2. Сделать так, что если просматриваются операции по одному счёту, то пользователь видит точно такое же количество колонок, как в первой версии, а если просматриваются операции по нескольким счетам, то количество колонок возрастает, причём существенно.

3. Оставить как есть в первой версии: просматривать операции можно только по одному счёту.

4. Сделать два вида закладок: "Операции по одному счёту" и "Операции по нескольким счетам".

Как вы считаете, какой вариант лучше? Может быть будут другие предложения?

Список операций по группе счетов Dervish 11/08/2003 05:03 #

Чуть выше ты поднимал вопрос про сохранение настроек. Почему бы не сделать возможность выбирать какие именно поля должны быть в том или ином случае. И хранить соответственно как это разобрано в
От: SZ, добавлено: 08.08.2003 г. 21:32:24 (MSK)

Сохранение настроек

Dervish: Получится, что надо будет хранить два варианта настроек. Это не очень удобно реализовывать, проще дать возможность "плодить" нужное количество страниц, в том числе одного типа.

Про операциям по нескольким счетам energoatom 30/08/2003 16:05 #

Уважаемый Dervish (Макс), было бы очень удобно видеть операции по нескольким счетам, причем скрывать ненужные пользователю колонки и менять очередность их отображения.

Например, посмотреть операции по счетам "Личный НАЛ" и "Командировочные НАЛ" по одной статье расходов "Пиво" в проекте "Х"

Dervish: Я это уже делаю. Там были некоторые сложности, но, вроде как, я их уже поборол.

Не путай божий дар с яичницей. Dervish 30/08/2003 17:39 #

Я здесь не при чём. У нас с автором просто ники одинаковые :-)

Dervish:

)

Синхронизация Andryk 12/08/2003 14:52 #

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

Dervish: Основная проблема синхронизации: что делать с конфликтными записями. Я пока выделил поля для синхронизации со знакомой мне платформой PocketPC, там синхронизация должна работать. Но я пока не думал, признаюсь честно, над синхронизацией двух баз на десктопе.

а здесь-то какие могут быть проблемы? RsH 13/08/2003 15:16 #

проводим синхронизацию, конфликтующие записи выводим списком и спрашиваем
1. какая запись "правильная"
2. что делать с неправильной записью:
  а. удалить
  б. редактировать и сохранить в обеих базах
  в. оставить как есть, не проводить синхронизацию этой записи в текущую сессию

Dervish: Нет, проблема немного в другом. Я наверное не совсем верно сформулировал предыдущий ответ. А прямо сейчас, с ходу, не получается хорошо сформулировать правильно. Давайте я подумаю над формулировкой и чуть позже прямо вместо этого текста наберу её.

Синхронизация или взаимный импорт? Dervish 24/08/2003 00:46 #

Насколько я понял описанную Andryk ситуацию - он имеет два "кошелька" (счета) - свой и жены. (У меня, кстати, примерно такая же ситуация, за исключением того, что счетов ~14). Может быть имеет смысл сделать возможность "Импорта" конкретного счета из конкретной "книги", т.е. форму, на форме выбираем базу-источник, в базе выбираем "что" (счета, валюты, курсы... и т.д. как при экспорте), если это "что" уже есть в нашей базе - спрашиваем "заменить?". Если заменить - чистим соответсвующий счет и добавляем туда все записи из другой книги. Вот. Естсественно не забыть про пароли, и сделать возможность пакетной работы (т.е. из командной строки).

Если отдашь формат баз - могу сделать такую тулзу отдельно, хотя у меня нет возможности и знаний писать на WinApi, но создать "синхронизатор" мысль была уже давно, да Delphi я думаю для этого хватит.

Dervish: Мне пришлось разбить описание проблем синхронизации на два сообщения: форум тоже имеет ограничения на длину текста. Так что, смотрите чуть ниже о сложностях синхронизации.

Что же касательно публикации формата базы... В общем, я могу опубликовать формат первой версии программы. Однако, надо иметь в виду, что вряд-ли им можно будет воспользоваться из программ на Дельфи. Если я не ошибаюсь, в Дельфи нету базированных указателей? Если действительно нет, то я не завидую тому программисту, который попробует читать базу данных. А если есть, то возникает второй вопрос: а решит ли такая публикация проблему? Ведь на подходе вторая версия программы, а там один только движок базы данных будет занимать около половины самой программы: за прелести undo/redo, за возможности синхронизации (с PocketPC), за шифрование базы, за возможности управления доступом приходится платить объемом кода.

Может быть чуть позже просто сделать специальный интерфейс (шлюз) для синхронизации данных?

Проблемы синхронизации - часть 1 Dervish 24/08/2003 19:39 #

Проблема вот в чём. Я начну с небольшого экскурса в ActiveSync, который, собственно и занимается синхронизацией. Есть две базы, одна на десктопе, другая в наладоннике. Каждую из этих баз следует рассматривать как хранилище объектов. И каждый объект в каждой базе имеет свой собственный уникальный идентификатор. Например, в хранилище (object store) PocketPC каждому объекту присваивается OID, который (а) уникален и (б) постоянен в течении всего срока жизни объекта. Кроме того, каждый объект может иметь какой-то свой, внутренний, не зависящий от системы ключ. Например, для базы данных контактов, Фамилия-Имя-Отчество.

Во время синхронизации ActiveSync проверяет по OID все объекты, которые были созданы/удалены/изменены с момента предыдущей синхронизации и делает аналогичные действия для второй, синхронизируемой базы данных. Эти действия могли бы быть выполнены автоматически, если бы не конфликты тех самых вторых ключей, зависящих от конкретной программы. Представьте, что и на декстопе и на наладоннике (независимо друг от друга) были созданы в адресной книге записи для, например, Иванова-Ивана-Ивановича. Что делать в этой ситуации? Наверное, только то, что делает ActiveSync - выдаёт запрос пользователю, какую из этих двух записей считать актуальной.

Кроме того, обратите внимание, что в каждой из баз данных принята своя идентификация объектов. А ActiveSync ведёт таблицу соответствия этих объектов. И, в случае утери этой таблицы, ему не остаётся ничего иного, как пытаться восстановить эту таблицу по значениям ключей, зависящим от реализации (например, по тому же ФИО).

Проблемы синхронизации - часть 2 Dervish 24/08/2003 19:40 #

Теперь о нашей конкретной ситуации. В базе данных Cash каждый объект тоже имеет свой идентификатор, который (а) уникален и (б) постоянен в течении всего срока жизни объекта. Кроме того, этот идентификатор не зависит от содержимого самого объекта. Мало того, один и тот же идентификатор в разных базах может быть отдан разным объектам. Значит, мы приходим к тому, что для успешной синхронизации нам тоже надо вести таблицу соответствия объектов одной базы объектам другой. Кто, а главное, как будет вести эту таблицу соответствия? Где её хранить? Что делать в случае её утери? Это очень непростые вопросы, на которые я не могу дать однозначный ответ.

Может возникнуть идея синхронизировать данные по каким-то уникальным значениям самого объекта. Но если это возможно, например, для статей/агентов/проектов/счетов, то я совершенно не представляю, какие именно значения могут однозначно сопоставлять операции в разных базах. Даты? Они не уникальны, а время не слишком принципиально и его можно вводить наугад. Суммы? Они часто повторяются. Статьи/агенты/проекты? Тоже не уникально. Комментарии? Лишний пробел и ничего не получилось.

Вот в чём состоит проблема синхронизации, как я её понимаю.

Проблемы синхронизации - надуманы? Dervish 25/08/2003 00:45 #

Для начала разобъем проблему на два этапа:

1. "Мало того, один и тот же идентификатор в разных базах может быть отдан разным объектам" [/i].
2. Реализация механизма.

1. Если в качестве OID (т.е. уникального идентификатора) использовать некий автоинкрементный счетчик, то действительно можно столкнуться с вариантом, когда в двух разных базах будет создано два разных действия с одним OID. Но зачем привязываться к счетчику? Не проще ли генгерить значение OID в зависимости от какого-либо постоянно меняющегося значения (системного таймера, например), + уникальный (в той же мере) идентификатор самой базы.

Преобразовать по какой-либо формуле значение текущей даты-времени, добавить идентификатор базы (да хоть серийный номер диска на котором лежит база) - вот и уникальный идентификатор в пределах 100 лет.

2. Собственно реализация зависит скорее от желания автора, но особых проблем здесь не видно.
Проблема с OID, проблема с определением "старшинства" записи (т.е. какая из двух конфликтующих записей верна)... и т.д.

Хотелось бы для начала иметь хотя-бы возможность "сращивания" двух баз с полной заменой каких-то счетов (смотри прошлое письмо).

Формат файла не может стоять преградой, где-то в 2001-2002 годах я приводил пример "изучения" собствено формата базы Cash`а. (см мыло).

Да и "внешнее управление" ввести можно, если уж серьезно взяться за проблему с точки зрения пользователя.

Dervish: На самом деле фраза "Мало того..." не была ключевой фразой моего сообщения. Основная идея: реализовать полноценную синхронизацию без файла соответствия, по-моему, будет почти невозможным. Но если для синхронизации нужен файл соответствия, то возникает второй вопрос: а где же его хранить? Опять же, в случае, когда должны синхронизироваться N баз данных (с выделением одной мастер-базы) надо бы создавать и поддерживать N-1 файлов соответствия.

Действительно, можно и не использовать счётчик. Можно, в конце концов GUID использовать, вроде как нам гарантировали его уникальность. Но основная сложность как раз в том, чтобы чётко обозначать соответствие что вот этот объект (неважно с каким идентификатором) в одной базе хранится в другой уже вот с этим идентификатором. И проблема осложняется тем, что, как я показал выше, для операций невозможно указать набор параметров, которые бы чётко отделяли одну операцию от другой. А значит, конфликты просто невозможны, значит, всё сливаем в одну кучу и только потом (вручную!) разбираемся, что в ней дублируется, а что нет.

Не нашёл я в мыле (хотя храню всю переписку) "изучения" формата базы первой версии программы (может быть потерялось?). Если не затруднит, повторите ещё раз.

Проблемы синхронизации - надуманы? (Часть 1) Dervish 26/08/2003 00:52 #

Хотелось бы подчеркнуть два момента из ответа:
1. Можно, в конце концов GUID использовать, вроде как нам гарантировали его уникальность.
2. чётко обозначать соответствие что вот этот объект (неважно с каким идентификатором) в одной базе хранится в другой уже вот с этим идентификатором.

Теперь рассмотрим ситуацию. Скажем я имею базу с одной записью "зарплата 1000р" (ID=232967). Копирую её себе на ноут, и ухожу на работу. На работе я заношу запись "завтрак 10р" (ID=468045).
Пока я был на работе жена в домашний компьютер занесла запись "продукты на обед" (ID=288576).

Теперь в результате мы имеем две базы:

Моя: ID=232967, ID=468045
Дом: ID=232967, ID=288576

Прихожу я домой и говорю "синхронизировать".
В результате синхронизации получаю базу:
ID=232967, ID=468045, ID=288576.

Конфликтующих записей нет, т.к. ID=232967 не менялась. Если записи ID=232967 отличаются в разных файлах, то смотрим у какой из них более свежее время изменения, ту и сохраняем.

При изменении записи ID меняться не должен.

см. часть вторую :-)

Dervish: Я немного "причесал" стиль: цитаты из моего текста все сделал курсивом, а то, что вы хотели выделить - выделил полужирным шрифтом. Текст не изменял, так что, надеюсь, вы на меня не в обиде.

По сути: вроде как всё должно работать. Но мне всё равно трудновато отказаться от привычных стереотипов.

Давайте я немного подумаю, так как вы меня немного загоняете в тупик. Дело в том, что во второй версии я уже сделал уникальные идентификаторы (ID), но они назначаются по-порядку. И, увы, по ряду соображений я не могу изменить это. Остаётся одно: добавить дополнительное поле "id для синхронизации", если только так. Благо, вторая версия базы будет позволять легко наращивать поля в базе.

Предложение AleS 26/08/2003 17:47 #

Может просто завести еще один идентификатор - для базы в целом? И операции при синхронизации рассматривать уже не только по их ID, а как ID базы + ID операции. Такая идентификация операций будет уникальной в пределах уникальности ID базы.

Dervish: Может быть и понадобится. Но не для того, чтобы синхронизировать операции (а надо ли, может быть действительно лучше просто сливать их), а для того, чтобы вести таблицы соответствия нескольких баз данных.

А зачем вообще синхронизировать операции?? WW 26/08/2003 18:47 #

Синхронизировать надо исключительно справочники, как-то: агентов, статьи бюджета, проекты, что там еще есть. Операции же надо объединять, чтобы количество операций в двух базах после синхронизации сравнялось. Обьясните, пожалуйста, смысл понятия "конфликт операций". Что, жена дома, а муж на работе внесут в свои базы покупку пакета молока, а потом будут выяснять, кто же все-таки потратил деньги? Вот набор статей расхода у мужа и жены может быть разным, так и совмещать надо именно его, а не операции - они, с точки зрения реальных денег, актуальны что у мужа, что у жены, пусть даже жена потратила десятку на "Питание", а муж на "Хлеб" -- деньги-то потратили оба

Dervish: Да, я помаленьку тоже прихожу к той же самой мысли. Мне кажется, что это правильно.

"Что такое синхронизация". Dervish 26/08/2003 20:19 #

Проще subj объяснить на примере.

Есть счет "пластиковая карта". Счётом владеют оба супруга. Расходные операции со счёта не ведутся, бывает только "перевод" денег в личные кошельки мужа-жены.

Для того чтобы видеть общую картину надо объединить эти две базы. Ок, тут я согласен.

А как поступить если дома я планирую "расход" со счета (т.е. проводу операцию без галочки "Операция выполнена"), а на работе узнав что мне денег понадобиться допустим меньше - корректирую эту операцию. Как без синхронизации поступить в этом случае?

Dervish: Всё будет работать правильно в вашем примере. Давайте разберёмся по шагам:

1. Дома. Планируете. Вводите не выполненную операцию. Далее, синхронизируете данные с вашей базой. По таблице соответствия программа узнаёт, что в домашней базе появилась новая операция, которую надо перенести в рабочую базу. Переносит. Обе базы корректны.

2. На работе отмечаете повторяющуюся операцию. Она становится выполненной, но в ней изменился один реквизит (признак "выполнено"/"не выполнено"). Меняете сумму операции, изменено два реквизита. Но, поскольку операция была повторяющаяся, программа автоматически сгенерирует следующую операцию. Со своим уникальным ID.

3. Приходите домой. Синхронизация. По таблице соответствий программа видит, что в рабочей базе изменена операция (одна штука) и добавлена операция (тоже одна штука). Соответственно, в домашнюю базу переносится изменение и добавляется новая операция. Вносятся изменения в таблицу соответствия.

Всё, процесс завершён, завершён корректно. Обе базы синхронизированы, данные соответствуют.

"Что такое синхронизация". Dervish 29/08/2003 04:08 #

Проблема раскрывается уже во втором пункте:

2. На работе отмечаете повторяющуюся операцию.

Теперь ещё раз что писал я:
а на работе узнав что мне денег понадобиться допустим меньше корректирую эту операцию.

Т.е. я не ввожу повторяющуюся операцию, а корректирую операцию

ID   Name                  Summa

База "дом" до синхронизации:
100 Покупка дискеты      15 рублей
База "работа" после корректировки, до синхронизации:
100 Покупка дискеты      13 рублей

Как поступить в этом случае при простом объединении

Dervish: Обратите внимание, что операции не просто объединяются, программа должна поддерживать таблицу соответствия. И в этой таблице отмечается не только какая операция какой соответствует, но и какой-то признак модификации операции, например, дату и время последней синхронизации. Сейчас, во вторую версию, я уже ввёл (пока) скрытое поле в базе данных - дату последнего изменения записи.

Кроме того, даже простая "отметина", которая изменяет состояние операции (выполнено - не выполнено), даже это фактически приводит к изменению записи. А дальше всё просто - смотрим по таблице соответствия, проверяем время последнего изменения, и если видно, что запись была изменена, проводим синхронизацию.

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

просто объединение касается только выполненных операций WW 29/08/2003 19:49 #

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

). Но вот планирующего их же в нескольких местах одновременно -- не слишком реальный пример.

Dervish: Там не шла речь о планировании и дома, и на работе. Речь шла о том, что запланированную дома операцию выполнили на работе. А такое встречается очень и очень часто.

Проблемы синхронизации - надуманы? (Часть 1) Dervish 26/08/2003 20:13 #

Разумно, если уж нельзя переделать существующие ID`ы. За стиль - сорри.

Dervish: Наверное ничего не бывает невозможным, но то, что мне это не хотелось бы делать, это факт.

Будет третья версия - будет полный передел. Dervish 29/08/2003 04:00 #

Вторую версию Вы переписали полностью, значит это будет переписано уже в третьей :-)

Dervish: В ответе хочется отметить сразу два момента:

1. Считаю, что синхронизацию можно проводить без изменения существующих ID-ов. В общем, эта тема довольно подробно была разобрана в этой ветви форума.

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

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

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

Проблемы синхронизации - надуманы? (Часть 2) Dervish 26/08/2003 00:53 #

часть II

значит, всё сливаем в одну кучу и только потом (вручную!) разбираемся, что в ней дублируется, а что нет.

А зачем в случае двух записей с одинаковым ID записывать обе? Если мы гарантируем уникальность ID в пределах одного периода, то значит две записи с одним ID действительно один и тот же объект.

При таком методе нет разницы в количестве синхронизируемых баз. Если доступны одновременно все, то сначала сливаем в одну, после копируем эту одну в каждую. Если доступно только две какие-либо, то синхронизим их.
В приведенном мною примере даже для 4-х баз доступна следующая схема синхронизации
1 с 2; 3 с 4; 1 с 3; 2 с 4;.
После такой схемы содержимое всех 4-х баз будет идентично.

Не нашёл я в мыле (хотя храню всю переписку) "изучения" формата базы первой версии программы (может быть потерялось?). Если не затруднит, повторите ещё раз.

Я немножко неправильно выразился, как такового "изучения" не было. Просто я как-то завёл разговор про пароли (письма с адреса MFilenko[at]uhb.parma.ru), и привел простенький метод избавления от них.

P.S. Может быть в мыло? На ваше усмотрение.

Dervish: С файлом во второй версии совсем другая песня. Сложность файла возрасла, по сравнению с первой версией, просто в разы, если не на порядки. Про то, как в первой версии снимался пароль, я уже молчу, думаю, что сделать то же самое в двойке будет очень и очень проблематично. Впрочем, у вас будет возможность попробовать.

Для этого и был придуман GUID (+) _Andrey_ 28/09/2003 18:30 #

Для этого и был придуман GUID - именно его и нужно использовать в качестве уникального идентификатора объекта.
Этот идентификатор является глобальным уникальным идентификатором (прошу прощения за невольный каламбур).
Естественно глобальность идентификатара имеет некоторую погрешность, но об этом хорошо написано в MSDN. И для данной задачи, на мой взгляд он подойдет.
Для примера можно глянуть утилиту из набора MS VC - GUIDGEN.EXE.

Dervish: Да, есть такое дело. Полностью солидарен с вами.

Добавление операций Александр 10/09/2003 00:14 #

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

Dervish: Кнопке "Добавить" назначена комбинация клавиш Alt+Д, вот только я не помню, сделано это было в версии 1.3 или 1.4. Мне кажется, что это правильный подход, переназначить Enter будет очень необычно.

Кнопка добавить Александр 13/09/2003 18:59 #

Алт+д работает только в главном окне.
А вот если б такая же комбинация работала в самом окне ввода операции (дублировала кнопку "добавить").
Мелочь, а приятно.

Dervish: В главном окне работает Alt+D, а я говорил об Alt-Д, именно в диалоге ввода операции, причём "Д" должна быть именно русской. Попробуйте.

Не работает! Александр 22/09/2003 23:32 #

Пробовал, alt-д - ставит/убирает флажок "операция выполнена".

Dervish: Если не работает, то это уже не фича, а бага. Спасибо, я внимательно проверю.

Форум Как лучше сделать во второй версии?