Евгений Сердюков, грубо говоря distinct "уничтожает лишние" результаты выборки. А следовательно из не надо изначально выбирать из БД, а следовательно запрос не оптимален. Конечно есть случаи когда без него никак, но это ооооочень редко. Как-то так.
Неправильно понял ваш вопрос. Так что неправильный ответ дал.
А по делу зависит от характера товара - если магазин "все по 10 р" то хранить в товаре, т.к. скорее всего товары буду сильно разные. Если же специализированный то справочники характеристик привязать к категориям.
procedure procIntOrStr(var arr: array of string); overload;
begin
bla bla...
end;
procedure procIntOrStr(var arr: array of integer); overload;
var arrInternal: array of string;
begin
arrInternal := convert(arr);
procIntOrStr(arrInternal);
end;
1) Почти правильно, только не отдельный атрибут "Высота", а сделать параметр "Высота" "предком" параметра "скорость ветра"
2) да, это новый параметр таблицы Params, если оно задано, то у этого параметра есть "предок". Например у "скорости ветра" есть предок "высота". Это позволит строить цепочки параметров - "скорость ветра" на "высоте" в "1 день новой луны" :)
Получается, что у нас один параметр зависит от другого (скорость ветра от высоты) или обобщая: сущность (параметр) зависит сама от себя. Обычно такие отношения решаются петлей:
Получится:
Params
idParam = 1
idParamParent = null
Name = 'Высота'
...
idParam = 444
idParamParent = 1
Name = 'Скорость ветра'
Weather
idParam = 1
Value = 100 метров
Time = 10:00
...
idParam = 444
Value = 15 градусов
Time = 10:00
kiru, "значение параметра" - это одна из характеристик погоды в конкретный момент времени в конкретной точке. Все это дело хранится в таблице Weather. Например:
Описываем параметр "давление" в таблице "Params" и присваиваем ему idParam = 1
Теперь метеостанция с idStation = 888 померила в 10:30 давление и получила значение 1000 kPa, записываем это событие в таблицу Weather присвоив полям следующие значения:
idStation = 888
idParam = 1
idParamType = 0 -- значение для типа параметра "факт"
Time = 10:30
Value = 1000
Необходимо описать и определить термины предметной области и отношения между ними:
"Температура на аэродроме, Температура в Москве" - географическая точка, которая входит в "зону" (например "зона повышенного давления")
Дальше строим логическую модель предметной области. На основе логической модели выбираем СУБД и для нее строим физическую модель.
Как видите ответ получился неконкретным и общим. Это произошло потому что я не знаю всех нюансов задачи и не могу дать однозначный ответ.
Поэтому советую нанять архитектора БД.
Как-то так.
какую базу ни возьми, в одну таблицу все эти товары записывать бессмысленно
И все таки такие попытки постоянно делаются. Бизнес говорит нам надо "просто" каталог товаров как в Excell, а дальше "херак-херак" и в продакшн.
Извините за off-top
Таблица Orders это промежуточная таблица, которая Client и Order связью многие ко многим?
Можно сказать и так, но предпочитаю читать схему так: "Список заказов (счет) Orders заказал клиент Client. Список заказов (Orders) содержит заказ (Order) на обслуживание кондиционера (Condition)." и т.п.
Стрелка кружочком обозначает, что в сущности Order может не быть связи с Condition, например в случае если техник пришел, а кондиционера нет :) Все остальные, да один ко многим. Т.е. если сущность есть, то связь должна должна быть.
Т.е. для каждой строки в столбец Type необходимо создать битовую маску и затем применить побитовое ИЛИ к текущему значению Type.
Для MS SQL:
update..
set Type = Type | (case условие then power(2,0) else 0 end | case условие then power(2, 1) else 0 end | ,,,, )
То же нету. По сути вы хотите роутер с двумя физическими интерфейсами - WiFi и Ethernet (ну или одним Ethernet), а чипы Expressiff это из другой оперы - IoT. Копайте в строну МК со встроенным PHY или МК+чип PHY (Тот же STM32 и enc28j60)
Что касается конкретно автомобилей можно рассмотреть такую схему: