ThunderCat, но нам будет достаточно информации только о конкретной книге, чтобы авторов найти?
Извините, я просто совсем новичок и плохо понимаю проектирование.
Тут больше теоретический вопрос по использованию промежуточных таблиц.
К ним не возбраняется обращаться для извлечения информации? Это приемлемый вариант в реальном проекте?
Или есть способы лучше/корректней/правильней, если мы хотим найти авторов конкретной книги?
AUser0, это ни к чему объяснять, потому что уровень архитектуры программы мы даже не затрагиваем.
Меня только вопрос нагрузки и производительности БД интересует, при том если будет необходимо последовательно совершать запись и чтение за единицу времени (1с).
Это как бы теоретический вопрос о пределах возможностей той или иной БД, до практики еще далеко.
Задержки критичны, т.е. с учетом всех операций, превышение в 1 секунду на весь цикл может быть фатально.
Запись и чтение всех показаний должно также производиться за 1 секунду. В эту же секунду происходит примитивный анализ в виде сравнения показаний за предыдущую секунду с показаниями текущей секунды.
Да, все еще и одновременно для всей тысячи приборов.
На счет флоатов не уверен. Там скорее всего даблы, т.к. числа не умещаются в диапазон флоатов (пример 99999.99999).
1000 * (30 * 64 * 2) = 3840000 бит (0.5 мегабайта)
Т.е. как минимум данные в чистом виде, без доп. флагов и временных отметок составляют до 0.5 мб в секунду.
Если туда докинуть временные метки (8 бит), флаги (8 бит) и еще что-нибудь примитивное, то 1 мб в секунду - это видимо предел объемов передаваемой полезной информации (исключая служебную) в одну сторону (запись) и столько же в другую (чтение).
Прям со всеми-всеми издержками и объемами 5 мб в секунду - это прям сказочно. Больше - это практически невозможно.
Ключом по логике вещей в TSDB служит временная отметка и/или отметка о приборе. По сути больше ничего не нужно.
Стабильность канала передачи и скорости обработки информации тут не учитывается, но как бы и фиг бы с ним, т.к. это уже другой раздел ПО. Скорость даже в 100 мбит/секунду у канала вообще избыточна, даже половины хватит.
Пока стоит вопрос о выборе именно типа БД.
Было бы здорово применять комплексный подход, однако стоящая задача еще не до конца определена и понятна.
Я пытаюсь разбить такую нечеткую задачу на разные области.
Важно понять, какой тип БД лучше подходит для информации, которая записывается и извлекается строго по заданным временным промежуткам, при том, что сама информация примитивна и однотипна, но в довольно больших объемах.
Пускай это даже будет теоретический вопрос.
Анализ - это по сути сравнение данных за предыдущий временной промежуток с текущим. Разница, как вы поняли, это как раз 1 секунда (максимум).
Сложные типы данных - это я об объектах. Фактически будут одни примитивные типы.
Схема работы ПО проста:
1. Сняли данные с приборов
2. Записали в БД
3. Сняли следующую порцию данных
4. Записали их в БД
5. Сравнили друг с другом, и сделали что-то, если колебания достигли какой-то константы (критическая отметка, например).
Естественно, я тут не учитываю многопоточность, параллелизм и т.д. Но это все предполагается в ПО по умолчанию.
Вопрос не в сложности анализа для каждого прибора, а в объемах информации.
Прогнозирования тоже нет, мы не пытаемся смотреть в будущее.
А между приборами нет никаких связей, даже косвенных. Каждый прибор живет своей жизнью. Поэтому о консистентности речи даже не идет.
Важна исключительно скорость записи и чтения в БД. Примитивный анализ второстепенен и по результатам запустит (если запустит) уже совсем другие процессы, информация о которых если и будет записана, то в другое место и в другом потоке.
Правильно ли выбран тип БД под такие задачи? Или есть варианты лучше?
Василий Банников, ну вот отдельная таблица и есть как абстрактное "Расписание", чтобы по цепочке извлечь минимальную информацию, отобразить её в расписании и там получить реакцию от пользователя на пункт в расписании в виде задачи.
Джоин джоином, но от пользователя нужна обратная связь и её регистрирование.
В общем, не суть. Если в одной таблице есть несколько FK из других таблиц - можно ли в следующую таблицу их просто копировать из нее? Это основной вопрос, т.к. это учебный проект, общего с реальностью не имеющий
Как на картинке.
alexalexes, "Вам под каждую новую задачу придется вписывать нового исполнителя."
Таки да, т.к. это лишь абстрактный кусочек БД. Задачи - это весьма маленькие действия, на которые достаточно одного человека, иначе и правда не обойтись без связи "многие-ко-многим" и еще одной промежуточной таблицы.
А расписание нужно, чтобы пользователь мог реагировать на него через спикеров, и реакция записывалась не к самим задачам.
Василий Банников, каким тогда образом реализовать вывод расписания, если не иметь такой таблицы, что в себе аккумулирует данные из других таблиц? Эта таблица избыточна? Но что если у пользователя предусмотрена реакция на какие-то задачи в виде обратной связи (пометки там всякие), которые надо регистрировать?
Валентин Бируля, но у меня есть условное расписание на много-много дней. И задач тоже много-много.
При этом само расписание может быть еще дополнено своими полями.
TRIG, правильнее даже спросить, будет ли ЭТОТ вариант корректным схематически?
Или в последней таблице "Расписание" я могу указывать лишь FK id_исполнителя???
alexalexes, допустим, у исполнителя и руководителя есть имя, а у задачи название.
Можно ли теперь в таблице "Расписание" получить всю эту информацию за счет одного FK_Исполнитель?
Могу более схематически указать:
Руководители {id_руководителя(PK), имя} -> Задачи {id_задачи(PK), название, id_руководителя(FK)} -> Исполнители {id_исполнителя(PK), имя, id_задачи(FK)} -> Расписание {id_расписания(PK), id_исполнителя(FK)}
Т.е. в таблице "Расписание" должна быть информация (поля) из ВСЕХ предыдущих таблиц, даже если это будут просто вложенные сущности со ссылками друг на друга. Или проще говоря, через эту таблицу нужно узнать, кто руководитель, какую задачу выдал и кто выполнил.
Т.е. можно ли теперь в таблице "Расписание" вывести информацию из таблицы "Руководители", если у них между собой нет никакой прямой связи, а лишь цепочка FK в разных таблицах?
БД имеет такие связи таблиц:
Руководители -> Задачи -> Исполнители -> Расписание
