[EfremenkoDO]

Можно ли как-нибудь блоки автокада загружать в БД и при необходиости из подключеной БД вставлять их?
Просто понять не могу какого типа должно быть поле БД с блоком. И как вставить из таблицы блок. Просто уверен, что это возможно.

PS работаю с лиспом

[hwd]

Сообщение от EfremenkoDO Просто уверен, что это возможно

Насколько мне известно - выдрать определение блока из Database нельзя, поскольку класс BlockReference не реализует интерфейса ISerializable и не помечен SerializableAttribute.
Как вариант - можно попробовать экспортировать определение блока в формат DXF. Если удастся - тогда проблем с сохранением этой информации в БД не возникнет. Однако я не знаю, можно ли конвертировать определение блока в формат DXF (с последующим его извлечением), не потеряв при этом такие важные "фичи", как аннотативность, динамичность и параметризацию...
Если мне не изменяет память - нечто подобное (хранение блоков в БД) делал Евгений Елпанов, но детали мне не известны...

[Pastor]

Блоки лучше всего хранить в самом естественном виде - в виде dwg-файлов. А в базе данных хранить "адреса": в каком каталоге и в каком файле хранится тот или иной блок. (ИМХО)

[hwd]

Сообщение от Pastor Блоки лучше всего хранить в самом естественном виде - в виде dwg-файлов. А в базе данных хранить "адреса": в каком каталоге и в каком файле хранится тот или иной блок. (ИМХО)

В этом случае встаёт вопрос о синхронизации. Например: в базе данных может иметься запись о наличии определения блока в неком dwg-файле, а по факту файла давно уже может и не быть, либо определение блока в файле было переименовано, ну и много др. "или"... Если определение блока можно без потерь хранить в DXF - это наиболее предпочтительный вариант (имхо), поскольку:
1. Вопросов о синхронизации не возникнет, т.к. все определения хранятся в одном единственном месте - БД.
2. Поиск нужного определения блока (если таковая необходимость возникнет) выполняется значительно быстрее, чем итерация по dwg- файлам.
3. Работать с определениями блоков (импорт/экспорт/изменение/удаление) можно не создавая объекта приложения AutoCAD.

[EfremenkoDO]

Сообщение от Pastor Блоки лучше всего хранить в самом естественном виде - в виде dwg-файлов. А в базе данных хранить "адреса": в каком каталоге и в каком файле хранится тот или иной блок. (ИМХО)

А теперь представьте, что фалов dwg уже десятки, разбитые по категориям. В каждом файле минимум 15 блоков. Чертеж использует одновременно минимум три файла.

Такой метод работы конечно самый бронебойный, но хотелось бы красоты и порядка, что может мне дать БД. А так же может дать мне скорость вставки блоков.

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

[hwd]

Сообщение от EfremenkoDO А теперь представьте, что фалов dwg уже десятки, разбитые по категориям. В каждом файле минимум 15 блоков. Чертеж использует одновременно минимум три файла.

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

Сообщение от EfremenkoDO Предчувствуя ответ, что в зависимости от размера БД будет тормозить автокад и скорость вставки (в связи с поиском) будет не на много выше, хочу заметить, что SQL еще ни кто не отменял.

Странное "предчувствие"... Разве, кто-то уже предположил, что с БД можно работать иначе чем через SQL (не беру в учёт SMO и RMO в случае если СУБД - MS SQL Server)?
И, честно говоря, не понял, коим боком размер БД может тормозить автокад и скорость вставки... Это по аналогии, что цвет автомобиля, стоящего у моего подъезда как-то может повлиять на настроение моей кошки, лежащей на кровати (такая же "логичная" связь)....

[Pastor]

1. Из LISP через ObjectDBX можно открывать dwg-файл втихую и копировать оттуда нужное определение блока, а не все скопом, если это принципиально.
2. Скорость вставки блока из dwg-файла максимальная, поскольку блок уже хранится в естественном виде. В случае dxf, например, необходимо его (dxf) перед вставкой создать физически на основе текстовой информации, хранящейся в базе.
3. Никакой итерации по dwg-файлам не требуется, поскольку база содержит исчерпывающую информацию о том, какой блок, в каком файле, в каком каталоге и на каком сервере хранится.

[hwd]

Сообщение от Pastor 1. Из LISP через ObjectDBX можно открывать dwg-файл втихую и копировать оттуда нужное определение блока, а не все скопом, если это принципиально.

Знаю, и делается это не только из LISP Я вроде и не писал, что придётся копировать все определения блоков (помимо нужного) - это было бы по меньшей мере странно...

Сообщение от Pastor 2. Скорость вставки блока из dwg-файла максимальная, поскольку блок уже хранится в естественном виде. В случае dxf, например, необходимо его (dxf) перед вставкой создать физически на основе текстовой информации, хранящейся в базе.

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

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

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

[EfremenkoDO]

Сообщение от hwd Странное "предчувствие"... Что, кто-то уже предположил, что с БД можно работать иначе чем через SQL (не беру в учёт SMO и RMO в случае если СУБД - MS SQL Server)? И, честно говоря, не понял, коим боком размер БД может тормозить автокад и скорость вставки... Это по аналогии, что цвет автомобиля, стоящего у моего подъезда как-то может повлиять на настроение моей кошки, лежащей на кровати (такая же "логичная" связь)....

Встречаются просто идивидумы

Сообщение от Pastor 1. Из LISP через ObjectDBX можно открывать dwg-файл втихую и копировать оттуда нужное определение блока, а не все скопом, если это принципиально.

Как?

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

[Pastor]

Как?

Попробуй поиск на форуме по ключевому слову "ObjectDBX". Точнее не скажу, поскольку этой темой не занимался (советую то, чего не умею сам )

[ShaggyDoc]

"Блок" в БД любого типа может храниться:
1. В BLOB-поле в виде двоичного кода. В этом случае, для вставки в AutoCAD его можно только извлечь в какой-то временный файл.

Проблема: как запихнуть в поле. Но это решаемо, при условии, что уже есть файл.

Теоретически возможно чтение BLOB в поток в память. Но манипуляции с этим участком памяти по превращению его в DWG средствами AutoCAD вряд ли возможны. Разве что очень извращенные и изощренные.


2. В BLOB-поле в виде какого-то текстового описания. В виде DXF, например, или ещё как-то. В этом случае возможно прочитать это описание и внутри AutoCAD сформировать описание блока и его вставку. Только для этого надо научить свою программу "с нуля" тому, что уже умеет делать AutoCAD.

Проблема: как запихнуть это пописание в BLOB. Решаемо, но много работы.

3. Ссылки на настоящие файлы. Самое простое, надежное, и проверенное. "Синхронизация" и прочее - надуманные проблемы.

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

Подобные вопросы - "БД или файл" многократно поднимались на программистских форумах по многим другим вариантам файлов. И оптимальное решение давно найдено. Догадываетесь какое? А как вы думаете хранятся "приложенные" картинки и файлы на этом форуме?

Не забываем, что базой данных является не только набор файлов какой-то СУБД, но и файловая система. Это самая надежная и удобная в работе база данных. В ней тоже делается и синхронизация, и поиск. И с этой базой данных уже от рождения обучен работать AutoCAD и все средства разработки для него. И она дает "красоту и порядок". Может дать и "полную анархию", но так же можно сделать и с БД.

И главный вопрос - зачем всё это нужно? Наверное, чтобы дать возможность работы пользователям - более удобную, чем штатными средствами AutoCAD. Но блоки в этом случае - частный случай. Начальный уровень, что-то наподобие блочных надстроек над LT. Да ещё с переживаниями о десятках блоков. Это же примитивнейший случай. Реально для пользователй нужны не только блоки, но и самые разнообразные программы.

И это достаточно просто делается, без заморочек с БД. Иллюстрации показывал неоднократно.

Вот что действительно надо хранить именно в БД (применительно к AutoCAD), так это, например, информационные данные (в том числе с графикой). Например, координаты границ земельных участков, трасс сетей, места расположения всяких притонов архитекторов.

"Впрочем, это совсем другая история". (С)