|
|
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
Имеется некое кол-во кабельных линий, каждая кабельная линия имеет свой тип (определяющий кол-во жил + доп. параметры), соединяются линии в узлах, причем жила линии А может быть соединена лишь с одной жилой другой линии. Также имеются некоторые промежуточные точки на линии, указывающие метраж в данной точке и используемые для рисования трассы. Итого, имеем следующие таблицы: 1) Типы кабельных линий (ID, название, кол-во жил, прочие несущественные поля) 2) Кабельные линии (ID, тип, название, прочие поля) 3) Узлы (ID, координата, название, описание) 4) Точка на линии (ID, номер п/п, координаты, принадлежность к узлу либо NULL для промежуточной точки) 5) Таблица соединений для узла. Со всеми пунктами, кроме п.5, проблем нет, все типовое. Вопрос: как задать собссно соединения? В данный момент таблица сварок реализована в виде (ID, номер точки линии 1, номер жилы 1, номер точки линии 2, номер жилы 2), где номер точки линии 1 и 2 - foreign ключи, + уникальные индексы (номер точки линии 1, номер жилы 1) и (номер точки линии 2, номер жилы 2). Однако у меня подозрения, что что-то здесь реализовано сильно не так, как нужно, а вот как это привести к правильному виду - пока не знаю. Собссно, может кто подскажет/подтолкнет в правильную сторону? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2012, 23:40 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
xirssИмеется некое кол-во кабельных линий, каждая кабельная линия имеет свой тип (определяющий кол-во жил + доп. параметры), соединяются линии в узлах, причем жила линии А может быть соединена лишь с одной жилой другой линии. Также имеются некоторые промежуточные точки на линии, указывающие метраж в данной точке и используемые для рисования трассы. Итого, имеем следующие таблицы: 1) Типы кабельных линий (ID, название, кол-во жил, прочие несущественные поля) 2) Кабельные линии (ID, тип, название, прочие поля) 3) Узлы (ID, координата, название, описание) 4) Точка на линии (ID, номер п/п, координаты, принадлежность к узлу либо NULL для промежуточной точки) 5) Таблица соединений для узла. Со всеми пунктами, кроме п.5, проблем нет, все типовое. Вопрос: как задать собссно соединения? В данный момент таблица сварок реализована в виде (ID, номер точки линии 1, номер жилы 1, номер точки линии 2, номер жилы 2), где номер точки линии 1 и 2 - foreign ключи, + уникальные индексы (номер точки линии 1, номер жилы 1) и (номер точки линии 2, номер жилы 2). Однако у меня подозрения, что что-то здесь реализовано сильно не так, как нужно, а вот как это привести к правильному виду - пока не знаю. Собссно, может кто подскажет/подтолкнет в правильную сторону? Я бы рекомендовал добавить таблицу для списка жил внутри отдельного кабеля - жила может быть элементарно бракованной/оборваной. Соответственно, хранить как минимум этот признак где-то надо... И бонусом от использования этой таблицы проявляется возможность отказаться от составных внешних ключей в таблице сварок - вместо (ID кабеля, номер жилы) на обоих "сторонах сварки" можно будет использовать только (ID жилы). IMHO, так же не хватает, условно, таблицы списка трасс: одна трасса может состоять из нескольких межкабельных/междужильных соединений.... Соответственно, таблица сварок должна включать в себя ID трассы... Кстати, Вы учитываете, что соединение (кабель 1, номер жилы 1) -> (кабель 2, номер жилы 2) МОЖНО рассматривать и как "обратное" соединение типа (кабель 2, номер жилы 2) -> (кабель 1, номер жилы 1)? А (иногда) это еще и НУЖНО делать? Соответственно, появляется некий признак "направление" соединения... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2012, 13:33 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
Ну список жил - можно в принципе добавить, то несущественное изменение. Меня больше волнует вопрос соединений. То, что обратное направление можно рассматривать - я знаю, насчет целесообразности этого - спорный вопрос (направление-то физически не существует), оттого - хотелось бы избавиться от двойственной трактовки. А как избавиться - пока не представляю. Почему собссно и создал топик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2012, 15:22 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
xirss, У всех вариантов будут плюсы и минусы. Есть симметричный вариант: ввести сущность - "Присоединение жилы к точке соединения". В ней хранить ключ жилы и ключ соединения. Таких записей будет две на каждое соединение. Симметрично... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2012, 16:05 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
Вариант в принципе... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2012, 16:23 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
pirovindosxirss, У всех вариантов будут плюсы и минусы. Есть симметричный вариант: ввести сущность - "Присоединение жилы к точке соединения". В ней хранить ключ жилы и ключ соединения. Таких записей будет две на каждое соединение. Симметрично... Не считая засады в виде соединения некоторых типов кабелей (задача про кабельные линии, однако), когда в одной точке могут соединяться более 2-х жил... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2012, 18:40 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
sphinx_mvpirovindosxirss, У всех вариантов будут плюсы и минусы. Есть симметричный вариант: ввести сущность - "Присоединение жилы к точке соединения". В ней хранить ключ жилы и ключ соединения. Таких записей будет две на каждое соединение. Симметрично... Не считая засады в виде соединения некоторых типов кабелей (задача про кабельные линии, однако), когда в одной точке могут соединяться более 2-х жил... :) Как раз вариант, когда много жил соединяется в одной точке, тоже хорошо описывается симметричным способом - будет больше чем две записи. Скорее, один из минусов симметричного описания - необходимость поддерживать нужное число записей, чтобы не оказалась одна запись или больше двух, но там, где это невозможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2012, 14:26 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
xirssИмеется некое кол-во кабельных линий, каждая кабельная линия имеет свой тип (определяющий кол-во жил + доп. параметры), соединяются линии в узлах, причем жила линии А может быть соединена лишь с одной жилой другой линии. Также имеются некоторые промежуточные точки на линии, указывающие метраж в данной точке и используемые для рисования трассы. Итого, имеем следующие таблицы: 1) Типы кабельных линий (ID, название, кол-во жил, прочие несущественные поля) 2) Кабельные линии (ID, тип, название, прочие поля) 3) Узлы (ID, координата, название, описание) 4) Точка на линии (ID, номер п/п, координаты, принадлежность к узлу либо NULL для промежуточной точки) 5) Таблица соединений для узла. Со всеми пунктами, кроме п.5, проблем нет, все типовое. Вопрос: как задать собссно соединения? В данный момент таблица сварок реализована в виде (ID, номер точки линии 1, номер жилы 1, номер точки линии 2, номер жилы 2), где номер точки линии 1 и 2 - foreign ключи, + уникальные индексы (номер точки линии 1, номер жилы 1) и (номер точки линии 2, номер жилы 2). Однако у меня подозрения, что что-то здесь реализовано сильно не так, как нужно, а вот как это привести к правильному виду - пока не знаю. Собссно, может кто подскажет/подтолкнет в правильную сторону? Мы решаем похожую задачу в корабельных системах. Собстввенно Ваша схема правильная. Мы так же имеем справочник типов кабелей, таблицу для хранения кабелей с их названиями, но в этой же таблице и оборудование, которое соединяет кабель. Есть таблица трасс кабелей с координатами точек X,Y,Z, что позволяет отрисовывать кабельные трассы на 3D модели корабля. Характеристики кабелей (напряжение, диаметр ...) храним в таблице значений параметров и имеем справочник параметров. Там же храним и параметры оборудования, например, потребляемая мощность. То есть все очень похоже. А вот Ваша пятая таблица это у нас таблица с полями: название (ID) кабеля название (ID) прибора слева, в Вашем случае это видимо соединительная коробка название (ID) прибора справа, в Вашем случае это видимо соединительная коробка При решении прикладных задач, например, обесточивания приборов затопленных помещений такая схема позволяет построить с помощью хранимой процедуры в БД граф связности ( по существу двоичное дерево) приборов при задании исходных приборов ( в нашем случае ГРЩ носовых и кормовых электростанций) Следует заметить что часть приборов - это щиты с автоматами, то есть к щиту может подходить один кабель, а уходить несколько на разные приборы от автоматов. В этом случае целесообразно иметь таблицу автоматов щита и в ней указывать к какому автомату присоединен какой провод ниже по иерархии. В вашем случае видимо это какая то трассировка в коммутационной коробке. Такая схема нам позволяет решать и ряд других задач. Возможно Вам мои рассуждения, чем либо помогут. Удачи. Сайт нашей компании www.spbsc.com ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2012, 15:40 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
pirovindossphinx_mvпропущено... Не считая засады в виде соединения некоторых типов кабелей (задача про кабельные линии, однако), когда в одной точке могут соединяться более 2-х жил... :) Как раз вариант, когда много жил соединяется в одной точке, тоже хорошо описывается симметричным способом - будет больше чем две записи. Скорее, один из минусов симметричного описания - необходимость поддерживать нужное число записей, чтобы не оказалась одна запись или больше двух, но там, где это невозможно.Симметрия возможна когда записи полностью равнозначны. В случае с теми же электропроводами всегда есть направление на источник тока и направление на потребителя, не говоря уже про разные фазы в многофазной сети переменного тока - т.е. не очень "равнозначные" линии с, соответственно, "плохой" симметрией. Полностью равнозначны только проводники, котрые подключены к защитным занулению/заземлению... Нечто аналогичное справедливо и для сигнальных сетей (телефония, компьютерные сети и т.п.). Определять, куда же на самом деле подключена конкретная жила обходом графа по точкам соединений - весьма нетривиальным и ресурсоемкая вычислительная задача, которая без использования понятия "направление" не имеет полезного практического решения. P.S. 2ТС: концы кабельных участков, между которыми производится пайка/сварка/скрутка/т.п, кстати, немножно не эквивалентны "географическим" точкам, где кабели соединяются между собой: "географическое" расстояние между точками не учитывает реальной длины (с учетом технологических и прочих запасов) самого кабеля, проложенного между ними - есть повод об этом тоже подумать... Учет реальной длины линии соединения очень часто крайне критичен... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2012, 19:35 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
sphinx_mvpirovindosпропущено... Как раз вариант, когда много жил соединяется в одной точке, тоже хорошо описывается симметричным способом - будет больше чем две записи. Скорее, один из минусов симметричного описания - необходимость поддерживать нужное число записей, чтобы не оказалась одна запись или больше двух, но там, где это невозможно.Симметрия возможна когда записи полностью равнозначны. В случае с теми же электропроводами всегда есть направление на источник тока и направление на потребителя, не говоря уже про разные фазы в многофазной сети переменного тока - т.е. не очень "равнозначные" линии с, соответственно, "плохой" симметрией. Полностью равнозначны только проводники, котрые подключены к защитным занулению/заземлению... Нечто аналогичное справедливо и для сигнальных сетей (телефония, компьютерные сети и т.п.). Определять, куда же на самом деле подключена конкретная жила обходом графа по точкам соединений - весьма нетривиальным и ресурсоемкая вычислительная задача, которая без использования понятия "направление" не имеет полезного практического решения. В общем-то да, но направление при этом - крайне условное, и применимо лишь в простейших случаях (для соединений типа звезда/сложная звезда), в то время как абсолютно не применима для колец. Ну и трассировка жилы - таки ресурсоемкая (относительно), но вполне тривиальная задача... sphinx_mvP.S. 2ТС: концы кабельных участков, между которыми производится пайка/сварка/скрутка/т.п, кстати, немножно не эквивалентны "географическим" точкам, где кабели соединяются между собой: "географическое" расстояние между точками не учитывает реальной длины (с учетом технологических и прочих запасов) самого кабеля, проложенного между ними - есть повод об этом тоже подумать... Учет реальной длины линии соединения очень часто крайне критичен... Для этого уже собссно предусмотрено у каждой географической точки поле "отметка", в котором будет указываться значение ближайшей метровой отметки... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2012, 19:44 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
xirsssphinx_mvпропущено... В общем-то да, но направление при этом - крайне условное, и применимо лишь в простейших случаях (для соединений типа звезда/сложная звезда), в то время как абсолютно не применима для колец. А вот как раз колец в кабельной системе быть не должно - физически! В сети могут быть логические кольца - но это никогда не физические кабеля! Несколько простых соображений: более своевременная диагностика и более простое решение проблем и, самое главное - безопасность обслуживания. Отправляешь электрика на ремонт распредщита с "кольцом" под напряжением... И все!.. Нет больше электрика... Есть выгоревшая подстанция и пол-города без электричества... А несколько человек едут на "куррортные работы" в места не столь отдаленные... xirssНу и трассировка жилы - таки ресурсоемкая (относительно), но вполне тривиальная задача... Без "направления" обход графа - весьма нетривиальная задача... Попадешь "на кольцо" (физическое или логическое) - жизнь медом не покажется... ;) xirsssphinx_mvУчет реальной длины линии соединения очень часто крайне критичен... Для этого уже собссно предусмотрено у каждой географической точки поле "отметка", в котором будет указываться значение ближайшей метровой отметки...На одну географическую точку (например, соединительную муфту) может приходить несколько разных концов кабелей, каждый из которых может иметь свою реальную длину. Соединение выполняется внутри муфты. Запас кабеля остается снаружи. Так к чему привязаны "отметка" и "метровая метка"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2012, 20:47 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
sphinx_mvА вот как раз колец в кабельной системе быть не должно - физически! В сети могут быть логические кольца - но это никогда не физические кабеля! Несколько простых соображений: более своевременная диагностика и более простое решение проблем и, самое главное - безопасность обслуживания. Отправляешь электрика на ремонт распредщита с "кольцом" под напряжением... И все!.. Нет больше электрика... Есть выгоревшая подстанция и пол-города без электричества... А несколько человек едут на "куррортные работы" в места не столь отдаленные... Есть и в электросетях кольца. Были, есть и будут. Для электросетей - это линии, запитанные (через коммутационное оборудование ессно) с двух сторон, т.зв. транзиты. Простейший пример - линия между двумя ГЭС, на которой висят потребители. В городской распредсети - аналогично, ТП соединены кольцевым кабелем 10кВ. Аналогично и в оптических сетях, через активное оборудование правда проходят... Соответственно, возникает вопрос: для элемента кольца - что считать началом, а что - концом? И как быть, если трассировку нужно сделать не с начала, а с конца или со средины? :) sphinx_mvБез "направления" обход графа - весьма нетривиальная задача... Попадешь "на кольцо" (физическое или логическое) - жизнь медом не покажется... ;) Обычный цикл, с сохранением шагов в массиве и (на всякий случай) проверкой наличия элемента в массиве на случай закольцовывания. sphinx_mvНа одну географическую точку (например, соединительную муфту) может приходить несколько разных концов кабелей, каждый из которых может иметь свою реальную длину. Соединение выполняется внутри муфты. Запас кабеля остается снаружи. Так к чему привязаны "отметка" и "метровая метка"? п.4 в приведенной в 1 посте схеме данных имеет поле "метровая метка". Запас прекрасно реализуется расположенными рядом географически точками с разными метровыми метками. В чем проблема? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2012, 21:01 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
xirsssphinx_mvА вот как раз колец в кабельной системе быть не должно - физически! В сети могут быть логические кольца - но это никогда не физические кабеля! Несколько простых соображений: более своевременная диагностика и более простое решение проблем и, самое главное - безопасность обслуживания. Отправляешь электрика на ремонт распредщита с "кольцом" под напряжением... И все!.. Нет больше электрика... Есть выгоревшая подстанция и пол-города без электричества... А несколько человек едут на "куррортные работы" в места не столь отдаленные... Есть и в электросетях кольца. Были, есть и будут. Для электросетей - это линии, запитанные (через коммутационное оборудование ессно) с двух сторон, т.зв. транзиты. Простейший пример - линия между двумя ГЭС, на которой висят потребители. В городской распредсети - аналогично, ТП соединены кольцевым кабелем 10кВ. Никогда не было и (не будет!) в электрических сетях колец! Кабельное кольцо - непосредственная связь концов кабеля на одном соединении. Если есть терминирующее оборудование - ни о каком кабельном кольце не мождет быть и речи. Есть всего лишь N независимых линий, подходящих на одну единицу оборудования. Да. Визуально выглядит как кольцо. Но физическим кольцом не является ни разу... xirssАналогично и в оптических сетях, через активное оборудование правда проходят... Соответственно, возникает вопрос: для элемента кольца - что считать началом, а что - концом? И как быть, если трассировку нужно сделать не с начала, а с конца или со средины? :) Любая терминация на оборудование фактически разрывает кабельное "кольцо"... Кольцо становится ЛОГИЧЕСКИМ. А по поводу что и как считать "началом" и "концом"... В своей системе я позволяю для порта устройства сети (рутеры, коммутаторы и т.п.) указать порт аплинка... Или даунлинка... Бэкбон (который, типа, "кольцо") - соединение особого типа между устройствами. Как раз для таких соединений у меня учитывается как связь "слева-направо" и как "справа-налево"... И даже для этого кольца считают не от середины бэкбона, а от конкретного порта или устройства, входящего в бэкбон... По сути, даже сам бэкбон можно рассматривать как некое виртуальное устройство в сети... xirsssphinx_mvБез "направления" обход графа - весьма нетривиальная задача... Попадешь "на кольцо" (физическое или логическое) - жизнь медом не покажется... ;) Обычный цикл, с сохранением шагов в массиве и (на всякий случай) проверкой наличия элемента в массиве на случай закольцовывания. Дык эта... У меня так и сделано... Только не просто цикл, а рекурсия - структура иерархическая... И "счастье" сильно зависит от того, сколько узлов в сети учитывается... И насколько подробный учет ведется... xirsssphinx_mvНа одну географическую точку (например, соединительную муфту) может приходить несколько разных концов кабелей, каждый из которых может иметь свою реальную длину. Соединение выполняется внутри муфты. Запас кабеля остается снаружи. Так к чему привязаны "отметка" и "метровая метка"? п.4 в приведенной в 1 посте схеме данных имеет поле "метровая метка". Запас прекрасно реализуется расположенными рядом географически точками с разными метровыми метками. В чем проблема?Чего-то в этом меня сугубо лично смущает... Может, например то, что вместо одной "обобщенной" географической точки, представляющей собой конкретную муфту, в которую входит несколько кабелей, нужно будет создавать "виртуальные" географические точки для каждого межкабельного соединения... С учетом того, что многожильные кабеля вполне могут быть разварены на разные кабеля, это легким движением пальцев оператора вызовет неразгребаемую путаницу. Длина - атрибут отдельного кабельного отрезка, который может быть легко получен для всех имеющихся внутри муфты соединений этого кабеля с другими... И кстати, так как прокладка кабелей - длительный процесс, то вполне может оказаться полезным учитывать отдельно даже каждый из концов прокладываемого кабеля: один из концов в какой-то муфте уже может быть разварен, а второй - еще "висит" где-нибудь в колодце или на столбе... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2012, 21:47 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
sphinx_mvЧего-то в этом меня сугубо лично смущает... Может, например то, что вместо одной "обобщенной" географической точки, представляющей собой конкретную муфту, в которую входит несколько кабелей, нужно будет создавать "виртуальные" географические точки для каждого межкабельного соединения... С учетом того, что многожильные кабеля вполне могут быть разварены на разные кабеля, это легким движением пальцев оператора вызовет неразгребаемую путаницу. Длина - атрибут отдельного кабельного отрезка, который может быть легко получен для всех имеющихся внутри муфты соединений этого кабеля с другими... И кстати, так как прокладка кабелей - длительный процесс, то вполне может оказаться полезным учитывать отдельно даже каждый из концов прокладываемого кабеля: один из концов в какой-то муфте уже может быть разварен, а второй - еще "висит" где-нибудь в колодце или на столбе... Точка в п.4 - это не муфта, а всего лишь точка кабеля (не важно, конец ли, или промежуточная). Муфта - это узел (п.3), на который ссылается точка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2012, 21:52 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
xirsssphinx_mvпропущено...Точка в п.4 - это не муфта, а всего лишь точка кабеля (не важно, конец ли, или промежуточная). Муфта - это узел (п.3), на который ссылается точка. Как в Вашей схеме определить реальную длину кабельной линии, состоящей из нескольких последовательно соединенных разных кабельных отрезков? Может показаться, что я занудствую, но это самый "обычный" вопрос из серии "оченьнадавчера"... ;-) И мы вовремя поставили его себе в самом начале разработки... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2012, 23:22 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
sphinx_mvxirssпропущено... Точка в п.4 - это не муфта, а всего лишь точка кабеля (не важно, конец ли, или промежуточная). Муфта - это узел (п.3), на который ссылается точка. Как в Вашей схеме определить реальную длину кабельной линии, состоящей из нескольких последовательно соединенных разных кабельных отрезков? Отметка в точке конца линии - отметка в точке начала линии куска 1 + отметка в точке конца минус отметка в точке начала линии куска 2 и т.д. Хотя мы заложили помимо отметок еще и поле длинна куска в п.2 (некоторая избыточность вносится, но оно будет актуально если неизвестны отметки в точках - а это собссно и будет происходить для всех старых данных, импортированных с того, что сейчас называется "документацией"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2012, 23:48 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
xirsssphinx_mvпропущено... Как в Вашей схеме определить реальную длину кабельной линии, состоящей из нескольких последовательно соединенных разных кабельных отрезков? Отметка в точке конца линии - отметка в точке начала линии куска 1 + отметка в точке конца минус отметка в точке начала линии куска 2 и т.д. Хотя мы заложили помимо отметок еще и поле длинна куска в п.2 (некоторая избыточность вносится, но оно будет актуально если неизвестны отметки в точках - а это собссно и будет происходить для всех старых данных, импортированных с того, что сейчас называется "документацией").ВОТ!!! "Прочие поля" в кабельных линиях я и "пропустил"... :-) Ну, а если "реальная длина" есть среди этих атрибутов, а "линия" эквивалента "куску кабеля", то никакой избыточности не наблюдается: вполне актуальный атрибут отдельно взятого куска кабеля... И я бы еще, наверное, предложил ввести возможность расширения кабельной линии от одного отдельного куска до последовательности из нескольких кусков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 00:13 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
sphinx_mvНу, а если "реальная длина" есть среди этих атрибутов, а "линия" эквивалента "куску кабеля", то никакой избыточности не наблюдается: вполне актуальный атрибут отдельно взятого куска кабеля... Наблюдается, т.к. это же значение получается исходя из метровых меток на кабеле. Но - это вынужденная мера, т.к. метки известны ен всегда (их может не быть, они могут быть недостоверные и т.д.) sphinx_mvИ я бы еще, наверное, предложил ввести возможность расширения кабельной линии от одного отдельного куска до последовательности из нескольких кусков. Не стоит, все равно точка стыка будет в том или ином виде документироваться. Лучше уж кабельную линию называть как "линия123.1", "линия123.2"... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 00:23 |
|
||
|
БД учета кабельных линий - как правильно спроектировать?
|
|||
|---|---|---|---|
|
#18+
xirsssphinx_mvНу, а если "реальная длина" есть среди этих атрибутов, а "линия" эквивалента "куску кабеля", то никакой избыточности не наблюдается: вполне актуальный атрибут отдельно взятого куска кабеля... Наблюдается, т.к. это же значение получается исходя из метровых меток на кабеле. Но - это вынужденная мера, т.к. метки известны ен всегда (их может не быть, они могут быть недостоверные и т.д.) Нет. Не вынужденная мера - я бы обозначил это как реально правильный вариант. Из личного опыта (а он у меня достаточно богатый)... "Погонные" метки на кабеле бывают двух видов: маркировка от производителя и "ручная" маркировка... "Ручная" метка сильно завязана на "электрика Васю", который в зависимости от расположения звезд на небе и вечера вчерашнего дня, может элементарно "забыть" их проставить. Да и реально муторная эта работа - на паре десятков километров УТП-5 в средней величины офисном здании особо не намаркируешься... И хорошо, если хотя бы концы кабелей в жгуте промаркируют, чтобы потом прозванивать не пришлось... Маркировка производителя ориентирована скорее на остаток кабеля в бухте, а не на измерение длины куска - с одной бухты может быть нарезано несколько кусков кабелей... И если ориентироваться на метки "из бухты", то глядя на торчащий в распредкоробке конец не сразу скажешь, какая метка будет следующая - больше или меньше той, которую видишь... И не всегда есть доступ к этим меткам... И кто даст гарантию, что "электрик Вася" не срастил где-нибудь посередине два куска кабеля между собой "сугубо в целях экономии"? Зато при списании кабеля всегда можно взять монтажников "за жабры" по поводу точного указания где, чего и сколько реально проложено... И потом указать эту справочную цифру в параметрах линейного участка... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 02:14 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38033152&tid=1541482]: |
0ms |
get settings: |
4ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
106ms |
get topic data: |
5ms |
get forum data: |
1ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 203ms |
| total: | 362ms |

| 0 / 0 |
