entermix

Маргарет Гамильтон стоит рядом с написанным ей исходным кодом бортового компьютера «Аполлона»

1. Для создания дельты изменений в чем бы то ни было (в тексте, или в бинарных данных и т.п.) есть утилиты/алгоритмы, уже готовые. Можете взять их и адаптировать под себя, например diff. Как это будет реализовано на уровне JS'а в браузере я пока не очень представляю, но гипотетически - это вполне возможно/реализуемо.

Как решить эту проблему? Возможно ли частичное обновление поля в MySQL

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

Судя по контексту эпитета выше - это проблема не базы, а медленного интернета конкретного пользователя. А так же, какие-то серьёзные ошибки архитектуры. Каким образом пользователи умудряются прислать половину запроса - я не очень представляю, такое даже в "лабораторных условиях" довольно не просто сэмитировать, не говоря уже о том, что бы подобное повторялось многократно. Но если уж у Вас запросы как-то кусками умудряются приходить - ставьте в конце запроса какой-то маркер, который не сможет воспроизвести пользователь, например, какой-то бинарный символ, который будет говорить о том, что это конец сообщения. Если его нет - выдавать пользователю сообщение, что всё очень и очень плохо...

Как выявить частичные изменения, чтобы не гонять весь текст целиком, а только внесённые изменения? Поделитесь опытом.

Ответ на этот вопрос содержится в 1-м абзаце, выше по тексту :)

Кроме того, как только пользователей станет много, подозреваю, сервер ляжет.

Довольно странно будет, если у Вас база ляжет от такой нагрузки... Это скорее больше похоже, опять таки, на серьёзные ошибки в архитектуре, а не проблемы БД/сервера как таковых.

CRM - это Customer Relationship Management, взаимоотношения с заказчиками.
При чем здесь "управление учебным процессом"???

CRM, это, например, ведете вы сделку, к которой нужно 100 согласований на разных уровнях - вот CRM и позволяет вам не забыть.
Или, к примеру, не забыть поздравить любимого крупного заказчика с днем рождением; прочитать в CRM, что он любит Спартак и подарить ему билеты на "Спартак - Челси" - это тоже можно назвать функцией CRM.

Прямого отношения к управлению собственным учебным процессом это не имеет.
Только косвенное.

=========================

Делается серверное API.
К которому потом запросто подключается веб-клиент, мобильный клиент и десктопный клиент.

Я вас разочарую, но в крутых БК это все делается ручками, причем достаточно высокооплачиваемых аналитиков. Матч могут перенести, отменить и т.п. Это никакой автоматикой не просчитаешь. То же самое и с линией, то бишь ставками. Для live может быть и есть какое-то добавочное ПО, которое на основании статистики по матчу (кол-во ударов, владение мячом, замены и т.п. ) корректирует ставку, но эти данные тоже надо где-то получать в реальном времени. Ну и результат тоже вносится руками, так как это важно, это же деньги. А результат там может быть не один - ставки бывают и на забитые мячи в определенном тайме, и разница забитых мячей и много чего еще. Ну и по этому событию (которое вручную ставит аналитик) уже начисляются выигрыши или возвраты. Это можно и нужно автоматизировать. Но это как раз, примитивная математика.

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