Дмитрий Энтелис

Сильно ли отличаются цены на хостинг, по сравнение с php хостингом. Тоже самое о администрировании сайта?

ASP тянет за собой стек технологий Microsoft, поэтому да, отличаются.
Что такое "администрирование сайта" в данном контексте не очень понятно.

Возможно ли делать небольшие проекты на ASP(и удобно ли это) ?

Если Вы знаете ASP - удобно. Ну и если ухитритесь найти заказчика который на это согласен.
Как мне кажется, ASP живо в сегменте интранета и в какой то степени около enterprise разработки, в вебе на нем проектов исчезающе мало. Это субъективная точка зрения основанная на личном опыте и знакомствах, возможно я не прав.

С точки зрения разработчика сайта или с точки зрения пользователя?

1) С точки зрения пользователя: поставить длинный сложный пароль который нигде более не используется, записать его на бумажке, бумажку сжечь, пепел развеять.
С точки зрения разработчика: вариантов куча.

2) Прикрепленный номер таки всегда можно восстановить. Если номер не привязан к паспорту - ну пользователь сам идиот.

Интересная проблема.

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

По пунктам того что Вы пишите:

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

Запросы реально исполняются несколько минут? Какой объем данных передается в ответе? Какой канал между серверами, не забивается ли он? Потребление памяти/процессора на SQL сервере в момент выполнения запроса?

Есть тупая идея увеличить max_connections, но я сомневаюсь что в Вашем случае это поможет, скорее всего проблема не в этом.

Это при том, что подключение к удаленной БД происходит прямо перед запросом, а закрытие подключения сразу после.

Можно так же попробовать использовать persistent connection, не будет оверхеда на постоянные подключения/отключения.

Возможно надо посмотреть в сторону оптимизации самих запросов, дробления их на части итд.

Правильное решение - перестать работать в этом ценовом сегменте.
Геморроя немерено, денег ноль, полезного опыта ноль.

www.ponyexpress.ru

google по запросу "crm для фитнес клуба" выдает много всего.
imho можно разделять процесс продаж вообще и процесс автоматизации клуба и учета.
Из того что я лично знаю по факту в одном из фитнес клубов: автоматизация клуба и статистика посещаемости на базе 1c, процесс продаж в amocrm.

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

Если нужно синхронизировать только структуру - любой менеджер миграций структуры, мне лично нравится https://phinx.org/ но есть много альтернатив.
Если нужно разово переносить "наработки за день"- можно сделать простенький скриптик с mysqldump и переносить им.

Любые решения с multi-master репликацией работают достаточно омерзительно, накладывают серьезные ограничения на запросы и требуют стабильного соединения между серверами.

Я стесняюсь спросить - а зачем вообще это? Не проще на бекенде делать нумерацию строк если уж так надо?
Или в чем вообще задача?

Любую задачу можно:
a) разбить на подзадачи
б) если время выполнения подзадачи не понятно либо понятно, но превышает 2-3 дня - см пункт "A"
в) исключение: задачи когда непонятно вообще ничего (освоение новой технологии, нового api итд) - тогда так и надо ставить задачу "research", с временем длительности определяемом субъективно.

+ нет смысла заниматься преждевременным планированием.
Мы детализируем с точностью до часа задачи на планируемый спринт (~5 дней)
Задачи на спринт после него - с точностью до дней.
Более поздние задачи - с точностью до недель.

PS Был хороший доклад Аксёнова не совсем про это, но близко: biqle.com/watch/2406506_152600625 очень рекомендую.

Даже если Вам на почту не приходит сохраненный пароль - это не значит что в недрах базы он не хранится plain text.

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

Я лично применяю это правило к ключевым для меня сайтам (+ где можно включаю двухфакторную аутентификацию), для ресурсов где регистрация не представляет для меня никакой ценности - один общий пароль.

Так работают киберсквоттеры.
Через пару дней-недель ждите письмо счастья с предложением купить домен обратно за крупную сумму $

судя по коду Users::model() возвращает какой то объект у которого вызывается метод findByPk с параметром $id

paypal, webmoney, - да кто угодно у кого есть массовые выплаты.
но готовьтесь к куче интимных вопросов на тему содействия терроризму, отмыванию денег итд итп

1. На старте - биржи фриланса. Потом - повторные обращения + рекомендации старых заказчиков.
2. см п.1

Я в целом согласен с ответами myfirepukan (отличный ник кстати хехе), Вячеслав Успенский , Виктор Ablebeam

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

На тех проектах что у Вас есть - выбор языка это чисто менеджерское решение.
По опыту выгоднее всего PHP - больше свободных разработчиков, ниже средний уровень зарплат.
Принципиальной разницы между скриптовыми языками по быстродействию/скорости разработки нет, а вот найти человека на Ruby/Python существенно дольше&дороже.

Что касается холивара в плане существующий framework / самодельный framework - единого ответа нет.
Если у Вас будет самодельный - будет оверхед для новых людей на изучение технологии (+ в ситуации когда нет однозначно квалифицированного персонала - велик шанс нарваться на говновелосипеды в коде), но зато для тех кто его разрабатывал - нет blackbox в коде.
Если использовать существующий - можно просто формулировать вакансию на уровне "требуется опыт с laravel/yii2/...".

В целом я бы вам рекомендовал связку php+массовый фреймворк.

PS Сейчас перечитал вопрос - мы тут что то все начали обсуждать на каком языке работать, а Вы то спрашивали как найти разработчика.
Если технических компетенций не хватает что бы оценить человека на примере тестового задания - найдите живой не срочный проект, завысьте сроки в 2-3 раза перед заказчиком, отдайте проект исполнителю. Уложится в сроки - значит он Вам подходит :-)