guest_20040621> Историю пока не сделал,но сделаю,технических сложностей никаких,триггер
> пихает текущую запись в соотв.теневую таблицу. И все.

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

Что-то не слышно о связях, классификации и локализации. Вы отвечаете на избранные вопросы?

> Разграничение доступа пока не сделал,но сделаю достаточно быстро,на
> меня поалияла очень дельная статья на эту тему на www.ib.ru

;) Там не все так дельно, как кажется.

> Все прочее проработано "по самое не балуйся", аж самому страшно...:)

Не бойтесь. Уверяю Вас, ничего особенного.

> Почему ввожу тип OLE? Для того,чтобы пользователь мог создавать объекту
> свойства типа OLE и хранить там оригиналы документов, всякие там CAD

У-у-у... Спасибо, можете не продолжать.

Дать точные и исчерпывающие ответы не могу,для этого нужно потратить много времени,если описывать все мелкие детали,взять хотя бы слежение за историей,все значения свойств имеют временную отметку,для которой они актуальны,ну и т.д. А вот конктетные пожелания/хотения хотелось бы услышать. Про OLE зря вы так пренебрежительно,это очень многое упрощает,в противном случае нужно уметь поддерживать тучу всяких форматов, не шмагу я...:)

guest_20040621> Дать точные и исчерпывающие ответы не могу,для этого нужно потратить много
> времени,

Исчерпывающе - не нужно. Вкратце. Чтобы стало понятно.

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

Как это должно быть организовано - я в курсе, спасибо. Интересно, как Вы это сделали.

> А вот конктетные пожелания/хотения хотелось бы услышать.

См. выше. Четыре пункта + разделение доступа - это минимум. И - производительность.

> Про OLE зря вы так пренебрежительно,это очень многое упрощает,в противном
> случае нужно уметь поддерживать тучу всяких форматов, не шмагу я...:)

Хранить файлы в базе данных - это ошибка. Поддерживать "тучу форматов" необходимости нет.

Увы, времени пока нет. Могу кинуть на мыло файлик с кратким описанием и скриншотами, правда он странький,апрельский...сейчас уже много доработано.

guest_20040621> Увы, времени пока нет.

;) Ну, на нет и суда нет.

На всякий случай (вдруг у Вас появится свободное время?): вообще говоря, описанный минимум - это imho функционал для несложного практического применения. Для полноценной реализации потребуется ссылочная целостность, ограничения, значения по умолчанию, схемы объектов, типы данных и прочая, прочая, прочая. ;))

Пишите на мыло,при необходимости созвонимся и все обсудим. Сейчас только скажу, что, все принципиальные вопросы позади, причем где-то с 1998 года,так уж сложилось. В партнерских взаимоотношениях заинтересован, на мог взгляд,есть шанс создать любопытный продукт,причем быстро. Потенциальный пользователь документооборота(инженерного в том числе) мне тоже будеть очень интересен...
-------------------------------
P.S. Не мешало бы и представиться, а то наша дискуссия стала меня как-то легкомысленно настраивать:)

guest_20040621> Увы, времени пока нет.

;) Ну, на нет и суда нет.

На всякий случай (вдруг у Вас появится свободное время?): вообще говоря, описанный минимум - это imho функционал для несложного практического применения. Для полноценной реализации потребуется ссылочная целостность, ограничения, значения по умолчанию, схемы объектов, типы данных и прочая, прочая, прочая. ;))

Ссылочная целостность была с самого начала, т.е. это декларации типа
CONSTRAINT PAR_NODE FOREIGN KEY(nParent) REFERENCES NODE(nID)
ничто не мешает ссылаться nID на nParent даже если они находятся в одной таблице.

guest_20040621> т.е. это декларации типа CONSTRAINT PAR_NODE FOREIGN KEY(nParent) etc

Я немного не то имел в виду. В данном случае imho поддержка целостности может быть построена не средствами SQL, а с помощью метаинформации, причем, это не будет целостностью в привычном понимании.

Проблема в том, что метаописаниями придется воспроизвести практичести все объекты реляционной СУБД, - очень геморройное и в общем не самое простое занятие.

Что-то до меня не дошло,зачем в sql-сервере нужно делать ссылочную целостность не средствами sql...зачем это нужно?

Ловкость рук и никаких дискуссий:)

Мне бы хотелось услышать соображения по классификации информации. Любой и всякой, а также классификации свойств,которые ее описывают.
Каких-то ограничений по иерархиям и тапам того и другого не существует,так же,как и по программной реализации, любые кубы,любых измерений - для этого привел эти картинки. Есть желающие?

guest_20040621> Ловкость рук и никаких дискуссий:)

;) Надеюсь, Ваш продукт будет иметь коммерческий успех.

Спасибо на добром слове! Но пока я подыскиваю себе работу,сейчас можно сказать,работаю не по специальности,-системным аналитиком...

Но хотелось бы все-таки по существу,т.е. о классификации всего и вся.
Мне сейчас нравится идея ввести тип данных "Script", который будет на основе многоязычного интерпретатора типа FastScript или подобного, ну и дизайнер форм...

Еще одна картинка по применению универсального хранилища,хотя это очень частный случай

guest_20040621> Мне бы хотелось услышать соображения по классификации информации. Любой и
> всякой, а также классификации свойств,которые ее описывают.

Хороший вопрос. ;) Imho подхода два:
1. сущность - классификация - характеристики (как функция от от некоторых признаков сущности);
2. глобальный перечень сущностей - глобальная классификация - глобальный перечень характеристик (зависимость чуть сложнее);

причем, я бы выделил три классификатора: а. внутренний (основной, подробный), б. официальные классификаторы, в. исходящий классификатор (т. е., такой, который можно будет использовать например для печати). Соответственно, ключи.

В свое время продуктивным мне показался подход, аналогичный используемому при построении тезауруса, - позволяет не зацикливаться на предметной области.

> Каких-то ограничений по иерархиям и тапам того и другого не существует,так
> же,как и по программной реализации,

Схема объектов на основе метаописаний. Вроде это уже обсуждалось?

А кому нужна такая схема и зачем?

guest_20040621> А кому нужна такая схема и зачем?

Кому - вопрос, видимо, риторический? ;)

Зачем: если пользоваться традиционными способами (т. е., сущность, ее классификация, ее параметры (как функция от некоторых признаков сущности, как мы уже отметили), получится, что в базе данных - куча таблиц, описывающих сущности, куча классификаторов (каждый классификатор - это десяток таблиц) и куча параметров сущностей. Никак между собой не связанных. И без реальной возможности связывания.

Если использовать схему объектов, то классификатор - один, описание параметров немного усложняется, но все равно получается достаточно компактно (причем, параметры уникальны). Т. е., в конечном счете получается строгая классификация (плюсов куча, но это основной) и единый подход к описанию любых сущностей.

Наиболее близкая аналогия - xml файл и dtd. Представьте, что данные у Вас храняться где угодно (в любых таблицах базы данных или файловой системе), - а в dtd Вы описываете зависимости, типы данных и пр., - т. е., все, что Вам необходимо для манипулирования данными.

Что касается схемы,то я опять не понял о чем речь. Если о таблицах в БД и связях между ними, то здесь жесткая и постоянная схема,она не меняется никогда. Я связываю вопрос классификации именно с вопросом наполнения хранилища.

Programmer_Ortodox guest_20040621> А кому нужна такая схема и зачем?

Кому - вопрос, видимо, риторический? ;)

Зачем: если пользоваться традиционными способами (т. е., сущность, ее классификация, ее параметры (как функция от некоторых признаков сущности, как мы уже отметили), получится, что в базе данных - куча таблиц, описывающих сущности, куча классификаторов (каждый классификатор - это десяток таблиц) и куча параметров сущностей. Никак между собой не связанных. И без реальной возможности связывания.

Если использовать схему объектов, то классификатор - один, описание параметров немного усложняется, но все равно получается достаточно компактно (причем, параметры уникальны). Т. е., в конечном счете получается строгая классификация (плюсов куча, но это основной) и единый подход к описанию любых сущностей.

Наиболее близкая аналогия - xml файл и dtd. Представьте, что данные у Вас храняться где угодно (в любых таблицах базы данных или файловой системе), - а в dtd Вы описываете зависимости, типы данных и пр., - т. е., все, что Вам необходимо для манипулирования данными.

Что касается схемы,то я опять не понял о чем речь. Если о таблицах в БД и связях между ними, то здесь жесткая и постоянная схема,она не меняется никогда. Я связываю вопрос классификации именно с вопросом наполнения хранилища.
Вдогонку добавлю,что если мы имеем дело с постоянной и неизменной структурой, то это сильно облегчает жизнь всего прогрессивного ИТ-человечества:):) , так как в течение долгого времени может создаваться масса приложений, не заботясь о том.что структура вдруг изменится!
А при введении типа данных "Script", сами мозги,т.е.целые приложения,написанные на нем,могут храниться там же,т.е. в БД, которая может иметь глобально распределенную структуру