|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
Приветствую уважаемых. Есть таблица EventSource - источник тревожного события - это видеокамера либо датчик. Это справочник с полями: Тип, Код, Наименование и т.д. (схема в файле из вложения). Есть таблица FacilityPlan - это справочник помещений, где видеокамеры/датчики будут располагаться. Поля: Код, Наименование и т.д. И есть таблица FacilityPlanEventSource - инфа о том в каком помещении находится какая видеокамера/датчик. Поля: ключи из EventSource и FacilityPlan, коодината X, координата Y, угол наклона камеры. На практике есть ситуации когда одна камера обозревает сразу несколько помещений. Для таких случаев, с целью избавить людей от указания разных углов наклона одной камеры для разных помещений (относительно одного помещения этот угол будет один, а относительно другого помещения уже другой), есть вариант решения чтобы указывать этот угол один раз как угол относительно направления на север (а не относительно стенок помещений). Для реализации этого, при текущем расположении поля угла в таблице FacilityPlanEventSource получается что значения угла для записей, относящихся к одному помещению, будет у всех одинаковое. С целью оптимизации, коллега предложил перенести это поле в табл. EventSource. Но ведь, по сути, угол не является атрибутом табл. EventSource, а является, все же, атрибутом табл. FacilityPlanEventSource (камеру переносят в другое помещение и угол меняется, т.е. есть зависимость и от камеры и от помещения). Как вы считаете, нужно ли оставить угол в табл. FacilityPlanEventSource и, если да, то нужно ли в данном случае каким-то способом избавляться от дублирования значений угла в табл. FacilityPlanEventSource ? И если нужно, то каким способом лучше ? Модератор: Тема перенесена из форума "Microsoft SQL Server". ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 14:20 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
Конечно оставить. От дублирования избавляться не надо. Хинт: бывают камеры, изменяющие угол. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 14:31 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
Сергей Васкецов, Спасибо, я тоже так думаю по обоим пунктам. Коллега, предложивший переместить поле угла, является руководителем отдела Backend и БД, но думаю, что правда восторжествует ). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 18:27 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
sps777Поля: ключи из EventSource и FacilityPlan, коодината X, координата Y, угол наклона камеры. А как вы собираетесь разбираться с качающимися камерами, которые выдают панораму? Или у вас таких в принципе не предусмотрено? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 18:36 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovsps777Поля: ключи из EventSource и FacilityPlan, коодината X, координата Y, угол наклона камеры. А как вы собираетесь разбираться с качающимися камерами, которые выдают панораму? Или у вас таких в принципе не предусмотрено? Пока таких нету, появятся - что-нибудь придумаем. Может быть, угол среднего положения. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 21:51 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
sps777Может быть, угол среднего положения. А поскольку это среднее положение может отличаться от положения в момент события, то хранить надо и то и другое. Логично?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 22:02 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
sps777Может быть, угол среднего положения. А какое будет среднее положение, скажем, в случае вращающейся на 360 градусов камеры? Я бы предложил вам хранить min и max. Это и для поиска полезнее, и 0-360 легко укладываются в эту парадигму, и одно и то же значение можно туда запихнуть, если угол фиксирован. Правда, тогда возможно будет рассогласование значений между разными способами отсчёта углов от разных стен (скажем, можно для непараллельных стен для одной камеры указать идентичные значения углов), но на уровне схемы БД и декларативных ограничений вы не сможете добиться, чтобы в общем случае нельзя было запихнуть в БД противоречивые данные. Кроме того если вам в дальнейшем потребуется сохранить в БД журнал зависимости угла камеры от времени, то вам потребуется извращаться, если одна камера будет присутствовать в нескольких журналах относительно разных стен, да и данные будут по сути дублироваться. То есть в сложном случае я бы не хранил углы относительно стен, а хранил азимуты для камер и стен, а всё прочее необходимое вычислял бы. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2019, 09:00 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
sps777, не вопрос, а фигня кака я то..., так и должно быть на самом деле sps777На практике есть ситуации когда одна камера обозревает сразу несколько помещений. Для таких случаев... относительно одного помещения этот угол будет один, а относительно другого помещения уже другой и не нужно никого ни от чего избавлять... по факту для одной камеры из EvenSorce и двух помещений из FacilityPlan должно быть две записи в FacilityPlanEventSource с разными углами (реальными углами). Если этого не делать, то хранение этих (не тех) углов для таких камер не имеет смысла от слова совсем (можно просто написать - да х.р его знает и хранить в любой таблице) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2019, 21:03 |
|
|
start [/forum/topic.php?fid=32&msg=39874042&tid=1539902]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 152ms |
0 / 0 |