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

← →
MsGuns © (2006-06-01 17:26) [40]

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

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

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

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

← →
Elen © (2006-06-02 08:13) [41]

> MsGuns

Все-таки я наверное не смог обьяснить суть моей проблемы. Я согласен с Вашими мыслями насчет корпоративной БД и остального. Но речь идет прежде всего о наполнении БД, когда в ней нет еще ничего по данному новому проекту.
Типичный пример. Конструктор выполнил проработку, принял окончательный вариант, оформил, сохранил в файле. Но также сохранил и все промежуточные результаты в виде файла. Поскольку он работает в пакетах, допускающих сохранение под ЛЮБЫМ именем, появляются файлы, имя которых понятно как правило, только разработчику.
Теперь ко мне приходит главный и говорит примерно так "Есть ДОКУМЕНТ с обозначением 123456СБ в проекте АБВ, а разработчика в данный момент НЕТ (командировка, отпуск и т.д.). Найдите.". Но ведь я имею дело ТОЛЬКО с ИМЕНАМИ файлов. Для того, чтобы найти, необходимо хоть как-то селектировать ФАЙЛЫ (напр. по расширению) и затем смотреть СОДЕРЖИМОЕ каждого файла. Были случаи, когда мы с коллегой искали чертеж 2 дня и не смогли его найти. А начальник не хочет ждать более, например, 1 часа, и считает, что мы полные бездельники.
В отделе уже 4 года есть приказ о правилах именования файлов и порядке сохранения проекта. В нем указан пример обозначения и то, что после завершения файлы проекта (окончательные) ДОЛЖНЫ быть требуемым образом переименованы и сохранены без мусора. Гл. инженер предложил мне составить список нарушителей для показательного наказания, вплоть до увольнения. В этот список из 130 чел. пришлось включить порядка 100 чел. Мне было заявлено, что ради наведения порядка никто не будет увольнять такое количество людей. Поэтому у меня нет никакой надежды решить проблемы ТОЛЬКО административным путем.
Вы говорите

> ни конструкторы, ни технологи, ни вообще кто-либо не мог там свободно лазать и что-то править

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

← →
Sergey13 © (2006-06-02 09:29) [42]

2 [41] Elen © (02.06.06 08:13)
>Только после закрытия проекта и передачи его в производство можно эти таблицы включить в корпоративную БД и закрыть доступ или его ограничить

Почему? Почему нельзя создать в БД новый проект и присвоить ему статус "В разработке"? Делайте с ним что хотите. Завершили - присвоили статус "Закончен" и далее все как вы думаете.

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

С моей точки зрения - это набор слов из статьи в женском журнале. Не надо подобных обобщений - не придется потом обижаться. 8-)

← →
Elen © (2006-06-02 10:29) [43]

>Sergey13

Спасибо, Sergey13. Вы в сообщении [38] сформулировали мою задачу/проблему более внятно чем это сделал я. Действительно я имел ввиду, пусть у конструктора будет сколько угодно файлов/проработок, но привязав ОДИН к БД можно считать его ОФИЦИАЛЬНЫМ документом и при любых посках не обращать внимания на все другие. А что касается сообщения [42], почти так оно и есть. Когда открывется новый заказ автоматически создается в БД новая таблица спецификации (главная), открытая на полный доступ конструктору, кроме ее уничтожения, и недоступная всем другим подразделениям. После завершения работы конструктор указывает на закрытие работ над проектом и тогда все таблицы (как главная, так и входящие) автоматически закрываются и им устанавливается доступ "только чтение". Вот как раз и хотелось воспользваться этим обстоятельством. То-есть при подаче сигнала "Закрыть проект" можно выполнить автоматическую проверку на привязку Запись-Чертеж, и если есть записи, не привязанные к файлу, процесс закрытия запрещать, то-есть таблица спецификации остается в режиме полного доступа только к конструктора. Последующие подразделения в технологической цепочке подготовки производства могут использовать информацию ТОЛЬКО после завершения проекта и его закрытия.

Прошу меня извинить за "хай", но это мой первый опыт общения в форумах, и наверное я был недостаточно тактичным, высказывая такие суждения. Больше не повторится, если Вы меня специально не спросите по какому-то вопросу подобного рода.

Самое для меня главное, что в процессе общения Мастера в целом подтвердили (пусть не во всем), что двигамся в нужном направлении.

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

← →
Sergey13 © (2006-06-02 10:43) [44]

2[43] Elen © (02.06.06 10:29)
>Когда открывется новый заказ автоматически создается в БД новая таблица спецификации (главная),
Упаси вас боже от такого топорного решения. Никаких новых таблиц!!! Пользователи должны создавать только записи в таблицах. Если это у вас не так - вы создали непродуманное решение (это мякго сказано) в 99% случаев (и не думайте что вы в оставшемся проценте 8-).

>Последующие подразделения в технологической цепочке подготовки производства могут использовать информацию ТОЛЬКО после завершения проекта и его закрытия.

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

>Не думаете ли Вы что разработка примерно такого специализированного софта, как мы обсуждаем, может быть полезна многим предприятиям?

Делим шкуру неубитого медведя? 8-))))))))
Тут все зависит от качества продукта и его настраиваемости в определенных рамках изменений бизнес-логики. Не такая уж тут специализация (хотя и не без нее разумеется). Сделаете хорошо - почему и не продать (если купят. Это не так просто - продавать). Дело за малым - сделать. 8-)))))

← →
Elen © (2006-06-02 11:25) [45]

>Sergey13

>Никаких новых таблиц!!! Пользователи должны создавать только записи в таблицах

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

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

Согласен с вами, но в данной конкретной ситуации доступ к предварительно прорабатывемой конструкторской документации просто бессмыслен, т.к. ее просто нет (сейчас в БД нет вообще НИКАКОЙ информации по конструкторскому документу). Это тоже один из моментов, который мы хотели бы решить. Связка Запись-ФайлЧертежа мог бы боле оперативно решать вопросы согласования со смежными подразделениями. То-есть в данном случае Вы правы и мы с Вами согласны.

Что касается вопроса продажи софта, то мы лишь подумали, что Мастера обсуждают вопрос о том, с каким софтом (игры, интернет и т.д.) можно выходить на рынок и не взяться ли виртуальному коолективу за такую работу. Звучало мнение, что это может быть специализированный софт. Вот и подумалось, может быть такой вид софта мог бы занять некоторую нишу.
Ссылка на ветку http://delphimaster.net/view/15-1148747923/. Но участвовать в нем мы вряд ли сможем (разве что советами практиков конструирования). Даже если такой софт будет сделан на предприятии, продавать его мы ,конечно, не сможем. А вот Мастера...

← →
Percent (2006-06-02 11:40) [46]

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

← →
Elen © (2006-06-02 11:53) [47]

>Percent

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

← →
Sergey13 © (2006-06-02 12:23) [48]

2[45] Elen © (02.06.06 11:25)
>Дело в том, что я плохо знаю Оракл

Это непринципиально. Метаданные БД плохо менять в любом случае.

>ситуации доступ к предварительно прорабатывемой конструкторской документации просто бессмыслен

Не согласен. Специалист уже по названию детали на 90% скажет какой у нее будет техпроцесс, расцеховка оборудование и т.п. "Крышка редуктора" или "фланец" говорят сам за себя.

← →
MsGuns © (2006-06-02 12:41) [49]

>Elen © (02.06.06 11:53) [41], [43], [45], [47]

Эхх, как бы это помягче сказать.. чтоб не обиделись..
Вы двигаетесь совершенно в неправильном направлении. У Вас полная путаница в голове. Вместо того, чтобы искать брод, вы ищите дерево, которое можно перебросить через реку и пытаетесь его пилить перочинным ножиком. А когда дерево падает не туда, то вините ножик, пильщиков, дерево..
Причем здесь "оракл", "перехват записи на диск", "терминальное проектирование",.. и еще желание заработать на проекте, который Вы пока себе не представляете даже в общих четрах.
Я Вам говорил, но Вы почему-то отмахиваетесь:
Постройте модель конструкторского документооборота. На бумаге ! Без всяких "ораклов", "виндуз" и вообще без ПК. Как бы Вы организовали работу с документацией КБ скажем Форда. Когда еще не было комплв вообще. И вот когда у Вас будет вырисовываться система, при которой документы не будут теряться, конструктора будут находить нужные чертежи за десять-пятнадцать минут и т.д. и т.п., только тогда думайте о том, как связать ее с моделями общепроизводственного документооброта (технологи, снабженцы, плановики, диспетчеры и т.д.) И только явязав хотя бы в основных узлах, есть смысл подумать о БД вообще.
ОС, "марка" СУБД, прикладное ПО - это в последнюю очередь.

← →
MsGuns © (2006-06-02 12:44) [50]

И еще по поводу "продажи".
Мой добрый совет: забудьте об этом и никогда никому не говорите. Занимайтесь тем, что Вы умеете хорошо делать - конструированием. Где у Вас есть реальный шанс заработать.

← →
Elen © (2006-06-02 12:58) [51]

> Percent А отчего бы не перехватывать запись/чтение на диск?

А какими способами Вы предлагаете это делать? Скажите пожалуйста

>Sergey13
Метаданные БД плохо менять в любом случае

С этим высказыванием в сообщени [48] согласен. Меня, как посредника между службой конструкторов и службой ведения БД, не очень интересуют работа с метаданными (хорошо/плохо). Пусть ломают головы в ОИС, им это реализовывать.

>Специалист уже по названию детали на 90% скажет какой у нее будет техпроцесс, расцеховка оборудование и т.п.

Вообще-то, Вы правы. На начале моей работы предполагалось, что конструкторы, прорабатывая варианты, будут в электронном виде согласовывать с технологами даже варианты. Для этого были предназначенны даже папки обмена информацией и средства внесения замечаний со стороны технологов (Volo View), которые позволяли технологу прямо на DWG-файл наносить замечания, не изменяя исходного файла. К сожалению, ОГТ весьма консервативен, и не желает этим пользоваться. Поэтому мы и не ставим на данной стадии вопрос о, скажем так, параллельной работы нескольких служб над проектом. Дай бог хоть навести нормальный порядок с рабочей документацией
Vik.

← →
MsGuns © (2006-06-02 13:22) [52]

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

Это ошибка. Достаточно серьезная.

← →
Sergey13 © (2006-06-02 13:33) [53]

2[51] Elen © (02.06.06 12:58)
> Поэтому мы и не ставим на данной стадии вопрос о, скажем так, параллельной работы нескольких служб над проектом.
Чем раньше вы поставите этот вопрос - тем меньше придется переделывать. 8-)))))))))))))))
Кострукторы ведь не боги, как и технологи, впрочем. Иногда технолог только взглянет на чертеж и скажет "фигня дело, мы такого не сможем". И фсе, весь ваш "законченный и сданный" проект летит вверх тормашками. 8-)

← →
Elen © (2006-06-02 14:02) [54]

>Sergey13

Вы абсолютно правы, но мне приходится соблюдать определенную дипломатию. Прототипную программу мы создаем как раз для того, чтобы продемонстрировать возможность создания хотя бы удобного средства систематизации конструкторской документации. Напоминаю, полномасштабная разработка будет вестись не нами, а нашим ОИС, а их тоже нужно заставить. Если поднять еще и этот вопрос, можно вообще похерить задумку. Другое дело, в полномасштабной программе заложить возможность развития в этом направлении c минимальными доработками (но это тоже требует усилий - возражения типа "А зачем это сегодня надо..."). Я понимаю, что для Вас это может звучать дико, как и для меня, но такова реальность.
Vik

← →
Sergey13 © (2006-06-02 14:09) [55]

2[54] Elen © (02.06.06 14:02)
> но мне приходится соблюдать определенную дипломатию.
Вот он - краеугольный камень построения любой ИС! Автоматизирующие хотят революции, а автоматизирумые не хотят ничего менять. Причем это может меняться на 180 градусов (как у вас, как я понял 8-). Пока проект (!) не будет одобрен и поставлен на контроль кем то из первых лиц конторы любые действия по автоматизации буду мучительной попыткой родить мертвого ребенка. И это уже не ИМХО практически.

>Sergey13

Да, Вы правы - это краеугольный камень. Пока 4 года назад лично директор завода проталкивал автоматизацию к нам в ОГК, мы могли ногой открывать к нему двери, он как мог поставлял техниу и требовал расширения, внедрения, улучшения... Не могу сказать, что мы имели все что хотели, но ОГК на сегодняшний день самый крупный держатель машин (40 шт., хотя нам этого мало). Предполагалось довести парк машин до 100-110 шт на 130-140 сотрудников. Даже то, что в ОГК (отделе главного конструктора) имеются программисты (я и Elen), чего больше нет ни в одном подразделении - его заслуга. Только 3 года назад хозяева его выкинули, ну началось... В руководстве зачастую даже не понимают, а что на компах можно делать (хотя-бы в принципе). Извините за плач в жилетку... Думаю, что и Вы это прошли, поймете, почему ограничения и т.д.
Vik.

2[56] Elen © (02.06.06 14:34)
>он как мог поставлял технику
>В руководстве зачастую даже не понимают, а что на компах можно делать (хотя-бы в принципе).

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

>Думаю, что и Вы это прошли, поймете, почему ограничения и т.д.
Плавали - знаем. Потому и пишу сюда.

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

Да, было и такое... Но его тоже можно понять. За 5 лет поднять уникальный завод (в СССР таких, кроме нас, еще один) с нуля до пусть и не 100% загрузки в бытность лучших времен. Ему просто не хватало времени (масса других забот+не лучшие первые помощники). Он поручил все работы по автоматизации ОГК молодому энергичному парню, дал ему карт-бланш и как мог помогал. Этот парень и привлек нас сюда. Но получилось так, что конструирование делали мы, а все остальное ОИС (экономика, планирование, бухгалерия и тд.). Вот и получились как-бы две независимо функцонирующие подсистемы. Отсюда и результат. А теперь нет ни этого парня, ни поддержки на хоть сколько-нибудь существенном уровне. Недавно появился перспективный зам. главного инженера. Первое, что он сделал, пришел к нам и плотно поговорил о нашем видении перспективы. Мы показали ему два варианта прототипных программ (был уже и первый без использования БД). Он обещал всяческую поддержку. Окончилось тем, что сейчас его так загрузили расхлебыванием узких мест в производстве, что он и в кабинете не бывает. Более того, в разговоре проскользнуло желание похерить все это и уйти. Вот так и бывает, наверное, когда к руководству машиностроительным предприятием приходят люди, умеющие только торговать Сникерсами.

(на бегу, мож не в тему попаду)
Search от intermech"а (насколько я в курсе) неплохая система конструкторского документооборота (на бывшем рабочем месте внедряли коллеги, вроде не слишком ругались)

← →
Percent (2006-06-02 19:31) [60]

А какими способами Вы предлагаете это делать? Скажите пожалуйста

http://delphimaster.net/view/15-1148747923/

[1], [2], [3], [4]

← →
Percent (2006-06-02 19:46) [61]

Бумажная книга "Недокументированные возможности Windows 2000" Свен Шрайбер:
http://oz.by/books/more103360.html

В интернете есть в неофициальном электронном виде (все время задаюсь вопросом, что значит "электронный вид"?). Найти легко самому. (Правила форума, однако, не позволяют разместить здесь ссылку на электронный вариант; авторские права там всякие, то да се).

Исходники и откомпилированные примеры к книге (официальная версия):
http://www.unix.kg/cache/examples/SchreiberSRC.zip

> k2

Да, мы 9 мес. юзали пробную версию Search 7.0. Хороша, ничего не скажешь. Ездили по предприятим, где она эксплуатировалась. Но тогда же и поняли один недостаток. Все такие системы делаются достаточно универсально (то-есть завод покупает, ставит и эксплуатирует, а за организацию порядка отвечает завод/пользователь . Но ведь и при использовании файловой системы можно иметь порядок - но не тут то было (см.[54...58]). Когда мы разобрались, поговорили с ИНТЕРМЕХом, оказалось, что они МОГУТ доработать для нас этот момент, но цена... На этом все и застопорилось.

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