Структура БД

← →
Ozone © (2004-02-26 17:52) [0]

Написал клиент/серверную программу которая собирает информацию о компьютерах из локальной сети (каждый месяц). Теперь стоит задача правильно огранизовать БД для хранения собираемой информации.
Дело вот в чем - необходимо отслеживать движение и изменение кофигурации компьютеров => если произошли некоторые изменения (поставили еще один HD, убрали принтер и т.п.), то необходимо эту информацию как-тоо зафиксировать.
В голову приходит только одна мысль - сделать что-то типа дерева, т.е. если произошли изменения конфигурации, то выношу их на первый план, а старую информацию уношу вниз.

Например:

изначально:
[b]
комп №1 (10.03.2001)
комп №2 (11.03.2001)
...
[/b]

через месяц (допустим была изм. конфигурация "комп №1" 10.04.2001), получаем
[b]
комп №1 (10.04.2001)
- комп №1 (10.03.2001)
комп №2 (11.03.2001)
...
[/b]

еще через месяц (опять изменили "комп №1"), получаем
[b]
комп №1 (10.05.2001)
- комп №1 (10.04.2001)
- комп №1 (10.03.2001)
комп №2
...
[/b]

← →
Sandman25+1 (2004-02-26 17:53) [1]

Каков вопрос?

← →
Ozone © (2004-02-26 17:56) [2]

Может быть есть более правильное решение моей проблемы?

← →
Sandman25+1 (2004-02-26 17:59) [3]

Нет правильного и неправильного.
Что нужно, то и делайте. Как удобно, так и делайте.
Можно перед показом запросить номер компьютера, а потом показывать информацию в Dbgrid. Тогда пользователь сможет сортировать как ему удобно (по дате, по названию измененного устройства, по цене).

← →
Vlad © (2004-02-26 18:00) [4]

а для чего тут дерево ?
Т.е. почему нельзя представить данные ввиде обычного списка с хранением истории ?

← →
Ozone © (2004-02-26 18:02) [5]

Есть же стандарты, нормальные формы и т.п.
Насколько это правильно с точки зрения правильного конструирования БД?

← →
Johnmen © (2004-02-26 18:02) [6]

Проблема с идеологией хранения или отображения ?

← →
Ozone © (2004-02-26 18:03) [7]

To Johnmen

с идеологией...

← →
Johnmen © (2004-02-26 18:03) [8]

Структура будет определяться тем, насколько удастся формализовать "изменение".

← →
Sandman25+1 (2004-02-26 18:03) [9]

[5] Ozone © (26.02.04 18:02)

Хранить можно в одном виде, показывать в другом. Это никак не связано между собой.

← →
Ozone © (2004-02-26 18:06) [10]

TO Sandman25+1

Дык хранить надо правильно, так?

← →
Vlad © (2004-02-26 18:07) [11]

> Ozone © (26.02.04 18:06) [10]

Чем правильно есть - вилкой или ложкой ?

← →
Ozone © (2004-02-26 18:08) [12]

TO Vlad

Смотря что есть...

← →
Sandman25+1 (2004-02-26 18:09) [13]

Можно так:

mod_main(id автоинкремент или генератор, id_computer INT, date_modif DATE, login INT или CHAR, ...)

mod_details(id из mod_main, старое значение, новое значение, ...)

← →
Vlad © (2004-02-26 18:09) [14]

> Ozone © (26.02.04 18:08) [12]

Правильно есть тем, чем тебе удобнее

← →
Ozone © (2004-02-26 18:12) [15]

Vlad
Ты же сказал "чем правильно", значит есть какие-то правила исходя из которых мы должны выбрать. Правильно?

← →
Vlad © (2004-02-26 18:13) [16]

> Ozone © (26.02.04 18:12) [15]

Это правило я привел в 14 посте

← →
Sandman25+1 (2004-02-26 18:13) [17]

[15] Ozone © (26.02.04 18:12)

Прочитайте про нормализацию. Все равно всю книжку мы тут Вам не перескажем.

← →
Ozone © (2004-02-26 18:14) [18]

Может быть ты по-своему и прав, но позволь мне не согласиться.

← →
Ozone © (2004-02-26 18:16) [19]

TO Sandman25+1[17]

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

← →
Sergey13 © (2004-02-26 18:18) [20]

2Ozone © (26.02.04 17:52)
>Написал клиент/серверную программу которая собирает информацию о компьютерах из локальной сети (каждый месяц).
Автоматически? Круто.
Не понятно зачем и что ты хочешь учитывать. Количество дисков с группировкой по маркам и емкостям? Наличие видюх с 3д и их соотношение с неимеющими 3д?

ИМХО 3 таблицы (если простенько)
1Компьютер
2Комплектующие
3Движение комплектующих
Если усложнить, то добавить на 2 несколько уточняющих справочников. В общем чем то похоже на склад. Развивать конечно можно бесконечно.
Важно знать, как вы покупаете новые. Я видел контору где покупали комплектуху партиями по 100/200 штук и сами собирали/апгрейдили. Тут конечно задача несколько другая.

← →
Johnmen © (2004-02-26 18:18) [21]

В общем и целом 2 таблицы. Одна описывает изменяемые сущности (компьютеры), другая - сущности изменений по каждому к-ру.

← →
Sandman25+1 (2004-02-26 18:20) [22]

[19] Ozone © (26.02.04 18:16)

>Мне не нужно пересказывать, про нормализацию я знаю.

Тогда не понимаю, в чем вопрос и при чем тут иерархия.
Если нужно избавиться от составных атрибутов вносим дополнительную таблицу, и чем все и пишут.

← →
Ozone © (2004-02-26 18:21) [23]

Т.е. получается так - если конфигурация комп-ра изменилась, то его комплектацию я заношу в 1-ю таблицу, а старую запись переношу во 2-ю (соотв. связывая ее с первой)?

> Ozone © (26.02.04 18:14) [18]

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

На первый взгляд в твоей задаче вполне можно обойтись без иерархических структур, не понимаю почему эта идея у тебя родилась первой ?

← →
Sandman25+1 (2004-02-26 18:23) [26]

[23] Ozone © (26.02.04 18:21)

Не надо ничего связывать.
select * from table where computer=:computer order by date_modif легко получает Вашу "иерархию".

TO Johnmen [25]

Не понял. Как?

>Ozone © (26.02.04 18:24) [27]

Пока ты ничего не сказал про степень формализации, то
запись: field1 id комп., field2 датавремя, field3 varchar "Сняли мы этот глючный винт и поставили IBM на 40"

запись2: field1 id комп., field2 датавремя+1день, field3 varchar "Дело оказалось не в винте, пришлось заменить Windows на Linux"

TO Deniz [29]
"датавремя+1день" быть не может - компы опрашиваются 1 раз в месяц.

2Ozone © (27.02.04 08:31) [30]
Опиши нармально - что за инфа у тебя есть и что ты хочешь с нее иметь. Диапазон решений по тому что ты написал - от 1 таблицы до дофига.

Sergey13 [31]

Информация - практически вся конфигурация системы.
Необходимо - вести "историю" копмьютера.

Да, кстати, что можно взять за первичный ключ?

2Ozone © (27.02.04 12:36) [32]
Да я про другое.
Например: можно обойтись и одной таблицей, куда напихать кучу полей. Например типа hdd=2 и hdd_size=80 из чего следует что есть 2 харда общей емкостью 80 гектар. Если такой инфы хватит, то и делай одной таблицей. Изменилась конфигупация создай копию этой записи с измененной инфой + некое поле(я) идентифицирующее версию комплектации и срок ввода в действие.
Если же надо отслеживать например серийные номера комплектухи, срок ее гарантии, статистику по моделям и т.п., то структура ессно будет, мягко говоря, несколько посложнее... 8-)
Если же надо сравнивать общее количество мегагерц в бухгалтерии с мегагерцами в плановом отделе в разрезе среднего возраста юзеров с учетом налоговых льгот, тут уж и до задачи класса ERP недалеко. 8-))))

ЗЫ: А у нас мужики-электронщики завели себе файлик в Ворде. И довольны.... 8-)

Структура БД Найти похожие ветки