d-stream

Гуглить GeoIp|Geobase например
только часовые пояса - это как бы следующая за геопривязкой задача.
Естественно все это обладает частичной точностью, ибо:
- иногда принадлежащие организации с определенным географическим положением размазываются по географически разнесенным филиалам
- иногда владельцы ip адресов меняются

Написать велосипед сервис/сервер, который будет с одной стороны взаимодействовать с программами, с другой писать файл на диск, а внутри - кэшировать это.

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

SQL придумали как почти естественный язык "попросить у базы":

select [выбрать]
* [все]
from Users [из Users]
where [когда/где/которые]
gender = Female and (today - birthday) < X [ женщины и возраст меньше х]
or (или)
gender = Male and (today - birthday) < X [мужчины и возраст меньше х]

Работает. Только моя телепатия подсказывает, что balans - строковый а пытаются хранить в нем цифры и потом возникает удивление почему 100,01 располагается не так рядом со 100,11

Не лучше ли использовать binding ?

СБ в меру своей задачи - отслеживает совершенно разными способами. Начиная от технических, что выше перечислила и заканчивая социальными (от стукачей на фирме до фейковых аккаунтов в соцсетях).

У снабженцев - классическая засада в виде фейкового контрагента-поставщика и вылет по результатам обсуждения откатов например -)

Резонный вопрос: а нафига? Это же сродни "ща запилю свою ос со своим ассемблером sql и компилятором" -)

Более-менее большие SQL-системы зачастую славятся именно тем, что в каждый конкретный момент времени (запрос) могут в том числе на основании статистики, памяти, загрузки построить разный план выполнения одного и того же запроса. Именно с целью его оптимизации.

Очень упрощенно, но в правильном направлении.

Как вариант: все-таки сохранять данные в базу, где добавить флажок "грязности" и по мере появления своего рода подтверждающих - сбрасывать флажок, ну и по мере устаревания грязных записей - удалять их.
Ну а там, где данные из базы отображаются - отображать только "чистые" данные

Может быть не поздно на тему плагинов: https://msdn.microsoft.com/ru-ru/library/dd460648(... https://habrahabr.ru/post/83928/

ПКМ и в свойствах файла снять галочку на тему что этот файл скачан из интернета и может быть опасным - обычно помогает.

p/s/ и на dll надо тоже сделать аналогичное

в sql запросе явно указано <выражение> as target

поэтому sql понимает в выражении group by по чему именно группировать

В Laravel выражении - нет колонки с именем target. Но судя по всему там тоже должна прокатить конструкция "...as name" или же "name=<длинное выражение>"

Потом начнется второй виток:

"на сайте 3 пользователя" <> "на сайте 5 пользователей"
супротив
"online 5 users" == "online 3 users"

Самый феншуй: https://technet.microsoft.com/ru-ru/library/mt1582...

Суда по всему надо копать в сторону RRC-protocol

Сожалею, но озвученный бюджет совсем не тянет на сервер. Только на "типа сервер". Даже более-менее приличный ноутбук для разработки получается дороже...
Руководству стоит задать вопрос о том какие интервалы простоя для него приемлемы. И сколько стоит час/день простоя. Потом объяснить разницу между "сервером" и сервером.
Я бы акцентировал внимание во-первых на конструктивную возможность резервирования узлов. Два блока питания, RAID, иногда даже банки памяти + возможность "замены на лету". Во-вторых на брендовый сервис. Если исключить казусы, то минимальный уровень поддержки выглядит как сообщение о наступающей проблеме и подвоз в течение дня-двух замене. А вот в обобщенном самосборе - "сами привозите на экспертизу, через две недели или гарантийный ремонт до 45 дней или отказ в гарантии"

Ну и в общем для SQL - побольше ядер/процессоров и побольше памяти + само собой быструю дисковую подсистему. Бэкапы - хранить как минимум не на сервере, а на отдельном устройстве (возможно территориально удаленном).