eRKa

Человеческие названия обычно уже делают на клиенте, по типу
<label>Тип:{{entity.type}}</label>
В базе редко хранят, что-то, что не меняется. Имена Ваших ключей навряд ли изменятся, а данные будут меняться постоянно.

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

Для оптимизации - имеет смысл, это действительно ускорит сложные запросы. Разницы нет, сколькими способами Вы будете доставать данные из бд в контроллере. Сборка загрузится один раз, и если она будет висеть без дела, погоды это не сделает. Вы можете сделать дополнительную прослойку Репозитория между бд и контроллером и внутри наделать методов которые будут хоть через EF, хоть через ADO.NET, или еще через что доставать данные.

Надо писать свою грамматику и анализатор под него, который будет генерировать нормальный sql запрос. Мы применяли antlr4cs

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

Теоретически Вы можете в одно поле запихнуть весь список id записей, как строку, как массив и т.д., но это очень плохой подход. Я так понимаю, что Вам нужна связь многие-ко многим: должна быть таблица, в которой в одной колонке будет id "этапов", а второй соответствующие этим этапам id документов.