eRKa

Поиск по дате должен идти по диапазону или точному совпадению

allOrdersByDate = db.Orders.Where(a => a.Date >= dateFrom && a.Date <= dateTo)

allOrdersByDate = db.Orders.Where(a => a.Date == date)

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

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

Судя по коду могу предположить, что Select Login from Accounts WHERE ... не может дать Вам скалярное значение. Нужно либо запрос другой писать, либо вызывать другой метод на command.

select vehicle.id, vehicle.mileage, vehicleType.name
from vehicle join vehicleType
on vehicle.vehicleTypeId = vehicleType.id

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

Rsa97 все правильно сказал. Бд может физически хранить данные вовсе не в том порядке как их отображает в таблице по дефолту и сортировка Вам ничего не даст. Для ускорения поиска данных существуют индексы. Делаете из своей связи составной ключ и индексируете все это дело.

Все зависит от того как Вы этот value собираетесь использовать.

Если не нужно будет по нему делать поиск, индексировать, то можно сделать MAX, и в нем же хранить тип значения, что-то вроде {"$type":"int","value":3}

Если по нему все же надо будет делать выборку, то я бы, наверное, сделал таблицу value с полями для всех возможно нужных типов и в options сделал два поля type и valueId ну и тогда я буду знать строку и колонку, где читать значение в таблице value.

Можно сделать сплит по пробелу и удалить два последних слова.

Вам нужны веб сокеты. Я не знаю как на php, но на C# есть хорошая библиотечка SignalR, она как раз и способна заниматься обновлением данных на клиенте, если происходят какие-то изменения в данных на сервере. Она как раз является оберткой над веб сокетами.