От: Иван Шкуропадский <shkmail@inbox.ru>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 6 августа 2004 г., 19:31:10
Тема: [Проектирование базы] - Историчность параметров {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
Hello clalist,
Люди добрые!
подскажите как это ПРАВИЛЬНО надо делать.
Чтобы и программировать было удобно,
и историчными могли бы быть ВСЕ поля - свойства объекта?
У меня есть несколько идеек - обязательно покажу.
Только не хочется позориться - вдруг решение проще?
И еще, плиз - дайте ссылок на практические примеры
построения баз данных/ Чтоб ы было как можно ближе к суровой
действительности.
Вот, например, историчность - позарез требуется реализовать!
СПАСИБО!!!
--
Best regards,
Иван mailto:shkmail@inbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Иван Шкуропадский <shkmail@inbox.ru>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 8 августа 2004 г., 9:53:31
Тема: [Проектирование базы] - Историчность параметров {01} {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
Всем спасибо за комментарии...
Если кому-нибудь мастабы задачи кажутся надуманными - посмотрите ТЗ
вложенное в недавнее мое сообщение
Re[2]: [Clarion + MS SQL 2000] - Общие вопросы {01} {01} {01}
а заодно и поучите меня ТЗ писать
))это мое первое
--
Best regards,
Иван mailto:shkmail@inbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Чушкин Сергей <chusha@mail333.com>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 8 августа 2004 г., 13:28:27
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01}
Файлы: Сообщение.html
--====----====----====----====----====----====----====----====----====----===--
Здравствуйте
From: Иван Шкуропадский
Если кому-нибудь мастабы задачи кажутся надуманными - посмотрите ТЗ
вложенное в недавнее мое сообщение
Масштабы самой задачи - нормальные.
Только непонятно зачем всё это городить для 1000 чел?
1000 чел. персонала для кадровой проги - это "тьфу"
Вот тысяч 100 это уже солидно
)Сергей - chusha@mail333.com ; chusha@hotbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Иван Шкуропадский <shkmail@inbox.ru>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 7 августа 2004 г., 17:45:48
Тема: [Проектирование базы] - Историчность параметров {01} {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
Hello Иван,
Friday, August 6, 2004, 7:31:10 PM, you wrote:
За повтор - извиняйте... mail.ru глючил, вот и отправил второй раз...
Что такое историчность параметров (свойств объектов)?
Классы: сотрудник, отдел, предприятия, приказ, договор.
Свойства: имя, фамилия, наименование, пол, дата, номер,
принадлежность.
Нужно сделать так, чтобы любое из свойств
с течением времени могло менять свое значение,
а потом можно было "достать" то, которое соответствует заданному
периоду.
Например предприятие меняет название. Тогда при формировании
какого-нибудь отчета задается дата: "формировать отчет на такое-то
число такого-то месяца такого-то года". И при этом в отчет
подставляется именно то название, которое было действительно на тот
момент.
То же самое должно происходить и при формировании представлений-
таблиц. То есть например фамилии сотрудников могут меняться и в
зависимости от того, какую дату задал оператор в качестве текущей,
в таблицу вносятся именно те фамилии, которые были на тот момент.
ЭТО ЕСТЬ ТРЕБОВАНИЕ ЗАКАЗЧИКА (то есть оно не обсуждается)
можно конечно хранить историю изменения только тех параметров, которые
будут являться историчными, а с остальными обращаться как с обычными
полями в таблице.
так вот хочется сделать так, чтобы в один прекрасный день, когда
заказчик попросит сделать историчным еще один параметр (свойство
объекта), программисту пришлось бы делать минимум работы.
ЕСТЬ задумка следующего рода:
некоторые таблицы и связи:
_Classes
IDClass (PK)
ClassName
ClassDescription
_Objects
IDObj (PK)
IDClass (<<-> _Classes)
_Properties
IDProperties (PK)
IDPropName
_ClassProperties (эту таблицу можно пока не рассматривать)
IDClass (<<-> _Classes)
IDProp (<<-> _Properties)
PropDescription
_PropertyValues
IDObj (<<-> _Objects)
IDProp (<<-> _Properties)
Value
InstallDate
это не все таблицы, но суть надеюсь ясна
_Classes - какие классы
_Objects - какие объекты
_Properties - разные свойства вообще все
_ClassProperties - свойства конкретного класса (для общности)
_ProperttyValues - те самые значения параметров,
значения которых Value было
установлено в момент времени InstallDate
таким образом обеспечивается историчность ВСЕХ свойств!
ВОТ
ПИНАЙТЕ
))--
Best regards,
Иван mailto:shkmail@inbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Вячеслав Черников <support@finsoft.ryazan.ru>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 7 августа 2004 г., 23:11:27
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
Здраствуйте, Иван!
...
> ВОТ
> ПИНАЙТЕ
Как любит говорить доктор, приступим...
Что-то слишком заумно про классы и свойства. Я бы предложил слегка упростить
концепцию и решить задачу в старом добром процедурном стиле
1. Определиться с базовыми понятиями в предметной области. Их немного. Это
список сотрудников, подразделений, приказы. Наверное найдется что-нибудь
еще.
2. Принять, что _любое_ изменение информации оформляется соответствующим
документом (приказом). Ну и сделать электронные аналоги этих документов.
3. Каждый документ имеет дату и устанавливаемые им новые значения
реквизитов. Это все, что нам нужно. Остается хорошо продумать индексацию для
быстрого поиска и диалоги для показа. Не думаю, что даная задача должна
работать в реальном режиме времени. Лучше предусмотреть граничную дату
запрета редактирования.
С уважением,
Вячеслав Черников support@finsoft.ryazan.ru
>
> --
> Best regards,
> Иван mailto:shkmail@inbox.ru
>
>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Иван Шкуропадский <shkmail@inbox.ru>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 8 августа 2004 г., 10:04:46
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01} {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
Hello Вячеслав,
Здраствуйте!
ВЧ> Что-то слишком заумно про классы и свойства. Я бы предложил слегка упростить
ВЧ> концепцию и решить задачу в старом добром процедурном стиле
Не дает покоя ООП
)ВЧ> 1. Определиться с базовыми понятиями в предметной области. Их немного. Это
ВЧ> список сотрудников, подразделений, приказы. Наверное найдется что-нибудь
ВЧ> еще.
Их-то может быть и не очень много (буду считать - впределах 20), но
свойств (параметров) у них может быть охренительно много.
Откройте, например, личную карточку сотрудника.
ВЧ> 2. Принять, что _любое_ изменение информации оформляется соответствующим
ВЧ> документом (приказом). Ну и сделать электронные аналоги этих документов.
Не-а... не любое.
Приказа (реального бумажного) на смену пола человека еще не придумали.
А если это происходит - то, например, процент женщин (мужчин)
на предприятии соответственно должен измениться
Пример конечно пограничный, но ВСЕ свойства(параметры) сущности могут
измениться в любой момент времени.
Это-же относится и к номерам телефонов, к адресам, и т.д.
А вот иметь электронные аналоги таких несуществующих документов
исключительно в информационной системе - мысль интересная.
)===================
Приказ №345
о смене пола сотрудницы Ивановой
Поменять значение свойства
"пол"
на
"Мужской"
дата:
23 февраля 2004 года
===================
ВЧ> 3. Каждый документ имеет дату и устанавливаемые им новые значения
ВЧ> реквизитов. Это все, что нам нужно. Остается хорошо продумать индексацию для
ВЧ> быстрого поиска и диалоги для показа. Не думаю, что даная задача должна
ВЧ> работать в реальном режиме времени. Лучше предусмотреть граничную дату
ВЧ> запрета редактирования.
Нет... пользователь должен иметь возможность получить сведения
действительные именно на тот, давний момент времени. Пусть даже тот
дом, улицу, город ныне полностью затопило нафиг...
ВЧ> С уважением,
Взаимно
--
Best regards,
Иван mailto:shkmail@inbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Чушкин Сергей <chusha@mail333.com>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 8 августа 2004 г., 13:37:14
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01} {01} {01}
Файлы: Сообщение.html
--====----====----====----====----====----====----====----====----====----===--
Здравствуйте
From: Иван Шкуропадский
Не дает покоя ООП
)ООП, вещь хорошая, но иногда заводит в дебри. Меня уже завела, вот сижу, разгребаю
)Их-то может быть и не очень много (буду считать - впределах 20), но
свойств (параметров) у них может быть охренительно много.
Откройте, например, личную карточку сотрудника.
Если мне память не изменяет, у нас было несколько сотен параметров.
Причём была потребность к увеличению ещё на сотню-полторы, когда
я уходил. Вот и представь себе, какой объём будет перелопачиваться
при 100% воплощении твоей идеи.
Сергей - chusha@mail333.com ; chusha@hotbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Oleg Fomin <oleg@fomin.info>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 7 августа 2004 г., 22:24:09
Тема: [OBORONA-SPAM] Re: [Проектирование базы] - Историчность параметров {01} {01} {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
Иван,
Зачем же пинать? Твоя схема очень логична, понятна и проста. А все простое -
гениально! Такая схема легко ложится на реляционную базу данных. Даже уже
продумано и помечено, где будет Primary Key <->> Foreign Key. Блестяще! И
какже я сам до такого решения не додумался? Наверное потому, что у меня не
хватит мозгов впоследствии реализовать эту идею за отпущенный год сроку,
обеспечить надежный контроль целостности данных (Primary Key <->> Foreign
Key уже больше не к чему прицепить, а ведь надо, чтобы "свойство"
Подразделение "класса" Сотрудник обязательно ссылалось на существующий
"объект" "класса" Подразделение), пытаюсь представить, как я реализую
банальные Browse/Form..., какой запрос я пошлю серверу, куда меня после
этого пошлет сервер... Нет. На этом у меня мысль заканчивается. Да. Но зато
как мне потом будет хорошо, когда заказчик прийдет навестить меня (в
психушку) и попросит сделать еще одно поле "историческим". Вот это будет
исторический момент, ради которого стоило жить! Каким же истерическим смехом
я тогда зальюсь прямо ему в глаза! Я скажу ему "Я знал! Вы не представляете
себе, как мне теперь легко...".
Нет Иван, ты не подумай, я не почти не прикалываюсь. Идея действительно
блестящая. Как раз подобная же идея посетила создателя(ей) системы
1С:Предприятие 7.х. И они эту идею даже реализовали. Если вы с товарищем в
состоянии сделать аналог за год, с поквартальным вводом в эксплуатацию
готовых подсистем, то полный вперед!
А теперь совсем серьезно. Давай ка будем зреть в корень и начнем читать твое
вложенное ТЗ с конца. Что мы видим:
> Для контроля над действиями операторов должно вестись протоколирование
> их работы с фиксацией номера рабочей станции, времени входа в подсистему,
> выполненных операций и т.д.
Задача обоснованная и понятная. Чуть что - говорим: "У нас все ходы
записаны" и делаем "разбор полетов". Оччень полезная фича в борьбе с
юзверями, бъющими себя в грудь, утверждая, что они "этого" не делали, это
оно само, это программа глючит, база сыплется. Так вот я для себя эту задачу
решаю достаточно просто средствами SQL сервера. Для некоей таблицы создаю
таблицу-двойник, которая содержит все те же поля, с теми же названиями, что
и оригинальная таблица, плюс еще три вспомогательных поля. Первое DATETIME -
время события, второе - событие (добавлено, исправлено, удалено), и третье
поле - логин пользователя, который это проделал. Эта таблица-двойник, в
отличие от оригинала, не имеет никаких реляционных связей и первичных
ключей. Зато есть триггер на таблицу-оригинал, который автоматически при
операциях INSERT, UPDATE, DELETE копирует запись(и) из оригинала и добавляет
новую(ые) запись(и) в таблицу-двойник. Таким образом, таблица-двойник хранит
не что иное, как полную историю изменений таблицы-оригинала. При
необходимости можно поднять все "версии" любой из записей таблицы оригинала
на любой момент времени. С таблицей-оригиналом работаем классически
Browse/Form безо всяческих "темпоральных" фильтров. Если ставится задача
темпоральной БД, то прописываем на сервере соответствующую VIEWшку или
хранимку, которая вместо текущих записей таблицы-оригинала вернет копии этих
записей, извлеченных из таблицы-двойника на заданный момент времени. Все.
Удачи,
---
Oleg Fomin <oleg@fomin.info>
-----Original Message-----
From: ClaListAdmin@clarion.ru [mailto:ClaListAdmin@clarion.ru] On Behalf Of
Иван Шкуропадский
Sent: Saturday, August 07, 2004 4:46 PM
To: clalist List Member
Subject: [OBORONA-SPAM] Re: [Проектирование базы] - Историчность параметров
{01} {01}
Hello Иван,
Friday, August 6, 2004, 7:31:10 PM, you wrote:
За повтор - извиняйте... mail.ru глючил, вот и отправил второй раз...
Что такое историчность параметров (свойств объектов)?
Классы: сотрудник, отдел, предприятия, приказ, договор.
Свойства: имя, фамилия, наименование, пол, дата, номер, принадлежность.
Нужно сделать так, чтобы любое из свойств с течением времени могло менять
свое значение, а потом можно было "достать" то, которое соответствует
заданному периоду.
Например предприятие меняет название. Тогда при формировании какого-нибудь
отчета задается дата: "формировать отчет на такое-то число такого-то месяца
такого-то года". И при этом в отчет подставляется именно то название,
которое было действительно на тот момент.
То же самое должно происходить и при формировании представлений- таблиц. То
есть например фамилии сотрудников могут меняться и в зависимости от того,
какую дату задал оператор в качестве текущей, в таблицу вносятся именно те
фамилии, которые были на тот момент.
ЭТО ЕСТЬ ТРЕБОВАНИЕ ЗАКАЗЧИКА (то есть оно не обсуждается)
можно конечно хранить историю изменения только тех параметров, которые будут
являться историчными, а с остальными обращаться как с обычными полями в
таблице.
так вот хочется сделать так, чтобы в один прекрасный день, когда заказчик
попросит сделать историчным еще один параметр (свойство объекта),
программисту пришлось бы делать минимум работы.
ЕСТЬ задумка следующего рода:
некоторые таблицы и связи:
_Classes
IDClass (PK)
ClassName
ClassDescription
_Objects
IDObj (PK)
IDClass (<<-> _Classes)
_Properties
IDProperties (PK)
IDPropName
_ClassProperties (эту таблицу можно пока не рассматривать)
IDClass (<<-> _Classes)
IDProp (<<-> _Properties)
PropDescription
_PropertyValues
IDObj (<<-> _Objects)
IDProp (<<-> _Properties)
Value
InstallDate
это не все таблицы, но суть надеюсь ясна _Classes - какие классы _Objects -
какие объекты _Properties - разные свойства вообще все _ClassProperties -
свойства конкретного класса (для общности)
_ProperttyValues - те самые значения параметров, значения которых Value было
установлено в момент времени InstallDate
таким образом обеспечивается историчность ВСЕХ свойств!
ВОТ
ПИНАЙТЕ
))--
Best regards,
Иван mailto:shkmail@inbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Иван Шкуропадский <shkmail@inbox.ru>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 8 августа 2004 г., 9:50:32
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01} {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
Hello Oleg,
Saturday, August 7, 2004, 10:24:09 PM, you wrote:
Спасибо за отзывы!
OF> обеспечить надежный контроль целостности данных (Primary Key <->> Foreign
OF> Key уже больше не к чему прицепить, а ведь надо, чтобы "свойство"
OF> Подразделение "класса" Сотрудник обязательно ссылалось на существующий
OF> "объект" "класса" Подразделение),
я так думаю, что удаление записей в штатном порядке не будет -
удаленные для пользователя объекты все равно будут существовать, но
при этом не будут доступны для обработки
Для этого в таблицу _Objects можно внести еще пару полей:
========================================================
_Objects
IDObj (PK)
IDClass (<<-> _Classes)
DateCreate
IDOperatorCreate (<<->_Operators)
DateDelete
IDOperatorDelete (<<->_Operators)
где
_Оperators - таблица учетных записей пользователей
IDOperator (PK)
IDObj (<->>_Obj) причем IDClass для такого IDObj должно
являться ID класса операторов
... кое-что о правах оператора, принадлежности
группам операторов и т.д.
а можно и более обще:
========================================================
_Objects
IDObj (PK)
IDClass (<<-> _Classes)
DateCreate
IDOperatorCreate ( == IDObj оператора)
DateDelete
IDOperatorDelete ( == IDObj оператора)
причем IDClass для такого IDObj должно
являться ID класса операторов
еще можно расширить и таблицу _Properties:
========================================================
_Properties
IDProperties (PK)
IDPropType (<<->_PropertyTypes)
PropName
здесь _PropertyTypes - таблица типов свойств (целый, дата и т.д.)
_PropertyTypes
IDPropertyType (PK)
PropTypeName
OF> пытаюсь представить, как я реализую
OF> банальные Browse/Form..., какой запрос я пошлю серверу, куда меня после
OF> этого пошлет сервер... Нет. На этом у меня мысль заканчивается.
Надеюсь что на первом этапе внедрения будет выручать брутальность
(простота) интерфейса. Поменьше развернутых browse-ов, побольше форм.
И, конечно, никакого EditInPlace-а.
OF> Да. Но зато
OF> как мне потом будет хорошо, когда заказчик прийдет навестить меня (в
OF> психушку)
весьма вероятно
OF> и попросит сделать еще одно поле "историческим". Вот это будет
OF> исторический момент, ради которого стоило жить! Каким же истерическим смехом
OF> я тогда зальюсь прямо ему в глаза! Я скажу ему "Я знал! Вы не представляете
OF> себе, как мне теперь легко...".
Не-а! Я зальюсь горючими слезами и попрошу продлить срок разработки (с
соответствующим количеством дополнительных денюжков
OF> Как раз подобная же идея посетила создателя(ей) системы
OF> 1С:Предприятие 7.х. И они эту идею даже реализовали. Если вы с товарищем в
OF> состоянии сделать аналог за год, с поквартальным вводом в эксплуатацию
OF> готовых подсистем, то полный вперед!
Этот товарищ - я в ночную смену. У нас в Новочеркасске просто нет
кларионистов... Будем пахать как в песне - "за себя и за того парня"
>> Для контроля над действиями операторов должно вестись протоколирование
>> их работы с фиксацией номера рабочей станции, времени входа в подсистему,
>> выполненных операций и т.д.
OF> Для некоей таблицы создаю
OF> таблицу-двойник, которая содержит все те же поля, с теми же названиями, что
OF> и оригинальная таблица, плюс еще три вспомогательных поля. Первое DATETIME -
OF> время события, второе - событие (добавлено, исправлено, удалено), и третье
OF> поле - логин пользователя, который это проделал. Эта таблица-двойник, в
OF> отличие от оригинала, не имеет никаких реляционных связей и первичных
OF> ключей. Зато есть триггер на таблицу-оригинал, который автоматически при
OF> операциях INSERT, UPDATE, DELETE копирует запись(и) из оригинала и добавляет
OF> новую(ые) запись(и) в таблицу-двойник. Таким образом, таблица-двойник хранит
OF> не что иное, как полную историю изменений таблицы-оригинала. При
OF> необходимости можно поднять все "версии" любой из записей таблицы оригинала
OF> на любой момент времени.
Это, насколько я ясно себе это представил, реализовывается той
структурой. что я предложил?
OF> С таблицей-оригиналом работаем классически
OF> Browse/Form безо всяческих "темпоральных" фильтров. Если ставится задача
OF> темпоральной БД, то прописываем на сервере соответствующую VIEWшку или
OF> хранимку, которая вместо текущих записей таблицы-оригинала вернет копии этих
OF> записей, извлеченных из таблицы-двойника на заданный момент времени. Все.
в моей задаче в качестве данных для Browse можно использовать только
VIEW - не так ли? Хотя я на это и рассчитываю - всю работу возложить
на сервер. Не только для крутизны, но и
=== QUOTE ===
Для того, чтобы впоследствии меньше возни было с переходом
на другое средство разработки (C++Builder, VC++, VC#)
А программа-АРМ будет выполнять исключительно
неитнеллектуальную работу: просмотреть VIEW, добавить запись,
обратиться к хранимой процедуре, вывести результат, распечатать отчет
в Excel (последнее, по хорошему, тоже нужно было бы оформить в виде
dll, написанной на другом языке - ну да пока и так сойдет)
=== /QUOTE ===
верно?
--
Best regards,
Иван mailto:shkmail@inbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Anton Ustimenko <ustim@web.de>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 8 августа 2004 г., 20:50:52
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01} {01} {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
Hallo clalist,
идея темпориальной структуры конечно хороша - но
imho для ее реализации нужны соответсвующие специальные средства
разработки.
может кто знает, есть такие в природе вообще ?
использование clarion для такой структуры вообще по моему становится
бессмысленно, во всяком случае теряются и не используются все те
преимущества, которые заложены в кларионе, как средстве _быстрой_
разработки приложений.
получается что в ручную просто придется заново написать всякие
browse, form, и т.д. для новой структуры. ( а енто целый пакет
шаблонов как минимум )
вообщем очень большой объем подготовительной работы
Вань, так, может вернемся к старому доброму Bulider'у ?
--
Mfg,
Anton mailto:ustim@web.de
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Иван Шкуропадский <shkmail@inbox.ru>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 9 августа 2004 г., 8:26:16
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01} {01} {01} {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
Hello Anton,
Если попытаться локализовать проблему, то:
Если работаем с привычной структурой таблиц, где свойства объекта
(атрибуты) развернуты в виде полей записи (кортежа), то при изменении
всего значения всего одного атрибута необходимо:
1. либо полностью копировать запись, изменять значение только этого
атрибута и время создания такой записи.
2. либо сохранять информацию о произведенном изменении в отдельной
таблице. Здесь:
а) либо иметь отдельные таблицы для каждого из изменяемых
полей.
б) либо иметь отдельную таблицу для каждой из таблиц,
содержащих изменяемые поля и указывать номер (имя)
изменяемого поля - здесь нужно будет приводить все
значения к одному (строковому) типу.
в) либо иметь одну таблицу для всех таблиц и всех полей -
тогда нужно указывать имя (усл. номер) таблицы и номер
(имя) измененного поля.
3. либо использовать тот вариант, который я и предлагаю последнее
времяобсудить и запинать
. С использованием одной таблицы длязначений всех свойств всех объектов.
Можно также иметь отдельные таблицы значений свойств для объектов
разных классов - принципиально это ничего не меняет, а логически
данные все-таки более упорядочены.
Проблема - выбрать один из этих вариантов.
>>Вань, так, может вернемся к старому доброму Bulider'у ?
А я к чему клоню?
Вот только не сейчас - минимум через полгода.
--
Best regards,
Иван mailto:shkmail@inbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Alexander Stepanets <clalists@partizansk.com>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 9 августа 2004 г., 3:12:29
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01} {01} {02}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
On 9 Август 2004 03:50, Anton Ustimenko wrote:
> Hallo clalist,
>
> идея темпориальной структуры конечно хороша - но
> imho для ее реализации нужны соответсвующие специальные средства
> разработки.
В данном конкретном случае IMHO не требуется реализация в полном объёме -
достаточно "сымитировать"
часть функциональности.>
> может кто знает, есть такие в природе вообще ?
Ест, кажется. Но подозреваю, что за ОЧЕНЬ отдельные деньши
> Вань, так, может вернемся к старому доброму Bulider'у ?
Как насчёт ASMа? Старого, и тоже - очень доброго...
))))--
С уважением,
Степанец Александр Валентинович.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Чушкин Сергей <chusha@mail333.com>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 8 августа 2004 г., 21:40:56
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01} {01} {01} {01}
Файлы: Сообщение.html
--====----====----====----====----====----====----====----====----====----===--
Здравствуйте
From: Anton Ustimenko
идея темпориальной структуры конечно хороша - но
imho для ее реализации нужны соответсвующие специальные средства
разработки.
Хм, я не силён в теории, но то что вчера мне удалось почитать (что нашёл в инете)
не впечатлили :) Насколько я понял, вся разница в тем.базах и просто базах
только в двух принципиальных вещах:
- ничто не удаляется физически (интересно, а если ошибся?)
- каждая сущность имеет время жизни
Ну и что тут такого сложного, что не может быть рализовано в Кларионе (причём,
относительно легко)?
Если я неправ - поправьте меня.
может кто знает, есть такие в природе вообще ?
использование clarion для такой структуры вообще по моему становится
бессмысленно, во всяком случае теряются и не используются все те
преимущества, которые заложены в кларионе, как средстве _быстрой_
разработки приложений.
Пример - в студию!
получается что в ручную просто придется заново написать всякие
browse, form, и т.д. для новой структуры. ( а енто целый пакет
шаблонов как минимум )
вообщем очень большой объем подготовительной работы
Это - да, конечно. Но ведь есть примеры подобных вещей, причём
сделанные одним человеком! Ну, например, ШВС или тот же MAV.
Это будет не сложнее...
Вань, так, может вернемся к старому доброму Bulider'у ?
Э-хе-хе, и тут же вспоминается бессмертное
"Флаг вам в руки и барабан на шею!"
)Сергей - chusha@mail333.com ; chusha@hotbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Vlad V. Shmel <vovs@lemoi.phys.dvgu.ru>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 8 августа 2004 г., 17:20:28
Тема: [Проектирование базы] - Историчность параметров {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
> OF> обеспечить надежный контроль целостности данных (Primary Key <->>
Foreign
> OF> Key уже больше не к чему прицепить, а ведь надо, чтобы "свойство"
> OF> Подразделение "класса" Сотрудник обязательно ссылалось на существующий
> OF> "объект" "класса" Подразделение),
> я так думаю, что удаление записей в штатном порядке не будет -
> удаленные для пользователя объекты все равно будут существовать, но
> при этом не будут доступны для обработки
Ну уж коль зашла речь за структуру предприятия, то всплывает еще
ряд интересных моментов:
1. Структура - явление изменчивое.
2. Подразделения могут сокращаться, образовываться новые, разукрупняться,
объединяться, переподчиняться, переименовываться.
3. Предприятие может иметь несколько структур подчинения. Например,
в образовательном учреждении: образовательная, научная, хозяйственная.
Я это к тому, что SingleTree в чистом виде для темпоральной структуры
не очень годится... А обслуживание дерева с временными параметрами...
Мы с товарищем уже третий год размышляем над красивым решением
такой структуры. Правда, пока без перехода к реализации, т.к. каждый
раз финансирование откладывается. Так что интересно и пообсуждать,
и почитать всяческие бумажки на эту тему, и посмотреть варианты
реализаций.
С уважением,
Владимир Смелик vovs@bigfoot.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Чушкин Сергей <chusha@mail333.com>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 7 августа 2004 г., 19:34:09
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01}
Файлы: Сообщение.html
--====----====----====----====----====----====----====----====----====----===--
Здравствуйте
From: Иван Шкуропадский
Нужно сделать так, чтобы любое из свойств
с течением времени могло менять свое значение,
а потом можно было "достать" то, которое соответствует заданному
периоду.
С теорией я не очень. А на практике, я пока решил делать так:
есть некая сущность, которая имеет некий уникальный ИД, который
не меняется за всё время существования базы. Например, "наименование".
Эта сущность может иметь вариации, которые я назвал синонимы,
которые имеют период действия. В принципе, периоды могут пересекаться,
и тогда нужно вводить приоритет.
так вот хочется сделать так, чтобы в один прекрасный день, когда
заказчик попросит сделать историчным еще один параметр (свойство
объекта), программисту пришлось бы делать минимум работы.
Наверное самое простое это:
Таблица
ИД объекта (сущности) - long
приоритет - long
значение - string или blob, если не задаваться максимальным значением
дата, время начала действия - long, long(date, time)
дата, время окончания действия - long, long(date, time)
для каждого поля.
По хорошему "значение" ещё бы надо разбить на Число, Строка, Картинка и т.д. для удобства.
В основных базах используешь только ИД объекта, а значение на данный момент времени
достаёшь из таблицы истории его изменений.
p.s.
Почему-то мне кажется, что при такой постановке задачи (полная универсальность)
всё будет работать очень тоскливо, особенно по скорости выборки.
Сергей - chusha@mail333.com ; chusha@hotbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Иван Шкуропадский <shkmail@inbox.ru>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 8 августа 2004 г., 10:08:28
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01} {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
Hello Чушкин,
ЧС> По хорошему "значение" ещё бы надо разбить на Число, Строка, Картинка и т.д. для удобства.
ЧС> В основных базах используешь только ИД объекта, а значение на данный момент времени
ЧС> достаёшь из таблицы истории его изменений.
если я правильно понял идею - то посмотри, пожалуйста, мое сообщение,
где я более подробнее расписываю структуру базы.
Это оно?
ЧС> p.s.
ЧС> Почему-то мне кажется, что при такой постановке задачи (полная универсальность)
ЧС> всё будет работать очень тоскливо, особенно по скорости выборки.
в том и ценность таких заказчиков, что на них можно отачивать
мастерство и искать(проверять) идеи, не сильно заботясь о
производительности системы (в разумных пределах, естественно)
- сугубое ИМХО
--
Best regards,
Иван mailto:shkmail@inbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Vlad V. Shmel <vovs@lemoi.phys.dvgu.ru>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 7 августа 2004 г., 20:23:52
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01} {01}
Файлы: Сообщение.html
--====----====----====----====----====----====----====----====----====----===--
С теорией я не очень. А на практике, я пока решил делать так:
есть некая сущность, которая имеет некий уникальный ИД, который
не меняется за всё время существования базы. Например, "наименование".
Эта сущность может иметь вариации, которые я назвал синонимы,
которые имеют период действия. В принципе, периоды могут пересекаться,
и тогда нужно вводить приоритет.
Приоритет - не очень кошерно. Или - очень некошерно. Поведение и обслуживание такого атрибута очень неясное...
так вот хочется сделать так, чтобы в один прекрасный день, когда
заказчик попросит сделать историчным еще один параметр (свойство
объекта), программисту пришлось бы делать минимум работы.
Наверное самое простое это:
Таблица
ИД объекта (сущности) - long
приоритет - long
значение - string или blob, если не задаваться максимальным значением
дата, время начала действия - long, long(date, time)
дата, время окончания действия - long, long(date, time)
для каждого поля.
Ну, если уж нормализовать, так до конца
ID_Entity ->> Name_Entity
->> Value_Entity
По хорошему "значение" ещё бы надо разбить на Число, Строка, Картинка и т.д. для удобства.
В основных базах используешь только ИД объекта, а значение на данный момент времени
достаёшь из таблицы истории его изменений.
Ну, вот здесь для простоты можно сделать вырожденную таблицу Vlaue_Entity:
ID_Record ULONG
ID_Entity ULONG
Value_Type xxxx !Список возможных типов значений, возможно - ссылка на базу правил интерпретации типов
Picture xxxx !Формат отображения
Value BLOB !Собственно значение
DTI xxxx !Дата создания
DTD xxxx !Дата удаления
Подобная схема позволит не делать менеджер типов значений, хранить списки с разделителями, менять тип значения по ходу жизни базы.
* xxxx - типы определяются разработчиком.
p.s.
Почему-то мне кажется, что при такой постановке задачи (полная универсальность)
всё будет работать очень тоскливо, особенно по скорости выборки.
А так же по объему, изолированности транзакций, ведению логов и т.п.
Но! Если грамотно построить клиент-серверное приложение, то есть подозрение, что не так уж и плохо все будет. Естественно, что нужно писать свои процедуры добавления/удаления/изменения, клиент будет работать только с представлениями и т.д.. Т.е. большую часть программного обеспечения такой структуры нужно выносить на сам сервер.
Сергей - chusha@mail333.com ; chusha@hotbox.ru
С уважением,
Владимир Смелик vovs@bigfoot.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Иван Шкуропадский <shkmail@inbox.ru>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 8 августа 2004 г., 10:12:32
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01} {01} {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
Hello Vlad,
VVS> есть некая сущность, которая имеет некий уникальный ИД, который
VVS> не меняется за всё время существования базы. Например, "наименование".
VVS> Эта сущность может иметь вариации, которые я назвал синонимы,
VVS> которые имеют период действия. В принципе, периоды могут пересекаться,
VVS> и тогда нужно вводить приоритет.
> Приоритет - не очень кошерно. Или - очень некошерно.
> Поведение и обслуживание такого атрибута очень неясное...
дык он и не нужен вовсе.
равно как и период действия.
ведь не может быть национальность человека
"русский" - с утра 1 января 2004 по вечер 31 декабря 2004
а
"еврей" - с утра 8 марта 2004 по вечер 8 марта 2004
VVS> p.s.
VVS> Почему-то мне кажется, что при такой постановке задачи (полная универсальность)
VVS> всё будет работать очень тоскливо, особенно по скорости выборки.
VVS> А так же по объему, изолированности транзакций, ведению логов и т.п.
VVS> Но! Если грамотно построить клиент-серверное приложение, то
VVS> есть подозрение, что не так уж и плохо все будет. Естественно,
VVS> что нужно писать свои процедуры добавления/удаления/изменения,
VVS> клиент будет работать только с представлениями и т.д.. Т.е.
VVS> большую часть программного обеспечения такой структуры нужно
VVS> выносить на сам сервер.
Ага... так и планируется см. ветку
[Clarion + MS SQL 2000] - Общие вопросы {01}
--
Best regards,
Иван mailto:shkmail@inbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Чушкин Сергей <chusha@mail333.com>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 8 августа 2004 г., 13:45:18
Тема: [Проектирование базы] - Историчность параметров {01} {01} {01} {01} {01} {01}
Файлы: Сообщение.html
--====----====----====----====----====----====----====----====----====----===--
Здравствуйте
From: Иван Шкуропадский
> Приоритет - не очень кошерно. Или - очень некошерно.
> Поведение и обслуживание такого атрибута очень неясное...
дык он и не нужен вовсе.
равно как и период действия.
Ну да? А если подумать?
Что, кроме параметров которые единовременно могут иметь только
одно значение, не может быть других?
Сергей - chusha@mail333.com ; chusha@hotbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Oleg Fomin <oleg@fomin.info>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 7 августа 2004 г., 16:08:21
Тема: [OBORONA-SPAM] [Проектирование базы] - Историчность параметров {01} {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
Иван,
ИМХО, чем два раза постить сообщение, лучше по-конкретнее описать задачу.
О чем речь то? Какие параметры? Какие "поля - свойства объекта"?
---
Oleg Fomin <oleg@fomin.info>
-----Original Message-----
From: ClaListAdmin@clarion.ru [mailto:ClaListAdmin@clarion.ru] On Behalf Of
Иван Шкуропадский
Sent: Friday, August 06, 2004 6:31 PM
To: clalist List Member
Subject: [OBORONA-SPAM] [Проектирование базы] - Историчность параметров {01}
Hello clalist,
Люди добрые!
подскажите как это ПРАВИЛЬНО надо делать.
Чтобы и программировать было удобно,
и историчными могли бы быть ВСЕ поля - свойства объекта?
У меня есть несколько идеек - обязательно покажу.
Только не хочется позориться - вдруг решение проще?
И еще, плиз - дайте ссылок на практические примеры
построения баз данных/ Чтоб ы было как можно ближе к суровой
действительности.
Вот, например, историчность - позарез требуется реализовать!
СПАСИБО!!!
--
Best regards,
Иван mailto:shkmail@inbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Vlad V. Shmel <vovs@lemoi.phys.dvgu.ru>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 7 августа 2004 г., 18:06:47
Тема: [OBORONA-SPAM] [Проектирование базы] - Историчность параметров {01} {01} {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
> ИМХО, чем два раза постить сообщение, лучше по-конкретнее описать задачу.
>
> О чем речь то? Какие параметры? Какие "поля - свойства объекта"?
Смею предположить, что человек спрашивает о том, что
называется "темпоральные базы данных".
С одной стороны - ничего сложного в этом нет. В каждую таблицу
добавляем поля Date_Time_Record_Inserted и Date_Time_Record_Deleted.
При добавлении записи CLEAR(Date_Time_Record_Deleted,+1).
В программе делаем глобальную переменную Date_Time_Work.
На каждую таблицу навешивается фильтр
(Date_Time_Record_Inserted <= Date_Time_Work) AND
(Date_Time_Work < Date_Time_Record_Deleted)
Ну и еще кое-какие мелочи... Удаления и переименования в программе
не существует.
Переименование:
1. Date_Time_Record_Deleted = Date_Time_Work; PUT
2. Date_Time_Record_Inserted = Date_Time_Work;
CLEAR(Date_Time_Record_Deleted,+1); ADD
Удаление: Date_Time_Record_Deleted = Date_Time_Work; PUT
Вроде бы тоже ничего сложного... Но ведь есть еще и ссылочная
целостность... Хотя и тут что-то можно организовать. Например,
Одну таблицу представлять в виде двух: ID_Table и Value_Table.
Ну а дальше... Дальше нужно думать. Почему-то пока темпоральные
сервера не получили широкого распространения на рынке.
;);)С уважением,
Владимир Смелик vovs@bigfoot.com
>
> ---
> Oleg Fomin <oleg@fomin.info>
>
> -----Original Message-----
> From: ClaListAdmin@clarion.ru [mailto:ClaListAdmin@clarion.ru] On Behalf
Of
> Иван Шкуропадский
> Sent: Friday, August 06, 2004 6:31 PM
> To: clalist List Member
> Subject: [OBORONA-SPAM] [Проектирование базы] - Историчность параметров
{01}
>
> Hello clalist,
>
> Люди добрые!
> подскажите как это ПРАВИЛЬНО надо делать.
> Чтобы и программировать было удобно,
> и историчными могли бы быть ВСЕ поля - свойства объекта?
>
> У меня есть несколько идеек - обязательно покажу.
> Только не хочется позориться - вдруг решение проще?
>
> И еще, плиз - дайте ссылок на практические примеры
> построения баз данных/ Чтоб ы было как можно ближе к суровой
> действительности.
> Вот, например, историчность - позарез требуется реализовать!
>
> СПАСИБО!!!
>
>
> --
> Best regards,
> Иван mailto:shkmail@inbox.ru
>
>
>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Alexander Stepanets <clalists@partizansk.com>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 8 августа 2004 г., 4:25:37
Тема: [OBORONA-SPAM] [Проектирование базы] - Историчность параметров {01} {01} {01} {01}
Файлы: <none>
--====----====----====----====----====----====----====----====----====----===--
Hello Vlad,
Sunday, August 8, 2004, 1:06:47 AM, you wrote:
>> ИМХО, чем два раза постить сообщение, лучше по-конкретнее описать задачу.
>>
>> О чем речь то? Какие параметры? Какие "поля - свойства объекта"?
VVS> Смею предположить, что человек спрашивает о том, что
VVS> называется "темпоральные базы данных".
Как бы да
Только ему от этого "маленький кусочек" реально нужен.
VVS> С одной стороны - ничего сложного в этом нет. В каждую таблицу
VVS> добавляем поля Date_Time_Record_Inserted и Date_Time_Record_Deleted.
VVS> При добавлении записи CLEAR(Date_Time_Record_Deleted,+1).
VVS> В программе делаем глобальную переменную Date_Time_Work.
VVS> На каждую таблицу навешивается фильтр
VVS> (Date_Time_Record_Inserted <= Date_Time_Work) AND
VVS> (Date_Time_Work < Date_Time_Record_Deleted)
VVS> Ну и еще кое-какие мелочи... Удаления и переименования в программе
VVS> не существует.
VVS> Переименование:
VVS> 1. Date_Time_Record_Deleted = Date_Time_Work; PUT
VVS> 2. Date_Time_Record_Inserted = Date_Time_Work;
VVS> CLEAR(Date_Time_Record_Deleted,+1); ADD
VVS> Удаление: Date_Time_Record_Deleted = Date_Time_Work; PUT
VVS> Вроде бы тоже ничего сложного... Но ведь есть еще и ссылочная
VVS> целостность... Хотя и тут что-то можно организовать. Например,
VVS> Одну таблицу представлять в виде двух: ID_Table и Value_Table.
А если так: в таблице свойств класса заводим признак "актуальности" -
какое из них "работает" в данный момент времени.
При любом изменении свойств модифицируем этот признак.
Ну и там помечаем, когда и who именно всё это натворил
Процедуры просмотра и, если требуется, "отката" реализуем в
соответствии с насущными потребностями.
P.S. Я, конечно, только-только проснулся, но вроде бы вариант вполне
рабочий
))VVS> Ну а дальше... Дальше нужно думать. Почему-то пока темпоральные
VVS> сервера не получили широкого распространения на рынке.
;);)Может, дешёвые слишком?
Или - "средний" персонал не тянет их обслуживание? ;D
--
Best regards,
Alexander mailto:clalists@partizansk.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Чушкин Сергей <chusha@mail333.com>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 7 августа 2004 г., 19:10:08
Тема: [OBORONA-SPAM] [Проектирование базы] - Историчность параметров {01} {01} {01} {01}
Файлы: Сообщение.html
--====----====----====----====----====----====----====----====----====----===--
Здравствуйте
From: Vlad V. Shmel
Смею предположить, что человек спрашивает о том, что
называется "темпоральные базы данных".
А вот тут поподробней, пожалуйста.
А ещё лучше ссылочку на теорию этого дела.
Сергей - chusha@mail333.com ; chusha@hotbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
От: Vlad V. Shmel <vovs@lemoi.phys.dvgu.ru>
Кому: "clalist List Member" <clalist@Clarion.ru>
Написано: 7 августа 2004 г., 19:53:08
Тема: [OBORONA-SPAM] [Проектирование базы] - Историчность параметров {01} {01} {01} {01} {01}
Файлы: Сообщение.html
--====----====----====----====----====----====----====----====----====----===--
Смею предположить, что человек спрашивает о том, что
называется "темпоральные базы данных".
А вот тут поподробней, пожалуйста.
А ещё лучше ссылочку на теорию этого дела.
Ну, собственно, теорию кратко я изложил. Да и ты потом повторил. Ссылок сейчас дать не могу - без http сижу. Но поисковики должны откликнуться. Из известных продуктов как темпоральная (tempora - время) СУБД позиционируется Postgress. Пощупать можно в составе пакета cygwin.
Вроде бы даже как-то проскальзывало, что кто-то в листе пытался с Postgress работать. По-моему, к Postgress есть ODBC-драйвер.
Сергей - chusha@mail333.com ; chusha@hotbox.ru
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Написал: ClaList(2)
