Разрабатывал локальные базы данных. Но в один момент возникла потребность создать удаленную базу данных на удаленном сервере ( Чтобы к серверу, расположенному на моем компьютере могли подключаться другие устройства по сети ). Помогите организовать.
А в чем собственно проблема? Ставим галочку в настройках сервера "Разрешить удаленные соединения", спокойно подключаемся через SQL Managment Studio и создаем баз сколько потребуется.
Никаких отличий от локальной, разве что:
1. разрешить sql серверу сетевые подключения (например tcp/ip)
2. озаботится безопасностью подключений (ну как минимум чтобы извне вообще не было доступа для sa ролей)
3. несколько позже - подумать о промежуточном звене....
Могли бы Вы прокомментировать 3 пункт пожалуйста?! "промежуточное звено" имеется в виду промежуточный сервер? если нет то что тогда, а если да то с какой целью?(security improving или распределение нагрузок..гадаю).
d-stream, Возможно, я неправильно Вас понял. В данный момент находясь в процессе изучения\написания web-приложения с использованием Spring MVC + java jdbc(Statements\Prep)и и даже не JdbcTemplate ) а JDBC API ибо таблиц не так много и использование JPA+Hiber(знаю.умею), со своим количеством необходимых ресурсов как минимум замедлят выполнение + лишний код ) ~ аналогично создателю поста уткнулся в вопрос: "Где должна находиться База Данных для того чтобы после деплоя приложения к этой БД могли обратиться с любого адреса в интернет-пространстве...при этом чтобы MySQL сервер + базы не находились у меня на компе , логика подсказывает что для этого нужен remote-сервер умеющий работать и как СУБД и как хранилище информации.
В данный момент в моём-shit-app'e подключение к MySQL-серверу(запускается как локальная служба) происходит через сокет "localhost:3306" но в процессе почему-то появилась мысль хранить всю информацию о зарегистрированных пользователях на стороннем "ресурсе"(поддерживающим такую возможность).. Чутье говорит что не туда копаю...но далее этот shit будет приобретать RESTful очертание где планируется в том числе и сервер авторизации(этот я тоже думал разместить в out of application artifact месте)
извините за монолит свыше, но мне(я ещё не Jun) нужен вектор куда копать и каким должно быть правильное понимание конкретного вопроса от человека который знает точно о чём говорит...заранее премного благодарен.
Ну для web приложения так или иначе трехзвенность напрашивается в виде:
- клиентская часть (выполняется в браузере)
- серверная часть (сервер приложений/web-сервер(s))
- база или базы как хранилище
зачастую второе и третье живут на одном сервере, но это не обязательно
но действительно голый sql светить в мир - совсем несерьезно. То есть до sql может достукиваться только web сервер (backend). А уже с ним - могут так или иначе взаимодействовать пользователи web/rest и т.п.
Вот на этом уровне - авторизации и т.п. ("кто такй, давать или не давать ему данные")
Ну и дальше уже можно все это развивать и множить в виде отдельного серверочка-билетера (то бишь web/rest-морда+база авторизаций) который будет раздавать "билеты" (jwt например) для доступа к основному сервису и тот, проверив "билеты" будет что-то добывать из базы/баз. А может не напрямую из баз, а обращаться к некоему пулу серверов приложений которые будут только ему отвечать на запросы уровня бизнес-логики, обращаясь для этого уже к базам.
d-stream, СУПЕР, СУПЕР, максимально исчерпывающий ответ размотавший клубок который я старательно 2 дня скатывал %FACEPALM%... А авторизацию конкретно через токен или Oauth хотел делать))
