Сергей Сулаков

Вполне себе любая развитая современная РСУБД годится для этой задачи.
MySQL, PostgreSQL...

А по мере роста нагрузки - тут не выбором СУБД нужно заморачиваться, а MQ-сервер ставить. Он гораздо легче сравиться с бешенными нагрузками.

Как вариант - Queue на базе Tarantool, например. Я даже не знаю что вы там должны такое сделать, чтобы заткнуть его производительность. При условии того, что на сервере достаточно много оперативной памяти.

Из самого критично подозрительного - полнотекстовый поиск.
Впрочем, полагаю, что полнотекстового поиска средствами MySQL или PostgreSQL вплоне хватит.

Если уж делать прям таки серьезный чат типа Slack, то для полнотекстового поиска я бы вообще отдельную специализированную БД держал бы. Например, SphinxSearch.

Но, для начала, возможностей PostgreSQL или MySQL будет вполне достаточно.

Что до Mongo... Если вам не нужна репликация без консистентности. Зато быстрая...
Так вот если вам не нужна такая репликация, то Монга вам не нужна.

РСУБД будут существенно быстрее.

Вот ежели вы планируете заводить ваш чат в кластер, когда одного сервера вам не хватит, то тут да, тут РСУБД не лучший выбор. Тут бы я рекомендовал как раз Монгу.
Но опять таки кластер серверов для чата вы без MQ не сделайте.

Вывод:

Начните с обычной РСУБД.
Как начнутся затыки - рассмотрите MQ
Как начнется рост до масштаба планеты - рассматрите Монгу.

Вся система работает с бд MySQL - InnoDB, сообщения пишутся в бд при каждой отправке (INSERT), пока сервис еще не запущен, сообщений мало (только мои тестовые) все работает шустро, но вот когда запущу и количество сообщений перевалит за несколько миллионов, что будет тогда с моей бд? Начнутся жесткие тормоза при select и insert?

Вам никто не мешает это проверить.
Сгенерируйте миллион случайных сообщений.

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

Это конечно говнокод, но ошибка только одна:

var n = prompt('введите начальное число диапозона', '0');
var k = prompt('введите конечное число диапозона', '0' );

prompt возвращает строки а не числа, поэтому нужно конвертировать в число, например так:

var n = parseInt(prompt('введите начальное число диапозона', '0'), 10);
var k = parseInt(prompt('введите конечное число диапозона', '0' ), 10);

через Number или parseInt.

Вообще, полезно знать разницу при сравнении чисел и строк:

9 < 10 // true
'9' < '10' // false

Во втором случае получается «ложь», потому что строки сравниваются по кодам символов, начиная с первого символа, те '9' < '1'. Смотрим коды символов:

'9'.charCodeAt(0) // 57
'1'.charCodeAt(0) // 49

57 больше 49, поэтому сравнение заканчивается, выдавая значение false.
Поэтому условие цикла n <= k работает не как ожидается.

Посмотрите среди платёжных агрегаторов, кто работает с физлицами, решение этого вопроса есть. Здесь этот вопрос тоже задавался не однократно и решения указывались.
Плюс есть ещё Яндекс Деньги и Киви, где платежи можно принимать на свои верифицированные кошельки картами и с кошельков, будучи физлицом, а потом переводить себе на карту либо заказать у них карту к кошельку. Но там другие нюансы.

Ответ прост:

['orderBundle'] массив нужно превращать в json.

$zaraza[] = array(
	'positionId' => '1',
	'name' => 'something stuff',
	'quantity' => array(
		'value' => 1, 
		'measure' => 'st'
	),
	'itemAmount' => $sum * 100, // возвращаемая сумма
	//'itemCurrency' => 643,
	'itemCode' => 'z-xc', // код продукта
	'tax' => array(
		'taxType' => 0
	),
	'itemPrice' => $sum * 100
	);
$zaraza2 = array (
	 'cartItems' => array('items' => $zaraza)
);	

$requestpay[ 'orderBundle' ] = json_encode($zaraza2); // ВСЯ ФИШКА ЗДЕСЬ

Но также стоит отметить, что нельзя ошибаться в значениях полей.

Софт одинаковый везде.
Настройки разные, версии разные.

OpenServer это не программа, это просто пачка разного софта в упаковке.
Хостинг это тоже всего лишь компьютер с тем же софтом, а не какая-то магическая штука/программа.

В общем курите гугл что и как. Пока у вас не будет представления об этом.

Системный администратор в связке с разработчиками вполне может это сделать.
1. Поставить nginx для балансировки
2. Размножить сервер на две ноды
3. Решить вопрос с БД - там или ее перемещать на отдельный сервер или делать связку один мастер - две реплики на нодах. Запись только в мастер, чтение с реплик.

Делов то :)

Почитайте в конце концов про ассиметричную криптографию и PKI.
В общем в кратце так, хотите с клиентами юридически значимый электронный документооборот - подписываете с каждым соглашение, что стороны соглашаются считать собственноручной электронную подпись сделанную с помощью такой-то технологии.
Технология при этом может быть различная. Довольно простой и легкий вариант - PGP, это не PKI, но довольно близко.
Каждая сторона генерирует себе пару ключей (секретный/публичный), публичный ключ передается противоположной стороне. С помощью соответствующего софта файлы подписываются и отправляются второй стороне.
Тут важно, что каждый из участников сам генерирует себе ключи и приватный ключ никому никогда не передается.
Именно по такому принципу работают большинство банков, только они обязаны использовать отечественную сертифицированную криптографию (CryptoPro, КриптоКом ...).

Если перейти на PKI, то добавляется еще один персонаж - центр сертификации (ЦС). Каждая сторона, после того как сгенерирует ключ отправляет запрос на сертификат в ЦС и получает от него сертификат. Сертификат, это по сути публичный ключ, подписанный на ключе ЦС с различными ограничениями. Например есть ограничение на срок использования сертификата.

Точно не уверен, но вроде как в нашей стране нельзя использовать западную криптуху по закону, поэтому лучше сразу ориентироваться на отечественный софт. Например не плохой вариант CryptoPro+КриптоАРМ. Отечественная стоит денег.
Если спросите, а что насчет SSL - там же сплошь западные алгоритмы, не сертифицированные, отвечу - в законе есть специальные оговорки про это, смысл в том, что если не возможно удалить из ПО поддержку западных алгоритмов, то можно. Но применительно к документообороту это не притянуть.

Если делать через код, то создаешь кнопку и далее привязываешь действие к ней.

UIButton *button  = [[UIButton alloc] init];
[button addTarget:self action:@selector(pushButton:) forControlEvents:UIControlEventTouchUpInside];

и дальше создаешь метод pushButton (тот что указан в action)

- (void)pushButton:(id)sender{
//code 
}

Если ты делаешь через сториборд, то

- (IBAction)refresh:(id)sender{
 //Code
}

нажми ПКМ на кнопку и перетащи на эту функцию или на пустой код и в появившемся окне выбери Action и xcode сам создаст аналогичную функцию

Urlencode

При разработке нормализованной или денормализованной базы размер HDD играет последнюю роль.

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

Нормализуя данные вы перекладываете часть логики проверки данных на СУБД, такие как консистентность и (частично) корректность. То есть уже на уровне вставки/изменения данных вы не можете не заполнить обязательное к заполнению поле или изменить поле в одной таблице, но забыть (или неправильно изменить) в другой (консистентность), вы не можете в поле date внести не дату, а в в поле int не int (корректность) и вы не можете удалить запись, если есть записи, которые на неё ссылаются (консистентность).

Нормализованное состояние БД это идеальное состояние базы, денормализацию нужно делать только если без неё никак не удаётся достичь нужных результатов (при условии, что вы разбираетесь как работает СУБД, как выбираются данные, индексы, сортируются и ищутся пересечения), если для вашей системы достаточно одного сервера, то в 99% случаев денормализация данных вам совершенно не нужна и противопоказана.
Проще говоря - если вы не знаете зачем нужна нормализация, то вам однозначно она нужна.

Нормализация нужна для борьбы с избыточностью. т.е. данные не дублируются и связаны только внешними ключами.
Видимо это было очень важно когда размер HDD был 10 мегабайт. Текущая практика показывает, что полностью нормализованная база работает очень медленно, т.к. обледенения данных это дорогая операция. Так же вы верно подметили относительно роста сложности запросов.
Однако в нормализации обновляемых данных есть и жирный плюс, вам не надо обновлять/удалять и вставлять, одни и те же данные в куче таблиц. Ведь это тоже сложно, держать в голове всё, что нужно обновить, что приводит к ошибкам. Также решает вопросы сложности разгуливания операций изменения данных когда операция прошла не полностью.

Поэтому оптимальность где то посередине.

Так же не забываете, что нормализованные таблицы гораздо проще проецировать на модели в языках программирования.

Количество не играет роли.
Играет роль:
1) Влезают ли индексы в отведённую для них память.
2) Хватает ли IO на диске для записи данных.
3) Хватает ли процессора для перестройки индексов.

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