Pavel V.Прошу помочь со следующей задачей. Есть система, в которую поступают телеметрические данные (по сути это одна табличка в БД с полями id, value и еще несколькими служебными). И есть несколько потребителей этих данных, которые преобразуют их в какой-то формат и пересылают дальше по собственному алгоритму. Мне необходимо отслеживать статус каждой записи - передана/не передана. В случае, когда потребитель данных был один, решалось всё простым добавлением поля status, в которое я записывал некоторое значение в случае успешной передачи. Когда же потребителей несколько, каждый из них должен вести собственный учет переданных данных, причем энергонезависимо, т.е. в БД.

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

Подскажите, пожалуйста, как правильно решается такая проблема?
Решается путем ясной формулировки задачи. Ее пока нет.
Если речь об одном признаке, который Вы назвали status, то достаточно просто объявить связь между двумя типами сущностей Измерение и Потребитель.
Приходится еще раз всем, и, в первую очередь, модераторам предложить: переименуйте раздел в "Проектирование реляционных БД". Потому что, все здесь мыслят исключительно "табличками"))

Pavel V.шмне обязательно. лучше когда что-то сделаешь с записью тогда и записать в табл. статусов ее состояние
А как тогда будет выглядеть запрос со стороны потребителя к базе данных для получения всех записей, которые не были обработаны этим потребителем?
Вы начали формулировать задачу, постепенно. И один из пунктов гласит:
n. Каждое измерение должно быть обработано каждым потребителем.
Pavel V.БредятинаРешается путем ясной формулировки задачи. Ее пока нет.Вроде постарался подробно описать задачу, что именно не понятно?
См. выше, и это, по всей вероятности, не все.
Pavel V.БредятинаЕсли речь об одном признаке, который Вы назвали status, то достаточно просто объявить связь между двумя типами сущностей Измерение и Потребитель.
Да, признак один. Потребитель здесь скорее не сущность, а некая программа.
Нет. Вы хотите сказать что тип сущности Потребитель - это программа. Можно назвать этот тип сущности Программа-потребитель, например.
Pavel V.Т.е. упрощенно можно представить так: одна программа принимает данные и складывает в базу, и несколько других программ подключается к той же базе и забирает эти данные для последующей обработки. И должна помечать уже обработанные.
Опять не формально)
n. Каждое Измерение должно быть обработано каждой Программой-потребителем.
Вероятно, пока, так.
Pavel V.БредятинаПриходится еще раз всем, и, в первую очередь, модераторам предложить: переименуйте раздел в "Проектирование реляционных БД". Потому что, все здесь мыслят исключительно "табличками"))
Прошу не сердиться, я хоть и программист, но с базами приходится иметь дело редко и пока нет возможности разобраться в этом вопросе, т.к. других заморочек хватает.
Я написал модератору) Зачем мне сердиться?)

Pavel V.А как тогда будет выглядеть запрос со стороны потребителя к базе данных для получения всех записей, которые не были обработаны этим потребителем?
В текущей постановке такой запрос не нужен. Так же не нужен и тип сущности Обработка измерений, который Вы хотите моделировать с помощью третьей таблицы.
При создании Измерения создается связь со всеми Программами-потребителями.
При успешной обработке связь удаляется:)

474БредятинаОпять не формально)
n. Каждое Измерение должно быть обработано каждой Программой-потребителем.
Вероятно, пока, так.

Хм... А откуда это следует? Из описания задачи не выводится, что каждый Потребитель обрабатывает каждое Изменение.
Описания задачи нет, и это может следовать только из того, что говорит в разных сообщениях автор:) Я предложил ему гипотетический n-ый пункт из будущего описания задачи.

Pavel V.Попробую описать еще раз задачу.
1. Данные приходят и попадают в БД, после этого они не изменяются никогда - это результаты измерений с кучи однотипных приборов.
Слова "куча", "однотипны" и "приборы" вносят серьезную путаницу. Подтвердите, что Вы погорячились, и приборы и их типы учитывать никак не нужно .
Pavel V.2. Есть несколько (пока не известно сколько) обработчиков этих данных. Каждый обработчик должен периодически забирать новые (после последнего запроса) данные и обрабатывать их, каким-то образом запоминая какие он уже обработал.
Пока писал родилась идея. Если все измерения попадают в таблицу с автоматически инкрементирующимся идентификатором, то можно просто в каждом обработчике запоминать последний обработанный id.
Неверная идея. Поскольку не определено, что значит "последний обработанный". Ведь ДО этого УСПЕШНО обработанного могут быть НЕ УСПЕШНО ОБРАБОТАННЫЕ:) Или не могут? Это тоже нигде не сформулировано.
Pavel V.В случае использования дополнительной таблицы можно произвольные выборки делать.
Опять неверно говорите. Вы хотите сказать, что хотели бы использовать и тип сущности Обработка измерений. Это имеет смысл, если предполагаются какие-то свойства этого типа сущности хранить в БД. До сих пор эти свойства не определены. И каких-либо запросов просто не может быть. Вероятно, Вы предполагаете, что свойства этого типа сущности, все-таки, нужны в БД.

Pavel V.1. Приборы учитывать не надо. Можно считать, что это показания термометра за окном раз в минуту.
2. Данные сейчас обрабатываются последовательно, т.е. пока не обработаем какую-то порцию, к новой не переходим.
3. Свойство нужно только одно - обработано показание или нет.

По поводу линейной/не линейной работы я имел в виду возможность сделать произвольную выборку необработанных обработчиком показаний данных (например, с 10-00 по 12-00) и отметить их обработанными. После этого я бы мог взять показания с 8-00 до 9-00. В этом случае вариант с идентификатором не пройдет.
13862531