Где хранить данные в простом приложении .NET Windows? - PullRequest
4 голосов
/ 10 ноября 2010

Представьте, что у вас есть приложение, которое управляет некоторой библиотекой и имеет свои собственные данные.Данные должны храниться где-то.Где должны храниться данные?

Я имею в виду следующее - вы собираетесь установить MySQL или SQL Server на клиентский компьютер?Это похоже на стрельбу мухами из пушки.Другой способ - использовать что-то вроде SQLite, для которого не требуется работающий сервер, но это неудобно (просто мое личное предпочтение).Существует также XML, но использование SQLite еще более болезненно.

Где вы храните данные?Установить SQL-серверы?Использовать собственные форматы данных?Есть ли другие способы?

Ответы [ 7 ]

3 голосов
/ 11 ноября 2010

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

При этом я бы никогда не сталмечтаю использовать любую базу данных для хранения простых данных клиента.Сложность и накладные расходы кажутся неоправданными, особенно когда преимущества базы данных SQL практически теряются в зависимости от типа приложения.Если ваш набор данных может быть либо полностью загружен в ОЗУ, либо влияние на производительность загрузки данных по требованию из сохраненного файла незначительно, вы могли бы хорошо изучить альтернативные варианты.Единственный сценарий, в котором я бы рассматривал хранение в базе данных на стороне клиента, - это если бы абсолютно требовалось более быстрое время извлечения данных, которого нельзя достичь с помощью более умного / более эффективного проектирования кода, или если приложение могло бы извлечь выгоду из возможностей индексирования и поиска, что-токак может предложить MySQL.

Вместо этого я обнаружил, что естественно стремлюсь структурировать данные в деревьях.Для любого приложения, где скорость не была первостепенным приоритетом или я не имел дело с особенно сложными типами данных, я бы выбрал XML-сериализация .Мало того, что запрос и изменение XML-файла значительно быстрее, чем базы данных с относительно небольшим набором данных, стандартная библиотека Microsoft DOM делает работу с источниками данных XML довольно простой.Сериализация экземпляров классов встроена в .NET Framework, и мне хочется, чтобы эта функциональность была у меня годы назад, когда я потратил все это время на написание кода для хранения и поиска данных.Другие преимущества XML заключаются в том, что он может практически исключить проблемы с версиями в будущих выпусках приложения, даже если добавлена ​​функциональность, и что файлы данных можно просматривать / редактировать вручную, если это необходимо.Также удобна переносимость, позволяющая другим программам легко читать и импортировать ваши данные, и если это произойдет, вы не рискуете повредить базу данных несколькими одновременными операциями чтения / записи.Наконец, я считаю, что сериализация пользовательских наборов данных в файлы XML неоценима при отладке: я могу сохранить состояние, а затем открыть файл XML, чтобы точно узнать, какие данные хранятся.

ВВ приложениях, которые XML не вполне соответствуют требованиям (обычно потому, что я пытаюсь обмануть и сохранить состояние классов управления данными, загруженных в память), я выбираю двоичная сериализация ,Это также отличная альтернатива XML, если вы ищете более быстрое время доступа, а сложность структуры данных / данных не поддается естественному иерархическому формату XML.Это также встроено прямо в .NET Framework и, возможно, даже проще в настройке, чем сериализация XML (если это возможно).Два основных недостатка этого типа хранения данных заключаются в том, что бесшовное управление версиями становится практически невозможным, а ваши данные хранятся в собственном формате, недоступном ни пользователю, ни другим приложениям.Если управление версиями не является проблемой для вашего приложения, вероятно, здесь не о чем беспокоиться.Однако, с парой приложений для управления данными, которые я написал, меня укусили после того, как я вернулся и добавил функциональность позже, не принимая мер предосторожности при чтении файлов данных, созданных в предыдущих версиях.

В любом случае, с двоичным илиСериализация XML, мне нравится гибкость, предоставленная мне как разработчику с несколькими отдельными файлами для документов.Я могу связать определенные расширения файлов с моим приложением в оболочке, пользовательский интерфейс становится намного более интуитивно понятным для таких вещей, как резервное копирование, и пользователи могут легко обмениваться файлами, созданными в моем приложении, с другими, у которых также есть мое приложение.Как вы думаете, Microsoft Word стал таким популярным?

2 голосов
/ 10 ноября 2010

если данные действительно простые, используйте Сериализация

2 голосов
/ 10 ноября 2010

Если бы хранимые данные были достаточно простыми, я бы, вероятно, выбрал XML.

В противном случае это было бы идеальным вариантом для SQL Server Compact Edition .

2 голосов
/ 10 ноября 2010

В прошлом я использовал XML для управления простыми структурами данных ... отлично работал.

Вы также можете хранить данные, используя Настройки

http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx

1 голос
/ 10 ноября 2010

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

0 голосов
/ 11 ноября 2010

CSV-файл?У него есть недостатки, но вам не нужна библиотека для его анализа.И это быстро.

0 голосов
/ 10 ноября 2010

Я бы выбрал db4o или SQL Server Compact Edition.

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