Выбор структуры БД

Нифига не понял. Можешь написать что-то вроде схемки или графа связей, кто под кем лежит?

P.S. Пока на основе сказанного я бы делал либо одну таблицу, либо связанные таблицы.

3000 таблиц не многовато будет?

Цель как раз в том, чтобы потом из полученной базы сделать граф связей всей сети. Сейчас на каждый коммутатор есть таблица в html, где расписаны назначения линков (порт ответного коммутатора или оборудования клиента и прочее).

почитай любую нормальную книгу по бд, про проектирование, и что такое нормализация

Дай мне структуру на пастбине. Я не знаю, как ты описываешь эти связи.

В том-то и вопрос. Я не знаю, много ли это, 3000 таблиц. Сами таблицы будут маленькими.

Таблица с коммутаторами (идентификатор коммутатора, имя и прочее), таблица с портами (идентификатор порта, идентификатор коммутатора-«владельца» и прочее), таблица связей (порт один, порт два, тип связи).

тебе прямая дорога к zabbix =)

Насколько понял, лучше первый вариант.

Удваиваю.

Таблица коммутаторов COMM

COMM.ID - Идентификатор
COMM.Name - Название
COMM.Model - Модель
COMM.Quantity - Количество портов
COMM.Place - Размещение
COMM.URL - Адрес админки и т.п.
COMM.Type - Тип (пограничный, конечный и прочее)
+ два три поля для резерва

Таблица портов коммутатора COMMPORTS.

COMMPORTS.ID - Идентификатор порта
COMMPORTS.COMM - Идентификатор коммутатор (-COMM.ID)
COMMPORTS.Num - Номер порта
COMMPORTS.Type - Тип порта (Up/Down)
COMMPORTS.UPLINK - Идентификатор порта uplinka (COMMPORTS.ID)
COMMPORTS.DOWNLINK - Идентификатор порта downlinka (COMMPORTS.ID)

Через COMMPORTS.UPLINK, COMMPORTS.DOWNLINK строить иерархию. По хорошему еще таблицу VLAN-ов можно замутить

ТС, это правильный ответ.

таблица с портами

таблица с портами/VLANами либо +1 таблица под VLANы

// мелкофикс

еще неплохо было бы сделать отдельными таблицами «производитель» и «модель»

я тоже туда посылаю

Он их не продавть собирается => не нужно

да, но не очень красиво хранить например 200 записей с одинаковым названием «cisco super commutator l200 gen2»

Обычно таблица=сущность. Соответственно, для коммутаторов таблица. Отдельный коммутатор - это строка.

доо, зато охрененно красиво городить огород в коде, совершенно бессмысленный при том.

g стив йегг портрет нуба

Очевидно, что уж совсем пренебрегать моделированием данных не стоит. Не очевидно, когда следует остановиться.

На сети уже крутится Заббикс. Но настроен кривовато, а у меня доступа к админкам нету. Да и хочется мне большего, чем он умеет. Вот и решился городить огород.

На сети уже крутится Заббикс. Но настроен кривовато, а у меня доступа к админкам нету. Да и хочется мне большего, чем он умеет. Вот и решился городить огород.

для каталогизации достаточно будет взгромоздить GLPI

делать для каждого коммутатора таблицу?

да ты упоролся.

зырь:

когда много однородных (т.е можно их набором(одним и тем же) полей базовых типов) данных то это таблица - ну или набор таблиц (для уменьшения «паразитности» и приведения в ту или иную циферную форму)

когда же данные коечто о кое чём - то заруливает ключ-значение.

вообще то эмульнуть первые на вторых проще чем вторые на первых ( однако в обоих случаях ненужные расходы на эмуляции)

так как всякие страшные ораклы и прочие решают воопросы промышленного учёта крупносерийного производства то и реляционные базы рулят

в разнородных данных(особенно пока не выкрестализовалась либо происходит смена структуризации) рулят простые ключ-значение ( по сути это и есть основа любой системы информации)

для твоей задачи стоит взять набор реляционных таблиц ибо коммутаторы «изделия массового производства» - т.е таблица марок , какой комутатор какой марки , ну и таблица топологии - ну тут сущьности ещё какие .

на часть данных которые в реляционной просто как мемо .- можно навертеть ключ-значения - ибо такие системы данных могут иметь любую структуру и не обязаны быть полными.

три таблицы: таблица коммутаторов, таблица портов (подчинение первой), таблица связей (порт1, порт2)

все. не городите огород.

Да на это всё надо! Сделай для каждого коммутатора свой текстовый файлик... Потому как реляционки имеют толк только если бд сделана правильна и к БД приставлен скрипткидди с SQL-прошивкой в голове.