гм... берем какой-нибудь многополосный эквалайзер, включаем музыку и выводим все ручки в самый низ, а одну самую низкочастотную - вверх. В итоге слышим только бум-бум. Потом выводим так же только самую высокочастотную - слышим псс-псс, потом выводим ручку в районе 1-3 кгц - слышим голоса певцов
Вот простейшая иллюстрация частотной фильтрации: из кучи разных частот - выделяем что-то одно.
Или как еще один вариант: делаем музыку погромче и ставим камертон рядом с динамиками - он будет вибрировать (резонировать) в такт с наличием ноты ля первой октавы, если таковая встретится в музыке.
Ставим рядом другой, экзотичный камертон на ре второй октавы - он будет звенеть на соответствующие ноты.
Если теперь попросить одного музыканта "морзянить" на ля первой октавы, а второго на ре второй - то этими двумя камертонами можно отделить одну морзянку от другой.
Просто стоит наверное ориентироваться на "битого клиента". Как только клиент готового движка с принабабахаными плагинами взвоет от тормозов и потратится на "оптимизацию" - он уже будет понимать чем узкоспециализированная конструкция лучше и самое главное - будет готов платить за это деньги.
Для самого начала не помешает озвучить что за маршрутизатор(ы) используются. У большинства НЕдомашних как правило в описаниях, примерах приводятся варианты балансировки каналов, мониторинга и динамического переключения маршрутов и т.п.
Как уже CityCat отметил про AS - пропускаем. А так: раскидываем каналы по вкусу (например по сервисам, приоритетам, нагрузкам) и мониторим доступность "вечного" ресурса через разные интерфейсы. В случае падения - динамически меняем маршруты или их метрики на второй канал
Ну можно "в лоб" - вычислять возраст как datediff(year, BirthDate, getdate())
или даже case сразу кластеризовать это по возрастным группам.
То есть нечто типа:
SELECT
LoginID,
age_group = datediff(year, BirthDate, getdate()) -- или же кэйсом разбивать на интервалы
FROM HumanResources.Employee
where age_group between 25 and 30
В зависимости от потребности в примерном возрасте или "полных лет" - чутка модифицировать datediff
Универсального нет. Выше вариант наводки дали, но это не всегда и не везде.
Посему наверное единственный универсальный вариант - наличие третьей стороны (сервера). Остальное - уже по вкусу:
- все взаимодействия через сервер (типа Hamachi, ammy и т.п.)
- сервер работает только сводником (торренты)
Тут как бы одно из двух - либо достаточно жесткую регулярность в виде классических таблиц с жестко задекларированными полями (что дает возможность строить специфичные хинты для поиска, отбора, сортировки - индексы), либо получать некую "гибкость", но теряя возможности регулярных операций.
На мой взгляд озвученная задача вполне вписывается в классику реляционных структур:
id, порядковый номер параметра, значение параметра
или даже
id, порядковый номер параметра, тип параметра, значение параметра
соответственно тогда все вкусности сортировки, группировки, агрегирования, поиска - будут доступны во всей красе
Дума первый камень преткновения, который подпортит жизнь - слова длиннее 30 символов... редкость, но бывают
Второй однокоренные слова, склонения-спряжения и прочие моментики.
Ну и на старте - "слова" из двух слов. Типа stand up, catch up, come across, sit down, be left
Притом половина таких глаголов "по частям" - может иметь самостаятельный смысл типа stand, up - встать, вверх, а часть - увы. К примеру be left
C учетом того, что народ подобное запускает на девайсах чуть мощнее бухгалтерского калькулятора - вполне потянет все кроме воспроизведения и рекодинга видео.
Как-то на практике чуть удобнее получается нечто типа 2 еще и с объединенным функционалом в виде create or update в "полунеявном" виде.
То есть если объект не имеет UID, то при сохранении - это явный знак, что он "новый" и надо insert, есть - значит update
Первый подход - получается двухшаговым, с отсутствием гарантии наличия второго шага. Грубо пользователь захотел создать новую запись - она создалась с дефолтами, а потом пользователь выключил комп...
В итоге в базе наплодится гора "пустых записей".
На мой взгляд там, где тип известен - все-таки явное указание типа будет лучше.
Мой взгляд собственно вырос из эксплуатации как жестко типизированных языков так и совсем нетипизированных, где можно было написать где-нибудь в редкой ветке
x="qqq"
а потом где-то забабахать цикл
for(x=0, x=x+1, x<10)
abs(length-5) - величина отклонения от искомого
соответственно нам надо найти позицию с самым маленьким отклонением
вот и сортируем позиции по возрастанию отклонения
и берем первую
select top 1
id, word, length
from words
order by abs(length - 5) asceding
написал top 1 в более привычном mssql в MySQL - видимо limit