как сохранить/загружать данные.
т.е. как лучше делать. понятно , что зависит от условий. и если задача требует БД, то тут никуда не деться.
Но если нет ограничений. то можно и подумать.
Скажем есть необходимость сохранять/загружать данные в несколько мегов ( может и много больше ).
что бы его было возможно перекидывать туда сюда, создавать копии.
допускаю ( а так оно и будет), что в последствии нужно будет туда что то добавить, новые поля, массивы.
нужно, что бы спокойно переварил старый формат данных.
данные будут разноформатные. не только числа и текст.
вот как я вижу существующие возможности
1. БД.
тут вроде всё понятно и + и -
+++:
*удобство,понятность
*в случае ошибки можно всегда подсмотреть данные , и сторонними средствами (типа SQL manager...) найти и исправить.
---
*при больших объёмах сохранение/загрузка начинает напрягать. начиная с x Мб.
хотя можно установить что то в духе MySQL. вроде обещают скорость выше
*не мобильно. необходимо иметь доступ к БД. просто перебросить файл проекта не получится. только в рамках сети или базу выковыривать и втыкать в другом месте.
2. Сериализация
+++
*значительно быстрее чем БД
*не нужно никаких усилий , что бы реализовать.
---
*если переименовать хотя бы одно сериализуемое поле - загрузка становится невозможной(?)
*запросто может создать клоны экземпляра класса.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
[Serializable]
Class A
{
public B b;
}
[Serializable]
Class B {}
[Serializable]
Class C
{
A a=new A();
B b=new B();
void K1()
{
a.b=b;
}
}
//при десериализации поля a.b и b могут не совпасть. будут идентичными клонами с разным GetHashCode()
* править сохранённый файл низя
* требуется наличие ссылок на проект , где сериализуемые классы описаны. сей факт затрудняет использовать этот формат при обмене данными между 2мя разными приложениями.
3. XML подобие сериализации. соизмеримая скорость
+++
*можно переименовывать, не нужно ссылок на другие сборки
*можно поправить сохранённый файл
---
* труднее в реализации , чем сериализация.
* бинарные данные хранить в текстовом файле это преступление
4. Што то рукописное а-ля MemoryStream.Read/Write & Byte.....
+++
в работе наибыстрейший. близко к теоретическому пределу скорости.
огромный массив интов,байт, строк переваривает не напрягаясь
---
* наитруднейшей при реализации. особенно при сложной структуре.
* править и подсмотреть особо ничего нельзя. hex редакторы что то могут, но не много.
вроде как то так. мож что не досмотрел.
Исходя из всего этого, склоняюсь к сериализации. хотя не очень хочется это делать.
хочется в духе п.4 , т.к. реально это быстро, не требует ничего дополнительно устанавливать, но это целый геморрой .делать и поддерживать возможность версионности данных.
Кто что думает?
