Lua против XML для хранения данных

Многие из нас были проинструктированы в использовании XML для хранения данных. Это преимущества и недостатки, как правило, известны, и я, конечно, не хочу обсуждать их здесь. Однако в проекте, который я пишу на С++, я также использую Lua. Я был очень удивлен, насколько хорошо Lua можно использовать для хранения и обработки данных. Тем не менее, этот аспект Lua менее признан, по крайней мере, в мире игрового программирования.

Я знаю, что XML имеет свои преимущества в таких случаях, как отправка данных через Интернет и в места, где безопасность вступает в игру (используя данные, загруженные из сети, например, или загружая редактируемые пользователем файлы конфигурации) и, наконец, в случаи, когда одни и те же данные считываются программами на разных языках.

Однако, как только я узнал, как легко и просто обрабатывать данные с помощью Lua (особенно с luabind, чтобы поддержать вас!), я начал задаваться вопросом, есть ли какая-нибудь причина использовать XML для хранения игровых данных, если мы уже используем Lua в любом случае?

Blizzard, используя Lua для написания пользовательского интерфейса, по-прежнему сохраняет макет в XML. Причина в том, что связано только с UI?

Каковы недостатки использования Lua в качестве языка хранения данных?

Ответ 1

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

Blizzard (WoW) использует XML для определения пользовательского интерфейса. Это похоже на XAML на С#, просто намного менее мощный, и большинство аддонов просто используют XML для загрузки аддона, а затем для создания UI в коде lua.

Также WoW фактически хранит аддон "Сохраненные переменные" в файлах .lua.

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

Хорошая вещь в XML заключается в том, что есть много инструментов и кода, уже написанных для тестирования, записи и анализа XML, что означает, что это может сэкономить вам некоторое время. Например XML Schema очень полезны для проверки файлов, написанных пользователем (безопасность - это только побочный эффект, хорошо, что если он передает вашу схему, данные, скорее всего, на 100% безопасны и готовы к подключению к вашему движку), и там есть немало валидаторов, которые вы уже писали для вас.

Затем снова некоторые пользователи боятся файлов XML (хотя они очень читаемы, возможно, слишком читаемы) и предпочли бы что-то "более простое". Если это просто для хранения (а не для конфигурации), никто в любом случае не собирается редактировать этот файл. XML также займет больше места, чем lua var dump (не имеет значения, если у вас нет большого количества данных).

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

Ответ 2

Спасибо за ваши ответы! Я позволю себе подвести итоги для будущей справки.

Недостатки использования Lua для хранения данных по сравнению с XML

Безопасность как при передаче данных, так и при их хранении, особенно при получении данных из неизвестного источника
Переносимость и простота доступа к данным с помощью других инструментов.
Менее полезные существующие инструменты, такие как валидаторы XML Schema
Меньшая поддержка для анализа данных
Проблемы с циклическими ссылками
Менее ограничительные - сложнее обеспечить соблюдение правильных соглашений, использования и дизайна.

Преимущества использования Lua для хранения данных по сравнению с XML

Использование единого языка для сценариев и данных (нет необходимости в отдельных файлах, нет необходимости в особых случаях при загрузке)
Меньше кода и зависимостей из-за использования одного языка
Более подробный и (возможно) более читаемый человеком
Более гибкий и расширяемый (это язык программирования в конце концов)
Данные "выполняются" и могут быть доступны по мере необходимости, когда они находятся на виртуальной машине.
занимает меньше места, особенно если скомпилировано в байт-код

Если я пропустил что-то в первом списке, укажите его!

Ответ 3

Lua - крупная победа для хранения данных. Удобный, быстрый и легко конвертируемый в другие форматы при необходимости. (Конвертируемость предполагает, что ваши данные будут представлены в других форматах, которые, если они будут представлены в XML, будут.)

Каковы недостатки использования Lua в качестве языка хранения данных?

Я знаю два недостатка, значение которых зависит от вашего приложения:

Если у вас есть таблицы Lua, которые содержат циклические ссылки, например, t1.next == t2 и t2.prev = t1, тогда процесс написания ваших структур Lua на диск становится утомительным, а полученный Lua труднее читать, чем простой return <list of big expressions here>. (Это никогда не случалось со мной, и если ваши данные представляются в XML, это не произойдет с вами.)
Если у вас много данных, например, если вы пишете инвертированный индекс всей инструкции Inform 7, вы можете запустить ограничения Lua на количество различных констант, которые могут появиться в блоке, Затем вам нужно разделить вещи на несколько блоков или функций или прибегнуть к другим решениям. Эта проблема укусила меня, и это огромная боль в заднице. Я хотел бы написать общее решение, но я не на 100% уверен, я понимаю ограничения, и я еще не занимался этим.

Если ваши данные содержат менее 100 000 числовых и строковых литералов, вам не нужно беспокоиться об этой проблеме.

Ответ 4

Я бы сказал, что самым большим недостатком является то, что другим инструментам труднее манипулировать этими данными. Если вы храните данные непосредственно в Lua, тогда вам нужно написать парсер Lua, чтобы автоматически манипулировать этими данными, в то время как в каждой среде есть синтаксические анализаторы и генераторы XML. Это не проблема только для инструментов на других языках; если вы хотите написать графический интерфейс для редактирования вашей конфигурации, есть ли у вас инструменты, которые могут анализировать, изменять и записывать данные конфигурации таким образом, который не влияет на слияние в вашей системе управления версиями? Это может быть важно для больших проектов с большим количеством людей, которые могут редактировать конфигурацию одновременно.

Тем не менее, эта же идея привела к JSON, который является подмножеством JavaScript, используемым в качестве формата данных. Но в настоящее время есть много инструментов, которые поддерживают JSON и, вероятно, не так много, что поддерживает синтаксис Lua.

Другая проблема, возникающая иногда, когда у вас есть код в вашей конфигурации, заключается в том, что люди начинают писать код для создания конфигурации или добавлять абстракции в свой файл конфигурации. И тогда любые пользователи, которые могут захотеть настроить вашу программу, могут запутаться, чтобы узнать, как программировать и весь язык программирования, а не относительно простой язык программирования.

Ответ 5

Если это не безопасность, тогда рассмотрите дисциплину. Если в файле данных имеется полный диапазон LUA, остается возможность добавить логику или поведение в файл данных. Наличие этих объектов, которые являются как данными, так и поведением, может затруднить управление крупным проектом: предположим, например, вы создали игровой движок и целую игру. Теперь вы хотите разделить весь конкретный контент, повторно использовать игровой движок, чтобы создать новую игру. Если контент/данные безопасно разделены от поведения, то это довольно просто. Если в момент слабости вы решили в один прекрасный день, что лучшим решением проблемы является сохранение функции как данных, тогда все становится немного странным.

Возможно, вы сможете обеспечить соблюдение такой дисциплины в своей команде, но, возможно, для пользователя есть вероятность, что она будет использована. Затем по дороге вы решите изменить формат данных, и эти пользовательские расширения не переносимы, поскольку они включают lua, которые не являются данными!

Такие объекты сложнее манипулировать программным способом в массовом масштабе.

И там все другие проблемы, возникающие из-за неправильного разделения проблем. Если вы позволите своим данным и коду перемещаться, все это, вероятно, все еще будет работать, но чем более запутанные вещи получатся, тем труднее они будут рассуждать.

Ответ 6

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

Вы знаете о json? Это может быть больше того, что вам нужно.

здесь две реализации: http://json.luaforge.net/

и здесь http://www.chipmunkav.com/downloads/Json.lua

Если json недостаточно мощный, другой вариант - YAML, надмножество JSON, хотя я не мог сказать вам, есть ли в Lua какие-либо приличные реализации.

Ответ 7

Помните, что виртуальная машина Lua и язык очень гибкие. Вы можете использовать функциональные среды для реализации любой формы безопасности, которую вы хотите, а затем использовать политику, чтобы избежать использования "вредоносного" кода. Просто удалите ВСЕ из среды, в которую вы loadstring() свои данные, и единственная опасная вещь, которую могут выполнять ваши данные, - это запустить цикл и записать CPU.

Остальная вещь, которую следует помнить, состоит в том, что вы всегда можете преобразовать таблицу Lua в XML и наоборот, хотя отображение элементов и атрибутов в таблицы Lua приведет к появлению некоторых странных шаблонов в таблицах.

Ответ 8

Я сделал несколько проектов, которые использовали Lua в качестве языка хранения данных/конфигурации

Ключевым элементом в решении использовать его было "Были ли мы уже используем Lua в этом проекте?"

Другое дело, что его перенос в любую точку можно скомпилировать интерпретатор lua. Его то же самое на всех платформах - нет специальных библиотек xml

JSON - хорошая альтернатива.

Единственный способ использования XML в эти дни - это аннотированный код-гене для сериализаторов .NET xml или JAXB, например).

Ответ 9

Я обычно держался подальше от XML, в основном из-за его многословия. В большинстве случаев я использую CSV или SQLite для хранения данных. Я использую языки сценариев, такие как Lua, Python или Scheme, чтобы предоставить интерфейс для расширения программного обеспечения.