Какую посоветуете базу данных с динамическим набором полей?

cjitkul33: скорее всего - не поняли.
Попробую еще раз свое видение:
1. ориентируемся на классические "прямоугольные" таблицы
2. структура таблиц вида:
- id датчика
- тип параметра
- значение параметра
3. получая данные с датчиков - мы однократно разбираем строку списка на отдельные параметры и помещаем в базу по строчке на параметр

Собственно все.
Дальнейшие запросы на все случаи жизни будут совершенно элементарными.

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

Далее, развив конструкцию - можно добавить "настроечные таблицы" где будут заданы для каждого типа параметров допустимые диапазоны - опять же простейшим запросом аж с одним join получить грубо говоря разбивку по исправному/сбойному состоянию

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

Какую посоветуете базу данных с динамическим набором полей?

cjitkul33: ну к примеру пришли мы к нечто типа id и кучка параметров в одну строку:

1 t:20; u:15; i:200
2 i:18;z;48

где и что искать - хз

в ситуации же типа id, тип_датчика, значение (пока не заглубляясь в типы значений) получим
1,1,20
1,2,15
1,3,200
2,3,18
2,4,48

и оттуда уже можно получить либо список показаний конкретного датчика в виде
select * from ... where id=...

или показания конкретного типа
select * from ... where тип_датчика=...

ну и далее

притом "свернуть" это в строку (например для печати) - без проблем

Какую посоветуете базу данных с динамическим набором полей?

cjitkul33: почему? какие сложности?
а сборка их "в кучу" - это значит на каждом телодвижении разбирать/распарсивать эту кучу...

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

Как пробивать НАТ?

А про полезность информации - тут как с полезностью очков в басне Крылов -)

Как пробивать НАТ?

dinegnet: upnp, µtp например, еще бочком тут и nat-traversal
те же торрент-клиенты перебирают разные варианты обходов nat (в силу множества разных nat)

ГОСТа на эти технологии нет, так же как и стандартизированных названий.

Какую посоветуете базу данных с динамическим набором полей?

cjitkul33: почему же, вполне вписывается
просто для конкретного датчика будет записываться ровно столько строк, сколько параметров

А при наличии информации о типе параметра и допустимых значениях - можно будет еще и отсеивать "плохие". Любые варианты "упаковки" этого в json или просто строки - просто потребуют при каждом обращении распаковки собственно в тот же вид, что я описал.

Разумно ли делать рассылку в 50 000 в день, через smtp Яндекс или Гугл?

Это до автоматического блока спамбота, а если от пары получателей придет жалоба - то грохнут насовсем и при сотне отправок.

Насколько уникальным является код, если NDA запрещает использовать наработки в других проектах?

Самое главное, что как правило NCA касается крупняков, а не кодера-надомника

Почему вознекает ошибка "System.ArgumentOutOfRangeException"?

на 25" с масштабом - что-то прочлось... теперь захотелось это развидеть -)))

while (k>1000){
...
}

... round(..., k)

Использовать var или объявлять тип явно?

kvasek: -)

Использовать var или объявлять тип явно?

kvasek: Русский язык, однако:

1. На мой взгляд там, где тип известен - все-таки явное указание типа будет лучше

2. Мой взгляд собственно вырос из эксплуатации как жестко типизированных языков так и совсем нетипизированных,

3. где [в некоторых нетипизированных языках] можно было написать где-нибудь в редкой ветке

Неужели сложно понять, что п.1 - мнение, п.2 и далее - причины почему так лично у меня, где совершенно не фигурирует шарп (его тогда еще просто не существовало)

Использовать var или объявлять тип явно?

kvasek: не, это видимо вы не совсем дружите с текстом -)

SQL Почему записи дублируются при выборке?

Алекcандр: www.geekphilip.com/wp-content/uploads/2012/04/Join...

SQL Почему записи дублируются при выборке?

Алекcандр: ну и да, лучше все-таки использовать более каноничное и естественное
select ....
from table1
left join table2 on ....
where ...

SQL Почему записи дублируются при выборке?

Использовать LEFT JOIN - тогда Places будут все, а "правая" часть где ее нету - будет пустой, т.е. null

Вычитание столбцов приводит к ошибке "Numeric value out of range", но не всё так просто?

Еще более забавные вещи бывают в ситуациях с decimal арифметикой и null...

ИП + PayPal = касса?

pchemu4ka: да, это похуже
Видимо останется только Ст.2 п.9 "Контрольно-кассовая техника не применяется при осуществлении расчетов с использованием электронного средства платежа без его предъявления между организациями и (или) индивидуальными предпринимателями."
Но тогда потребуется "прослойка" в виде какой-нибудь робокассы или подобных сервисов которые являются юрлицом или ИП. То есть клиент-физик оплачивает услуги через эту прослойку, прослойка естественно выдает ему чек (ну или как она хочет), а потом явно безналичным образом уже переводит деньги продавцу.
Вполне возможно, что в качестве прослойки может прокатить и paypal

ИП + PayPal = касса?

pchemu4ka: если платеж одноразовый - то точно нет смысла закупаться ККМ.
Судя по 54ФЗ - до 2018 года можно не "бить чеки" ЕНВД-шникам и ПСН-щикам

И еще один момент бросился в глаза: само название ФЗ
«О применении ККТ при осуществлении наличных денежных расчетов и (или) расчетов с использованием платежных карт»

Относится ли PayPal к платежным картам?

Насколько уникальным является код, если NDA запрещает использовать наработки в других проектах?

sim3x: По существу уже давно все сказано.

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

Как победить медленный SQL запрос с множественными JOIN?

Евгений: но могу подтвердить, что эти рецепты достаточно распространены и бывают даже долгие и затейливые холивары на эту тему... так же как и "join a.id=b.id vs join b.id=a.id" =))