Страница 1 из 2
Железо, пользователи, сеть
Добавлено: 21 авг 2006, 18:47
londinium
Здравствуйте, Господа!
Работаю я anykey-щиком на государственной службе и для облегчения работы себе и приобретения начальных навыков в клиент-сервер решил спроектировать базу данных подведомственного оборудования, пользователей и сетевых настроек. В этом и прошу Вашей помощи.
Итак, в базе необходимо хранить список пользователей, список комнат, тип оборудования, его инвентарный номер и статус, а также IP-адресацию компьютеров. Пока пришел к такой структуре таблиц:
Код: Выделить всё
CREATE TABLE REFWORKERS (
ID INTEGER NOT NULL,
SURNAME VARCHAR(50)
);
REFWORKERS - справочник сотрудников (Иванов, Петров, Сидоров)
Код: Выделить всё
CREATE TABLE REFSTATUS (
ID INTEGER NOT NULL,
DESCRIPTION VARCHAR(20) NOT NULL
);
REFSTATUS - справочник статуса оборудования(работает, ремонт, подано на списание, списано)
Код: Выделить всё
CREATE TABLE REFROOMS (
ID INTEGER NOT NULL,
NUMBER VARCHAR(15)
);
REFROOMS - справочник комнат(104,105, подсобка и т.п)
Код: Выделить всё
CREATE TABLE REFEQUIPMENTTYPE (
ID INTEGER NOT NULL,
DESCRIPTION VARCHAR(150)
);
REFEQUIPMENTTYPE -справочник типов оборудования (компьютер, монитор, принтер, ксерокс).
Код: Выделить всё
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 и т.п)
Пока думаю в таблице EQUIPMENT хранить все подряд оборудование(т.е. не делать отдельных таблиц под принтеры, ксероксы, мониторы)
База будет крутиться под FireBird SuperServer на Windows 2k/XP, максимальное количество пользователей – 20 человек(в далекой перспективе), на данный момент - 2.
Вопросы таковы:
--насколько я хорошо/плохо придумал структуру таблиц
-- как лучше хранить IP-адресацию, а то пихать ее в таблицу EQUIPMENT пока не хочется ибо чистый ксерокс(не МФУ) при всем желании не имеет IP-адреса.
Четкой привязки IP-адреса нет, может меняться как пользователь(уволился), так и компьютер(сгорел, уехал на ремонт)
Заранее всем спасибо за ответы и просьба сильно не ругаться
Добавлено: 22 авг 2006, 08:08
Dimitry Sibiryakov
Структура более-менее нормальная. На IP адреса я бы задействовал DHCP и не заморачивался, а хранил бы MAC адреса. Но тут возникает проблема смены частей - замена монитора, сетевой карты и т.д. а отсюда возможно дробление оборудования на части и спец. таблица для объединения этих частей в (текущие) сборки.
Кроме того возможно в будущем тебе захочется хранить не текущий статус, а историю: такого-то введен в эксплуатацию, тогда-то отдан в ремонт, списан и т.д.
Добавлено: 22 авг 2006, 09:13
ODIN
Предлагаю ввести таблицу типа Workplace (рабочее место или размещение) а к нему уже привязывать и сотрудника (занимающего это место), к нему же привязывать оборудование (на этом месте установленное). таблица будет зависеть от таблицы помещений и от таблицы Department (отделы, подразделения) Ввести таблицу типов рабочих мест (серверный шкаф, рабочее место бухгалтера, терминал, склад и т.п.)
В таблице Equipment поле Name предлагаю не использовать, а связаться с таблицей Nomenclature где уже указывать тип устройства, производителя и тп. (это для того чтобы потом небыло "пересортицы" в наименованиях оборудования)
Добавлено: 22 авг 2006, 10:15
londinium
Предлагаю ввести таблицу типа Workplace (рабочее место или размещение) а к нему уже привязывать и сотрудника (занимающего это место), к нему же привязывать оборудование (на этом месте установленное).
Отличная идея.
Добавлено: 22 авг 2006, 10:46
WildSery
londinium писал(а):Предлагаю ввести таблицу типа Workplace (рабочее место или размещение) а к нему уже привязывать и сотрудника (занимающего это место), к нему же привязывать оборудование (на этом месте установленное).
Отличная идея.
Ничего "отличного". Куча оборудования у тебя не привяжется к конкретному рабочему месту. Например, переносной HDD - куда? А что-то такое у тебя и так есть - REFROOMS. Только доработать чуть.
А вот с комплектующими ты вообще ничего не продумал, конечно. А ведь учитывать захочется...
Журнал изменений статуса вести нужно для каждого оборудования - когда пришло, когда в ремонт сдано, когда списано.
Необходимо предусмотреть перемещение между "рабочими местами" и комнатами - хранить ли историю или только текущее положение.
Добавлено: 22 авг 2006, 12:12
ODIN
повторюсь что таблица Worplace имеется ввиду не только рабочее место, но и "размещение" а у этой таблицы есть таблица подтипов склад, бухгалтер, терминал, диагностический стенд на колёсах
переносной HDD всё равно где то (место, размещение) числится, т.е. если вещь общего пользования то её иногда берут попользоваться, но расположена она обычна всегда например у "ответственного" сотрудника, например материально ответсвенного лица или просто человека который часто ею пользуется, или чаще всего лежит "на складе". В задачу не входит отслеживание где мобильного устройства во времени и в простанстве в такой детализации, достаточно чтобы в отчёте видно было что числится за тем то, там то должно находится.... или вы предлагаете учитывать что Вася передал гаджет Пете Петя Коле каждые 1-2 часа
а на счёт доработки REFROOMS не совсем согласен, тут принципиально нужно учитывать что рабочее место (расположение), зависит и от помещения (территориально) и от подразделения, отдела и тд (административно)
Добавлено: 22 авг 2006, 12:24
WildSery
Т.е. по твоим словам, Workplace будет содержать в себе и Refrooms, и Refworkers, и ещё кучу всего.
Тогда зачем упомянутые сущности в отдельности?
Твоё предложение выливается в "справочник справочников" что-то типа:
Код: Выделить всё
ID CONCEPT NAME
0 0 Справочники
1 0 Юзеры
2 0 Комнаты
3 0 Подразделения
4 1 Пупкин
5 1 Васечкин
6 2 Кладовка
7 3 Сбыт
8 3 Склад
с тем, чтобы ссылка на "местоположение" могло быть чем угодно, хоть комнатой, хоть пользователем.
Добавлено: 22 авг 2006, 13:17
ODIN
нет, справочник справочников я не предлагаю, я предлагаю что то типа регистра
Код: Выделить всё
CREATE TABLE WORKPLACE (
ID TID NOT NULL /* TID = INTEGER */,
ID_DEPARTMENT TID /* TID = INTEGER */,
ID_WORKMAN TID /* TID = INTEGER */,
ID_BUILD TID /* TID = INTEGER */,
ID_TYPE TID /* TID = INTEGER */,
PHONE TSTRING /* TSTRING = VARCHAR(255) */
);
если есть более интересная идея всегда готов рассмотреть
Добавлено: 22 авг 2006, 15:00
WildSery
В таком регистре у тебя многие поля будут null, как мне видится. У меня вообще к null неприятие выработанное...
Добавлено: 22 авг 2006, 17:06
ODIN
значение null если и будет то крайне мало, да вообщем то для полей типа ID (FK) null это нормально, над такими полями сложения, конкатенации и других всяких обработок в которых null бяка не учавствуют.... мож я и не прав тоды просветите
Добавлено: 22 авг 2006, 17:59
kdv
обработок в которых null бяка не учавствуют.... мож я и не прав тоды просветите
а ты Дейта почитай "Введение в системы баз данных". Главу "Отсутствующая информация". На ночь.
Добавлено: 23 авг 2006, 16:53
ODIN
а если таблицы ссылаются друг на друга, без null в FK не обойтись, да и в данном случае "отсутствие информации" т.е. Null таблицы Workplace в поле ID_WORKMAN просто информирует нас о том что на данном рабочем месте никто не сидит, и всё
вообще незря же PK уже подразумевает наличие not null условия, а в FK это оставлено на разработчика, если ему надо задать ограничение на null в FK, если это действительно надо по требованиям бизнес правила его БД то пожалуйста... стандарт SQL такой
Добавлено: 23 авг 2006, 17:22
kdv
если это действительно надо по требованиям бизнес правила его БД то пожалуйста
я тебе про это и говорю. Дейта ты судя по всему, не читал. Рекомендую почитать упомянутую главу, там как раз про null в FK написано.
Добавлено: 23 авг 2006, 23:26
ZanZag
угу-угу...
не читали оне, а зря, право сударь, напрасно.
отсутствие null (что перевести можно как "неопределено/неизвестно") в данных есть правило хорошего тона и залог безпроблемности в данных...
а коли оно (null) есть, то значит не особо то модель хорошая...
когда-то, на заре моей юности, мне быстро гуру доказали, что не бывает случаев где нельзя избежать null.
в указанном случае решить вопрос довольно просто, в справочнике заводиться записть с ID 0 и значением "раб. место не занято" или что-то подобное.... и никакие null не потребуются...
Добавлено: 24 авг 2006, 08:21
Andrew Sagulin
ZanZag писал(а):в указанном случае решить вопрос довольно просто, в справочнике заводиться записть с ID 0 и значением "раб. место не занято" или что-то подобное.... и никакие null не потребуются...
Здесь это уже обсуждалось...
http://forum.ibase.ru/phpBB2/viewtopic. ... highlight=
Вот скажите мне, пожалуйста, чем вот так вот уж очень сильно, если знать про особенности трёхзначной логики, null отличается от специального значения? Какая разница, пишем ли мы is null или = 0.
Не поймите меня неправильно: я не спорю, я на самом деле хочу увидеть реальный пример, когда null в FK неудобен, или опасен.
Добавлено: 24 авг 2006, 08:50
ODIN
Вообще конечно мне тут лучше уточнить что в моей схеме всё таки нет таких моментов как null в FK. схему я приводил по памяти больше, а при просмотре уточнил что связка на таблицу Workplace идёт от таблицы Workman (есть поле ID_workplace), а во всех других случаях в таблице размещений нет наличия null в связи с принципом работы модели бд.
А на счёт добавления записи "не указано" в принципе тоже вариант, хотя откуда в таблице работников может появиться человек с такой фамилией
во всех случаях есть свои тараканы.
лучше бы господа хорошие предложили что нибудь по существу темы...
Добавлено: 24 авг 2006, 10:13
kdv
Вот скажите мне, пожалуйста, чем вот так вот уж очень сильно, если знать про особенности трёхзначной логики, null отличается от специального значения? Какая разница, пишем ли мы is null или = 0.
офигеть. тебе Дейта как - сюда перепечатать? Или ты сам как-нибудь?
null в FK не может быть опасен. это или удобно, или неудобно. это или правильно для конкретной модели, или неправильно.
Добавлено: 24 авг 2006, 10:55
Andrew Sagulin
kdv писал(а):
офигеть. тебе Дейта как - сюда перепечатать? Или ты сам как-нибудь?
Намёк понял, ухожу...
А Дейта обязательно куплю при случае.
В поисках null-ов забрёл
сюда. Может быть кому-нибудь будет интересно.
Добавлено: 15 сен 2006, 14:59
Zhur
Не хочу никого злить... но должен признаться - Дейта не читал, так как живу в маленьком городе с маленьким ассортимментом литературы. Если он (Дейт) не будет против, буду рад прочитать хотя бы эту главу на сайте.
Добавлено: 15 сен 2006, 16:06
CyberMax
Не сочтите за рекламу.
Zhur писал(а):Дейта не читал, так как живу в маленьком городе с маленьким ассортимментом литературы.
А
http://www.books.ru тебе на что? В магазинах в основном поп. литературу по компьютерам продают, то есть такую, которая быстро расходится. Cпец. литературу даже у нас найти сложно. В последнее время только через интернет-магазины закупаюсь. Скажу даже так - Дейта, Борри, "Мир InterBase" брал именно там. Единственный минус - товар около трех недель идет.