d-stream

Беспроигрышный способ: плясать от карты как идентификатора, а суммы хранить централизованно на защищенном сервере. Тогда по крайней мере не будут страшны клоны карт.

А без централизации - будет нечто типа старых билетов на метро с магнитной полосой: путем разных манипуляций народ вполне реализовывал "вечные" билеты - уменьшенное число поездок на них не записывалось -)

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

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

Притом обратится - это не по телефону или мылу, а ДОКУМЕНТАЛЬНО. Например отправив заказное письмо с описью вложения и уведомлением о вручении.

Из практики работы в компании, осуществляющей юридическое и бухгалтерское обслуживание кучи других фирм из холдинга: 90% выигрышей и проигрышей в такого рода хозяйственных спорах обусловлены банально грамотным подходом к документообороту. (совсем по-народному: больше бумаги - чище ж...)

Корректный вариант: предобразование Фурье, естественно перед этим избавиться от "обрезания", далее оттуда получаем основную гармонику.

Малокорректный вариант (в свое время видел в практическом использовании у сейсмологов): находить некую "ось" ("ноль") и считать полупериодом соседние пересечения оси.

"ось"\"ноль" - видимо аппроксимировать полиномом первого порядка из среднеквадратичного.

Стоит начать с того, что использовать фигурные скобки везде. Особенно в ветках if

ибо в исходнике сейчас
if (string_i == "0") {
;
}

Ну и char string_1[7] - это некая коробочка с 7 ячейками.
Ячейки нумеруются от 0 до 6.
Каждая ячейка может вместить только ОДНУ букву

соответственно string_1[7] = "00" - выглядит как "впихнуть в 7 ячейку коробочки ДВЕ буквы"

а это уже как в анекдоте про тест на интеллект среди ментов: победили сильные -)

Кстати стоит иметь в виду, что в реальной жизни зачастую "скидка на скидку" неприменимо.
Посему лучше заблаговременно подойти к "правилам скидок".

Как один из вариантов:
1. таблица групп(категорий) скидок rules_groups (id, descr, [ordering])
2. таблица "правил применения скидок" rules(id, group_id, descr, ordering, percent [условия])

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

select top 1 percent from rules where group_id=xx and (кучка условий на соответствие правилу) ORDER BY ordering

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

По вкусу можно на уровне групп или правил предусмотреть признак мультипликативная (умножение на коэффициент) это скидка или аддитивная (вычитание суммы) и "за единицу" или "за партию".
Ну и с учетом танцев с финокруглениями на тему НДС - неплохо иметь признак "С НДС"/"Без НДС" (но это подразумевает ньюансы хранения цен.

Еще элементом тюнинга будут флаги или коэффиценты на предмет применять ли правило при снижении отпускной цены ниже себестоимости"

А юзеров чуть больше чем пальцев на руках? -)

Имеет смысл бороться со структурой, если там фигурируют tel1, tel2, tel3 и т.п. Точнее не бороться, а нормализовывать.

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

Комментариев к одному сообщению может быть больше одного - как бы намекает на отношение 1:N

Можно попробовать вот так:
declare @filter table(x int, y int, primary key(x,y))
insert into @filter (x,y) values (192,18),(191,17).....

select * from dbo.boards_map inner join @filter as f on f.x=dbo.boards_map.x and f.y=dbo.boards_map.y

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

С антеннами абстрактно дело чутка получше, но не в бытовых мыльницах - там чаще всего антенны - элемент декора.

чем плох классический datediff ? можно даже сразу вычисляемое поле сделать.

А заказчик будет готов документально подтвердить свое умышленное участие (соучастие) в безналоговой сделке?
Полагаю что расчеты производились "мимо кассы", иначе у исполнителя бы были в наличии документы.
Так же готов предположить, что у заказчика есть мозги (раз есть деньги на заказ работы) и он сам себе накручивать соучастие не будет.

Просто byte[] image

Гм... а разве лимит накладывается до order ???

Для надежности можно конечно вот так сделать:
select * from
(select * from table order by z) as ordered_table
limit x,y

только как мне кажется последовательность применения все-таки WHERE -> GROUP BY -> HAVING -> ORDER BY -> LIMIT

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

В общем случае - никак.

Образчик 2,2 и 4
Несколько вариантов алгоритма:
1. 4=2+2
2. 4=2*2
Но этими двумя вариантами множество алгоритмов не исчерпывается...

Возможно подробное описание предметной области позволит сузить круг алгоритмов.

Совсем упрощенно:

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

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

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

Думаю стоит начать с нечто типа "устройство полупроводниковых приборов для самых маленьких" и далее по нарастающей к триггерам-регистрам

Вариант Light: копируем текст JSON в клипборд, в VS выбираем Edit-> Paste Special