d-stream

Адреса, по крайней мере для РФ - это практически однозначно kladr.ru (урезав по вкусу)

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

А вот некие таблицы допатрибутов - да, без проблем

Как вариант:
нечто типа таблицы значений "допов" в виде id_user, attr_type, row, value *
ну и в довесок attr_type, descr,value_type - типа справочник названий атрибутов

---------
* - value - это будет скорее несколько колонок разных типов

Ну тут "в лоб" с данностью не побороться. Если оцениваемое число запросов - 300 шт, то с учетом ограничения - 100сек...

Дальше только смотреть - действует это ограничение на один ip или одну учетку, если "на один ip" - ну значит размазываемся по нескольким прокси, если "на учетку" - то делаем несколько учеток.

Персона, если не заморачиваться со сменами фамилии, пола и т.п. - по сути одна, а эта персона во времени может приходить, уходить и т.п.

Вот и напрашивается одна табличка с первичным ключом person_id и горой данных типа ФИО и т.п., а вторая слегка упрощенная табличка - этакая история (хронология) событий:
датавремя, персона (person_id), действие (например int или enum)

соответственно если взять первую запись по хронологии для конкретной персоны - увидим когда персона впервые появилась, по действию последней записи персоны - понимаем ее статус

ну и всяческие "сколько в прошлом месяце пришло и сколько ушло" или сколько было френдов 143 дня назад" запросы лепятся в одну строчку... точнее вру, последний получится чуть посложнее

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

В чем проблема проектирования?

Для дома собственно достаточно простой концепции: лишних розеток не бывает так же как и лишних проводов
То бишь в сторону потенциальных точек типа телевизора - кидаем минимум две витухи.

Где-то в "центре" ставим коммутатор умеющий vlan + маршрутизатор, умеющий в том числе нормально работать с IGMP и мультикастом

далее в зависимости от реализации iptv вещание провайдером делаем нужные настройки и получаем непрерывное счастье даже при изменении технологии вещания провайдером или провайдера целиком

в правилах firewall разрешены входящие/исходящие подключения ?

Общая идея:

left join таблица_свойств
...
where id_в_таблице_свойств is not null

В особо разлапистых случаях весь этот селект группируем по id или distinct по вкусу и используем как inner join к таблице товаров

Как говаривал один сантехник: "да тут всю систему менять надо".

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

Добавляем например статический или динамический ресурс и складываем туда хоть 100500 иконок. Туда же складываем строки текста и т.п. Потом все это собираем в виде отдельной dll и когда программа завоюет например мексиканский рынок - делаем такую же dll с такими же именами ресурсов, но только картинки (пиктограммки) все в сомбреро, а текстовые строки - на испанском языке... Получается чуть-чуть локализация путем замены всего одной dll -)

Ну а дальше по вкусу, например для каждого окна приложения задаем/меняем свойство Icon, указывая конкретную картинку в ресурсе, то же самое делаем для основного приложения по событиям например ресайза или таймера и получаем свистяще-пердяще-смердящее приложение -))

Нет. Ибо те самые "белые карточки" работают на совсем других частотах.

Подробнее - https://ru.wikipedia.org/wiki/RFID

Доход <1млн. в год

При таком доходе думать про патент - бессмысленно.

Ну и помнить что кроилово ведет к попадалову.

Если что-то из этого неочевидно - могу пояснить подробнее с циферками.

Любым удобным способом заполняем некую временную таблицу с колонками xml_id и user_id теми самыми xml_id

потом делаем апдейт этой таблицы - заполняем user_id

ну и далее delete from ... where xml_id in (select xml_id from temp)

Собственно простой вариант решения:

create spReadAddress @addr 
as 
select * from adrTable where address = @addr  
if @@rowcount>0 update adrTable set requestCount=requestCount+1 where address = @addr

и соответственно по месту вместо селекта - дергать процедуру

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

ну а для вариантов поиска например по like - "в лоб" вываливать результаты поиска во временную таблицу и потом из нее делать апдейт счетчиков (или инсерт в лог) и потом уже выводить

Кстати дальше может оказаться интересным логгирование обращений к отсутствующим странам - типа как повод их подгрузить

Латиница-кириллица не может пакостить?
А то в приведенном примере как минимум 3 буквы имеют начертание 1:1 (К,В,С)

Судя по www.sitealyzer.net/en/p/sb/remove-bcp.crwdcntrl.net это локальная зараза на конкретном компьютере

Скорее всего тупо боты лезут в известные им точки уязвимости или еще какой-нибудь пакостности.

В зависимости от производителя - это может по-разному называться, но чаще это bridge mode - типа "режим моста".

В итоге получается почти-почти как будто кинули прямой провод.

Да... если еще нет гарантии "непропуска" события - то совсем беда-беда...

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

Ну а потом - для каждого включения (status=2) суммируем те самые "расстояния"

Если получится формУлизовать ценообразование - то можно что-то намутить. Только зачем?
Пугает число 5000? Оно в общем-то совсем не страшно для СУБД.

Впрочем стоит попытать тех экономистов, которые изобретали ценообразование. Не исключено, что тогда появится пара иных сущностей типа категорий/классов мест и секторов и коэффициентов.
Типа "боковые", "центральные", "ближние", "дальние" места в секторе + сами сектора нескольких сортов a'la трибуны на стадионе. Тогда цена конкретного места будет получаться как ЦенаСеанса*КоэффициентПоСекторам*КоэффициентПоМестам