Схема подключения терминалов INTOOLS: эффективное решение

Этот пост публикуется по частям; когда работа будет завершена, её можно будет поделиться с всеми

SPI — это что-то потрясающее. Проход через EXCEL. . .

Кстати, идея хорошая, но с надежностью часто возникают проблемы. Когда я это делал, я тоже думал о том, чтобы ввести данные в Orical с помощью внешнего записи, но потом понял, что риски слишком велики, и могут возникнуть серьезные проблемы. Поскольку процесс импорта осуществляется вручную и не контролируется автоматически, введенные вами данные могут не соответствовать правилам базы данных. Например, могут появиться пробелы перед или после данных, а также другие необычные ситуации. Поскольку данные импортируются (обычно с использованием Excel), невозможно гарантировать их стандартизацию, что может привести к повреждению базы данных. К тому же такие проблемы часто трудно обнаружить; вы сможете заметить лишь ошибки при попытке использования функций подключения SPI, но определить точную причину ошибки будет сложно. Поэтому для подобных программ с высоким уровнем специализации и закрытостью не рекомендуется использовать метод внешнего записи данных. Можно использовать данные из существующих библиотек, но вносить новые данные туда не стоит.

Здравствуйте, спасибо за сообщение. На текущем этапе, согласно тестам, запись данных в базу данных с помощью SQL не вызывает никаких проблем. Ключевым моментом является анализ структуры базы данных INTOOLS, определение внутренних связей между различными параметрами, а также способов взаимодействия между данными.

Разработку можно разделить на 5 этапов: 1. Анализ структуры базы данных и выбор необходимых таблиц. 2. Анализ выбранных таблиц базы данных, определение информации о различных параметрах, установление формата параметров для SQL-запросов, а также сбор информации для вызова таблиц базы данных. 3. С учетом стандартов данной отрасли разработать правила присвоения номеров, расположения кабелей и оборудования централизованного управления. 4. Встроить разработанные правила в программу и, согласно формату SQL-запросов, определенному на втором этапе, массово генерировать SQL-запросы, которые можно напрямую записать в базу данных.

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

На первом этапе происходит анализ структуры базы данных. После частого использования INTOOLS структура базы данных становится более знакомой, поэтому здесь не будет подробных объяснений. Кроме того, речь идет о вопросах конфиденциальности, просим понимания. На втором этапе, после того как будет определена структура базы данных INTOOLS, необходимо разработать формат отдельных команд. Например, для записи информации о кабеле, распределительном щитке, контактах и т. д. требуются специальные команды. После того как на этом этапе будут разработаны такие команды, на четвертом этапе они будут объединены в группы.

На третьем этапе основное внимание уделяется соблюдению стандартов данной отрасли; формируются различные правила, соответствующие требованиям этой отрасли, включая правила, касающиеся кабелей, коробок подключения, центральных узлов управления и т. д. Четвертый этап — это процесс интеграции второго и третьего этапов, при необходимости разрабатываются соответствующие процедуры.

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

В приложенном файле находятся SQL-запросы, сгенерированные пакетно; они сохранены в формате EXCEL. Для использования необходимо скопировать SQL-запросы и вставить их в клиентскую программу, после чего их можно выполнить. На выполнение SQL-запросов для 3000 записей уходит примерно 5 минут. На самом деле на генерацию SQL-запросов программным обеспечением уходит примерно 30 секунд.

Судя по вашему описанию, вероятно, произошла ошибка при записи типа данных; соответствующие значения должны быть связаны между собой. Например, для хранения информации о типе IO в базе данных используются данные из таблицы IO_TYPE; в таблицу component достаточно указать соответствующий ID. Однако если вы будете вводить тип IO непосредственно в базе данных, она выдаст ошибку. Во всех модулях INTOOLS все одинаково, вызовы довольно сложны.

После завершения записи можно войти в INTOOLS, чтобы посмотреть результаты записи; при наличии проблем их можно вручную скорректировать. После завершения записи в модуль подключений происходит также запись информации о кабелях; список кабелей можно получить непосредственно из INTOOLS.

Эм... Возможно, вы не поняли, что я имею в виду. Не ясно, предназначено ли то, что вы пишете, только для личного использования или для всего отдела. Если же речь идет о программе, которую хотят использовать все, тогда, когда она будет введена в эксплуатацию, вы поймете, что я имею в виду. У пользователей совершенно нет понимания того, как работает ваша программа. Они просто знают, что если они введут данные, вы сможете передать их в INTOOLS. Но правильность этих данных совсем не входит в их поля зрения. Например, если в базе данных какой-либо столбец предназначен для хранения чисел, но пользователь вводит туда текст, то при сохранении данных возникнут ошибки. Это ещё можно легко диагностировать. Многие люди при работе с Excel используют функцию копирования и вставки; при этом могут быть вставлены различные символы, которые невозможно увидеть. Например, кажется, что там ничего нет, но на самом деле после данных есть пробел, который на самом деле является каким-то скрытым символом. Подобных проблем много, и они постоянно возникают. Проблема не в том, что функция не может выполнять свою задачу, а в том, что для пользователя это слишком сложно. Это приводит к нестабильности данных в całом проекте. Вот что я имею в виду.

Теперь я понимаю: уровень квалификации сотрудников в отделе разный, и действительно существует эта проблема. Но моему программному обеспечению нужна только простая информация; в процессе использования достаточно снова скопировать и вставить исходные данные, оставив лишь саму информацию. Ключевой пункт — только один, остальное, включая пробелы, не влияет

Особенно восхищаюсь такой доработкой программного обеспечения, она действительно повышает эффективность работы.

В процессе реального проектирования у ответственных инженеров желательно иметь базовые навыки написания SQL-запросов, а также определённое понимание структуры базы данных.