Если я не собираюсь сохранять данные в базу данных SQL, где я должен ее сохранять?

Question

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

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

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

Я в основном будет экономить только строковые переменные и некоторые видео/анимацию (see my other question)

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

Answer 1

Что случилось с старой старой файловой системой?

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

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

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

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

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

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

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

Answer 2

либо XML или двоичные файлы были бы мои предложения

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

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