| Правила | Регистрация | Пользователи | Поиск | Сообщения за день | Все разделы прочитаны |  Справка по форуму | Файлообменник |

Вернуться   Форум DWG.RU > Программное обеспечение > Прочее. Программное обеспечение > Загрузка параметров дин. блоков из базы данных

Загрузка параметров дин. блоков из базы данных

Ответ
Поиск в этой теме
Непрочитано 04.09.2007, 10:45 #1
Загрузка параметров дин. блоков из базы данных
Дима_
 
Продуман
 
Питер
Регистрация: 22.02.2007
Сообщений: 2,843

Всем здравствуйте, подскажите кто знает, можно-ли загружать в параметры дин. блока значения из базы данных - обыскал хелп и форум - ничего не нашел. Собственно идея такая (если нет подобных штатных средств, то наверное лиспом) есть дин. блок связанный с например с экселевской областью имена параметров и имена столбцов (естественно кроме ключевого - хотя и его можно занести в виде атрибута, чтоб в связь не лезть) совпадают. соответственно - одна программа меняет параметры всех дин.блоков в соответствии с БД, другая наоборот экспортирует параметры в БД - в результате получается универсальный САПР.
__________________
Когда в руках молоток все вокруг кажется гвоздями.
Просмотров: 3522
 
Непрочитано 04.09.2007, 10:55
#2
Кулик Алексей aka kpblc
Moderator

LISP, C# (ACAD 200[9,12,13,14])
 
Регистрация: 25.08.2003
С.-Петербург
Сообщений: 38,876


Если коротно - то головняк и геморрой. Добраться до допустимых свойств дин.блока, и их значений возможно. Если свойства индексированы, то работа с БД возможна. Но вот внесение новых значений в дин.блок... Что делать, если сначала были допустимы значения параметра 1: 1, 2, 3, 5; а после обновления - 1.5; 6; 18? А в файле уже вставлены блоки с первыми значениями параметров? В ADT, например, приходится руками по новой импортировать описания стилей AEC-объектов (прародителей дин.блоков) для корректной работы с ними.
ИМХО прежде чем ваять код, надо с БД разобраться по полной программе, и всю технологию проработать.
__________________

---
Обращение ко мне - на "ты".
Все, что сказано - личное мнение.
Кулик Алексей aka kpblc вне форума  
 
Автор темы   Непрочитано 04.09.2007, 11:16
#3
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,843


Технологию взаимодействия я вижу примерно так -
[ATTACH]1188890180.JPG[/ATTACH]

... ну и как я догадался штатных средств синхронизации нет.
__________________
Когда в руках молоток все вокруг кажется гвоздями.
Дима_ вне форума  
 
Непрочитано 04.09.2007, 11:44
#4
Кулик Алексей aka kpblc
Moderator

LISP, C# (ACAD 200[9,12,13,14])
 
Регистрация: 25.08.2003
С.-Петербург
Сообщений: 38,876


Прошу прощения, но это не технология, а просто 1 [почти] штатная кадовская форма, и не больше.
Вопрос-то не столько в оформлении, сколько во внутренностях софта. Какова структура БД? Насколько она нормализована (или там все в одной таблице болтается)? Кто имеет права на ее изменение? Что делать со вставленными ранее блоками при изменении БД? Что делать, если состав блока пришлось менять, вводить новые параметры (в том числе и видимости) - в смысле, как поступать с уже вставленными блоками? Как отслеживать соответствие изменения БД и неоткрытых файлов? Как быть с файлами, содержащими внешние ссылки?
Меня пугает не столько трудность написания, сколько количество вопросов, на которые нет однозначных ответов.
__________________

---
Обращение ко мне - на "ты".
Все, что сказано - личное мнение.
Кулик Алексей aka kpblc вне форума  
 
Автор темы   Непрочитано 04.09.2007, 12:07
#5
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,843


Попробую описать - я думаю что для большинства задач не больно нужна гибкая структура данных (данный пример, как я уже писал, сделан в экселе - соответственно нормализации там никакой нет "все в одной таблице болтается") - алгоритм примерно такой (напишу на словах ну не блок-схему же рисовать).
1. Находим и открываем первый блок.
2. Проверяем есть ли в нем настраиваемые параметры и связи.
3. Берем атрибут блока - его считаем номером поля (строки таблицы), в принципе правильней будет придумать контрольное слово например "строка х", где х - и есть номер.
3а. Если не хочется заморачиваться с атрибутами то можно воспользоваться штатной связью (там есть выборка) - но по моему с атрубутом более гибгко получится.
4. Берем имя 1-го настраиваемого параметра - ищем такое же в строке и осуществляем импорт (в случае экспорта либо меняем "атрибутную" запись, либо создаем с номером атрибута).
5. Аналогично с другими параметрами.
6. Аналогично со всеми блоками.
В результате получаем следующее - подготавливаем дин. блоки, а далее что нужно - либо с них спецификацию снимаем, либо рисунок строится на основе полей - ну чем не САПР.
__________________
Когда в руках молоток все вокруг кажется гвоздями.
Дима_ вне форума  
 
Непрочитано 04.09.2007, 12:20
#6
Кулик Алексей aka kpblc
Moderator

LISP, C# (ACAD 200[9,12,13,14])
 
Регистрация: 25.08.2003
С.-Петербург
Сообщений: 38,876


Жалко, до abok.ru не достучаться... Есть там тема "автоматическое создание спецификаций", подобные вопросы и там тож поднимались. Првда, с привязкой больше к внешним ссылкам, но все равно.
__________________

---
Обращение ко мне - на "ты".
Все, что сказано - личное мнение.
Кулик Алексей aka kpblc вне форума  
 
Автор темы   Непрочитано 04.09.2007, 12:28
#7
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,843


Да как раз то спецификации - это дело вторичное (сдесь и полями обойтись можно и штатные средства есть), вопрос скорее в построении по б/д - просто у меня очень много однотипных задач (да я думаю не только у меня) и хочется все это "оцифровать" - дин. блоки уже почти везде сделал, но по ним прыгать муторно - а так в таблицу данные ввел и 80 процентов работы сделал.
P.S. - абок молчит.
__________________
Когда в руках молоток все вокруг кажется гвоздями.
Дима_ вне форума  
 
Автор темы   Непрочитано 04.09.2007, 14:51
#8
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,843


Абок ожил - но там я ничего не нашел.
__________________
Когда в руках молоток все вокруг кажется гвоздями.
Дима_ вне форума  
 
Непрочитано 04.09.2007, 15:21
#9
Кулик Алексей aka kpblc
Moderator

LISP, C# (ACAD 200[9,12,13,14])
 
Регистрация: 25.08.2003
С.-Петербург
Сообщений: 38,876


Тема http://forum.abok.ru/index.php?showtopic=14612
Цитата:
Сообщение от Дима_
Попробую описать - я думаю что для большинства задач не больно нужна гибкая структура данных (данный пример, как я уже писал, сделан в экселе - соответственно нормализации там никакой нет "все в одной таблице болтается") <...>
Ага, а потом будешь долго голову ломать, как добиться корректной работы при резко возросшем количестве записей. Я б советовал (так, навскидку) все же работать через хоть какую-то БД, создав в ней всего 3-4 таблицы: таблица имен блоков, таблица состава блока, таблица имен дин.свойств блока и таблица допустимых значений свойств дин.блока. Примерно так, наверное:
Код:
[Выделить все]
CREATE TABLE tblDynBlocks(ID Autoincrement primary key, Name char(50) not null unique);
CREATE TABLE tblDynBlocksContent(ID Autoincrement primary key, lnk_tblDynBlock long not null, EntityName memo not null);
CREATE TABLE tblDynBlocksPropName(ID autoincrement primary key, lnk_tblDynBlock long not null, Name char(70) not null);
CREATE TABLE tblDynBlocksPropValues (ID Autoincrement primary key, lnk_BlockName long not null, lnk_PropName long not null, arValues memo);
Код написан для MS Access. Без подробной проработки. Назначение полей по идее понятно из имен. Но это особо не важно. Важно то, что, выполнив SQL-запрос примерно такой, наверное:
Код:
[Выделить все]
SELECT tblDynBlocks.Name, tblDynBlocksContent.EntityName, tblDynBlocksPropName.Name, tblDynBlocksPropValues.arValues
FROM ((tblDynBlocks INNER JOIN tblDynBlocksContent ON tblDynBlocks.ID = tblDynBlocksContent.lnk_tblDynBlock) INNER JOIN tblDynBlocksPropName ON (tblDynBlocksContent.ID = tblDynBlocksPropName.ID) AND (tblDynBlocks.ID = tblDynBlocksPropName.lnk_tblDynBlock)) INNER JOIN tblDynBlocksPropValues ON (tblDynBlocksContent.ID = tblDynBlocksPropValues.ID) AND (tblDynBlocks.ID = tblDynBlocksPropValues.lnk_BlockName) AND (tblDynBlocksPropName.ID = tblDynBlocksPropValues.lnk_PropName)
WHERE (((tblDynBlocks.Name)='ИмяБлока'));
Ты сможешь узнать все возможные варианты для этого блока.
А вариант
Код:
[Выделить все]
SELECT tblDynBlocks.Name, tblDynBlocksContent.EntityName, tblDynBlocksPropName.Name, tblDynBlocksPropValues.arValues
FROM ((tblDynBlocks INNER JOIN tblDynBlocksContent ON tblDynBlocks.ID = tblDynBlocksContent.lnk_tblDynBlock) INNER JOIN tblDynBlocksPropName ON (tblDynBlocksContent.ID = tblDynBlocksPropName.ID) AND (tblDynBlocks.ID = tblDynBlocksPropName.lnk_tblDynBlock)) INNER JOIN tblDynBlocksPropValues ON (tblDynBlocksContent.ID = tblDynBlocksPropValues.ID) AND (tblDynBlocks.ID = tblDynBlocksPropValues.lnk_BlockName) AND (tblDynBlocksPropName.ID = tblDynBlocksPropValues.lnk_PropName)
WHERE (((tblDynBlocks.Name)='ИмяБлока') AND ((tblDynBlocksPropName.Name)='ИмяСвойства'));
все варианты блока с указанным значением свойства (любого). Вдобавок такая БД будет достаточно легко наращиваться, и головняка с запросами будет меньше.
Цитата:
Сообщение от Дима_
алгоритм примерно такой (напишу на словах ну не блок-схему же рисовать).
1. Находим и открываем первый блок.
Наверное, имеется в виду первое вхождение блока?
Цитата:
Сообщение от Дима_
2. Проверяем есть ли в нем настраиваемые параметры и связи.
Как проверять-то? Ну есть в этом блоке свойство "Diam", дальше что? Блока такого нет в БД, вносить?
Цитата:
Сообщение от Дима_
3. Берем атрибут блока - его считаем номером поля (строки таблицы), в принципе правильней будет придумать контрольное слово например "строка х", где х - и есть номер.
Я б на атрибуты поменьше заморачивался.
Цитата:
Сообщение от Дима_
В результате получаем следующее - подготавливаем дин. блоки, а далее что нужно - либо с них спецификацию снимаем, либо рисунок строится на основе полей - ну чем не САПР.
Спецуху еще снять можно, но вот строить что-то... Я б не рискнул.
Видишь ли, в дин.блоках есть еще свойства неиндексируемые, то есть у которых значение не ограничено чем-то-там. Как с этим делом поступать?
__________________

---
Обращение ко мне - на "ты".
Все, что сказано - личное мнение.
Кулик Алексей aka kpblc вне форума  
 
Автор темы   Непрочитано 04.09.2007, 15:53
#10
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,843


Насчет вхождения блока - это абослютно правильно - ерунду написал, а по поводу вносить или нет в бд - то подразумевается, что если вхождение блока связано то вносить. Но с другой стороны - если ты считаешь - что если из б/д в рисунок экспорт неуместен, то и тема колом всатет (больше ее почему-то никто не подхватывает), ведь основная идея все таки в этом была, а спецуху, как я уже говорил, можно гораздо легче в любой файл снять, а потом штатными средствами СУБД разгруппировать.
__________________
Когда в руках молоток все вокруг кажется гвоздями.
Дима_ вне форума  
 
Непрочитано 04.09.2007, 16:18
#11
Кулик Алексей aka kpblc
Moderator

LISP, C# (ACAD 200[9,12,13,14])
 
Регистрация: 25.08.2003
С.-Петербург
Сообщений: 38,876


Еще один вопрос - как определяется, "связан" блок или нет?
__________________

---
Обращение ко мне - на "ты".
Все, что сказано - личное мнение.
Кулик Алексей aka kpblc вне форума  
 
Автор темы   Непрочитано 04.09.2007, 17:03
#12
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,843


C точки зрения лиспа не знаю (вобще в лиспе как свинья в апельсинах), но с уровня пользователя, нажимаешь на вхождение правой кнопкой (и если горит связь значит подключен???) - или мы друг друга не поняли.
P.S. Кстати, только что проверил - сделал два блока - один связанный, другой нет; их ctrlC, закрыл документ, создал новый, ctrlV - связи остались - по сему предпологаю что хранятся они где-то во вхождении.
__________________
Когда в руках молоток все вокруг кажется гвоздями.
Дима_ вне форума  
Ответ
Вернуться   Форум DWG.RU > Программное обеспечение > Прочее. Программное обеспечение > Загрузка параметров дин. блоков из базы данных

Инженерные консультации
Размещение рекламы
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск