|
|
|
Учет оборудования по ИТ и связи - изменение схемы данных
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток! Сразу хочу извиниться за вероятный повтор вопросов, однако, не смог найти разбора моих вопросов среди тем по складскому учету и учету оборудования. Смотрел в том числе эти темы: Тема 1 Тема 2 Тема 3 Мой первый опыт создания БД, поэтому сильно прошу не пинать :) Итак: исходя из первоначальных требований по учету фактического местоположения оборудования, набросал БД с прилагаемой схемой, в которой: Голубая рамка - иерархия местоположения оборудования Красная рамка - модель (например: iPhone 5s, Samsung Galaxy S5 и пр.) и тип оборудования (например: Мобильный телефон, Системный блок, Монитор, принтер и пр..) Сиреневая рамка - данные по расходным материалам Желтая рамка - информация по договорам поставки. Зеленая рамка - справочники по сотрудникам, текущему статусу (в работе, в ремонте, в резерве) и пр... В центре собственно основная таблица, в которой хранятся данные по всем объектам учета. Общий объем записей планируется около 4 000 - 5 000. Задачи: 1 . на текущем этапе появилось желание хранить данные о характеристиках оборудования. Например: для принтера указать его скорость печати, максимальный формат, цветной или ч/б, струйный или лазерный; для монитора - диагональ, тип матрицы и пр... Вопрос: Как лучше (правильнее) сделать, чтобы еще облегчить себе задачи с последующей выборкой данных: а) Привязать к модели и типу оборудования одну таблицу в которой создать кучу полей со всеми возможными параметрами для всех типов оборудования. Тогда для конкретной записи многие поля будут пустыми, т.к. не имеют отношения к конкретному типу или б) создать "много" таблиц для каждого типа оборудования, в каждой из которых хранить только относящиеся к нему данные. Тогда, насколько я понимаю, при появлении нового типа оборудования придется создавать новую таблицу и переписывать или дописывать запросы... в) другие альтернативы 2. Каким образом организовать хранение данных по текущей конфигурации конкретного устройства? Например: данная модель принтера поддерживает подключение по сети, однако, не все из них используют сеть и многие подключены по usb к ПК пользователя, или данная модель системного блока с завода имеет 2 Gb RAM, но в процессе эксплуатации было добавлено еще 2 и сейчас их, понятно, 4. 3. Правильно ли я понимаю, что с целью хранения истории перемещений или модификации конфигураций "типовое решение" - это отдельные таблицы, в которые копируется запись перед ее изменением? Так же сейчас начинаю конструировать запросы из таблиц и понимаю, что в результатах поиска у меня должна отображаться информация в табличном виде (использую ListBox) из 9 таблиц БД. Придется делать много вложенных запросов. Насколько сильно это скажется на производительности БД при существующей структуре? Заранее большое спасибо всем кто откликнется! P.S. Пытаюсь работать в MS Access 2010. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2014, 12:59 |
|
||
|
Учет оборудования по ИТ и связи - изменение схемы данных
|
|||
|---|---|---|---|
|
#18+
Любая из ваших проблем (хранение разного типа оборудования или хранение истории имеет более одного решения). У каждого решения есть свои достоинства/недостатки. Насколько это важно для ВАШИХ условий решать вам. авторТогда, насколько я понимаю, при появлении нового типа оборудования придется создавать новую таблицу и переписывать или дописывать запросы...А что вы хотели - новое оборудование - новые формы для ввода и т.д. А при попытке использовать старые таблицы возможна ситуация когда в старый отчет вместе с принтерами попадают новозаведенные телевизоры. автор1 в) другие альтернативы создать общую таблицу с общими полями (наименование, инвентарный номер, местоположение и т.п) и/или полями для поиска и по дополнительной таблице для каждого из типов оборудования. автор2. Каким образом организовать хранение данных по текущей конфигурации конкретного устройства?Зависит от запросов. Уверен, рано или поздно вас осенит ИДЕЯ EAV. Гоните ее прочь, ибо это дает быстрый старт, но большой гемор в поддержке. Хотя для ваших объемов это не существенно. авторПравильно ли я понимаю, что с целью хранения истории перемещений или модификации конфигураций "типовое решение" - это отдельные таблицы, в которые копируется запись перед ее изменением?Это один из возможных подходов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2014, 18:47 |
|
||
|
Учет оборудования по ИТ и связи - изменение схемы данных
|
|||
|---|---|---|---|
|
#18+
SERG1257, Спасибо за комментарий. SERG1257У каждого решения есть свои достоинства/недостатки. Насколько это важно для ВАШИХ условий решать вам. Не могли бы Вы подсказать в какие направлениях нужно вести "раскопки", что бы потом более менее взвешенно принять решение? SERG1257автор2. Каким образом организовать хранение данных по текущей конфигурации конкретного устройства?Зависит от запросов. Уверен, рано или поздно вас осенит ИДЕЯ EAV. Гоните ее прочь, ибо это дает быстрый старт, но большой гемор в поддержке. Хотя для ваших объемов это не существенно. С EAV понял :) Да запросы в общем скромные, но насколько я сейчас понимаю, в любом случае потребуются дополнительные таблицы для каждого типа оборудования в которой будет хранится текущая конфигурация каждой железки... Пока ничего лучше не придумал... SERG1257 авторПравильно ли я понимаю, что с целью хранения истории перемещений или модификации конфигураций "типовое решение" - это отдельные таблицы, в которые копируется запись перед ее изменением? Это один из возможных подходов. Не могли бы подсказать альтернативные варианты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 07:26 |
|
||
|
Учет оборудования по ИТ и связи - изменение схемы данных
|
|||
|---|---|---|---|
|
#18+
Mr. Max. G.Не могли бы подсказать альтернативные варианты? Добавьте в таблицу Hardvare_tbl поле Сomments varchar(....) и записывайте там все, что не укладывается в остальные поля. По комментариям можно будет контекстный поиск сделать. Скорость в Вашем случае некритична. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 16:20 |
|
||
|
Учет оборудования по ИТ и связи - изменение схемы данных
|
|||
|---|---|---|---|
|
#18+
Mr. Max. G. Не могли бы Вы подсказать в какие направлениях нужно вести "раскопки", что бы потом более менее взвешенно принять решение?Для ваших объемов почти все недостатки можно объявить несущественными. Плюс многие особенности проявляются в процессе эксплуатации. Но если тезисно По наследованию 1 Хранить все в одной таблице с пустыми полями Достоинства - самый простой и самый быстрый подход. Быстро искать, легко править. Несмотря на кажущуюся неэффективность (много пустых полей) это не проблема для "взрослых" СУБД (null не занимает место). 2 Хранить все в разных таблицах объединяя их по union all Достоинства - можно править любую часть. Однако поиск будет неторопливым. Такой подход характерен для отчетов, когда данные скорее разные чем общие. 3 Гибридный подход Общие поля и поля для поиска в таблицу предка Специфичные поля отдельные для каждого типа и связаны 1:1 с общей таблицей. По хранению истории Историю можно хранить как в отдельной таблице (как у вас), так и в той же самой таблице. Историю можно хранить с одной датой d_change (надежнее, но медленнее, с лишним сканом таблицы) так и с двумя датами d_from, d_to (быстрее, легче искать, но сложнее поддерживать) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 17:53 |
|
||
|
Учет оборудования по ИТ и связи - изменение схемы данных
|
|||
|---|---|---|---|
|
#18+
Спасибо за комментарии. Буду работать в предложенных направлениях! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 07:07 |
|
||
|
Учет оборудования по ИТ и связи - изменение схемы данных
|
|||
|---|---|---|---|
|
#18+
суффикс tbl - умиляет EAV можно использовать для хранения и специфических характеристик, а для аналитической обработки - атрибуты трансформировать (pivot) в столбцы в отдельные таблицы = равные блокам. Разметку атрибутов по блокам хранить в метаданных EAV. Работает, проверено. А вот использовать EAV для фронт-офисной системы, где навьючено много ветвистой логики - убийственно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 21:55 |
|
||
|
|

start [/forum/topic.php?desktop=1&fid=32&tid=1540934]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
30ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 255ms |
| total: | 373ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...