Сериализация по сравнению с базой данных

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

Однако другие ребята из моей команды считают, что сегодня лучше всего просто сериализовать весь графический объект в двоичном или XML файле.
Не нужно говорить (но я все равно это скажу), что между нами идет Третья мировая война, и я хотел бы услышать ваше мнение по этому вопросу.

Лично я ненавижу сериализацию, потому что:

  • Сохраненные данные привязаны только к вашей платформе разработки (С# в моем случае). Эти данные не могут использовать никакие другие платформы, такие как Java или С++.
  • Сохраняется весь граф объекта (включая всю цепочку наследования), а не только нужные нам данные.
  • Изменение модели данных может вызвать серьезные проблемы с обратной совместимостью при попытке загрузить старые состояния.
  • Разделение частей данных между приложениями проблематично.

Я хотел бы услышать ваше мнение об этом.

Ответы

Ответ 1

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

  • Если эти данные очень большие (например, многие экземпляры рассматриваемых объектов), база данных может помочь в производительности благодаря своим возможностям индексирования. В противном случае это, вероятно, повредит производительность или неразличимо.

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

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

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

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

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

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

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

Ответ 2

Это зависит от того, что вы хотите сериализовать, конечно. В некоторых случаях сериализация смехотворно проста.

(Я как-то написал вид временной программы в Java, где вы можете нарисовать en, перетащить и изменить размер объектов. Если вы были готовы, вы можете сохранить его в файле (например, myTimeline.til). На этом монете сотни сохраненных объектов, их положение на холсте, их размер, их цвета, их внутренние тексты, их спецэффекты,...

Вы можете, нежели, конечно, открыть myTimeLine.til и продолжить работу.

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

Работая на временной шкале, вы также можете "сохранить" для разных версий и файлов "til", где очень легко создавать резервные копии и почту.

Я думаю, что в моем конкретном случае было бы немного идиотом использовать базы данных. Но это, конечно, только для документов-подобных структур, например Word, чтобы назвать их.)

Моя точка первая: , конечно, есть несколько сценариев, в которых базы данных не будут лучшим решением. Сериализация не была изобретена разработчиками только потому, что им было скучно.

  • Неверно, если вы используете XMLserialization или SOAP
  • Не совсем актуально
  • Только если вы не будете осторожны, для этого существует множество "лучших практик".
  • Только если вы хотите, чтобы это было проблематично, см. 1

Конечно, сериализация имеет помимо скорости реализации другие важные преимущества, такие как отсутствие необходимости в какой-либо базе данных в некоторых случаях!

Ответ 3

См. fooobar.com/questions/63674/... для комментария о применимости XML и применимости системы управления базами данных. В нем обсуждается проблема, которая очень похожа на тему дебатов в вашей команде.

Ответ 4

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

  • Ну, вы всегда можете написать конвертер в С#, чтобы извлечь данные позже, если это необходимо.

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

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

  • Нет, если программа С# передает данные другим приложениям. Другие приложения не должны получать доступ к данным, которые принадлежат этому приложению, если они?

Ответ 5

Для передачи и автономного хранения сериализация в порядке; но для активного использования какая-то база данных предпочтительнее.

Обычно (как вы говорите) без базы данных вам нужно десериализовать весь поток для выполнения любого запроса, что затрудняет его масштабирование. Добавьте неотъемлемые проблемы с потоками и т.д., И вы просите о боли.

Некоторые из ваших других болевых точек о сериализации не все верно - пока вы выбираете разумно. Очевидно, что BinaryFormatter является плохим выбором для переносимости и управления версиями, но " буферов протокола" (формат сериализации Google) имеет версии для Java, С++, С# и много других и предназначен для толерантности к версии.

Ответ 6

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

Сериализация графического объекта в файл может быть хорошим быстрым и грязным начальным решением, которое очень быстро реализуется.

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

Ответ 7

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