Если я не собираюсь сохранять данные в базе данных SQL, где мне их сохранять? - PullRequest
3 голосов
/ 19 декабря 2009

Я создаю программу энциклопедии, похожую на RAWR для World of Warcraft. Я не собираюсь сохранять данные в базе данных SQL, но мне так сложно всегда это делать, когда я уверен, что есть альтернативы для этих более легких случаев.

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

Где мне сохранить эти вещи? Под сохранением я подразумеваю сохранение их для развертывания при выпуске программы.

В основном я собираюсь сохранить только строковые переменные и некоторые видео / анимацию ( см. Мой другой вопрос )

Спасибо за помощь, ТАК. Как всегда, ребята, вы молодцы!

Ответы [ 5 ]

5 голосов
/ 19 декабря 2009

Что не так с базой данных для статических данных? Данные не являются статичными, с БД ваша административная / проектная программа для создания пакета данных будет намного проще, если вы будете использовать ее в базе данных. Если вы храните его в виде простых файлов, действительно ли вы хотите написать логику запроса, чтобы решить, как найти данные, или просто выполнить простой запрос SQL?

Использование System.Data.Sqlite позволяет использовать встроенную базу данных, один файл данных без серверного процесса. Это чрезвычайно популярная база данных, и я готов поспорить, что вы будете ежедневно с ней взаимодействовать. Кроме того, он поддерживает все замечательные функции RAD в Visual Studio для проектирования и взаимодействия с вашими данными.

3 голосов
/ 19 декабря 2009

Что не так со старой доброй файловой системой?

Вы просто создаете подпапку в папке приложения и в своем коде всегда ссылаетесь на файлы в этой подпапке, используя путь относительно папки приложения. например.

string imagePath=Path.Combine(Environment.CurrentDirectory,"SubFolderName\\picture.jpg");

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

Кроме того, реляционная база данных, такая как SQL Server / SQLite, на самом деле не идеальна для хранения двоичных данных. Они определенно могут, но это не то, что они делают лучше всего, поскольку они могут столкнуться с проблемами масштабирования.

Если у вас много бинарных файлов, таких как изображения, музыка, видео и т. Д., То мой первый выбор - файловая система.

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

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

2 голосов
/ 19 декабря 2009

Мой ответ зависит от того, сколько именно данных вы говорите. С чисто проектной точки зрения вы всегда должны отделять свои данные от логики приложения. Итак, вы хотите иметь внешний файл данных. Но если у вас на самом деле не так много данных, и они относительно статичны, вы можете просто поместить их в файл XML и использовать Linq to XML для запроса данных. Взгляните на класс XDocument .

При этом базы данных, как правило, облегчают вашу жизнь, особенно если вы получаете хороший инструмент для реляционного отображения объектов или объектную базу данных. Я бы порекомендовал вам использовать что-то вроде SubSonic SimpleRepository для помещения ваших данных в базу данных SQLite . Или, что еще лучше, взгляните на использование базы данных с чистыми объектами, такой как DB4O !

0 голосов
/ 19 декабря 2009

Моя первая мысль - это XML (предпочтительно) или двоичный файл, как предлагали Марк Эвер и yetapb. Предложения SQLLite также звучат довольно хорошо.

Другим вариантом является электронная таблица Excel с использованием поставщика OleDb. Вы бы использовали операторы SQL для чтения и записи данных. Если вы идете по маршруту Excel, знайте, что есть несколько причуд, к которым нужно привыкнуть, таких как: 1) Способ, которым вы указываете, на какой лист в книге вы ссылаетесь (аналогично тому, как вы ссылаетесь на таблицу в SQL + знак доллара и некоторые скобки). 2) Если у вас есть столбец только с текстом, но в одной ячейке есть номер, то OleDb будет работать с исключением, если вы немного не помассируете данные. Я знаю, это звучит странно, но это только на голову.

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

Я бы предложил хранить мультимедиа в вашей файловой системе, в зависимости от того, что вы делаете. Затем просто укажите записи данных, будь то в SQL, Excel, XML или в двоичном виде, и укажите имя файла. Это значительно облегчит вам управление данными.

0 голосов
/ 19 декабря 2009

Мои пожелания - либо xml, либо бинарные файлы

...