SQL, как найти не пустой столбец?
Маркерный Блок довольно прост реализовать.
Запускаются с блока с 5 маркерами.
Каждый 5/8 секунды: Если блок имеет меньше чем 5 маркеров, добавьте тот.
Каждый раз Вы хотите отправить сообщение: Если блок имеет маркер ≥1, выньте один маркер и отправьте сообщение. Иначе ожидайте/отбрасывайте сообщение/независимо от того, что.
(очевидно, в фактическом коде, Вы использовали бы целочисленный счетчик вместо реальных маркеров и можно оптимизировать каждый шаг 5/8s путем хранения меток времени)
<час>Чтение вопроса снова, если ограничение скорости полностью сбрасывается каждые 8 секунд, то вот модификация:
Запускаются с метки времени, last_send, за один раз давно (например, в эпоху). Кроме того, запустите с того же блока с 5 маркерами.
Забастовка каждое 5/8 правило секунд.
Каждый раз Вы отправляете сообщение: Во-первых, проверьте если last_send ≥ 8 секунд назад. Если так, заполнитесь, блок (установите его на 5 маркеров). Во-вторых, если существуют маркеры в блоке, отправьте сообщение (иначе, отбрасывать/ожидать/и т.д.). В-третьих, установите last_send на теперь.
, Который должен работать на тот сценарий.
<час>я на самом деле записал бота IRC с помощью стратегии как это (первый подход). В Perl, не Python, но вот является некоторым кодом для иллюстрирования:
первая часть здесь обрабатывает добавляющие маркеры к блоку. Вы видите оптимизацию добавляющих маркеров на основе времени (2-й для длительности строки), и затем последняя строка фиксирует содержание блока к максимуму (MESSAGE_BURST)
my $start_time = time;
...
# Bucket handling
my $bucket = $conn->{fujiko_limit_bucket};
my $lasttx = $conn->{fujiko_limit_lasttx};
$bucket += ($start_time-$lasttx)/MESSAGE_INTERVAL;
($bucket <= MESSAGE_BURST) or $bucket = MESSAGE_BURST;
, $conn является структурой данных, которая роздана. Это в методе, который обычно работает (он вычисляет, когда в следующий раз он будет иметь что-то, чтобы сделать и спит или что долго или пока это не получает сетевой трафик). Следующая часть метода обрабатывает отправку. Это скорее сложно, потому что сообщениям связали приоритеты с ними.
# Queue handling. Start with the ultimate queue.
my $queues = $conn->{fujiko_queues};
foreach my $entry (@{$queues->[PRIORITY_ULTIMATE]}) {
# Ultimate is special. We run ultimate no matter what. Even if
# it sends the bucket negative.
--$bucket;
$entry->{code}(@{$entry->{args}});
}
$queues->[PRIORITY_ULTIMATE] = [];
Это - первая очередь, которая выполняется несмотря ни на что. Даже если это уничтожило наше соединение для лавинной рассылки. Используемый для чрезвычайно важных вещей, как ответ на PING сервера. Затем, остальная часть очередей:
# Continue to the other queues, in order of priority.
QRUN: for (my $pri = PRIORITY_HIGH; $pri >= PRIORITY_JUNK; --$pri) {
my $queue = $queues->[$pri];
while (scalar(@$queue)) {
if ($bucket < 1) {
# continue later.
$need_more_time = 1;
last QRUN;
} else {
--$bucket;
my $entry = shift @$queue;
$entry->{code}(@{$entry->{args}});
}
}
}
Наконец, состояние блока сохраняется назад к структуре данных $conn (на самом деле немного позже в методе; это сначала вычисляет, как скоро это будет иметь больше работы)
# Save status.
$conn->{fujiko_limit_bucket} = $bucket;
$conn->{fujiko_limit_lasttx} = $start_time;
, Как Вы видите, фактический код обработки блока является очень маленьким — приблизительно четыре строки. Остальная часть кода является приоритетной обработкой очереди. Бот имеет приоритетные очереди так, чтобы, например, кто-то болтающий с ним не мог препятствовать тому, чтобы он делал свои важные обязанности удара/запрета.
5 ответов
SELECT
CASE
WHEN A IS NOT NULL THEN 'A'
WHEN B IS NOT NULL THEN 'B'
WHEN C IS NOT NULL THEN 'C'
WHEN D IS NOT NULL THEN 'D'
END
FROM
MyTable
Попробуйте case ...
SELECT
CASE WHEN A IS NOT NULL THEN 'A' WHEN B IS NOT NULL THEN 'B' WHEN C IS NOT NULL THEN 'C' WHEN D IS NOT NULL THEN 'D' END as NotNullCol, OtherCols
FROM YourTable
Всякий раз, когда вы пытаетесь сделать что-то с наборами из нескольких столбцов, вы, вероятно, ошиблись в своей схеме.
Почти наверняка будет проще разделить A, B, C и D в отдельные строки в отдельной таблице, свяжите их обратно со строкой в исходной таблице и создайте запрос типа JOIN .
В качестве альтернативы, если только одна из них когда-либо не является NULL, я бы выбрал для двух столбцов введите (A, B, C или D) и значение. Тогда вы не тратите впустую столбцы в каждой строке, и запросы будут неизмеримо проще (при условии, что типы одинаковы).
Однако вы можете сделать это таким образом с case :
select case
when A is not null then 'A'
when B is not null then 'B'
when C is not null then 'C'
else 'D'
end
from ...
Синтаксис может быть неточным, вам нужно его найти. Я обычно этим не занимаюсь, так как считаю это плохой идеей (построчные функции в select никогда не масштабируются хорошо).
Неприятно, но это то, что вам нужно:
select case
when a is not null then 'a'
when b is not null then 'b'
when c is not null then 'c'
when d is not null then 'd'
end
Я бы переделал. Почти всегда оказывается плохой идеей хранить данные таким образом, а не в связанной таблице.
В связанной таблице вам будет проще запросить информацию. Вы также можете более легко наложить ограничение на данные, что разрешена только одна запись, поэтому у вас, вероятно, будет лучшая целостность данных.
Меньшее количество таблиц не обязательно означает более быстрый доступ или лучший дизайн в реляционных базах данных. Как правило, хорошо спроектированные и проиндексированные связанные таблицы. И хотя вы можете подумать, что пятая колонка вам никогда не понадобится, бизнес-правила меняются, и я видел много вещей, которые, по мнению людей, не нуждались в расширении, для которых требовалась масштабируемость.