Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Структура БД [D7]

Страницы: 1 2 >
Ozone © (2004-02-26 17:52:00)
Написал клиент/серверную программу которая собирает информацию о компьютерах из локальной сети (каждый месяц). Теперь стоит задача правильно огранизовать БД для хранения собираемой информации.
Дело вот в чем - необходимо отслеживать движение и изменение кофигурации компьютеров => если произошли некоторые изменения (поставили еще один 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]

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

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

Ozone (2004-02-27 12:36:00) [2]
Sergey13 [31]

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

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

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

Ozone (2004-02-27 08:31:00) [4]
TO Deniz [29]
"датавремя+1день" быть не может - компы опрашиваются 1 раз в месяц.

Deniz (2004-02-27 07:43:00) [5]
запись2: field1 id комп., field2 датавремя+1день, field3 varchar 'Дело оказалось не в винте, пришлось заменить Windows на Linux'

Johnmen (2004-02-26 18:28:00) [6]
>Ozone © (26.02.04 18:24) [27]

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

Ozone (2004-02-26 18:24:00) [7]
TO Johnmen [25]

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

Sandman25+1 (2004-02-26 18:23:00) [8]
[23] Ozone © (26.02.04 18:21)

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

Johnmen (2004-02-26 18:22:00) [9]
>Ozone © (26.02.04 18:21) [23]

Нет. Все изменения в одной таблице...

Vlad (2004-02-26 18:21:00) [10]

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

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

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

Ozone (2004-02-26 18:21:00) [11]
Т.е. получается так - если конфигурация комп-ра изменилась, то его комплектацию я заношу в 1-ю таблицу, а старую запись переношу во 2-ю (соотв. связывая ее с первой)?

Sandman25+1 (2004-02-26 18:20:00) [12]
[19] Ozone © (26.02.04 18:16)

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

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

Johnmen (2004-02-26 18:18:00) [13]
В общем и целом 2 таблицы. Одна описывает изменяемые сущности (компьютеры), другая - сущности изменений по каждому к-ру.

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

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

Ozone (2004-02-26 18:16:00) [15]
TO Sandman25+1[17]

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

Ozone (2004-02-26 18:14:00) [16]
Может быть ты по-своему и прав, но позволь мне не согласиться.

Sandman25+1 (2004-02-26 18:13:00) [17]
[15] Ozone © (26.02.04 18:12)

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

Vlad (2004-02-26 18:13:00) [18]

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

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

Ozone (2004-02-26 18:12:00) [19]
Vlad
Ты же сказал "чем правильно", значит есть какие-то правила исходя из которых мы должны выбрать. Правильно?

Vlad (2004-02-26 18:09:00) [20]

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

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »