Три вопроса о дополнительных данных в AutoCAD и об Xdata в частности
На всякий случай: я никогда не использовал Xdata, не планирую использовать и не пропагандирую их использование.
1. Отдельно об Xdata приходится говорить, т.к. это:
- во-первых, старейшее и известнейшее средство хранения неграфических данных,
- во-вторых, оно так и не получило в AutoCAD удобного для пользователей представления и достаточных пользовательских инструментов.
Autodesk мог бы создать на основе Xdata условные «Udata» (от «users») понятной пользователям «табличной» структуры (название «таблицы», названия полей и типы данных) в виде командно-оконного интерфейса. Который и был бы для пользователей, собственно, «Udata». И Autodesk мог бы как-то отграничить такие «Udata» от остальных Xdata, предназначенных для программистов. Придав «Udata» внутренний отличительный признак или т.п. При этом ни один программист бы не пострадал. :)
Естественно, так же необходим и достаточный набор инструментов использования таких «Udata» (Xdata), данных из них. И, само собой, чтобы эти данные были видны в окне Свойства AutoCAD и доступны для ввода-редактирования их значений.
Сделаны такие «Udata» Autodesk за 25 лет (или больше?) не были. Но с начала и до сих пор Xdata постоянно применяются для описательных данных в бесконечно создаваемых пользовательских приложениях или вручную. Одновременно Xdata постоянно используются программистами для своих целей. При этом сталкиваются интересы и данные программистов и пользователей, применяющих Xdata по-разному.
К тому же довольно быстро (лет за 5 - ?) выяснилось, что ограничения объема Xdata создают проблему их применения.
Кстати, все написанное так же относится и к Xrecord – что мешало Autodesk создать такие условные "Urecord" с набором инструментов для их использования? При том, что Xrecord не имеют ограничения объема.
2. Среди программистов есть мнение, что Xdata предназначены для программных целей, а не для хранения описательных данных.
Это или не так, или может быть не так – прямых свидетельств от Autodesk я не нашел. За такое мнение программистов то, что Xdata фактически доступны только программистам. Но, например, в справке XDATA (Express Tool) они рассматриваются на примере описательных данных трубопроводов.
Вероятнее всего, что вопроса фактически и нет. Xdata, как и Xrecord, предназначены для хранения разных данных – без специализации. Как это прямо сказано в Help об Xrecord: «Объекты XRECORD используются для хранения и обработки произвольных данных».
При этом:
- Xdata позволяют хранить при одном объекте данные в 16К с достаточным набором типов данных. Объем такой величины важнее для описательных данных, чем для программных целей.
- В Help об Xrecord Class сказано, что они являются лучшей альтернативой Xdata, благодаря отсутствию такого ограничения объема. Что в первую очередь нужно для описательных данных. Т.е. это может указывать, что и Xdata тоже были созданы для описательных данных.
Мнение же, что Xdata не предназначены для описательных данных, есть, вероятно, неточно сформулированное, что Xdata удобнее для программных задач, но хуже для описательных данных. Кроме того, поскольку Xdata часто используются для программных задач, то с точки зрения программистов логично применять для пользовательских данных другие средства. Чтобы не возникало конфликтов.
3. Существует дискуссия о том, где и как хранить описательные неграфические данные об объектах. В dwg с помощью Xdata, Xrecord или т.п. Или во внешних БД.
Активных участников всего четверо: я сторонник использования Xrecord или т.п., а трое за внешние БД. Другие лишь иногда подают реплики, но развернутых мнений не высказывают. Длится это уже больше пяти лет, и давно безнадежно – позиции и число участников не меняются.
Один из сторонников внешних БД за решение вообще без AutoCAD или с AutoCAD в качестве вьювера, средствами одних БД. Но здесь это обсуждаться не будет, чтобы не уходить от контекста.
На мой взгляд, проблема безнадежности дискуссии в ее асимметричности. Я ограничиваю применимость и целесообразность своего способа. А мои оппоненты придают своему способу абсолютный характер. Я признаю целесообразность использования внешних БД, а мои оппоненты вообще отрицают целесообразность использования Xrecord или т.п.
Я никогда и нигде не отрицал нужность использования внешних БД для задачи в целом. И я всегда считал использование Xrecord или т.п. ограниченно целесообразным. Внешние БД – для больших объемов данных и для использования собранных данных, для анализа. А Xrecord или т.п. – для небольших объемов, для сбора данных, черчения.
Я никогда и нигде не отрицал, что с использованием внешних БД задача решается в т.ч. и для небольших объемов. Хотя, я считал и считаю, что это не оптимально, не целесообразно для сбора данных, в процессе создания моделей.
В ответ никогда не звучало допущения целесообразности Xrecord или т.п. хотя бы частично – только отрицание, и утверждения необходимости только внешних БД.
И никогда от оппонентов не звучало допущение одновременного существования этих двух способов – в разных пользовательских нишах, для разных типов задач и объемов данных.
Я готов допустить, что может быть решение с внешними БД, настолько же простое, надежное, технологичное и дешевое, как решение с Xrecord или т.п. Т.е. оптимальное так же и для сбора данных, создания моделей. Хотя, из общих соображений это мне кажется невероятным.
Я не вижу, каким образом AutoCAD + внешняя БД + установление и поддержание их связи может быть проще одного AutoCAD, а манипулирование такими данными может быть технологичнее, чем данными только dwg.
Многократно проверено на практике, что Xrecord или т.п. в dwg удовлетворительно решает задачу в соответствующих пределах. И нет необходимости делать сложнее, если можно проще. Для соответствующих пределов.
Для использования Xrecord или т.п. в AutoCAD нужно только 1-2 несложных программных модуля, не требуется повышения квалификации пользователей, не требуется изменения принципов работы в AutoCAD, никакого другого ПО. Работоспособность этого способа любой человек всегда может проверить на примере моего модуля ODCLASS в свободном доступе.
Для оценки способа с внешними БД так же нужна возможность прочитать развернутые их описания и возможность всесторонне их проверить практически. Чтобы убедиться, что этот способ не дороже, не сложнее и надежен для небольших моделей, объемов данных.
И еще реплика о программистах и пользователях.
Много раз сталкивался с высокомерно-пренебрежительным отношением программистов к пользователям. Как будто программисты пишут либо для себя, либо для других программистов, либо прямо для компьютеров. :) Программисты - демиурги, отцы-благодетели, носители сакрального знания. А пользователи, особенно типа «тетка», это нечто вроде энтропии.
Пользователи же, особенно типа «тетка», если программисты хорошо сделали свою работу, неблагодарно ни о программах, ни о программистах вообще не думают. Вспоминают о них, когда программы работают плохо или не позволяют сделать все нужное.
Пользователи заняты моделями, данными. Именно «тетки» создают модели и вносят данные теми кривыми и косячными способами и инструментами, которые им достались от программистов.
А это и есть главное, не замечаемый слон - сами модели, данные.
02.01.2020
Александр Шаров
