V Sh.

Роберт Найстром "Game programmig patterns" - про устройство игровых движков: что он должен в себя включать, как устроен и прочее.

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

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

Можно сделать это посредством работы с БД.
1) Создать триггер, который при добавлении новой записи в таблицу заказов будет посылать вам письмо с подробностями.
2) Создать процедуру, которая будет формировать необходимую отчетность и производить необходимые дейсвтия и засунуть ее в шедуллер. Это же можно сделать и с помощью языка программирования (подойдет практически любой).

Есть три подхода для создания игр, если ты новичок:
1) Это брать и делать. Не планируя далеко вперед, наступая на всевозможные грабли, преодолевая и себя и свой плохой код. Минусы очевидны. Плюсы: не нужно заморачиваться с теоретической базой, делаешь все тяп-ляп "лишь бы работало", но зато обрастаешь практическими знаниями как на дрожжах.
2) Читать методологическую литературу. Долго, муторно, упорно. Причем большинство годной литературы есть только на английском. Выписывать то, что тебе кажется пригодиться в разработке, написать какой-никакой план своих будущих действий. Минусы: это долго, это тяжело, ты забываешь то, что прочитал не так давно. В конечном случае все получится не так, как ты планировал. Плюсы: ты будешь на чужом опыте научен всевозможным граблям. Другое дело, что ты и не поймешь почему это грабли, т.к. практики маловато.
3) Найти опытную команду и вступить туда джуном. Причем обязательно в новый проект. Небольшой. Можешь даже ничего там не делать, кофе носить, но ты должен быть в курсе всего, что там происходит. Постоянно следить за изменениями, интересоваться почему это делают так, а не иначе и все в таком духе. Плюсы очевидны.

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

А что касается непосредственного вопроса, судя по всему вы даже не знаете как устроены игровые студии и их разработка, что собой представляет игровой движок... Прочтите, для начала, книгу "Game Engine Architecture" Джейсона Грегори, чтобы иметь представление о главном инструменте в руках разработчика игр. Вот там описано что такое движок, из каких подсистем он обычно состоит, как это обычно реализуется и как с этим работают программисты и творцы игр.

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

В направлении "формируем и отправляем pdf на стороне сервера". Навскидку это решается так. Пишется фронтэнд, который получает данные и post-запросом отправляет их на сервер. На сервере при получении такого запроса, приложение записывает полученную информацию в базу данных (хранение), строит pdf-файл на основании этих данных и отправляет по почте.

Не делите таблицу. Просто для первой строчки - свой стиль, для всех остальных - другой.

Если удаление какого-либо элемента в таблице БД рушит всю систему, то база данных спроектирована неверно: где-то не указаны первичные ключи, где-то опущена логика удаления элементов (например, каскадная). Другое дело, что доступ к БД напрямую имеет только администратор системы и напрямую работать с таблицами не рекомендуется (но можно, если осторожно).

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

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

Если вы делаете фильтр и хотите его куда-нибудь передавать, например, другому человеку копированием ссылки, то следует состояния хранить в адресной строке в качестве параметра. Пример: demo.com?mychecker=1.
Затем уже на этой странице строить и фильтровать что нужно, извлекая информацию из адресной строки.

Если очень вкратце, то:
1) Собственно, сервер (свой или выделенный, физический или виртуальный). Вы на нем царь и Бог. Сами ставите удобную для вас ОС (Linux, Windows Server или что-то еще). Сами разворачиваете службу (IIS, Apache и пр.), которая будет отвечать на запросы пользователей(обычно по портам 80/443 http/https, если речь о WEB'е) . Если у вас одиночный сервер, то запиливаете сюда же и базу данных по своему вкусу. Конфигурируете это все, настраиваете брандмауэр и еще всякую фигню. Когда сервер работает - вы публикуете свои сайты/приложения в папки (физические и виртуальные) службы (IIS, Apache).
2) Хостинги. То же самое, что и пункт 1: только всю работу по настройке (выбор платформы, БД и пр.) берет на себя провайдер, а вам предоставляет доступ (обычно через WEB-интерфейс, FTP и SSH) ТОЛЬКО на закрепленную за вами папку в службе (IIS, Apache) и ТОЛЬКО к вашей схеме/каталогу БД.

Это что касается размещения вашего приложения. Сама же работа довольно таки простая: Браузер шлет запрос серверу (для простоты рассмотрим GET HTTP по порту 80). Сервер принимает запрос через службу, которая денно и нощно прослушивает требуемый порт на наличие запросов. Получив запрос, служба парсит его, выделяет из заголовков нужную информацию (тип, кому предназначена, зачем вообще нужна) и перенаправляет далее. Уже зная какое приложение/сайт нужно запросу, запускается выполнение. В IIS, например, для этого используют так называемые Application Pools - выделенные мощности на сервере (обычно, память), внутри которых крутятся приложения/сайты и если сайт/приложение крашится, то кладет оно не всю службу IIS, а лишь свой пул. Ну и между пулами нельзя общаться - типа защита и все такое. Наконец-таки запрос доходит до самого сайта/приложения, где обрабатывается по логике, заложенной программистом.

По пути, естественно, может случаться всякое: не найдена страница - возвращаем 404, не авторизован пользователь (а в настройках службы/пула/приложения стоит, что неавторизованных шлем подальше) -401 ошибка и пр...

Ну да, не совсем корректное сравнение. MVC - это целая система, реализующая архитектурный паттерн. Помимо основного языка, на котором написана платформа (C#) необходимо изучить еще множество вещей: модели, представления, контроллеры, ОРМ, роутинг, принятые соглашения. Также не помешает знание "прикладных" вещей: IIS, .NET, Visual Studio, база данных (Oracle, MS SQL, etc)

И не соглашусь, что мало литературы по ASP.NET MVC. Ее полно. Даже есть неплохие русскоязычные ресурсы, такие как Professorweb и metanit.