|
|
|
Подскажите более здравую идею для организации бд
|
|||
|---|---|---|---|
|
#18+
Есть некие "объекты" Есть значения "датчиков" F0..F9 для этих объектов Показания датчиков для разных объектов могут соответствовать неким величинам "назначениям" скажем А0..А9 при этом возможны случаи когда А рассчитывается как некая математическая функция от F или от нескольких F. В итоге имею три таблицы справочник датчиков, справочник назначений и третью таблицу связывающую объект, датчик и назначение. Вроде бы все хорошо. Но в итоге хочется сделать view где будут уже не F0..F9, а рассчитанные на основании связей величины "назначений". И я не могу придумать ничего лучше чем динамический SQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2018, 20:45 |
|
||
|
Подскажите более здравую идею для организации бд
|
|||
|---|---|---|---|
|
#18+
vanlove2die, Ну динамический SQL тоже имеет право на жизнь, особенно когда нельзя один запрос оптимизировать для разных жизненных случаев. Вы обрисовали ситуацию, но не ясно, в чем именно проблема? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2018, 21:20 |
|
||
|
Подскажите более здравую идею для организации бд
|
|||
|---|---|---|---|
|
#18+
Может быть я плохо описал свою проблему. Есть таблица Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Она заполняется другой программой. Мне же интересны уже преобразованные данные, для понимания что есть что есть 3 таблицы Код: sql 1. 2. 3. 4. 5. 6. Код: sql 1. 2. 3. 4. 5. 6. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. В итоге я бы хотел в самой базе преобразовать данные от датчиков к местам их расположения. но как это сделать кроме как собирать запрос через Prepare Execure я не придумал. С учетом остальных связей.. выходит грустно. и чем дальше тем грустнее. Делаю через View, который пересоздаю в триггере, когда добавляются/изменяются записи в таблице sensor_alias ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2018, 21:36 |
|
||
|
Подскажите более здравую идею для организации бд
|
|||
|---|---|---|---|
|
#18+
vanlove2dieДелаю через View, который пересоздаю в триггере, когда добавляются/изменяются записи в таблице sensor_aliasХм, насколько я в курсе, в триггерах нельзя создавать VIEW. Да и нет никакой необходимости пересоздавать VIEW только из-за изменения количества записей. vanlove2dieВВ итоге я бы хотел в самой базе преобразовать данные от датчиков к местам их расположенияЗвучит слишком просто, чтобы делать из этого проблему: Код: sql 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2018, 22:00 |
|
||
|
Подскажите более здравую идею для организации бд
|
|||
|---|---|---|---|
|
#18+
miksoft, Если вдаваться глубже, 1 т.к совокупность назначений для постов разная собираем структуру для одного поста потом объединяем с другим и т.д. 2 т.к есть значения порогов для мест установки этот View лезет еще и в эти таблицы для рассчета финальных значений. а там еще анализ на коды отказов. и прочее. 3 нужно в базе считать время следующего опроса относительно предыдущего в зависимости от нахождения значений между порогами.. и все это растет как снежный ком. никакой прозрачности. этот монструм даже работает, но как-то медленно. и я начинаю задумываться об альтернативном подходе.. мб даже таблицу создавать куда бы это все 1 раз пересчитывалось. а не миллион раз при обращении к этому view, но вроде как дублирование данных, да и если справочник placements будет расти, таблицу эту расширять надо, чтоб покрыть все варианты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2018, 22:04 |
|
||
|
Подскажите более здравую идею для организации бд
|
|||
|---|---|---|---|
|
#18+
Звучит слишком просто, чтобы делать из этого проблему: Код: sql 1. 2. 3. 4. Я не совсем понимаю как это мне поможет. Оконными функциями потом это сворачивать? Простите , то ли опыта нет, то ли мозгов. Мне нужно из таблицы data, F0... F9 получить тублицу data, А0..А9 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2018, 22:17 |
|
||
|
Подскажите более здравую идею для организации бд
|
|||
|---|---|---|---|
|
#18+
miksoft, idpost_iddateOfMeasurementF0F1F2F3F4F5F6F7F8F9placement_idsensor_idplacement_name11"2018-09-22 20:38:02"912111111116PhaseA111"2018-09-22 20:38:02"912111111153PhaseA211"2018-09-22 20:38:02"912111111112PhaseA111"2018-09-22 20:38:02"912111111124PhaseB111"2018-09-22 20:38:02"912111111149Ground_wire121"2018-09-22 20:40:36"1112111111116PhaseA121"2018-09-22 20:40:36"1112111111153PhaseA221"2018-09-22 20:40:36"1112111111112PhaseA121"2018-09-22 20:40:36"1112111111124PhaseB121"2018-09-22 20:40:36"1112111111149Ground_wire132"2018-09-22 23:58:00"812111111111PhaseA142"2018-09-22 23:58:12"2912111111111PhaseA151"2018-09-30 21:36:52"1112111111116PhaseA151"2018-09-30 21:36:52"1112111111153PhaseA251"2018-09-30 21:36:52"1112111111112PhaseA151"2018-09-30 21:36:52"1112111111124PhaseB151"2018-09-30 21:36:52"1112111111149Ground_wire1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2018, 22:38 |
|
||
|
Подскажите более здравую идею для организации бд
|
|||
|---|---|---|---|
|
#18+
vanlove2dieЕсть значения "датчиков" F0..F9 для этих объектовЯ верно понимаю, что а) для каждого объекта существует именно такой набор "датчиков", не больше и не меньше, и измениться он не может в принципе; б) суть этих "датчиков" строго фиксирована и уникальна, и изменение их нумерации (не значений, а именно самих имён-заголовков) недопустимо? Если да, то 10 полей в таблице объектов - это правильно, иначе скорее ошибочно. vanlove2dieПоказания датчиков для разных объектов могут соответствовать неким величинам "назначениям" скажем А0..А9 при этом возможны случаи когда А рассчитывается как некая математическая функция от F или от нескольких F.Это реализуется или запросом. или, при слишком высокой сложности, пользовательской функцией. В любом случае динамический SQL тут нафиг не нужен. vanlove2dieя начинаю задумываться об альтернативном подходе.. мб даже таблицу создавать куда бы это все 1 раз пересчитывалось.Если исходные значения для расчёта статичны (фиксируются и в дальнейшем не изменяются) - то предрасчёт есть вполне нормальное и достаточно эффективное решение. Даже если они таки изменяются, но редко - всё равно пересчёт предрасчётных значений может (да и, вероятно, будет) более эффективен, чем постоянный расчёт по актуальным значениям. Особенно когда есть временнОй зазор между изменением и использованием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2018, 07:45 |
|
||
|
Подскажите более здравую идею для организации бд
|
|||
|---|---|---|---|
|
#18+
Akina, Akina для каждого объекта существует именно такой набор "датчиков", не больше и не меньше, и измениться он не может в принципе; На данном этапе да.. их 10, но я так подозреваю что их может быть больше в дальнейшем. Суть в том для разных объектов эти датчики могут измерять разные величины, ну например на одном посту F0 меряет вес одного провода на другом другого провода. А ограничения и пороги привязаны к наименованиям провода, а не значению датчика. да и иногда для измерения какого-то веса используется сразу несколько датчиков например A1 = (F0+F2)*0.876, формулы расчета могут быть и сложнее. А я хочу в базе переводить для каждого поста показания датчика к тому что он измеряет. Akina10 полей в таблице объектов - это правильно, иначе скорее ошибочно. Есть таблица куда с каким-то интервалом записываются текущие показания со всех датчиков постов. Мб вас ввела в заблуждение моя табличка, это результат запроса предложенного ранее. Просто я не понял как он мне поможет. и опубликовал результат. AkinaЭто реализуется или запросом. или, при слишком высокой сложности, пользовательской функцией Вы можете привести пример запроса каким я получу сколько весит провод который считается как (F1+F2)*0.867 . Что ж я нормально объясниться то не могу.=( Мне нужно в итоге превратить показания датчиков в то что они меряют при этом схема этого превращения для каждого поста измерений разная.. вернее эта схема задается через табличку sensor_alias и часто несколькими датчиками совместно меряется одна величина по какой-то формуле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2018, 14:15 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39724165&tid=1829518]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
46ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 146ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...