Облегченные гибкие варианты сохранения данных

Question

Первоначально я использовал SQLCE, сначала начав с LINQ to SQL, а затем переместившись в Entity Framework, но кажется, что SQLCE слишком негибкий. (Прямо сейчас я не могу даже удалить таблицу, чтобы воссоздать ее, потому что она говорит, что я не могу удалить PrimaryKeyA, потому что на нее ссылается PrimaryKeyA ... поэтому я не очень уверен в возможности изменить ее позже)

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

Он должен быть легким для развертывания, менее 10 МБ, но предпочтительно менее 5. Пользователь не должен (не должен) изменять данные вне приложения, и ему не нужно знать или заботиться о том, как данные хранятся ,

Высокая производительность не проблема, это просто данные одного пользователя. Прямо сейчас у меня возникает соблазн сказать, что просто используйте XML, чтобы использовать LINQ to XML. Но мне интересно, есть ли другие предложения. Я хотел бы что-то, что легко переводить в и из обычных объектов, сработает ли для этого сериализация XML?

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

Answer 1

Я предлагаю использовать System.Data.SQLite . Он дает вам простой, высокопроизводительный SQL через интерфейсы ADO.net, и он легкий. Это также довольно хорошо документировано и легко устраняет неполадки с помощью клиента командной строки sqlite.exe вместе с другими инструментами. Одним из существенных преимуществ SQLite является то, что он имеет довольно свободную типизацию, поэтому вам не нужно тратить много времени на возмущение схемами.

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

Answer 2

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

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

Преобразование выполняется на лету различными методами Serialize (). Например, если объект, который в настоящее время находится в Схеме версии 5, встречает данные, которые были записаны с использованием Схемы версии 4, он будет знать, как с этим обращаться.

Однако, если вам нужен SQL-запрос, это может быть не лучшим вариантом. Это работает лучше всего, когда вы собираетесь читать все данные.

Пример:

Скажем, у вас есть класс Foo, который имеет 2 переменные-члены, которые вы хотите сериализовать:

class Foo
{
public:
  const unsigned int SCHEMA = 1;
  int i;
  double d;

  void Serialize(bool bSaving, CBinaryFile file)
  {
    if (bSaving)
    {
      // Serialize everything out
      file << SCHEMA << i << d;
    }
    else
    {
      // Read in the schema number first
      unsigned int nSchema;
      file >> nSchema;

      // Validate the schema number
      if (nSchema > SCHEMA)
      {
        // We're reading in data that was written with a newer version of the program
        // Since we don't know how to handle that let's error out
        throw exception;
      }

      // Read everything in
      file >> i >> d;
    }
  }
}

Теперь, скажем, через год вы добавите еще одного члена в Foo. Вы бы справились с этим так:

class Foo
{
public:
  const unsigned int SCHEMA = 2;
  int i;
  double d;
  string s;

  void Serialize(bool bSaving, CBinaryFile file)
  {
    if (bSaving)
    {
      // Serialize everything out
      file << SCHEMA << i << d << s;
    }
    else
    {
      // Read in the schema number first
      unsigned int nSchema;
      file >> nSchema;

      // Validate the schema number
      if (nSchema > SCHEMA)
      {
        // We're reading in data that was written with a newer version of the program
        // Since we don't know how to handle that let's error out
        throw exception;
      }

      // Read everything in
      file >> i >> d;
      if (nSchema > 1)
        file >> s;
    }
  }
}

Пока вы упаковываете все в числа в схемах, преобразование на лету происходит просто.

Answer 3

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