krupennikov писал(а): ↑11 янв 2012, 00:10Это массивы и списки (List). А у кого нет практики с ними, приведу различие между массивами и списками, оно одно единственное:
- массивы всегда имеют фиксированный размер. Чтобы изменить размер, потребуется писать дополнительный код. Как то это напоминает один из минусов РБД. Списки не имеют фиксированного размера.
Вообще-то, там где это описывается (например у Кнута) обычно говорится что в разница в эффективности добавления/удаления элемента, удобстве сортировки.
И массив совсем не объязан быть фиксированным.
krupennikov писал(а): ↑11 янв 2012, 00:10Для сохранения списка в файл метода не существует, придется писать самим. То же самое и для загрузки из файла. Но это будет трудоемко и много заморочек. Но! Можно уменьшить трудоемкость и заморочки. Сделать небольшой код для переноса списка в таблицу типа DataTable, то есть в АБД. А у АБД есть готовый метод WriteXml.
И что же там такого трудоемкого?
Код: Выделить всё
// FileName - имя файла, куда будет сохранен XML-документ
// settings - настройки форматирования (и не только) вывода
// (рассмотрен выше)
using (XmlWriter output = XmlWriter.Create(FileName, settings))
{
...
// Создали открывающийся тег
output.WriteStartElement("starShip");
// Добавляем атрибут для starShip
output.WriteAttributeString("name", ship.name);
output.WriteAttributeString("speed", ship.speed);
// Создаем элемент <shiphull>...</shiphull>
output.WriteElementString("shiphull", ship.shiphull.retAsString());
...
// Закрываем starShip
output.WriteEndElement();
...
// Сбрасываем буфферизированные данные
output.Flush();
// Закрываем фаил, с которым связан output
output.Close();
}
А можно и вообще не заморачиватся, и сбрасывать все в бинарном виде
(если данные в классе в POD-формате)
Код: Выделить всё
starShip::writeToFile(File file){
file.writebinary( this, sizeof(this) );
}
krupennikov писал(а): ↑11 янв 2012, 00:10Точно также при загрузке переносить из АБД в список. Но возникает вопрос, зачем переносить из АБД в список, если можно напрямую работать с АБД?
Давайте сравним АБД и список.
Может давай все же для начала озвучим,
какой именно програмный продукт мы имеем в виду под абревеатурой АБД?
Потому что, при реальной разработке важны не только абстрактные размышления "что лучше", но и реальные характеристики используемых модулей.
Особенно если они сторонней разработки.
krupennikov писал(а): ↑11 янв 2012, 00:10Список - сохранение и загрузка
- пипец какой код... Причем при каждом изменении полей класса (смотрите Список-создание), редактируется и код
Пипец какие проблемы.
Особенно учитывая,
что мы ведь пишем по детальному диздоку,
и значит эти все структуры будут написаны один раз
и потом не будут менятся.
krupennikov писал(а): ↑11 янв 2012, 00:10Есть еще одна разница. При использовании списков невозможно добавить новый "столбец" во время выполнения программы. Как и абсолютно новый тип объекта (например, если у кого то из программистов возникнет желание сделать конструктор чего то нового, типа чтобы игрок мог создать новый объект, несуществующий в игре, прям во время игры), так как списки построены на классах. Если вы заметили АБД не привязана ни к каким классам.
Ну да. Если программист альтернативно-одаренный,
тио ему еще и не такого может захотется добавить.
))
krupennikov писал(а): ↑11 янв 2012, 00:10List - это массив с нефиксированной длиной, АБД - вроде тоже. Но! List - это массив объектов, у любого объекта могут быть методы. АБД - это массив данных.
Пипец какое точное определение.
))
krupennikov писал(а): ↑11 янв 2012, 00:10Так вот в АБД мы не можем написать что то типа
answer.Go(...);
нам просто невозможно приписать методы к каждой строке в базе данных. База данных - это таблицы значений, а не массив объектов. Если для хранения данных использовать List, то в памяти за каждым starShip будут храниться еще и его методы, поля, свойства и т.д. плюс куча всякого добра, которое можно увидеть в студии при выполнении кода. С таким раскладом у вас оперативки точно не хватит.
последнее замечание... доставило
krupennikov писал(а): ↑11 янв 2012, 00:10 В базе данных если тип столбца указан как int, то каждая ячейка будет занимать в памяти именно 4 байта, ни больше ни меньше.
Угу. Вспомогательные структуры самой базы данных мы ведь конечно не считаем.
)
