Официальный форум российского программного комплекса T-FLEX PLM


Поиск  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти
 
Поле БД как переменная
 
Вопрос по дазе данных.
В функции обычно явно указывают имя поля базы данных,
а как сделать так,
чтобы это имя поля была переменной, а в переменной я бы назвал это поле.

Просто есть механизм отбора значения из поля по условию, а вот выбор самого поля исходя из условия нету или есть?

Можно мне выйти из положения, если сделать базу данных, а в переменной сделать список на основе этой базы данных и выбор осуществлять по любым полям, а не по одному, как сейчаз имется в программе.
Страницы: Пред. 1 2 3 След.
Ответы
 
Цитата
Александр Конорев пишет:

При составлении внутренней базы данных материалов ЛДСП нужно связать поле наименование "Бук Бавария" в базе данных с материалом текстуры (предварительно закинутой туда) и так для каждого наименования, как это сделать ?
Для подобной задачи БД не нужна. Есть список материалов 3D модели. С ним связана внешняя или внутренняя переменная (например $Материал). Выбираем из списка значение и все. И для изображения в 3D модели применяем и для записи материала. Если же необходимо к материалу дополнительную информацию прицепить через поле БД, то вроде тоже проблем не должно быть - используем текстовое поле с именем материала и выбираем по нужным критериям. Только не забдьте все материалы описать в файле модели. Я обычно для этих целей создаю собственные библиотеки материалов (для разных проектов разные). Я, правда все это использую в 10 версии, в 11 не проверял. Но должно работать. Эти приемы5 версии работали
По фрагментам тоже возможно задавать имена через текстовые переменные. Главное с путями не напутать. Самое простое, если сборка и фрагменты в одной папке лежат. Если нет, то надо использовать библиотеки и прописывать путь через библиотеки. Использовал подобный подход давным давно на заре знакомства с TF. Тогда версия 5.3 вроде как была. Все работало.
 
Цитата
Павел Перфильев пишет:

Самое простое, если сборка и фрагменты в одной папке лежат. Если нет, то надо использовать библиотеки...

Переменная ссылка на фрагмент работает и с абсолютными путями. Нюанс в том, что вместо "D:\Ножка.grb" в переменной должно быть "D:\\Ножка.grb".
Кто ищет - тот всегда найдет!
 
Работать с абсолютными путями на мой взгляд не совсем хорошо, даже я бы сказал неправильно. По крайней мере, я своим подчиненным так работать запрещаю. Есть механизм библиотек, конфигурации. Надо их использовать. Иначе потом возникают вопросы типа а как открыть сборку на друго компьютере.
Изменено: Павел Перфильев - 08.02.2010 07:55:36
 
Цитата
Александр Конорев пишет:

И еще вопрос, как использовать разные 3d фрагменты в переменных в качестве выбора.
Посмотрите как это сделано в библиотеке Крепежные соединения 3D.
 
Цитата
Павел Перфильев пишет:

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

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

Я сам на работе со ссылками "собаку съел", знаю какие у пользователей возникают проблемы. Тем не менее, существует возможность использования ссылки на фрагмент по переменной, даже если ссылки абсолютные. Использование абсолютных путей может привести к проблемам, но создание и использование копий файлов может привести к другим проблемам (обсуждалось здесь http://tflex.ru/vhodnaforum/read.php?FID=10&TID=1456&MID=1). Лично я, за то, чтобы одному документу соответствовал 1 файл, а не несколько.

P.S.1 Павел, я не собираюсь Вас переубеждать, просто хочу, чтоб другие пользователи были осведомлены о возможных проблемах.
P.S.2 Для переноса файлов проекта существуют специальные команды.
Кто ищет - тот всегда найдет!
 
Цитата
Brom25 пишет:

Я сам на работе со ссылками "собаку съел", знаю какие у пользователей возникают проблемы. Тем не менее, существует возможность использования ссылки на фрагмент по переменной, даже если ссылки абсолютные. Использование абсолютных путей может привести к проблемам, но создание и использование копий файлов может привести к другим проблемам
Я вообще-то не говорил о копиях. Я просто говорил о библиотеках и конфигурациях. Конечно все зависит от предметной области, в которой каждый из нас работает. Я просто не использую заимствованных деталей за очень очень редкими исключениями, когда используются типовые узлы. Правила один документ - один файл я тоже придерживаюсь - у нас каждый проект в определенной папке на одной машине. И если кто-то работает локально, то получит соответсвтующий нагоняй.

Я для переноса проекта я использую простое копирование с сетевого диска на переносной. И открываю дома рабочий проект без всяких заморочек. А утром на работе обратная процедура. И никаких проблем и не надо заморачиваться с переносом проекта - сборок то там не единицы а десятки и сотни. Но я свой подход здесь на форуме никому не навязываю, просто делюсь опытом.

Куда то исчез мой ответ Александру, повторю :
Цитата
Александр Конорев пишет:

В руководстве черным по белому написано что любой параметрический объект нужно начинать с разработки базы данных
Возможно я давно не читал руководство, но такого однозначного утверждения там вроде как нет. Не обязательно параметрическая модель должна иметь базу данных. У меня достаточно много фрагментов, параметрических конечно, но без всякой базы данных. Так что в этом плане что-то Вы путаете.
Что касается сути вопроса, то надо четко обозначить цели, которые вы преследуете задавая вопрос. Какой набор параметров Вы хотите определить через базу данных?
Если только вид материала (по крайней мере первоначально я так понял), то БД не нужна, достаточно создать список значений для соответствующей переменной. Если же параметров(взаимосвязанных друг с другом) несколько, то имеет смысл создать БД. В данном случае я бы посоветовал создать внутреннюю базу данных по ссылке ( в качестве ссылки можно использовать электронную таблицу Excel). В чем преимущество БД по ссылке? Ведь наверняка фрагментов, использующих одну и ту же БД будет не один. Может потребоваться подредактировать БД. В этом случае достаточно легко вносить изменения, всего лишь подредактировать файл Excel. Внешняя база на мой взгляд в этом плане менее удобна - чтобы работать с ней нужна соответсвующая программа - редактор БД. Я по крайней мере в свое время использовал таблицу Excel при создпании библиотеки для проектирования торгового оборудования - надо было увязать номер профиля, его отделку и цену и при этом требовалось легкое редактирование через Excel.
Что касается непосредственно базы данных. Я бы пошел следующим путем. Формируем библиотеку материалов T-Flex, в которой описываем наименования всех используемых материалов (бук бавария, вишня, орех и т.п.) Эта библиотека нам нужна для отображения текстур на модели. За основу можно взять базовую библиотеку Tflex "Дерево.mat". Там куча всяких текстур имеется. Либо создавать свои. Новую библиотеку сохраняем под нужным именем. И все фрагменты создаем с использованием этой библиотеки. Далее создаем базу данных с необходимым набором полей. Одно из полей текстового типа, в котором записаны наименования текстур. Другие поля те которые Вам нужны (толщина, цена и т.п.). Тут кстати встает вопрос как делать выбор записи? Ведь, наверняка для одного и того же наименования материала могут быть несколько разных толщин (10, 16, 28). Я бы в файле модели фрагмента для переменных Материал и Толщина создал простые списки, не связанные с БД, а уже по их значениям делал выборку остальных параметров. На мой взгляд так проще и легче реализовать. Хотя возможно кто-нибудь предложит и другой вариант. Но я в похожих ситуациях делал так, по крайней мере в 10 версии (в 11 у меня таких задач пока не встречалось)
Изменено: Павел Перфильев - 08.02.2010 22:10:38
 
Цитата
Александр Конорев пишет:

В руководстве черным по белому написано что любой параметрический объект нужно начинать с разработки базы данных.
Ну я разве что ошибся в слове "нужно" на "желательно"

Цитата
Павел Перфильев пишет:

Я бы в файле модели фрагмента для переменных Материал и Толщина создал простые списки, не связанные с БД, а уже по их значениям делал выборку остальных параметров. На мой взгляд так проще и легче реализовать.Что касается сути вопроса, то надо четко обозначить цели, которые вы преследуете задавая вопрос. Какой набор параметров Вы хотите определить через базу данных?
Честно говоря и не думал что так все сложно, а условие одно - по наименованию материала в редакторе переменных автоматически обновлять все поля включая текстуру материала.
baza.JPG (23.43 КБ)
 
Цитата
Александр Конорев пишет:

Цитата
Павел Перфильев пишет:

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

Честно говоря и не думал что так все сложно, а условие одно - по наименованию материала в редакторе переменных автоматически обновлять все поля включая текстуру материала.
Да это в общем-то не сложно. Но для упрощения можно при выборе значения наименования материала из списка просто отображать в списке не одно поле наименования материала, а все необходимые поля БД, если одному наименованию может соответствовать несколько записей из-за толщины или еще чего нибудь.
В принципе, на основе той же общей БД можно организовать за счет фильтров формирования списка значений более красивый способ выбора значений. Будет выглядеть как предлагает Павел, с отдельным заданием наименования материала и толщины, но вторичный список толщин для каждого наименования материала будет автоматом формироваться на основе общей БД с учетом заданного условия в фильтре формирования списка значений.
Похоже именно эта технология используется в последнее время самими Топ Системами в новых библиотечных элементах.
Изменено: Antonio - 08.02.2010 23:32:37
 
Цитата
Antonio пишет:

Да это в общем-то не сложно. Но для упрощения можно при выборе значения наименования материала из списка просто отображать в списке не одно поле наименования материала
Добавил доп. поле в базу данных и... заработало! Текстуру потом подправлю на родную. Поверьте, очень сложно новичку разобраться в длинных и непонятных (пока для) меня разъяснениях, хотя я в свою очередь пытался быть лаконичным. Спасибо Всем за участие ! :applanse:
baza1.JPG (21.94 КБ)
Изменено: Александр Конорев - 09.02.2010 00:26:02
 
Цитата
Александр Конорев пишет:

Поверьте, очень сложно новичку разобраться в длинных и непонятных (пока для) меня разъяснениях, хотя я в свою очередь пытался быть лаконичным.
Я думаю Вы сами себе усложняете задачу. Если базу делаете под ЛДСП, так там цена вроде не зависит от текстуры, только от толщины (по крайней мере у нас вроде так) Вес 1 кв.м также определяется толщиной листа и плотностью ЛДСП. Т.е. можно вообще без БД обойтись. Только переменные и списки значений. Толщин то всего наверно три значения - 10, 16 и 28 мм . Я конечно, плотно не занимаюсь мебельным производством но немного интересуюсь этой темой (так для дома для семьи понемногу делаю кое-что).
Повторюсь, но база данных и параметризация это не одно и то же. Можно вполне успешно создавать параметрические модели и без БД.
 
Цитата
Александр Конорев пишет:

Добавил доп. поле в базу данных и... заработало! Текстуру потом подправлю на родную. Поверьте, очень сложно новичку разобраться в длинных и непонятных (пока для) меня разъяснениях, хотя я в свою очередь пытался быть лаконичным. Спасибо Всем за участие !
Скачать файл (сохраните файл нажатием правой кнопки мыши)
Кстати, в Вашем примере, в списке значений текстовой переменной можно через точку с запятой добавить комментарий-наименование, например,
1;Дуб
2;Орех
3;Вишня
Если затем использовать элементы управления для задания значений переменных, то в списке будут показываться только имена, и присваиваться будут численные значения. Так, например, сделан выбор типа резьбы (переменная Type_Threads) в элементе Threaded hole.grb из служебной библиотеки отверстий.
 
Цитата
Antonio пишет:

В принципе, на основе той же общей БД можно организовать за счет фильтров формирования списка значений более красивый способ выбора значений. Будет выглядеть как предлагает Павел, с отдельным заданием наименования материала и толщины, но вторичный список толщин для каждого наименования материала будет автоматом формироваться на основе общей БД с учетом заданного условия в фильтре формирования списка значений.
Похоже именно эта технология используется в последнее время самими Топ Системами в новых библиотечных элементах.
Например, Болт 12459-62.grb из библиотеки болтов к станочным пазам. Для переменной L список значений формируется динамически на основе базы данных в зависимости от значения диаметра болта.
 
Можно попробовать использовать функцию
val ( номер_записи, поле_базы_данных, смещение), где номер_записи - любое арифметическое выражение, значением которого является целое число, поле_базы_данных - обращение к полю, смещение (необязательный параметр) - номер столбца, из которого будет отбираться значение (номер отсчитывается от поля, задаваемого вторым параметром).

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

смещение (необязательный параметр) - номер столбца, из которого будет отбираться значение (номер отсчитывается от поля, задаваемого вторым параметром)

Интересно, а для чего это нужно. Ведь поле базы данных и так можно задать по имени - так как то надежнее даже? Может что то с исполнениями связано. Что то я не могу придумать как это применить. Может конец рабочего дня сказывается?
 
Возможно, для случаев, когда список значений переменой зависит от значения другой переменной. Например, список возможных длин винта зависит от выбранного диаметра резьбы. В этом случае может оказаться удобнее переключать столбец длин винта в БД.
Изменено: Brom25 - 09.02.2010 18:29:57
Кто ищет - тот всегда найдет!
 
Цитата
Павел Перфильев пишет:
Работать с абсолютными путями на мой взгляд не совсем хорошо, даже я бы сказал неправильно. По крайней мере, я своим подчиненным так работать запрещаю. Есть механизм библиотек, конфигурации. Надо их использовать. Иначе потом возникают вопросы типа а как открыть сборку на друго компьютере.
Доброго времени суток! Может вопрос покажется некорректным, но подскажите пожалуйста как создавать относительный путь к файлам и как абсолютный?
Заранее Благодарю!
 
Пути создаются в основном, когда Вы вставляете фрагменты. По умолчанию пути создаются относительные, и Вам не надо беспокоиться по поводу них. Главное, чтобы весь Ваш проект лежал в одной папке и на одном диске. А где по уровню вложенности в папке - уже не важно.
Если сборка на одном диске, а исходный файл фрагмента на другом, то создаётся абсолютный путь (сказанное не относится к библиотекам). При этом программа предупредит Вас, что создаётся абсолютный путь. Также путь можно сделать абсолютным в свойствах фрагмента, только в этом нет никакой пользы.
А что у Вас такое приключилось, что вдруг возник такой вопрос? Просто тема ссылок обычно не стоит особого внимания (если только вдруг проблемы не возникли).
 
Цитата
Андрей Ширшов пишет:
Пути создаются в основном, когда Вы вставляете фрагменты. По умолчанию пути создаются относительные, и Вам не надо беспокоиться по поводу них. Главное, чтобы весь Ваш проект лежал в одной папке и на одном диске. А где по уровню вложенности в папке - уже не важно.
Если сборка на одном диске, а исходный файл фрагмента на другом, то создаётся абсолютный путь (сказанное не относится к библиотекам). При этом программа предупредит Вас, что создаётся абсолютный путь. Также путь можно сделать абсолютным в свойствах фрагмента, только в этом нет никакой пользы.
А что у Вас такое приключилось, что вдруг возник такой вопрос? Просто тема ссылок обычно не стоит особого внимания (если только вдруг проблемы не возникли).
Просто при перемещении проекта с одной рабочей машины на другую некоторые фрагменты, независимо 2D или 3D, теряют путь и приходиться по долгу собирать все на место!
 
Цитата
Сергей Нестеренко пишет:
Просто при перемещении проекта с одной рабочей машины на другую некоторые фрагменты, независимо 2D или 3D, теряют путь и приходиться по долгу собирать все на место!
Сергей Нестеренко, покажите мне пожалуйста, какой путь стоит в свойствах этих фрагментов, и какова версия программы. Попробую помочь.
Страницы: Пред. 1 2 3 След.