[vl74]

Давно уже занимаюсь проектной деятельностью и заметил одну вещь - нет нормального способа оформлять расчеты. Понятно - NormCad, "ом снип железобетон", модули SCAD, в LIRA есть расчеты узлов стыков и баз металлических конструкций (с подробным протоколом расчета по пунктам нормативов).
Сам я изобретал велосипед - расчеты в EXCEL, но там сложности с вставкой формул и последующей постановкой значений переменных.
Но когда надо быстро сделать отчет с рисунками и формулами - иногда проще вручную, чем в WORDе.

И я решил попробовать WORD+VBA. Не самый простой вариант, но документ получает сразу конечный вид.
За основу взял пример 22 пособия к СП 52-101-2003, скопировал текст и в VBA набрал программу.
Пример выложил, голубым цветом отмечены вводимые данные, коричневым - результаты расчета. После ввода данных нажмите CTRL+Q
Он не совсем идентичен тексту примера, но тут уж издержки расчета.

И по-моему в примере ошибка с определением коэффициента nu_v (он не равен 1 , его нужно считать по формуле 3.86). Но в файле оставил как в примере.


ПОПРАВКА - в примере нет ошибки.

[ShaggyDoc]

Собственно ваш отчет тому пример - явно неудачная альбомная компоновка листа, при том, что табличный подход тут сравнительно удачно реализован.

Это часть расчетов с широкими таблицами. Большинство книжная А4. Но тут суть в том, что такой отчет можно как угодно скомпоновать. Можно и в виде текста. Здесь важен принцип - данные в БД, ввод только нужных параметр, расчет и формирование оформления - автоматически.

p.s. Сергей Александрович, а не знаете ли где взять данные по зонам влажности (карта зон влажности из приложения «В» СНиП 23-02-2003) соотнесенные с населенными пунктами из списка СНиП 23-01-99 «Строительная климатология»?

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

Вот чем всякие расчеты в Word, Excel и прочих "инженерных" системах привлекают? Тем, что обычный инженер может относительно легко, без привлечения всяких программистов, выполнять всё, что ему надо. И это очень хорошо. Но до определенного уровня. Рано или поздно приходится уже привлкать дополнительные средства - VBA или какие-то другие "языки программы". Да и там особо много не сделаешь, а потом еще и об оформлении думать. Т.е. инженер уже сталкивается с программированием, которое ему вполне по силам.

Но тогда уж лучше изучить какую-то универсальную среду и в ней делать свои программы. Программирование и придумали ленивые люди, чтобы облегчить рутинные операции. И средства разработки теперь достигли совершенства. Сами расчеты в программах занимают от силы 10%, остальное - интерфейс. Но и его сейчас легко разрабатывать, несравнимо легче, чем во времена DOS. А жизнь-то долгая, проще месяц потратить на освоение какой-нибудь среды, чем всю жизнь мучиться с MatchCAD-ами.

[AY]

Сообщение от ShaggyDoc Но тут суть в том, что такой отчет можно как угодно скомпоновать. Можно и в виде текста. Здесь важен принцип - данные в БД, ввод только нужных параметр, расчет и формирование оформления - автоматически.

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

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

Сообщение от ShaggyDoc Но тогда уж лучше изучить какую-то универсальную среду и в ней делать свои программы.

Изучение среды, автоматически не позволяет делать отчеты, нужно еще и с этой стороной вопроса разбираться, ну и работа с БД отдельная тема и еще кое-какие технологии. Многие ли способны (и имеют время) освоить сказанное? Надо думать, сущие единицы, поэтому Excel, поэтому "мучения" с MathCad. Впрочем, мы опять начинаем обсуждать "какой язык для расчетов лучше".

Сообщение от ShaggyDoc Мне таких данных найти не удалось. Справочник климатологии у меня есть, к нему можно бы и зону прицепить. Но это надо долго возиться. Пока оставил выбор зоны из списка. Все-таки не каждый раз в разных зонах проекты делают, можно и на карту глянуть или помнить.

Понятно. Надо бы как-то пользователей сорганизовать на подобное - допустим каждый пользователь из какой-то области заполняет зоны влажности не только для своего населенного пункта, но и для прочих из своей области :) Что конечно мало реально... Загвоздка в том, что на карте, разумеется, показаны далеко не все населенные пункты (из табл. СНиП) поэтому нужны "местные жители", которые смогут определить где на карте находится тот или иной нас. пункт.

[perpetule]

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

[ShaggyDoc]

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

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

Любые данные, хранящиеся в одном из "DataSet" сраз сами "умеют" очень многое. И визуальное отображение, и поддержка типов данных (невозможна ситуация, как в начале этой ветки: "Точно число вводите? А то не пойму ЧЯДНТ!"). В БД хранятся любые данные, включая и чертежи, и формулы. БД "умеет" сама производить вычисления и множество всяких операций, невидимых пользователю). И те же отчёты в любой мыслимой форме с помощью специальных "Конструкторов". Всё это может храниться в одном файле, с которым могут и одновременно несколько человек работать.

У любого инженера всегда есть куча справочной информации, которая может лежать в БД. Всё это может быть в справочных БД, используемых в разных программах. Вот у меня в программе Лидер-Энергопроект каждый "проект" - это один файл БД. В нем 51 взаимосвязанная таблица. Используется еще один файл Справочников. В нем 43 таблицы (включая климатологию). Этот справочник используется ещё в 4-х других программах. И, даже если надо выбрать одну из трех зон, то также используется таблица всего из трех строк. Пользователь выбирает, например зону "Сухая", а программа получает её номер и по нему сама пересчитвывает связанные пераметры.

Но это очень большая и сложная программа. А ничто не мешает сделать сборник маленьких программ. Это любому инженеру под силу. Конечно, придется поизучать. Но это окупится. В том числе и материально. Вообще-то подавляющее число инженерных программ разработаны именно инженерами.

Да что убеждаю, просто приложу несколько картинок - программа, выбор из справочников, конструирование отчета, просмотр отчета.

[Бахил]

Сообщение от perpetule свои расчеты оформляю в автокаде с использованием таблиц автокада

Offtop: Ну некоторые товарищи и в екселе чертежи делают
Вообще то офис+VBA предоставляют широкие возможности. Данные в аксессе, вычисления в екселе, отчёты в ворде.
Можно конечно любой из пакетов использовать как угодно. Но лучше по назначению.

----- добавлено через ~2 мин. -----
Тем более передача данных между ними не представляет каких то сложностей.

[AY]

Сообщение от ShaggyDoc Это типичное заблуждение - подсознательный страх перед базами данных

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

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

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

И здесь я даже не говорю о том, что свести воедино программу с 51 таблицей вечерком после работы дано далеко не каждому. Вот вы пишите, что: "У любого инженера всегда есть куча справочной информации, которая может лежать в БД.", а я не знаю какую бы информацию положил в базу данных, в голову приходят сортаменты проката, да и то пользуюсь ими довольно редко, что делать с чертежами в базе данных тоже не знаю...

[ShaggyDoc]

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

Конечно, если почитать серьезную литературу, где втолько "Введение" составляет 1060 страниц, то можно испугаться. Но можно и проще.

Лучший пример - тот же Офис с MS Access. Почему-то инженеры только до Excel доходят и часто её используют, как БД, со всеми последующими проблемами. В Access есть хороший пример - "Борей.mdb". Это и база данных, и программа, и отчеты, и формы в одном флаконе. И сама справочная система Accsess великолепно объясняет работу с БД такого уровня. А "расчетная" БД гораздо проще, чем практически реальный учет в торговой компании.

а я не знаю какую бы информацию положил в базу данных, в голову приходят сортаменты проката, да и то пользуюсь ими довольно редко

Ну так какую-то работу всё равно делаете? Вот у меня только для теплотехнических расчетов набралось более 40 справочников. Конечно, чтобы рассчитать M=q*l^2/8 справочников не надо. А вот сечения под момент подобрать уже понадобится. Причем ведь можно и разом весь сотамент проверить или по каким-то условиям.

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

Office - превосходный набор инструментов, но их надо использовать по назначению. Не делать "расчеты в Ворде" (разве что сумму колонки с данными). Расчеты надо в Excel делать, там же и оформлять. Но и с Excel надо с умом. Встречаются очень интересные таблицы, которые годами совершенствуют. Но для них нужны данные, которые тут же и хранят. Со всеми неудобствами. И все равно VBA начинают использовать. Так переходите на Access - написать формулу на Basic проще, чем ссылками на ячейки, а главное надежнее. Поставил в Excel разделитель неправильный (а неправильным может оказаться и точка, и запятая) - получил ошибку, иногда незаметную.

[Бахил]

Сообщение от ShaggyDoc Поставил в Excel разделитель неправильный

Excel тем и хорош, что ему без разницы какой разделитель заявлен в ОСе. Если формат ячейки числовой, то при смене системного разделителя автоматически происходит и его смена в Excel. В отличии от Worda.

[ShaggyDoc]

Excel тем и хорош, что ему без разницы какой разделитель заявлен в ОСе. Если формат ячейки числовой, то при смене системного разделителя автоматически происходит и его смена в Excel.

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

Но Excel ещё хоть реагирует на ошибки. А вот в электронной таблице OpenOffice такие ошибки пропускались. Неправильное число считалось нулем, вычисления продолжались без предупреждений. Представляете, какие ошибки бывали, например в денежных документах. Причем разработчики ОО об этом знали. Но там же "колхоз". Исправит кто-то в одной версии, а другой разработчик затрет своим кодом и ошибка вновь появляется. И ведь как отбрехивались - "зато мы не зависим от Windows. А зато у нас вообще для каждой ячейки можно индивидуальный формат разделителя задать".

[realdoc]

Сообщение от AY на ум приходит только несколько таблиц с характеристиками бетона да сортаменты проката.

Это если думать только о расчетах. На самом деле для базы данных в проектной фирме очень большое применение. По сути вся область деятельности фирмы может быть охвачена такой базой данных.
Но и конструкторам широкое поле деятельности. Во первых спецификация - самая что ни на есть база данных элементов в комплекте. Учет этих элементов - чем не аналог складского учета где базы данных живут прекрасно.
Зато можно получить раскладку по материалам в любой момент как во вложении.
Таблицы нагрузок. Тоже хорошо считаются из БД и хорошо экспортируются куда угодно. Конечно можно посчитать и руками. Но автоматически гораздо приятнее.

Сообщение от AY что делать с чертежами в базе данных тоже не знаю...

Как что. А применение типовых элементов. Выбрал чертеж закладной из базы в виде картинки и вставил ее сразу в отчет общих данных со штампам КЖИ.
А учет самих чертежей. В общем поле непаханое для применения БД в проектной организации.

[trir]

Если поменять разделитель в Excel'е то можно обнаружить кучу неожидоностей, например в таблице могут оказатся числа с разными разделителями - потому что тип данных разный текст/число, VBA может это игнарировать...
А SQL гораздо удобней формул в Excel'е, особенно если надо ссылатся на кучу таблиц. ИМХО формулы удобны в рамках одного листа, если нужно >2 листов - однозначно БД

[AY]

Сообщение от ShaggyDoc Конечно, если почитать серьезную литературу, где втолько "Введение" составляет 1060 страниц, то можно испугаться. Но можно и проще.

В общем, будем считать, что вы меня уговорили, по меньшей мере, на чуть более системный подход к предмету :) Стало быть, мне в таком случае нужен совет с какой базой работать. На виду: PosgreSQL, MySQL, SQLite... MS Access мне по всей видимости не подходит т.к. работать база должна на сервере под Linux.

Сообщение от realdoc Это если думать только о расчетах. На самом деле для базы данных в проектной фирме очень большое применение. По сути вся область деятельности фирмы может быть охвачена такой базой данных.

Если уж на то пошло, то много чего можно охватить базой данных, но надо ли? Сэкономлю ли я время и силы охватывая КЖИ базой данных или суммарные трудозатраты окажутся меньше, если файлы попросту положить в некоторой папке (может в нескольких структурированных)? Думается, что последнее более вероятно.

Кстати, с ведомостью расхода стали удачно напомнили, уж и призабыл этот опыт. Некогда решил я (в очередной раз как нынче) стать более прогрессивным и загнал кое-какой КЖ в MS Access с марками и закладными, болтами и тому подобным. Таблицы там всякие сделал для арматуры, проката, классов стали, бетона разного ну как положено. И стал пробовать штатными средствами из этого дела калькуляцию тянуть. И так и сяк тянул - не выходит... без дополнительного программирования. Ну, думаю, может это я совсем тупой - кнопки не правильные нажимаю и пошел к одному нашему специалисту по базам - он на SQL как на родном изъясняется, хоть и при слове "аксес" слегка морщит рот (работал я тогда в сравнительно большой организации там даже PDMS был - так-то вот, нынче расскажи - не поверят). В общем то ли гражданин не проникся моими заботами, то ли я был не достаточно красноречив, но обычным SQL калькуляцию вытянуть не удалось, а ковырять Бейсик тамошний я то ли не захотел то ли времени не нашел. Так бесславно закончилось мое очередное весенне-осеннее обострение. Это собственно критика про всемогущество БД и возможность чего-то посчитать оной :)

[ETCartman]

Базы данных это когда одновременно обращаются к источнику много пользователей и нужно производить обработку быстро. Просто инженерные расчеты - прекрасное средство электронные таблицы + VBA или еще лучше - Open-Office Basic (который помощней VBA будет - поддержка функций массива например).
Конечно нужно основы освоить - вставлять обязательно обработчик ошибок. Плюс - можно сразу считать много много (например проверить сразу 100 элементов по СНиП) Для каждого при этом не обязательно расписывать одни и те же формулы - достаточно в приложении поместить выдранную из стройконсультанта методику и закоментированный текст программы. Так по крайней мере по американским правилам - считайте хоть в чем, но все должно быть ясно и понятно - что откуда.
вот статьи на эту тему
http://myooo.ru/content/view/172/95/
http://myooo.ru/content/view/173/95/
Программы типо маткада-нормкада я вообще никогда не понимал - в качестве профессиональной математической она сильно слабая (по сравнению с той же Техасской и свободной wxmaxima)
для инженерных целей - избыточная
для оформительских целей - слишком убогая.
Такие вещи как правило рекламируются через агрессивный маркетинг и эксплуатируют какую то уязвимость пользователя - например безграмотность, неумение перевести единицы (прогулянные уроки арифметики) и так далее.

[ShaggyDoc]

Стало быть, мне в таком случае нужен совет с какой базой работать. На виду: PosgreSQL, MySQL, SQLite... MS Access мне по всей видимости не подходит т.к. работать база должна на сервере под Linux.

Сначала надо подумать, а должна ли БД быть именно на сервере. Если говорить о расчетах, да еще таких, которые выполняет один человек или несколько попеременно, то лучше имель локальную БД, которую можно положить куда угодно и перенести куда угодно в виде одного файла. На сервере под Linux лучше всего использовать MySQL - он просто есть "везде". PosgreSQL менее распространена и нужна для очень больших объемов данных. Хотя принципиальных отличий между ними нет, здесь не пользователь выбирает, а администратор сервера.

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

Для расчетов удобнее локальная работа. Один проект - один файл, в котором исполнитель сам хозяин. Тут уж MySQL неудобен, хотя он может работать и на локальной машине, но с постоянно запущенным сервером MySQL. Хотя весь сервер - это одна DLL.

SQLite для расчетов удобнее - это однофайловая БД, которую можно поместить где угодно, хоть локально, хоть на сервере. Для работы тоже нужна одна sqlite3.dll (для Windows, на Linux другой движок). Вот тут и засада обнаруживается. Как всякую "свободную" систему SQLite "рихтуют" под себя все, кому не лень. Имеется множество одноименных вариантов, которые часто несовместимы между собой. Поэтому каждая программа тащит с собой свою версию и количество их на компьютерах растет. И хорошо еще если DLL кладут в папку своей программы, а не в System. У меня на машине нашлось 18 штук этих DLL в разных вариантах.

Кроме того SQLite не имеет визуальных компонентов. А именно они нужны прикладному программисту (инженеру). Это просто сервер, который очень хорошо выполняет SQL-запросы. А чтобы применить его в конкретной программе, нужны дополнительные компоненты - как минимум для Connection, DataSource, Table и Query. И здесь уже дело за средой программирования. В каких-то штатных средств вообще нет - нужны сторонние. А они обычно очень "разные" - как правило корявые. И, даже если такие найдутся, то необходимо и другое - например генератор отчетов, который тоже должен уметь работать с SQLite.

Если заниматься программированием БД, то сначала надо выбрать среду программирования, а потом уже выбирать из того, что доступно в ней. Т.е. сначала какую-то "веру" принять.

Я, например, работаю в Delphi. Там есть всё для БД - и локальных и серверных. Например, Firebird, который и локально с однофайловой БД работает (embedded), и с той же БД на сервере будет работать, без каких-то изменений в программе. И набор превосходных компонентов есть. Можно и через ADO работать, т.е. вообще с любой БД, для которой есть OleDbProvider (а их не так уж много хороших). Как минимум с БД формата Access (mdb) вполне возможно. Но тут уже обнаруживаются козни Майкрософта. Они взялись плодить новые версии и в них, по их "доброй" традиции, стали появляться недопустимые глюки. Поэтому я для расчетных программ теперь уже навсегда перешел на AbsoluteDatabase - в ней есть всё, что надо и не нужны вообще никакие посторонние "движки".

Если же "продал душу" Майкрософту, то уже ни Firebird, ни Interbase, ни AbsoluteDatabase, ни десяток других СУБД не будут доступны - там "вера не позволяет". Должен хавать то, то позволили Билл - он самый богатый, значит и самый умный.

пошел к одному нашему специалисту по базам - он на SQL как на родном изъясняется, хоть и при слове "аксес" слегка морщит рот

Ну и правильно делает. Программу MS Access программисты не используют, разве что для конструирования самой БД. Она же для "чайников", всё кнопками делается, нет даже окна для ввода SQL-запроса. А вот базу в формате Access использовать можно, но с учетом её возможных глюков и распухания.

[trir]

Я бы посоветовал MySQL - книжек и доков больше (на руском), хотя SQLite и Firebird - логичней
И да, без програмирования - никуда

[DMSbrick]

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

а картиночки (бмп жпег) как вставляете?

[swell{d}]

Чего-то сложно. Проще в экселе

[perpetule]

Картиночки (png) - как правило относительным путем на папку с фиксированным именем "image", или без пути, но упаси вас использовать OLE.

[Boxa]

Сообщение от swell{d} Чего-то сложно. Проще в экселе

Что сложного то? Для того что бы въехать можно посмотреть вот эту статью: http://www.sergechel.info/ru/content...reparing-tools

[swell{d}]

Boxa, я лично вообще не понимаю, зачем это нужно