Войти
ПрограммированиеФорумОбщее

Сериализация vs. базы данных в юнити (3 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#30
17:39, 5 апр. 2018

Alprog
> Почему тогда Notepad не использует базу данных?
Юзер работает с одним тестовым файлом

Alprog
> Или Photoshop?
одним рисунком

причем тут это? клоун?

#31
19:10, 5 апр. 2018

tac
Одной сценой.

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

#32
21:39, 5 апр. 2018

Alprog
> Одной сценой

вот это и странно ... сцена в отличии от текстового файла и изображения, не однородна - это не буквы в словах, и не пиксели в изображении

Alprog
> хоть один игровой движок
причем тут движок? у Юнити есть соответствующие проблемы как у движка, концептуально не преодолимые ... и те кто терял результаты своей работы из за такой работы "одной сценой" думаю всегда были довольны таким супер решением ...

но же говорим о другом даже, ты сделал движок в движке ! и мало того, что сделал, так еще думая, что у тебя там какая та аналогия со сценой ...

Никогда не слышал о таком термине как объектно-ориентированная декомпозиция? видимо нет, если у тебя представление работы со сценой как с одним целым.

#33
21:58, 5 апр. 2018

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

#34
23:38, 5 апр. 2018

tac
> причем тут движок? у Юнити есть соответствующие проблемы как у движка, концептуально не преодолимые
Хорошо, я делаю неправильно. Юнити делает неправильно; Unreal, CryEngine, Defold — все идиоты. Хорошо.
Назови мне хоть одну компанию, хоть один движок, хоть одну игру, где сцены сохранялись бы в бд (кроме ссылок на свои велосипеды, конечно).
Неужели все-все дураки? И Кармак, и Свини, и Пранчкевичус? Неужели только tac во всей вселенной понял, что такое объектная база данных?

> те кто терял результаты своей работы из за такой работы "одной сценой" думаю всегда были довольны таким супер решением
Расскажи мне, как в твоей системе с бд будет реализовано:
— Откат локальных изменений сцены из системы контроля версий;
— Merge изменений, внесённых на одну и ту же сцену с разных компьютеров;
— Тестирование внесённых изменений с последующим откатом обратно;
— Функция «Save as…» с копированием сцены целиком;
— История изменений для Undo/Redo;
— Перенос сцены из одного проекта в другой.

Слушай, расскажи побольше про себя и свой опыт 20+. Мне прям интересно, как можно было столько лет заниматься программированием и остаться настолько невеждой?
И, что самое удивительное, упёртым. Тебе сколько лет-то вообще? Лет 40 же есть? Не стыдно совсем?

#35
5:41, 6 апр. 2018

Alprog
> Назови мне хоть одну компанию, хоть один движок, хоть одну игру, где сцены
> сохранялись бы в бд (кроме ссылок на свои велосипеды, конечно).
Карта в майнкрафте считается за "сцену"?

Alprog
> Расскажи мне, как в твоей системе с бд будет реализовано:
> — Откат локальных изменений сцены из системы контроля версий;
> — Merge изменений, внесённых на одну и ту же сцену с разных компьютеров;
> — Тестирование внесённых изменений с последующим откатом обратно;
> — Функция «Save as…» с копированием сцены целиком;
> — История изменений для Undo/Redo;
> — Перенос сцены из одного проекта в другой.
В принципе, выглядит всё решаемо, в худшем случае велосипедированием версий поверх таблиц БД; вот только времени на прикручивание такого велосипеда к игродвижку уйдёт больше, чем суммарная выгода при дальнейшем использовании, вот никто из серьёзных дядек и не прикручивает.

#36
6:11, 6 апр. 2018

Delfigamer
> Карта в майнкрафте считается за "сцену"?
Ой, там много. О чём там вкратце? Подозреваю, что речь идёт о том, чтобы сериализовать карту в json/бинарь и уже ПОТОМ записывать в базу по каким-то своим причинам.

> вот только времени на прикручивание такого велосипеда к игродвижку уйдёт больше, чем суммарная выгода при дальнейшем использовании
Начнём с того, что ни одной системой контроля версий пользоваться будет невозможно. Если БД реализовано в виде огромного бинаря, то мы за пару недель засрём git-репозиторий и LFS.
Если мы работаем в Perforce, то придётся ставить локи на всю базу целиком и тем самым останавливать работу всех остальных. SVN, mercurial? Тоже как-то не радужно там всё.

Придётся изобретать свою собственную систему контроля версий или вообще принципиально новый способ работы в команде изобретать. Не слишком ли круто?
Ради чего? Ради того, чтобы Ctrl+S отрабатывала не за 0.1, а за 0.09 секунды? Не бредятина ли?

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

#37
6:59, 6 апр. 2018

Alprog
> ни одной системой контроля версий пользоваться будет невозможно
видимо, что такое резервное копирование БД не слышал, да и про логи sql тоже

клоун, у БД и так есть контроль версий через журнал, для того кто в танке, она не нуждается в еще одном

#38
7:00, 6 апр. 2018

Alprog
> Придётся изобретать свою собственную систему контроля версий или вообще
> принципиально новый способ работы в команде изобретать. Не слишком ли круто?
Ну я и говорю.
Delfigamer
> времени на прикручивание такого велосипеда к игродвижку уйдёт больше, чем
> суммарная выгода при дальнейшем использовании, вот никто из серьёзных дядек и
> не прикручивает

Alprog
> Ой, там много. О чём там вкратце? Подозреваю, что речь идёт о том, чтобы
> сериализовать карту в json/бинарь и уже ПОТОМ записывать в базу по каким-то
> своим причинам.
Вот, нашёл прямо описание.

+ Показать

Короче, я опять всё неправильно понял, они не используют БД как БД, им просто была нужна своя файловая система, которая не загибается от 500 мелких файлов по 100 директориям.
#39
7:03, 6 апр. 2018

Alprog
> Не проще ли тогда просто бекапить содержимое в AppData периодически
ага, сделай после окончания ввода свойства и т.п. атомарного действия пользователя .. поржем вместе как скоро юзер нах пошлет такой тормазнутый движок, запись сцены измеряется секундами, а не их долями ... впрочем и так Юнити не блещет в этом, а она лучше всех остальных

#40
7:06, 6 апр. 2018

Alprog
> Неужели все-все дураки? И Кармак, и Свини, и Пранчкевичус? Неужели только tac
> во всей вселенной понял
сам в шоке :))

#41
7:45, 6 апр. 2018

Delfigamer
> они не используют БД как БД, им просто была нужна своя файловая система
Как я и подозревал :)

tac
> клоун, у БД и так есть контроль версий через журнал, для того кто в танке, она не нуждается в еще одном
Какую систему контроля версий предполагается использовать для исходного кода и изображений? Каким образом осуществляется их синхронизация?
После того, как два человека поменяли каждый у себя на компьютере одни и те же записи в БД, какие действия они должны выполнить, чтобы смерджить изменения?
А если при этом менялся ещё и код и изображения?

> как скоро юзер нах пошлет такой тормазнутый движок
Сохранять необязательно синхронно.

> запись сцены измеряется секундами, а не их долями
Купи себе комп и SSD.

> сам в шоке :))
Никто так не делал, потому что это в принципе неюзабельное решение. Оно тянет за собой целые ряд не- или почти нерешаемых проблем.

#42
7:50, 6 апр. 2018

Alprog
> два человека поменяли каждый у себя на компьютере одни и те же записи в БД
база данных одна :) в базе мерджить? совсем основ не знаешь?

#43
8:02, 6 апр. 2018

Alprog
> Оно тянет за собой целые ряд не- или почти нерешаемых проблем.
все там решаемо .. другой вопрос, согласен, более трудоемко, но и более стабильно. Вопрос тут так сказать в кризисе роста, пока сцена однородна или небольшая, то и простое сохранение в файл будет норм, как только она становится структурирована, растут размеры или доступ становится не 'все или ничего' сразу приходится переделывать под бд ... ну и конечно, когда надо получать разные view /select/ с одних и тех же данных, это уже прямое указание, что на сериализации дальше не прокатишь, от слова совсем

а это наступает достаточно быстро, например если хранятся древообразная структура то еще норм, но как только появляется ситуация, что храним одно, например, связи вида ребенок имеет мать и отца, и надо показать такое родословное дерево, то для отображения уже нужен view над этими данными, и не очень простой, соединяющий в одну запись связь ребенок - отец - дед, и т.п. /это лишь пример как мало надо чтобы возникла необходимость во view над данными

#44
8:05, 6 апр. 2018

tac
> база данных одна :)
Лоооооол.

Хорошо, а как же тогда быть в следующих ситуациях:

1. Вся команда работает над актуальной версией игры, а программист в течение дня откатывается на версию недельной давности, двух, трёх и т.д.,
экспериментируя с ними и пытаясь определить момент, когда тот или иной баг впервые появился. Как не мешать остальным при этом?

2. Три программиста работают каждый над своей объёмной задачей. Каждая задача занимает несколько дней и локальные изменения
каждого потенциально приводят к неработоспособности билда до тех пор, пока задача не будет решена. Как не мешать друг другу?

3. Главный программист поехал в Перу и хочет продолжать работать из гостиницы, но вай фай не пашет. Как работать?

Это реальные ситуации, возникающие постоянно. Ты вообще в команде работал когда-нибудь?

Страницы: 1 2 3 4 5 6 7 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.