powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Пользователи, железо,сеть
8 сообщений из 8, страница 1 из 1
Пользователи, железо,сеть
    #33926991
londinium
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте, Господа!

Работаю я anykey-щиком на государственной службе и для облегчения работы себе и приобретения начальных навыков в клиент-сервер решил спроектировать базу данных подведомственного оборудования, пользователей и сетевых настроек. В этом и прошу Вашей помощи.
Итак, в базе необходимо хранить список пользователей, список комнат, тип оборудования, его инвентарный номер и статус, а также IP-адресацию компьютеров. Пока пришел к такой структуре таблиц:

Код: plaintext
1.
2.
3.
4.
CREATE TABLE REFWORKERS (
    ID       INTEGER NOT NULL,
    SURNAME  VARCHAR( 50 )
);
REFWORKERS - справочник сотрудников (Иванов, Петров, Сидоров)

Код: plaintext
1.
2.
3.
CREATE TABLE REFSTATUS (
    ID           INTEGER NOT NULL,
    DESCRIPTION  VARCHAR( 20 ) NOT NULL
);
REFSTATUS - справочник статуса оборудования(работает, ремонт, подано на списание, списано)

Код: plaintext
1.
2.
3.
4.
CREATE TABLE REFROOMS (
    ID      INTEGER NOT NULL,
    NUMBER  VARCHAR( 15 )
);
REFROOMS - справочник комнат(104,105, подсобка и т.п)

Код: plaintext
1.
2.
3.
4.
CREATE TABLE REFEQUIPMENTTYPE (
    ID           INTEGER NOT NULL,
    DESCRIPTION  VARCHAR( 150 )
);
REFEQUIPMENTTYPE -справочник типов оборудования (компьютер, монитор, принтер, ксерокс).

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
CREATE TABLE EQUIPMENT (
    ID              INTEGER NOT NULL,
    INVENTARNUMBER  VARCHAR( 10 ) NOT NULL,
    TYPEEQ          INTEGER NOT NULL,
    DESCRIPTION     VARCHAR( 100 ) NOT NULL,
    WORKER          INTEGER NOT NULL,
    PLACE           INTEGER NOT NULL,
    STATUS          INTEGER NOT NULL
);
ALTER TABLE EQUIPMENT ADD CONSTRAINT FKPLACE FOREIGN KEY (PLACE) REFERENCES REFROOMS (ID);
ALTER TABLE EQUIPMENT ADD CONSTRAINT FKSTATUS FOREIGN KEY (STATUS) REFERENCES REFSTATUS (ID);
ALTER TABLE EQUIPMENT ADD CONSTRAINT FKTYPE FOREIGN KEY (TYPEEQ) REFERENCES REFEQUIPMENTTYPE (ID);
ALTER TABLE EQUIPMENT ADD CONSTRAINT FKWORKER FOREIGN KEY (WORKER) REFERENCES REFWORKERS (ID);

EQUIPMENT - таблица оборудования.
Поле INVENTARNUMBER - инвентарный номер
Поле DESCRIPTION - описание(Samsung SyncMaster 753DFX, HP LaserJet 1320n и т.п)

База будет крутиться под FireBird SuperServer на Windows 2k/XP, максимальное количество пользователей – 20 человек(в далекой перспективе), на данный момент - 2.

Вопросы таковы:
--насколько я хорошо/плохо придумал структуру таблиц
-- как лучше хранить IP-адресацию, а то пихать ее в таблицу EQUIPMENT пока не хочется ибо монитор при всем желании не имеет IP-адреса.
...
Рейтинг: 0 / 0
Пользователи, железо,сеть
    #33927110
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
londiniumмонитор при всем желании не имеет IP-адреса.не факт!
раз
два
три
четыре
и это только навскидку!

PS. чисто для справки - у одного девайса (не любого) может быть более одного ip-адреса, в т.ч на одном физическом порту
...
Рейтинг: 0 / 0
Пользователи, железо,сеть
    #33927234
londinium
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
не факт!
раз
два
три
четыре
и это только навскидку!


Признаю, не прав, но мы(в смысле контора), пока, до таких мониторов не доросли, потому так написал.


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

Согласен. Поэтому и вопрос, как лучше сделать с сетевыми настройками. Пока только идея хранить их в отдельной таблице и связать эту таблицу с EQUIPMENT по внешнему ключу.
Кто что еще может посоветовать?

С уважением, londinium
...
Рейтинг: 0 / 0
Пользователи, железо,сеть
    #33927278
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а при смене компьютера у пользователя ip-адрес остается прежним?
т.е. ip-адрес привязан к железяке или к рабочему месту?
...
Рейтинг: 0 / 0
Пользователи, железо,сеть
    #33927473
londinium
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а при смене компьютера у пользователя ip-адрес остается прежним?
т.е. ip-адрес привязан к железяке или к рабочему месту?

IP-адрес остается, т.к привязка идет к рабочему месту.
...
Рейтинг: 0 / 0
Пользователи, железо,сеть
    #33929643
londinium
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Живо вверх!
...
Рейтинг: 0 / 0
Пользователи, железо,сеть
    #33942095
_slava_k_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
К структуре таблиц обычно приходят в послледнюю очередь.
Вот схемку Вы нарисовали красивую - от неё нужно плясать.
А IP адрес - это, по-моему, атрибут, не совсем относящийся к описанию "железных" и прочих качеств железяки.

Я бы подумал над тем, что есть люди, оборудование, помещения.
Люди работают и сидят в помещениях. Оборудование работает, ломается/чинится, отдаётся под роспись людям в помещения, настраивается (вот тут IP адрес может быть одним из атрибутов).

А если IP закрепляется за рабочим местом - в этой таблице его и надо указать. Только нужно следить, чтобы это всё соответствовало действительности :-). , т.к. этом случае получается кривовато - IP адрес прикрепляется к рабочему месту, а является атрибутом железяки.
...
Рейтинг: 0 / 0
Пользователи, железо,сеть
    #33944794
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
также начал работать на подобной проблемой
а ни кто не делал такое в виде дерева и атрибутов к вершинке?
например
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
- учреждение
  - отдел А
    - комната  205 
      - ПК  1 
        - системный блок
          - main board
          - CPU
          - LAN
        - монтор
        - принтер
      - ПК  2 
атрибутом ПК, может быть, инвентарный номер, Фамилия пользователя, версия ОС
для LAN - модель сетевухи, MAC, IP
таблички
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
для хранения дерева
- node_id
- parent_id
- obj_id

для хранения видов объектов (ПК, кабинет, принтер...)
- obj_id
- obj_name

для хранения видов атрибутов (ФИО пользователя, IP, производитель)
- otr_id
- otr_name

для связи дерева и вида объекта
- id
- node_id (ref)
- obj_id (ref)

для привязки атрибутов к объектам
- id
- node_id  (ref)
- otr_id  (ref)
- otr_value
тут и всё можно хранить, и легко "переставить" системник в другое помещение
и перед глазами не будет "универсальной" формы с 30 полями о характеристиках оборудования
можно ещё для "вида отрибута" указать для какого "вида объекта" он применим, чтобы когда пользователь добавляет к системнику комплектующую, не прокручивал "кабинеты, стулья..." :)
Мне кажется так будет более гибко чем в первом посте, да и не только железо можно будет учитывать

что думаете по поводу?
...
Рейтинг: 0 / 0
8 сообщений из 8, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Пользователи, железо,сеть
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]