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

Question

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

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

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

1. Сохраненные данные привязаны только к вашей платформе разработки (C # в моем случае). Никакие другие платформы, такие как Java или C ++, не могут использовать эти данные.
2. Сохраняется весь граф объектов (включая всю цепочку наследования), а не только те данные, которые нам нужны.
3. Изменение модели данных может вызвать серьезные проблемы с обратной совместимостью при попытке загрузить старые состояния.
4. Обмен частями данных между приложениями проблематичен.

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

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

Answer 3

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

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

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

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

4. Нет, если программа C # передает данные другим приложениям. Другие приложения не должны обращаться к данным, которые непосредственно принадлежат этому приложению, не так ли?

Answer 4

См. в этой публикации Stackoverflow для комментария о применимости XML к применимости системы управления базами данных В нем обсуждается вопрос, который очень похож на предмет обсуждения в вашей команде.

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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