AS3 с подключением mysql с сокетами или PHP?

Question

Итак, мы хотим выйти из Air (среди прочего, прекращение поддержки Adobe и очень плохая реализация sqlite api).

Я хочу сделать 3 вещи:

1. Соединение с помощью flash (не веб) приложения с локальной базой данных mysql.
2. Соединение с фальшивым (не веб) приложением к удаленной базе данных mysql.
3. Соединение с флэш (веб) приложением с удаленной базой данных mysql.

Все это можно сделать без проблем, однако: 1 и 2 можно сделать (БЕЗ использования веб-сервера), используя, например, следующее:

http://code.google.com/p/assql/

3, насколько я понимаю, можно сделать и с помощью приведенного выше.

Вопрос:

• если вы можете соединиться с сокетом с сервером mysql, зачем использовать веб-сервер (например, с php) для соединения, как между собой? почему бы не подключиться напрямую?
• Я делал это много раз, например, с использованием AMFPHP, но не быстрее ли будет работать напрямую?
• В случае доступа к локальному компьютеру это будет более простое приложение для развертывания, для которого требуется только приложение флэш-памяти + сервер MySQL, а также не нужно устанавливать веб-сервер. Это предположение верно?

Заранее большое спасибо.

Answer 1

Поскольку удаленное подключение через Интернет создает огромные проблемы с безопасностью.Вы никогда не должны развертывать приложение, которое подключается через Интернет к базе данных напрямую.Вот почему AIR и Flex не имеют удаленных драйверов Mysql, потому что они никогда не должны использоваться, за исключением инструментов разработки.И даже если вы создали инструмент, который мог бы подключаться напрямую, любой администратор нисходящей сети заблокирует доступ к базе данных из любой точки за пределами DMZ и внутренней сети.

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

Во-вторых, большинство баз данных не шифруют учетные данные или данные, проходящие черезпровод.Хотя большинство баз данных поддерживают SSL-соединения, большинство людей не включают его, потому что приложения хотят сверхбыстрого доступа к данным и не хотят платить за шифрование SSL-бла-бла-бла.Кроме того, большинство приложений находятся в демилитаризованной зоне, а их база данных находится за брандмауэром, поэтому между сервером и базой данных вряд ли что-то может быть подслушано в их разговоре.Однако, если вы подключились напрямую из приложения AIR к базе данных, было бы очень легко вставить себя в середину и наблюдать за трафиком, исходящим из вашей базы данных, потому что вы не используете SSL.

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

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

Answer 2

Необходимость отдельного уровня доступа к данным обычно обусловлена ​​тем, как люди создают приложения, многоуровневой архитектурой, распределением рабочей нагрузки и т. Д. SQL-сервер обычно не предоставляет очень надежного API для управления пользователями, управления сеансами и т. Д., Поэтому можно было бы использовать промежуточный уровень между базой данных и клиентским приложением, чтобы этот уровень мог решать проблемы, не связанные непосредственно с хранением данных. Безопасность также играет здесь важную роль. Есть и другие проблемы, например, иногда вы хотели бы закрыть весь доступ к базе данных по причинам обслуживания, но если у вас нет промежуточного уровня, чтобы уведомить пользователя о вашем намерении, вы уходите им интересно, живо ли ваше приложение. Слой доступа к данным также может выполнять много операций кэширования, фактически сохраняя ваши поездки в базу данных, вы должны были бы сделать это из клиента (конечно, клиент может сделать это тоже, но ymmv).

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