Хранение данных (Обсуждениедля всех)
Хранение данных (Обсуждениедля всех)
\\Виртуальная (автономная) база данных это такая же реляционная база данных (SQL, oracle, MySQL и т.д.).
Чего ж так.
Наверное стоит тогда сразу и назвать конкретные примеры таких АБД
Я лично не знаю, что там еще есть кроме SQLite
ну еще может DB4
Хотя, зачем это вам в вашем проекте?
Я еще понимаю для онлайновой игры, на РНР
там нет особо других вариантов для хранения данных.
А для игры как у вас SQL база данных -- это ИМХО перебор.
Замотаетесь с составлением запросов к БД.
Чего ж так.
Наверное стоит тогда сразу и назвать конкретные примеры таких АБД
Я лично не знаю, что там еще есть кроме SQLite
ну еще может DB4
Хотя, зачем это вам в вашем проекте?
Я еще понимаю для онлайновой игры, на РНР
там нет особо других вариантов для хранения данных.
А для игры как у вас SQL база данных -- это ИМХО перебор.
Замотаетесь с составлением запросов к БД.
Хранение данных (Обсуждениедля всех)
Насколько я понял, вы хотите обсудить вопрос хранения данных в игре?
Можете предложить какие-то альтернативы виртуальной БД и реляционной БД?
Готовы сделать такой же доходчивый обзор-сравнение вашей альтернативы способа хранения данных по отношению к Базам Данных, как это сделал krupennikov?
Можете предложить какие-то альтернативы виртуальной БД и реляционной БД?
Готовы сделать такой же доходчивый обзор-сравнение вашей альтернативы способа хранения данных по отношению к Базам Данных, как это сделал krupennikov?
Хранение данных (Обсуждениедля всех)
Ну, я просто указал что использование SQL базы для хранения данных игры,
даже встраиваемой как SQLite это явный оверкил.
Я так понимаю что у вас предполагается два типа данных.
Игровые ресурсы -- которые загружаются в начале, и не изменяются по ходу игры.
и
Текущее состояние игры -- которое желательно уметь сохрянять\загружать в виде сейвов.
Ни то ни другое не требует явной БД.
даже встраиваемой как SQLite это явный оверкил.
Я так понимаю что у вас предполагается два типа данных.
Игровые ресурсы -- которые загружаются в начале, и не изменяются по ходу игры.
и
Текущее состояние игры -- которое желательно уметь сохрянять\загружать в виде сейвов.
Ни то ни другое не требует явной БД.
-
- Сообщения: 53
- Регистрация: 25 янв 2011
Хранение данных (Обсуждениедля всех)
Именно поэтому я и предложил использовать виртуальную БД, где не надо заморачиваться с SQL-запросами.
Хранение данных (Обсуждениедля всех)
А зачем тогда вообще БД? Без Сиквеля?
В чем тайный смысл?
БД нужна для произвольной манипуляции.
В игре ничего такого не нужно.
Для ресурсов игры (графики, текста) нужен просто способ грузить их, кешировать в памяти.
Для объектов игры -- возможность манипулировать ими в соответствии с правилами игры, и возможно сереализировать и сгружать/загружать...
к чему тут какая-то БД???
В чем тайный смысл?
БД нужна для произвольной манипуляции.
В игре ничего такого не нужно.
Для ресурсов игры (графики, текста) нужен просто способ грузить их, кешировать в памяти.
Для объектов игры -- возможность манипулировать ими в соответствии с правилами игры, и возможно сереализировать и сгружать/загружать...
к чему тут какая-то БД???
-
- Сообщения: 53
- Регистрация: 25 янв 2011
Хранение данных (Обсуждениедля всех)
Ответ в соседней ветке
Хранение данных (Обсуждениедля всех)
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 байта, ни больше ни меньше.
Угу. Вспомогательные структуры самой базы данных мы ведь конечно не считаем. )
Хранение данных (Обсуждениедля всех)
а вот здесь по подробнее... как в c# сделать не фиксированный массив...
с примерами...
да действительно мелочь какая... прописать каждый параметр вручную... на запись и на чтение... и при добавлении одного параметра менять его в двух местах...
а ты когда-нибудь в программах сохранял так сотню - другую парметров?
я сохранял... и потом - ой!... там забыл поменять одно название парметра и он не сохраняется... а программа уже вышла... надо выпускать патч...
да... очень не трудоемко получается...
и вместо того чтобы для тестов или модов менять параметры в файлах, прикрутим редактор к игре... очень даже упростим код...
т.е. новых версий делать мы не будем...
не надо на нас переносить опыты всяких 1С... они игру сделали, продали и забыли... у нас не много другой подход...
в нашем случае мы больше считаем сколько времени это может сэкономить...
у нас тут как бы это... люди учаться программировать... поэтому... либо некоторые начинают писать по делу... чтобы любой открыл, почитал и понял почему одно хорошо, а другое плохо...
либо я лично выпишу бан...
Хранение данных (Обсуждениедля всех)
А шарпей -- это единственный на всю Вселенную ТРУ язык???
И больше нет никаких других, ни даже сторонних библиотек?
Выделение памяти там еще есть?
Значит ничего не мешает сделать свою реализацию массива,
с изменяющимся размером.
Даю 100 против 1-го что это даже самому не нужно делать,
есть уже куча готовых реализаций, библиотек.
Согласен.
Но, "пофиксиш" эту проблему, оно вылезет в другом месте.
Вот, обращатся к полям данных через интерфейс БД, оно разве лучше???
Да. Так и поступают.
Думаеш ХМЛ у тебя получится более читабельный и редактируемый, чем бинарник?
Попробуй вон поредактировать файлы проект вручную, если не веришь.
А вообще. "Усложнять легко, упрощать -- сложно" (с)
Вообще-то это было саркастическое замечание.
ясн