|
||
| Правила | Регистрация | Пользователи | Сообщения за день | | Поиск | | Справка по форуму | Файлообменник | |
|
Поиск в этой теме |
|
||||
Thượng Tá Quân Đội Nhân Dân Việt Nam Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381
|
Цитата:
Цитата:
Вот чем всякие расчеты в Word, Excel и прочих "инженерных" системах привлекают? Тем, что обычный инженер может относительно легко, без привлечения всяких программистов, выполнять всё, что ему надо. И это очень хорошо. Но до определенного уровня. Рано или поздно приходится уже привлкать дополнительные средства - VBA или какие-то другие "языки программы". Да и там особо много не сделаешь, а потом еще и об оформлении думать. Т.е. инженер уже сталкивается с программированием, которое ему вполне по силам. Но тогда уж лучше изучить какую-то универсальную среду и в ней делать свои программы. Программирование и придумали ленивые люди, чтобы облегчить рутинные операции. И средства разработки теперь достигли совершенства. Сами расчеты в программах занимают от силы 10%, остальное - интерфейс. Но и его сейчас легко разрабатывать, несравнимо легче, чем во времена DOS. А жизнь-то долгая, проще месяц потратить на освоение какой-нибудь среды, чем всю жизнь мучиться с MatchCAD-ами. Последний раз редактировалось ShaggyDoc, 14.12.2014 в 18:03. |
|||
|
||||
webcad.pro Регистрация: 06.01.2005
Московская обл.
Сообщений: 501
|
Цитата:
Для себя вижу применимость БД только в том случае если задаться целью хранить на сервере исходные данные (введенные в интерфейсе) для всех расчетов пользователя, что бы спустя время он мог вернуться к какому-то расчету и что-то изменить - пересчитать. Есть у меня такие мысли, но тут надо делать систему идентификации пользователей (чего я не умею) и переделывать интерфейс, что бы старые данные из базы подгружать в интерфейс. Цитата:
Понятно. Надо бы как-то пользователей сорганизовать на подобное - допустим каждый пользователь из какой-то области заполняет зоны влажности не только для своего населенного пункта, но и для прочих из своей области :) Что конечно мало реально... Загвоздка в том, что на карте, разумеется, показаны далеко не все населенные пункты (из табл. СНиП) поэтому нужны "местные жители", которые смогут определить где на карте находится тот или иной нас. пункт. |
|||
|
||||
Thượng Tá Quân Đội Nhân Dân Việt Nam Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381
|
Цитата:
Любые данные, хранящиеся в одном из "DataSet" сраз сами "умеют" очень многое. И визуальное отображение, и поддержка типов данных (невозможна ситуация, как в начале этой ветки: "Точно число вводите? А то не пойму ЧЯДНТ!"). В БД хранятся любые данные, включая и чертежи, и формулы. БД "умеет" сама производить вычисления и множество всяких операций, невидимых пользователю). И те же отчёты в любой мыслимой форме с помощью специальных "Конструкторов". Всё это может храниться в одном файле, с которым могут и одновременно несколько человек работать. У любого инженера всегда есть куча справочной информации, которая может лежать в БД. Всё это может быть в справочных БД, используемых в разных программах. Вот у меня в программе Лидер-Энергопроект каждый "проект" - это один файл БД. В нем 51 взаимосвязанная таблица. Используется еще один файл Справочников. В нем 43 таблицы (включая климатологию). Этот справочник используется ещё в 4-х других программах. И, даже если надо выбрать одну из трех зон, то также используется таблица всего из трех строк. Пользователь выбирает, например зону "Сухая", а программа получает её номер и по нему сама пересчитвывает связанные пераметры. Но это очень большая и сложная программа. А ничто не мешает сделать сборник маленьких программ. Это любому инженеру под силу. Конечно, придется поизучать. Но это окупится. В том числе и материально. Вообще-то подавляющее число инженерных программ разработаны именно инженерами. Да что убеждаю, просто приложу несколько картинок - программа, выбор из справочников, конструирование отчета, просмотр отчета. |
|||
|
||||
? Регистрация: 17.06.2014
Царицын
Сообщений: 12,211
|
Offtop: Ну некоторые товарищи и в екселе чертежи делают
Вообще то офис+VBA предоставляют широкие возможности. Данные в аксессе, вычисления в екселе, отчёты в ворде. Можно конечно любой из пакетов использовать как угодно. Но лучше по назначению. ----- добавлено через ~2 мин. ----- Тем более передача данных между ними не представляет каких то сложностей.
__________________
Не откладывайте на завтра! Положите на всё уже сегодня.(с) |
|||
|
||||
webcad.pro Регистрация: 06.01.2005
Московская обл.
Сообщений: 501
|
Я не отрицаю, что перед использованием баз данных у меня имеется "психологический барьер" и я бы не сказал, что он подсознательный - вполне осознанный и тому есть причины.
Для начала это просто большая и сложная технология включающая проектирование базы данных и взаимодействие с ней и освоиться с такой технологией дилетанту вроде меня очень не просто, тем более в отсутствии времени. Я немного читал про реляционные базы данных поэтому общее представление у меня имеется, хотя практическую часть не освоил. Но главное препятствие, пожалуй в том, что я не вижу где это применять. Ваш пример интересен и отличная демонстрация того как это может работать, но я не вижу как это можно применить у себя. Вот тут-то, собственно, "собака зарыта" - я и, надо думать, многие другие не видим. Вы видите, а мы нет! Мы мыслим иными категориями и преодолеть - это крайне затруднительно - нужна иная культура мышления. И здесь я даже не говорю о том, что свести воедино программу с 51 таблицей вечерком после работы дано далеко не каждому. Вот вы пишите, что: "У любого инженера всегда есть куча справочной информации, которая может лежать в БД.", а я не знаю какую бы информацию положил в базу данных, в голову приходят сортаменты проката, да и то пользуюсь ими довольно редко, что делать с чертежами в базе данных тоже не знаю... |
|||
|
||||
Thượng Tá Quân Đội Nhân Dân Việt Nam Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381
|
Цитата:
Лучший пример - тот же Офис с MS Access. Почему-то инженеры только до Excel доходят и часто её используют, как БД, со всеми последующими проблемами. В Access есть хороший пример - "Борей.mdb". Это и база данных, и программа, и отчеты, и формы в одном флаконе. И сама справочная система Accsess великолепно объясняет работу с БД такого уровня. А "расчетная" БД гораздо проще, чем практически реальный учет в торговой компании. Цитата:
Но и сам расчет внутри БД может быть, начиная с реквизитов и заканчивая росписью по буковкам и отчетом. Тут и сравнение вариантов, и "обоснование", и иллюстрации если надо - с графиками. Чертежи хранить не обязательно, а вот расчетные схемы с возможностью выбора вариатов - вполне уместно. Office - превосходный набор инструментов, но их надо использовать по назначению. Не делать "расчеты в Ворде" (разве что сумму колонки с данными). Расчеты надо в Excel делать, там же и оформлять. Но и с Excel надо с умом. Встречаются очень интересные таблицы, которые годами совершенствуют. Но для них нужны данные, которые тут же и хранят. Со всеми неудобствами. И все равно VBA начинают использовать. Так переходите на Access - написать формулу на Basic проще, чем ссылками на ячейки, а главное надежнее. Поставил в Excel разделитель неправильный (а неправильным может оказаться и точка, и запятая) - получил ошибку, иногда незаметную. |
|||
|
||||
? Регистрация: 17.06.2014
Царицын
Сообщений: 12,211
|
Excel тем и хорош, что ему без разницы какой разделитель заявлен в ОСе. Если формат ячейки числовой, то при смене системного разделителя автоматически происходит и его смена в Excel. В отличии от Worda.
__________________
Не откладывайте на завтра! Положите на всё уже сегодня.(с) |
|||
|
||||
Thượng Tá Quân Đội Nhân Dân Việt Nam Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381
|
Цитата:
Но Excel ещё хоть реагирует на ошибки. А вот в электронной таблице OpenOffice такие ошибки пропускались. Неправильное число считалось нулем, вычисления продолжались без предупреждений. Представляете, какие ошибки бывали, например в денежных документах. Причем разработчики ОО об этом знали. Но там же "колхоз". Исправит кто-то в одной версии, а другой разработчик затрет своим кодом и ошибка вновь появляется. И ведь как отбрехивались - "зато мы не зависим от Windows. А зато у нас вообще для каждой ячейки можно индивидуальный формат разделителя задать". |
|||
|
||||
Документооборот и управление Регистрация: 15.01.2014
Минск
Сообщений: 1,222
|
Цитата:
Но и конструкторам широкое поле деятельности. Во первых спецификация - самая что ни на есть база данных элементов в комплекте. Учет этих элементов - чем не аналог складского учета где базы данных живут прекрасно. Зато можно получить раскладку по материалам в любой момент как во вложении. Таблицы нагрузок. Тоже хорошо считаются из БД и хорошо экспортируются куда угодно. Конечно можно посчитать и руками. Но автоматически гораздо приятнее. Как что. А применение типовых элементов. Выбрал чертеж закладной из базы в виде картинки и вставил ее сразу в отчет общих данных со штампам КЖИ. А учет самих чертежей. В общем поле непаханое для применения БД в проектной организации. |
|||
|
||||
Регистрация: 18.12.2010
Сообщений: 5,057
|
Если поменять разделитель в Excel'е то можно обнаружить кучу неожидоностей, например в таблице могут оказатся числа с разными разделителями - потому что тип данных разный текст/число, VBA может это игнарировать...
А SQL гораздо удобней формул в Excel'е, особенно если надо ссылатся на кучу таблиц. ИМХО формулы удобны в рамках одного листа, если нужно >2 листов - однозначно БД |
|||
|
||||
webcad.pro Регистрация: 06.01.2005
Московская обл.
Сообщений: 501
|
Цитата:
Цитата:
Кстати, с ведомостью расхода стали удачно напомнили, уж и призабыл этот опыт. Некогда решил я (в очередной раз как нынче) стать более прогрессивным и загнал кое-какой КЖ в MS Access с марками и закладными, болтами и тому подобным. Таблицы там всякие сделал для арматуры, проката, классов стали, бетона разного ну как положено. И стал пробовать штатными средствами из этого дела калькуляцию тянуть. И так и сяк тянул - не выходит... без дополнительного программирования. Ну, думаю, может это я совсем тупой - кнопки не правильные нажимаю и пошел к одному нашему специалисту по базам - он на SQL как на родном изъясняется, хоть и при слове "аксес" слегка морщит рот (работал я тогда в сравнительно большой организации там даже PDMS был - так-то вот, нынче расскажи - не поверят). В общем то ли гражданин не проникся моими заботами, то ли я был не достаточно красноречив, но обычным SQL калькуляцию вытянуть не удалось, а ковырять Бейсик тамошний я то ли не захотел то ли времени не нашел. Так бесславно закончилось мое очередное весенне-осеннее обострение. Это собственно критика про всемогущество БД и возможность чего-то посчитать оной :) |
|||
|
||||
Регистрация: 09.12.2008
Сообщений: 4,649
|
Базы данных это когда одновременно обращаются к источнику много пользователей и нужно производить обработку быстро. Просто инженерные расчеты - прекрасное средство электронные таблицы + VBA или еще лучше - Open-Office Basic (который помощней VBA будет - поддержка функций массива например).
Конечно нужно основы освоить - вставлять обязательно обработчик ошибок. Плюс - можно сразу считать много много (например проверить сразу 100 элементов по СНиП) Для каждого при этом не обязательно расписывать одни и те же формулы - достаточно в приложении поместить выдранную из стройконсультанта методику и закоментированный текст программы. Так по крайней мере по американским правилам - считайте хоть в чем, но все должно быть ясно и понятно - что откуда. вот статьи на эту тему http://myooo.ru/content/view/172/95/ http://myooo.ru/content/view/173/95/ Программы типо маткада-нормкада я вообще никогда не понимал - в качестве профессиональной математической она сильно слабая (по сравнению с той же Техасской и свободной wxmaxima) для инженерных целей - избыточная для оформительских целей - слишком убогая. Такие вещи как правило рекламируются через агрессивный маркетинг и эксплуатируют какую то уязвимость пользователя - например безграмотность, неумение перевести единицы (прогулянные уроки арифметики) и так далее.
__________________
мой блог по некоторым вопросам Последний раз редактировалось ETCartman, 16.12.2014 в 00:14. |
|||
|
||||
Thượng Tá Quân Đội Nhân Dân Việt Nam Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381
|
Цитата:
На сервере удобно иметь постоянную БД с фиксированным набором таблиц. Например этот форум работает или с 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, ни десяток других СУБД не будут доступны - там "вера не позволяет". Должен хавать то, то позволили Билл - он самый богатый, значит и самый умный. Цитата:
|
|||
|
||||
КЖ; C# Регистрация: 03.11.2005
Санкт-Петербург
Сообщений: 2,589
|
Что сложного то? Для того что бы въехать можно посмотреть вот эту статью: http://www.sergechel.info/ru/content...reparing-tools
|
|||