.Net сохраняя большие списки и поддерживая актуальность данных почти в реальном времени - PullRequest
0 голосов
/ 24 января 2011

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

У меня есть настольное приложение на C # .Net (Windows Forms, но, как мне кажется, это может быть и WPF), которое представляет собой систему ввода и управления заказами на продажу. Проблема, с которой я сталкиваюсь, заключается в том, что один из самых важных списков данных, которые мне нужно использовать в приложении, довольно большой (около 15 тыс. Записей и продолжает расти) и постоянно меняется, и я хотел бы сохранить этот список в память синхронизируется с базой данных, не опрашивая базу данных каждые 2 секунды или что-то еще. Приложение также не является единичным экземпляром, поэтому все эти списки потребностей приложения заносятся в память из базы данных и сохраняются один раз для каждого экземпляра.

Хорошо, теперь, когда вы можете увидеть дилемму, давайте посмотрим, сможем ли мы найти решение.

Мои мысли:

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

Чтобы свести к минимуму загрузку данных из базы данных, я думал о чем-то вроде сохранения различных списков в текстовые файлы XML на ПК пользователя в какой-то специальной папке, а затем - одного окончательного файла XML для отслеживания файлов XML. и их даты. При запуске приложения выполняется один вызов в БД, получая список таблиц / списков и «дату последнего обновления» для каждой. Для каждого файла XML, который имеет одну и ту же дату последнего обновления, я могу загрузить из файла XML, а не запрашивать базу данных. Что касается списков, которые устарели, я мог запросить изменения с даты, которую я имею, затем загрузить файл XML и затем зафиксировать изменения. Таким образом, скорее всего, единственные изменения, которые мне придется ждать, - это изменения из наиболее часто обновляемых списков, а не всех таблиц / списков. Хорошо, я признаю, что я не лучший в объяснении вещей, но я думаю, что вы должны быть в состоянии это визуализировать.

Что касается поддержания актуальности в реальном времени, я думал о том, чтобы иметь триггеры вставки и обновления (не будет происходить удаление), которые будут вызывать SP, и тогда я немного неясен, как-то пропускаю вставленный / обновил информацию для службы WCF, на которую подписались приложения, и обновления передаются клиентам через обратные вызовы WCF. Теперь я думаю, что все это должно работать, но, например, не приведет ли это к тому, что 3 экземпляра приложения будут обновлять одно и то же изменение в памяти одновременно? Может ли служба WCF отправлять обновления только одному экземпляру на клиентский ПК; это может дифференцироваться?

Заранее спасибо за любые мысли, мнения и мнения по этому вопросу. Я зарезервирую «присуждение» ответа в течение как минимум 48 часов, так как я хотел бы дать каждому возможность добавить свои 2 цента и сделать эту тему немного более полезной для будущего ...

Ответы [ 3 ]

5 голосов
/ 24 января 2011

Я не вижу выгоды от сохранения базы данных в памяти. Смысл базы данных - быть базой данных.

Вам необходимо воспроизвести в вашем приложении функции многопользовательской базы данных.

Это похоже на беспроигрышное предложение. Оставьте это Microsoft. Вместо этого создайте n-уровневое приложение, которое использует все функциональные возможности сервера sql. Затем, когда у вас есть рабочая бета-версия, ищите части приложения, которые работают медленно и оттуда.

1 голос
/ 24 января 2011

Способ и, возможно, лучший способ достичь этого - это журналирование.

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

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

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

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

Второе: каждые 2 секунды? Это пахнет для меня как требование, основанное на вере в магию, а не на фактическую потребность бизнеса. И если это обусловлено потребностями бизнеса, это заставляет меня беспокоиться о более глубоких проблемах, таких как: предположим, что пользователю требуется более 2 секунд для выполнения транзакции с участием клиента, что произойдет, если строка клиента изменится во время транзакции?

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

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

1 голос
/ 24 января 2011

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

Если у вас естьэлемент пользовательского интерфейса с 15k элементов в нем ваша программа будет в основном непригодной для человека (может также ничего не отображать вообще и просто держать его в списке).Вам следует рассмотреть возможность использования диалогового окна поиска или чего-то подобного.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...