История изменений
Исправление vbr, (текущая версия) :
СУБД вовсе не обязательно предполагают SQL. Они бывают разные.
Я думаю, в этом топике речь преимущественно про традиционные РСУБД и про язык SQL, как стандартизированное средство взаимодействия с ними.
Тебе не нужно обеспечивать мультиверсионность или блокировки, у тебя, например, смартфон с одним пользователем по определению.
Да, в таком случае тебе скорее всего не нужна СУБД, как я собственно и говорил.
Но с другой стороны в том же sqlite много хорошего. К примеру даже простая задача сохранения данных на практике приводит к многим вопросам. Просто перезаписывать? Батарея сдохла на середине перезаписи и юзер потерял все данные. Нехорошо. Сохраняем в новый файл и переименовываем? Очень неэффективно. Если данные в память не хочется грузить целиком - сразу возникает куча интересных проблем, давно решённых в sqlite. Когда проект развивается, развивать схему СУБД с миграциями это понятный и простой путь. Когда схема где-то неявно описана в коде, это сложно.
Так что про «не нужна» многие поспорят. Где провести границу между оправданностью велосипеда - очень нетривиальный вопрос.
Я видел мнение, что в 100% случаев для хранения данных надо использовать sqlite. Т.к. он строго лучше любого другого формата. Даже для передачи данных надо передавать sqlite файл, а не XML/JSON/Protobuf.
Исходная версия vbr, :
СУБД вовсе не обязательно предполагают SQL. Они бывают разные.
Я думаю, в этом топике речь преимущественно про традиционные РСУБД и про язык SQL, как стандартизированное средство взаимодействия с ними.
Тебе не нужно обеспечивать мультиверсионность или блокировки, у тебя, например, смартфон с одним пользователем по определению.
Да, в таком случае тебе скорее всего не нужна СУБД, как я собственно и говорил.
Но с другой стороны в том же sqlite много хорошего. К примеру даже простая задача сохранения данных на практике приводит к многим вопросам. Просто перезаписывать? Батарея сдохла на середине перезаписи и юзер потерял все данные. Нехорошо. Сохраняем в новый файл и переименовываем? Очень неэффективно. Если данные в память не хочется грузить целиком - сразу возникает куча интересных проблем, давно решённых в sqlite. Когда проект развивается, развивать схему СУБД с миграциями это понятный и простой путь. Когда схема где-то неявно описана в коде, это сложно.
Так что про «не нужна» многие поспорят. Где провести границу между оправданностью велосипеда - очень нетривиальный вопрос.