Как я хранил данные в Godot: почему JSON победил.tres и MySQL

[Zx2001]

Ллм слоп - не по содержанию, которое интересно, а по стилю. Зачем авторы как будто спецом портят текст и прячут часто неплохую идею/мысли/инфу за слоп?

[Plus3s]

Перед вами мой сознательный текст о моем сознательном выборе. Мне что, надо было душу вам тронуть, чтобы заслужить поощрение? Или вернуться к наскальной живописи? Я просто охреневаю от охотников за привидениями здесь.

[crama]

Это ж твоя 9-я статья. Первый раз вахтеров встречаешь?

[Plus3s]

Ну раньше как-то так ещё не было. Получается, что недовольные всегда есть и они рядом. Тут 100 раз подумаешь, прежде чем писать 10-ю статью.

[HemulGM]

JSON

1. Нет никакой защиты

2. Нет гибкости и масштабируемости (сегодня 20 человек, через год 200)

3. Для поиска и работы ты вынужден держать всё в ОЗУ

SQLite был бы идеальным выбором:

1. Это самая простая бд, файловая, не требующая установки

2. Быстрый поиск

3. Есть легковесные редакторы бд для быстрой правки

4. Миграция - проработанный механизм

5. Если нужно будет, легко заменить на крупную бд без необходимости вообще вносить правки в коде

Как итог: хранить в json чуть проще, чем SQLite, но это не стоит того

[Plus3s]

1. Скорость в доли секунды не важна, когда у тебя в базе всего несколько десятков строк.

2. Когда в базе несколько десятков строк, я нахожу нужную практически сразу же (быстрее, чем через какой-либо поиск)

3. Ну, в общем-то смотри первые два пункта

4. Отлично. Буду иметь в виду, если понадобится

5. Вообще никогда не нужно будет

   Вопрос: а зачем оно мне, если меня абсолютно всё устраивает? В данном случае, если вы не поняли, преимущество в простоте.

[stvoid]

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