Администрирование SQL.

← →
MsGuns © (2006-05-30 12:57) [0]

Столкнулся на новом месте работы с такой ситуацией:
Имеется куча БД на нескольких серверах (MS SQL Server 7 и 8), инфа которых иногда пересекается, а иногда просто повторяется на ровне целых таблиц или их фрагментов).
Все приходится собирать в кучу, разрабатывать новую, общую Модель Данных с нормализацией, унификацией логики и т.д.
Но это полбеды. Убивает другое. Очень трудно, а иногда невозможно найти проекты (исходники) приложений - клиентов, еще хуже с документацией.

Как организовано комплексное администрирование БД и ПО в ваших конторах ? Существуют ли стандарты техдокументации на проектирование, внедрение и эксплуатацию серверных и клиентских приложений ?

Буду весьма признателен за информацию, советы, полезные ссылки.

← →
Sergey13 © (2006-05-30 13:05) [1]

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

← →
MsGuns © (2006-05-30 13:07) [2]

>Sergey13 © (30.05.06 13:05) [1]
>Если честно - не завидую я твоей новой работе. Напоминает авгиевы конюшни.

А я люблю трудные задачи ;))

← →
Sergey13 © (2006-05-30 13:18) [3]

2[2] MsGuns © (30.05.06 13:07)
Удачи. Искренне.

← →
Elen © (2006-05-30 14:01) [4]

>MsGuns

У нас похожие проблемы. Конструкторское подразделние (~140 юзеров, ПО - AutoCAD+MDT6, Kompas,Spot Light 5,Word). Информация хранится на файл-серверах, пользовательские папки с ограниченным доступом, но внутри них у каждого - полный доступ. Отсюда полный хаос - каждый юзер устанавливает свои правила обозначений папок/файлов. Найти что-нибудь крайне трудно. Усугубляется проблема полным нежеланием администрации что-либо изменить в административном порядке (хотя мы убедились - только административные меры недостаточны). Сейчас прорабатывается вопрос комплексной среды проектирования с достаточно жесткими правилами создания папок/файлов, когда имена даются ТОЛЬКО после заполнения регистрационных карточек по жестким правилам/проверкам на допустимость. Я рассматриваю разные возможные варианты решения этой задачи вплоть до самых нестандартных (перехвата действия в других программах)

> Существуют ли стандарты техдокументации на проектирование?

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

← →
Sergey13 © (2006-05-30 14:15) [5]

2 [4] Elen © (30.05.06 14:01)
Если

>Сейчас прорабатывается вопрос комплексной среды проектирования

то почему бы совсем не уйти от "папок/файлов" в сторону БД?

← →
tesseract © (2006-05-30 14:26) [6]

А на novell перейти не пробовали?
Или поставить сервер индексирования документов?

← →
MsGuns © (2006-05-30 14:27) [7]

Я в принципе определился с хранением:
Сервера делятся на
1. Промышленные (для хранения текущих корпоративных данных, оперативно использующихся подразделениями предприятия)
2. Тестировочные (для проектирования и отладки)

БД регистрируются у админа БД (пока это функция сисадмина, но планирую у него забрать), им же сохраняются, журналируются и тд)
Каждая БД в своей папке, доступ которых клиентам сети воспрещен. В этой же папке сохраняются архивы с проектами и документацией. Изменения в архивах выполняются сисадмином по служ.запискам по завершению внедрения или выпуска новой версии ПО.

Хуже со стандартами. Видимо, придется разрабатывать самому ;(

← →
Sergey13 © (2006-05-30 14:38) [8]

2[7] MsGuns © (30.05.06 14:27)
>Хуже со стандартами. Видимо, придется разрабатывать самому ;(
Разарабатывать свой стандарт не так уж и плохо - сам себе хозяин. Самое сложное - постоянно и неуклонно следовать стандарту в реальной жизни, которая как правило очень многогранна. Иначе хоть со стандартом, хоть без него - результат один - хаос.

← →
Elen © (2006-05-30 15:40) [9]

> Sergey13 © то почему бы совсем не уйти от "папок/файлов" в сторону БД?

Так и надо бы, но это связано с глубокой перестройкой всей системы существующей на предприятии в данное время, но БД предполагаются как ядро проекта

> Sergey13 © Самое сложное - постоянно и неуклонно следовать стандарту в реальной жизни, которая как правило очень многогранна. Иначе хоть со стандартом, хоть без него - результат один - хаос.

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

>MsGuns © БД регистрируются у админа БД (пока это функция сисадмина, но планирую у него забрать), им же сохраняются, журналируются и тд)
Каждая БД в своей папке, доступ которых клиентам сети воспрещен. В этой же папке сохраняются архивы с проектами и документацией. Изменения в архивах выполняются сисадмином по служ.запискам по завершению внедрения или выпуска новой версии ПО.

У нас на предприятии существуют две подсистемы конструкторской документации: конструкторская спецификация (на базе БД) и конструкторская документация (файловая), которые (сейчас совершенно не связаны). То-есть пользователь клиентской программой заполняет БД спецификаций для организационно-экономических задач. Такой процесс достаточно жестко контролируется доменными админами. А конструкторская документация хранится в виде файлов на локальных серверах нашего подразделения. Поэтому и возникла идея связки БД спецификаций и файловой системы. В таком случае в спецификации УЖЕ имеется идентификакционная информация о чертеже, значит заполнив БД и привязав к ней файл (с любым именем) есть возможность его переименовать/переместить в нужную папку с ограниченным доступом. После окончания проекта БД спецификации закрывается (по доступу на изменения) и тем самым, закрывается доступ на модификацию чертежа.
Что касается хранения чертежей в memo/blob полях, то такй вариант возможен, но имеет свои недостатки (мы много работаем с 3D-графикой, а это объем для сети). Известные нам системы КД на этом принципе (Search 7, TDSM e.t.c) почти хороши, но они сделаны УНИВЕРСАЛЬНО, и не имеют (как правило) защиты от мусора, который пользователи спокойно набивают в БД (на соседнем предприятии у наши друзей та же проблема с Search 7). Поэтому наряду с тем что такие системы просто очень дороги, еще значительные суммы нужно тратить на адаптацию (на тех предприятиях, где мы были адаптация тянет до ~50% стоимости приобретения.

А в принципе, можно судить, что несмотря на то, что у нас проблемы с файл-системой, а у автора с "мусорной" БД - трудность одна: WINDOWS плохо предназначен для такой МНОГОПОЛЬЗОВАТЕЛЬСКОЙ работы. Ведь он изначально создавался как ОДНОПОЛЬЗОВАТЕЛЬСКАЯ МОНОПОЛЬНАЯ (для пользователя) OS. И из этх детских штанишек так и не вырос. Наложите на это вольности юзеров - и Вы имете то, что имеете...

← →
Sergey13 © (2006-05-30 15:55) [10]

2 [9] Elen © (30.05.06 15:40)
1. Ваша проблема НИКАК не связана с сабжевой. Проблемы есть у всех, но они не одинаковы.

2. Не надо валить все на Винду. То что Вы не в состоянии, что либо сделать не говорит о ее (винды) недостатках. Она тут вообще с боку. Поставьте Югикс наконец и наслаждайтесь. 8-)

← →
MsGuns © (2006-05-30 16:24) [11]

>Elen © (30.05.06 15:40) [9]

Мне показалось, что у нас с Вами ситауция несколько разная ;))
Вы смотрите на проблему с точки зрения модели документооборота, я же - модели данных и связанных с ними программных средств обработки. У меня не стОит задача увязки конструкторской, технологической и проч. документации в БД и, тем более, увязки ее в какую-то ИТ. Моя задача иная - систематизировать все разрозненные Базы Данных, клиентское ПО и документацию (в основном это инструкции пользователям, терминология, схемы процессов обработки данных и т.д.), создать НОВУЮ МОДЕЛЬ ДАННЫХ (по всей науке ;) ) спроектировать ее и импортировать в нее все задачи (ПО)так, чтобы их технологичность, избыточность и достоверность по крайней мере не ухудшились для конечного пользователя.

← →
MsGuns © (2006-05-30 16:25) [12]

Прошу прощения за "стОит".
Сам не знаю, как получилось :))

← →
Игорь Шевченко © (2006-05-30 16:31) [13]

> WINDOWS плохо предназначен для такой МНОГОПОЛЬЗОВАТЕЛЬСКОЙ
> работы. Ведь он изначально создавался как ОДНОПОЛЬЗОВАТЕЛЬСКАЯ
> МОНОПОЛЬНАЯ (для пользователя) OS. И из этх детских штанишек
> так и не вырос

Нечего на детали пинать, коль паяльник не тем концом держишь
(с) журнал "Радио"

← →
tesseract © (2006-05-30 16:49) [14]

> Поставьте Югикс наконец и наслаждайтесь. 8-)

проблемы с правилами хранения документации уйдут на второй план....

← →
Petr V. Abramov © (2006-05-30 17:15) [15]

> Игорь Шевченко © (30.05.06 16:31) [13]
???
имелось в виду "не за тот конец"?
:)

← →
Игорь Шевченко © (2006-05-30 17:17) [16]

Petr V. Abramov © (30.05.06 17:15) [15]

Цитата точная :)

← →
Elen © (2006-05-31 15:08) [17]

> Sergey13

Уважаемые Мастера!
Вообще-то под ником Elen Выступает колега, но здесь влез я, которого Вы можете назвать Vik. Извините , но еще до появления XT...AT машин довелось мне поработать c терминальными системами на базе СМ и ЕС (если кто помнит).Так вот, работа велась в рамках интегрированного пакета, когда пользователь работал с документацией, понятия не имея где и под каким имененм хранится файл. Его имя/расположение определялось программно. Затем появились Интеловские машины, ACAD,PCAD. Ура и в воздух чепчики... Но пока машин было мало и количество файлов невелико, можно было смириться с вольностями юзеров. Когда я выразился о Виндовс, я имел ввиду не саму Виндовс, а средства управления файлами (Проводник, Командер и т.д.). Меня злит, что есть хорошие системы ведения проектных работ, но в них нет средств нормального ведения проектов с запретами и контролем (по типу старых терминальных разработок). То-есть разработчики хорошо выполнили фцнкционал разработки, но практически не реализовали функционал систематизации (как правило все на откупе юзера). Тем, кто прошелся по мне за Виндозу приношу извинения, но я думал, что они поймут меня правильно. Виндоза, конечно, как ОС не причем.

> MsGuns

Когда я писал о схожести задач, я имел ввиду, что любая МОДЕЛЬ в некотором роде абстрактна (ИМХО). Например, можно рассматривать файлы как некие условные поля БД. Меня в моем положении интересуют любые (даже, извините, сумашедшие) идеи структуризации файловой информации. Для БД имеются много литературы (я и сам 15 лет программировал самоучкой на Фоксе и ВизуалФоксе и не так уж плохо освоил методику проектирования БД). А вот теории по структуризации файлов, способов создания таких систем не попадалось. Схожесть я усматривал достаточно абстрактно.

tesseract
>> Поставьте Югикс наконец и наслаждайтесь. 8-)
проблемы с правилами хранения документации уйдут на второй план....

Наверное имеется в виду UNIX/Linux. Но как можно в них решать надежно вопрос структуризации? Я в них профан. Я ведь имею ввиду не МНОГОПОЛЬЗОВАТЕЛЬСКИЙ режим, а именно средства структуризации файлов/папок. И хоть переход на эти ОС крайне проблематичен, если Вы считаете что там можно рыть, черкните свое мнение и я полезу...

Уважаемые мастера! Влезть сюда меня заставила необходимость, но если Вы считаете, что пишу не в тему или глупости, то обещаю лишь смотреть форум, не высказываясь (кстати форум ВЕСЬМА интересен).
Благодарю Vik

← →
isasa © (2006-05-31 15:16) [18]

Lotus Domino/Lotus Notes не поможет?

← →
isasa © (2006-05-31 15:19) [19]

Да, добавлю.
БД не реляционная, и работал с ней лет 6 назад(релиз R5), сейчас посвежее(7?), но уже там была возможность связки с SQL.
Я к чему, для документооборота, неплохая платформа.

← →
Игорь Шевченко © (2006-05-31 15:20) [20]

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

Вообще-то системы документооборота в Windows не входят. В операционные системы на ЕС и СМ - тоже. Следовательно, если вы ждете готовой системы а-ля Lotus Notes, встроенной в Windows, то ждать можно еще долго с тем же результатом. А вот если не ждать милостей от природы, а написать систему систематизации (пардон за тавтологию), то задачу решить можно с гораздо большей вероятностью.

← →
tesseract © (2006-05-31 15:32) [21]

> Наверное имеется в виду UNIX/Linux. Но как можно в них решать
> надежно вопрос структуризации?

см сайт ibm :-)
А также novell GroupWise.

Решение вопроса структуризации - имхо модно решить наложением хитрых ограничений на запись/чтение папок.

← →
Sergey13 © (2006-05-31 15:34) [22]

2[17] Elen © (31.05.06 15:08)
По такой логике в нарушении ПДД виноваты автомобили. Разъездились. 8-)

← →
MsGuns © (2006-05-31 15:36) [23]

>Elen © (31.05.06 15:08) [17]

Мне кажется, Вы слегка путаетесь в понятиях "файловая система", "документооборот"

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

Злиться не нужно, можно просто поискать. Просто пример:

http://www.dps.kiev.ua/rus/solutions/docob.html#769

← →
Elen © (2006-05-31 15:48) [24]

> Игорь Шевченко

От Vik. Ждать от Windows или других ОС системы документооборота под наши задачи, конечно, не приходится. Сейчас мы как-раз и пытаемся создать пакет для такой работы. Есть некоторые наработки. Проблема-то в том, что нужно убедить руководство или потратиться на имеющиеся пакеты с их адаптацией, или что мы и сами можем это сделать (конечно не на уровне функционала Search , TDSM). Поэтому и ищем любую информацию.

> isasa

Мы понимаем, что иерархии файловой системы более соответствует иерархические БД, но я в них полный нуль, а рзбираться специально для собственных работ не хочется. Что касается Lotus Domino/Lotus Notes, то с их возможностями специально не разбирался, но попробую оценить перспективность.
Дело в том что 9 месяцев юзал SEARCH 7.0 (ИНТЕРМЕХ,пробная версия). Вот и крутятся мысли вокруг аналогичных решений. Если бы не общая цена (с адаптацией), может быть и пытались бы пробить. Но вряд ли, уже пробовали.

← →
Sergey13 © (2006-05-31 15:51) [25]

2[17] Elen © (31.05.06 15:08) или 2 Vik
>Так вот, работа велась в рамках интегрированного пакета, когда пользователь работал с документацией, понятия не имея где и под каким имененм хранится файл.

Вот то, о чем вы сожалеете как о безвозвратно утерянном "из-за Видовс".
Вам нужен такой же по функциональности пакет программ. Можно искать готовое - можно написать самим. Простейший вариант для спеца выльется в месяц работы. Однако даже такой вариант способен навести порядок в документации.
Смысл такой - создается несложная БД с возможностью хранить файлы. Допуски к этим файлам регулируются самой БД и/или программной оболочкой для работы с ней. Выбирая чертеж (или что там у вас), пользователь скачивает его из БД и по типу файла запускается связанное с ним приложение (автокад, ворд и т.п.). Поработав с документом, юзер сохраняет файл в БД.
Основное отличие от хранения просто в файловой системе - жесткая (или такая, какая ВАМ нужна) структуризация и разграничения доступа.

← →
stone © (2006-05-31 15:56) [26]

> пользователь скачивает его из БД и по типу файла запускается
> связанное с ним приложение (автокад, ворд и т.п.).

Есть довольно большие файлы, которые какчать туда-сюда довольно не быстро. Я не знаю, подробностей задачи Elen ©, может там это не актуально.

← →
Sergey13 © (2006-05-31 16:05) [27]

2[26] stone © (31.05.06 15:56)
Я описал общий принцип - конечно всякое может быть. Однако я слабо представляю, как можно не скачивая (все равно откуда) что-то исправить. Если только ками нибудь терминалами пользоваться наверное.

← →
Elen © (2006-05-31 16:27) [28]

> Sergey13

Именно в таком направлении мы и роем прежде всего. Имеется БД Спецификаций (строго контролируемая) и файлы чертежей. Беда в том, что я администрирую файлы, а БД другое подразделение, и как оно согласится изменить давно действующую БД под наши предложения по хранению чертежей в БД - пока неясно (отвечают ни да ни нет).
В прототипной программе мы смоделировали и опробовали пока только связку БД (Фокс)+ссылки на сетевые имена файлов.
Но есть чисто программные моменты, которые пока не опробаваны на прототипе. Наши пользователь много работают с 3D-чертежами, которые могут включать в себя ссылки на другие файлы (их сетевые имена). При файловой системе+БД мы видим выход в программной корректировке этих ссылочных файловых имен (пересборке документа) после переноса его в нужное место с нужным именем. А вот как это сделать, если файл хранится в БД, пока не знаем, хотя и будем пробовать. Есть и некоторые другие непонятки.

> Основное отличие от хранения просто в файловой системе - жесткая (или такая, какая ВАМ нужна) структуризация и разграничения доступа.

С положением о структуризации через БД согласны на 120%

> MsGuns

Такого рода пакеты (TDSM, OutDOCS и еще некоторые, в т.ч. по Вашей ссылке) нам известны. Но они специализированны, как правило, под канцелярский (извините) документоооборот.А конструкторский имеет свою специфику и по нашим предположениям, вряд ли она там может быть достаточно корректно решена

2 [28] Elen © (31.05.06 16:27)
> Имеется БД Спецификаций (строго контролируемая) и файлы чертежей.
Вот бы и добавили в спецификации одно поле с чертежом. 8-)

> БД (Фокс)
Ребята! Вы бы еще Парадокс взяли! 8-)

>Наши пользователь много работают с 3D-чертежами, которые могут включать в себя ссылки на другие файлы (их сетевые имена).

Ссылки должны быть в БД, а не в чертеже. Впрочем, тут я не шарю - что у вас там за 3D-чертежи.

> Sergey13

VisualFox использовался для прототипа потому, что он спокойненько работает у меня на локальной машине и мне не нужно лезть на недоступный мне Oracle (другое подразделение - общезаводской отдел информационных систем ). И к тому же Paradox у нас есть только в BDE, а сним связываться неохота. Не разворачивать же мне Oracle локально для отработки прототипа.
3D-чертежи можно условно представить как весьма своеобразную БД. Допустим, имеетюся узлы (сборки) с именами У1 и У2, причем У1 содержит в себе детали Д1 и Д2, а узел У2 - детали Д3 и Д1. При этом в У1 внутри (!) вместо размеров, свойств и других характеристик детали Д1 имеется только ссылка на файл Д1, откуда они при прорисовке У1 и берутся. То-есть, 3D-чертежи могут включать в себя во внутреннем формате ссылки на другой файл или часть файла. Поверьте, проще не изложу, если Вы этим не занимались, иначе придется много описывать о формате файлов 3D-чертежей, которые создаются AutoCAD+MDT6
Vik.

> разворачивать же мне Oracle локально для отработки прототипа.

15 минут.
С учетом того, что оракл работает на уровне с парентовыми деревьями, его использование будет оправдано.
А 10G Express вообще халявый и ставится очень быстро.

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

Кстати, хранение на файл-сервере файлов трафик не уменьшит, т.к. в любом случае копия перекачивается на машину клиента, пусть и неявно.

> ANB

В данный момент мы делаем только прототип программы для отработки технических вопросов (чтение информации, взаимодействие компонент и программ и т.д). Поэтому для имитации вполне хватает Фокса, тем более, что я 15 лет на нем работал. Прототип лишь демонстрирует решение некоторых технических вопросов. А затем нормальную программу будет разрабатывать другой отдел - владелец озщезаводской БД на Оракле.
Что касается идеи с промежуточными клиентскими рабочими папками - такая идея пока нам в голову не приходила. Большое спасибо, будем пробовать. Но у нас возникла и другая - попробывать залезть во внутренний формат файлов AutoCAD и поковыряться прямо там. Дело в том, что мы уже извлекаем оттуда кое-какую информацию, попробуеи добраться и до ссылочной информации.
Что касается хранения информации на файл-сервере, это сделано для централизации места хранения разработок нашего отдела. Так мы работаем уже лет 6, в общем скорость работы терпима. Зато упрощается администрирование. До сих пор не отвечал как раз потому, что занимался селективной архивацией файлов рабочих документов.
Vik.

2[32] Elen © (01.06.06 14:37)
> В данный момент мы делаем только прототип программы для отработки технических вопросов (чтение информации, взаимодействие компонент и программ и т.д). Поэтому для имитации вполне хватает Фокса,

Как можно отлаживать технические вопросы самолета на модели жигулей? То, что вы пишете (избретаете!) на Фоксе например в части прав и разделения доступа к данным уже давным давно решено в промышленных СУБД на уровне сервера.
Врочем дело ваше.

> Sergey13

В данный момент меня СОВЕРШЕННО НЕ ИНТЕРЕСУЕТ как будет спроектирована сама БД в части прав и разделения доступа и т.д.. Нас интересуют вопросы, связанные с работой с документами. В них (документах) есть информация, которую нужно вытаскивать в БД или туда загонять (разработчик, обозначение, наименование и т.д.). Вот для проверки взаимодействия БД (любой) и компонент чтения/редактирования документации мы и моделируем (проверяем). Например, если нужно найти ссылочный чертеж, указанный в одной записи, в другой записи. А что касается прав, доступов, ролей, относящихся собственно к БД, то они будут решаться при полномасштабной разработке (и не мной, см.[32]). Если Вы считаете, мои вопросы не в тему, так и напишите. Я заткнусь. Или попробую пообщаться по E-mail с людьми, которые считают возможным мне помогать хотя-бы советами.

2[34] Elen © (01.06.06 15:19)
Че ты так кипятишся то? Никто ничего не считает. 8-)
Я просто пишу свое мнение о том что пишешь ты.
Вот ты написал

>В них (документах) есть информация, которую нужно вытаскивать в БД или туда загонять (разработчик, обозначение, наименование и т.д.).

А надо, ИМХО, с точность до наоборот. Все связи, обозначения, наименования и прочая и прочая должны быть в БД. Спецификация же есть? Есть. Что это такое? Состав изделия. Из чего оно состоит? Из узлов и деталей, на которые должны быть чертежи. Так? Вот я бы и сопоставил каждой детали (узлу) - свой чертеж. Т.е. выбрал деталь в спецификации - получи чертеж, а не наоборот.

> Sergey13

Извини, погорячился, показалось, что вам уже неинтересны мои проблемы.
Может быть, я и ошибаюсь, но по-моему у Вас не совсем верное представление о процессе конструирования. Для сведения, у меня стаж - 15 лет конструирования, 15 лет программирования. Обьясняю.
Когда конструктор начинает проектировать изделие, он понятия не имеет, сколько и каких узлов/деталей будет в ОКОНЧАТЕЛЬНОМ варианте. Поэтому он сперва делает целый ряд проработок (по конструкторски - прорисовок). В ходе прорисовки он отрабатывает состав узла. И лишь потом, выбрав окончательный вариант, он разрабатывает (оформляет) по всем правилам чертежи и может составить спецификацию. Конечно, теоретически, он может составить спецификацию и ДО ОФОРМЛЕНИЯ (по прорисовкам), но насколько мне известно, никто и никогда так не делает. Поэтому спецификация оформляется , как правило, последней. Но информация, заносимая в спецификацию, УЖЕ сидит в документации. И чтобы не вносить ее ручками заново, и возникла идея выдернуть ее оттуда автоматически (или полуавтоматически). Когда запись в БД и чертеж сопоставлен - нет проблем, но вот заполнение БД спецификации без разработанных (оформленных) чертежей вряд ли возможно чисто по практическим соображениям. Кстати, в Search сделано как раз по твоему рецепту. Конструктор разрабатывет ВСЕ проработки и хранит их БД. Вот и представь себе сколько там мусора. А чистить его у конструкторов, как правило, руки не доходят, кстати, как и при чисто файловой системе. Ведь все мои проблемы как раз в том и сосотоят, что имеется куча файлового мусора. Например, сегодня делал общее архивирование за месяц с помощью небольшой утилиты. Так вот всех файлов на сервере ~200 тыс., а в архив было отобрано (отбор по рабочим расширениям DOC, DWG, CDW,TIF) попало только ~60-70 тыс. файлов. при этом я УВЕРЕН, что окончательно оформленных документов может только примерно половина (остальное проработки). Уж извини за длинное разъяснение, но может быть, я как бывший конструктор, зациклися и не могу глянуть на проблему свежим взглядом.

>А чистить его у конструкторов, как правило, руки не доходят, кстати, как и при чисто файловой системе

Тогда БД ничего не даст, кроме прятания "мусора" вместе с нужным.
Все, что Сергей сказал по поводу того, "кто на ком должен стоять", есть истина и единственный путь к ПОРЯДКУ.
Пытаться автоматизировать бардак - дело абсолютно безнадежное.
Вам необходимо разработать прозрачную модель документооборота, удовлетворяющую неким исходным требованиям, и всех заставить работать только в рамках этой модели (для этого, собственно и придумали БД). Другого пути - нет.

2[36] Elen © (01.06.06 16:35)
Да я в общем то тоже кой чего понимаю в конструировании. Даже помню справочник Федоренко и Шошина. 8-)

>Уж извини за длинное разъяснение, но может быть, я как бывший конструктор, зациклися и не могу глянуть на проблему свежим взглядом.

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

Одна идея тут у меня проскочила - строка пути в файловой системе к файлу чертежа в принципе может являться ключом для поиска этого чертежа в БД. Может это как то присандырить к твоему варианту.

> MsGuns

Я бы с Вами ПОЛНОСТЬЮ согласился. но есть возражение. Реально имется в данный момент 2 подсистемы. Одна на БД спецификаций очень строго проверяется на мусор. А чертежи хранятся в файлах. Задумка такая. Конструктор разрабатывает сколько угодно вариантов. Затем заполняет спецификацию. Пока сам конструктор не закрыл спецификацию (не подтвердил окончание работы), он может в спецификацию вносить любые изменения. Но как только он закрыл спецификацию, она автоматически переходит в режим только чтение (запрет внесения изменений). Можно автоматически проверить, связал ли конструктор запись в БД с каким-нибудь файлом, и если нет, запретить закрытие БД на редактирование. Затем можно файлы, соотнесенные к записям БД, переместить в соответствующую папку, недоступную рядовому юзеру, с нужными именами. Это и будет точное соответствие спецификации к набору файлов, фактически архив рабочей документации. Конечно, имеются ряд тонкостей, но пока я излагаю только общую концепцию.
Vik

>Elen © (01.06.06 16:59) [39]

Вы описали типовую схему работы инженера (совсем не обязательно конструктора):
Задача - Проект - Решение - Эксперимент - Результаты - Проект - Решение - Эксперимент - Технология
Любая правка - это тот жу путь по второму кругу. В когце всегда должна быть технология, в Вашем случае - конструкторская документация.
Изменение технологии делается не абы как, а с помощью конструкторских (технологических) извещений, которые подписываются, утверждаются и только потом отражаются "в металле". Для "тонких", промежуточных случаев есть проекты извещений, которые могут быть оператоивно подправлены или даже отменены без изменения технологии.

Вы, как мне кажется, смешали все в одну кучу: корпоративный документооборот с конструкторской "кухней".
Корпоративная БД вмнсте с чертежами на то и корпоративная, что ни конструкторы, ни технологи, ни вообще кто-либо не мог там свободно лазать и что-то править. Любые "вмешательства" в информациооное пространство БД выполняется в строго определенном порядке, приоритете, правах и объемах, заданных МОДЕЛЬЮ БД. Т.е. для замены чертежа с одного на другой конструктор долеж выпустить извещение, гл.инженер проекта его утвердить, бюро стандартизации проверить и зафиксировать, соотв. служба БД поставить его в очередь изменений.. и т.д., вплоть до изменения цеховых планов, комплектационных карт, планов закупок ПКИ и материалов службой снабжения и т.д.
То же, что творится со старыми чертежами, проблема самого конструктора и гл.инженера проекта. Если вы хотите как-то упорядочить свою "кухню", вам и карты в руки. Мне кажется, что для этого вполне хватает простого архиватора плюс файловой системы (любой - роли не играет) и продуманной схемы документирования (достаточно простой кстати).

И еще. Не думаю, что автокадовское хозяйство много сложнее, чем "требуха" дельфишных проектов. Однако никто еще на моей памяти не хаял Делфу за то, что там нет "нормальной системы хранения и администрирования" старых проектов.

Администрирование SQL. Найти похожие ветки