Comments 22
Вопрос: а это зачем вообще может понадобиться?
Я просто не могу представить, в каких случаях клиентскому приложению можно предоставить прямой доступ к БД…
Я просто не могу представить, в каких случаях клиентскому приложению можно предоставить прямой доступ к БД…
Ну в моём случае мне понадобилось создать онлайн хранилище для игровых карт. Чтобы пользователи могли иметь доступ ко всем картам, и добавлять свои. Для этого они должны были иметь доступ к какой-то общей БД. А при аренде веб-хостинга как правило доступна и БД на MySQL. Так что грех — не воспользоваться такой возможностью.
а можно по подробнее описать этот процесс.
я так понял — этот код находится на сервере
Пользователи, по какому-то определенному запросу загружают из БД определенный объект 3dUnity?
я так понял — этот код находится на сервере
Пользователи, по какому-то определенному запросу загружают из БД определенный объект 3dUnity?
По подробнее я это опишу позднее в отдельной статье.
Но в принципе в самой игре идёт обращение к БД. Считывается список доступного контента и сравнивается с имеющимся. При необходимости из БД докачивается необходимый контент.
На самом сервере есть только таблицы с данными и несколько процедур для добавления/удаления контента.
Но в принципе в самой игре идёт обращение к БД. Считывается список доступного контента и сравнивается с имеющимся. При необходимости из БД докачивается необходимый контент.
На самом сервере есть только таблицы с данными и несколько процедур для добавления/удаления контента.
Простите, вы знаете что такое Application Layer и API?
Прямой доступ к БД из клиента — крайне плохая идея, ждите много-много хакеров.
Прямой доступ к БД из клиента — крайне плохая идея, ждите много-много хакеров.
Ну, я постараюсь правильно задать роли в БД;) Всё-таки моя специальность — защита информации. Не получится, буду искать другие варианты
Вам тут пытаются объяснить, что должно быть n-tier приложение:
Unity3D Client <=> Web Services / Web Application <=> RDBMS / Other data storage
Если у вас приложение имеет прямой доступ к БД, то строку подключения вы храните внутри, видимо. Стало быть рано или поздно юзеры получат пароль от БД, и все накроется медным тазом.
Так что надо делать сразу нормальную архитектуру, а не потом выгребать дерьмище :)
Unity3D Client <=> Web Services / Web Application <=> RDBMS / Other data storage
Если у вас приложение имеет прямой доступ к БД, то строку подключения вы храните внутри, видимо. Стало быть рано или поздно юзеры получат пароль от БД, и все накроется медным тазом.
Так что надо делать сразу нормальную архитектуру, а не потом выгребать дерьмище :)
Что накроется медным тазом если у пользователя будут права только на SELECT определённых таблиц и выполнение пары-тройки процедур?
Естественно, что у каждого пользователя будет своя учётная запись в БД.
Естественно, что у каждого пользователя будет своя учётная запись в БД.
И вся игровая логика в виде trigger-ов? Это крайне плохая идея.
я где-то говорил про игровую логику и её реализацию?
Это просто гайд о том как обращаться из Юнити к БД. Не надо делать из него далеко идущие выводы.
И что такого плохого в реализации логики на базе триггеров, кроме её сложности?
Это просто гайд о том как обращаться из Юнити к БД. Не надо делать из него далеко идущие выводы.
И что такого плохого в реализации логики на базе триггеров, кроме её сложности?
«Это просто гайд о том как обращаться из Юнити к БД.»
Это просто гайд как ни в коем случае нельзя строить архитектуру клиент-серверного приложения.
Во-первых, я, может и не настолько глубоко знаю возможные дыры в безопасности СУБД конкретной, но есть такой принцип Разделение Ответственности. Не должно быть интеграции в одном месте сразу и слоя презентации (UI), и слоя работы с данными (Сервисы и Безопасность).
Если Вы храните критическую к секьюрности инфу на стороне клиента, то Вы в потенциальной опасности. Если реквезиты доступа к хранилищу данных находятся в недоступном для конечного пользователя месте, то уровень безопасности становится на порядок выше.
Во-вторых,
«И что такого плохого в реализации логики на базе триггеров, кроме её сложности?»
сложность это уже весомый довод, чтобы так не делать. Нужна особая причина, чтобы этой сложностью пренебречь.
Это просто гайд как ни в коем случае нельзя строить архитектуру клиент-серверного приложения.
Во-первых, я, может и не настолько глубоко знаю возможные дыры в безопасности СУБД конкретной, но есть такой принцип Разделение Ответственности. Не должно быть интеграции в одном месте сразу и слоя презентации (UI), и слоя работы с данными (Сервисы и Безопасность).
Если Вы храните критическую к секьюрности инфу на стороне клиента, то Вы в потенциальной опасности. Если реквезиты доступа к хранилищу данных находятся в недоступном для конечного пользователя месте, то уровень безопасности становится на порядок выше.
Во-вторых,
«И что такого плохого в реализации логики на базе триггеров, кроме её сложности?»
сложность это уже весомый довод, чтобы так не делать. Нужна особая причина, чтобы этой сложностью пренебречь.
А ещё есть бритва Оккама. И если для конкретной задачи безопасность можно обеспечить средства БД, то какой смысл выносить эти функции в отдельный слой?
Это уже дело разработчика.
И вообще откуда столько негатива?
сложность это уже весомый довод, чтобы так не делать. Нужна особая причина, чтобы этой сложностью пренебречь.
Это уже дело разработчика.
И вообще откуда столько негатива?
Еще одна причина, почему так делать не надо: вы не сможете абстрагировать БД от клиента. Клиент-серверная технология обычно подразумевает абстрагирование сервера от клиента, а Вы хотите захардкодить работу с БД прямо в клиента.
Я молчу о том, что Ваша БД будет для хакеров как на ладони.
Но если Вы вдруг в один прекрасный момент захотите, например, поменять структуру таблиц или вообще заменить СУБД на какую по-интереснее, Вы этого сможете сделать, только заставив пользователя заново скачивать Вашу игру.
К сожалению, я всё ещё не могу придумать, когда может понадобится подключаться из Unity к MySQL напрямую, кроме как из любопытства…
Но если Вы вдруг в один прекрасный момент захотите, например, поменять структуру таблиц или вообще заменить СУБД на какую по-интереснее, Вы этого сможете сделать, только заставив пользователя заново скачивать Вашу игру.
К сожалению, я всё ещё не могу придумать, когда может понадобится подключаться из Unity к MySQL напрямую, кроме как из любопытства…
Всё-таки моя специальность — защита информации
Да вы, должно быть, шутите
Собственно, и я об этом говорю))
Никакими ролями в БД тут не обойдешься, если ты делаешь игру не для себя и другана, а для массового пользователя.
Никакими ролями в БД тут не обойдешься, если ты делаешь игру не для себя и другана, а для массового пользователя.
Мдем. После прочтения заголовка ждал мануала по использованию libmysqld из C#, а тут…
Нужно больше стриншотов с пунктами меню!
Использование баз данных прямо из клиентского кода — обычное дело для простых инди систем или начинающих инди разработчков. Если смотреть на статью сквозь эту призму, то статья годная. С архитектурной же точки зрения, так делать низя — нужно отделять мух от котлет.
Sign up to leave a comment.
Unity3D и MySQL