На MySQL сразу выяснилось, что джоинить квартиры (а также корпуса и секции) к жилым комплексам астрономически долго, просто потому, что квартир много, а комплексов мало. Гораздо быстрее делать наоборот - брать квартиры и присоединять к ним жилые комплексы, а также все остальные сущности по наличию.
Но в PostgreSQL 12 GROUP BY так делать не умеетПостгресс делает правильно. А вот MySQL - "какой бы бред не получился, лишь бы работало". Распечатайте крупно, повесьте на стену и заучите - Звезда используется только в COUNT(*), вол всех остальных случаях поля перечисляются все, которые нужны, поштучно, по одному. Отступать от этого правила можно лишь тем, кто чётко понимает последствия.
получается такой запрос
у меня есть таблица t. значения в столбце t.sequence упорядоченные и уникальные.
есть таблица t_intervals со столбцами id - id интервала, start и end - которые указывают на t1.sequence.
но я бы хотел
Как найти провод идущий от Nanostation?
пришли ребята от другого провайдера и откинули все провода с роутера и повтыкали свободные куда попало
большая часть сети собрана кабелем тппэп 20х2х0.5. Какая уж тут маркировка.
Для этого надо WinServer и выделенный сервер, а кто на них денег даст
Ещё как-то надо побороть CS1.6 который копируется без установкиЕсть в политиках такая штука, как список разрешённых к запуску программ.
Может ещё что подскажете?Угу... прекратить маяться фигнёй с рабгруппами и организовать нормальный домен. И заблокировать любую возможность загрузки со стороннего носителя.
С моей точки зрения большую часть логики можно описать в рамках основного языка программирования, после передав запрос к базе, не уверен в необходимости написания сложных функций и циклов на стороне базы.
Фильтры клиент может создать какие угодно и потом их сохранить, поэтому задача хранить все в json формате.
{
{"filterID":1, "filterExpression":"WHERE size IN ('S','M') AND 'color' = 'black'", "appliedTo":"coverall"},
{"filterId":2, "filterExpression":"WHERE size = 43 AND model = 'Wellingtons'", "appliedTo":"boots"}
}