Привет всем. Беспокоит Саша фром Уфа. Народ, я не программист, а электронщик. Учусь пока
Мне необходимо создать базу данных, отражающую различные эл. элементы. А пользователь, юзающий этот продукт, вводя по ключевым словам необходимое устр-во, должен получить готовое инжен. решение. Т.е. есть кроме голой инфо еще и ПРОГРАММИРОВАНИЕ. Это должна быть НЕ ПРОСТО БД, а прогр. продукт, выдающий решение на основе данных включенной в него БД. Подскажите: подойдет ли готовая СУБД, в частности аксесс?
Заранее спасибо)))

М	Пожалуйста в следующий раз давайте темам осмысленные названия! sergej.z

Цитата(SashaUfa @ 7.11.2005, 23:48)

подойдет ли готовая СУБД, в частности аксесс?

Да. А для

Цитата(SashaUfa @ 7.11.2005, 23:48)

я не программист, а электронщик. Учусь пока

подойдет лучше других программных средств.

Начинай с чтения справки. Там разделы "Приступая к работе" или "Тем кто пока с БД дела не имел". Читай дло ПОЛНОГО понимания. Потом рисуй структуру исходных данных, связи меж ними (карандашом, на бумаге!!!). Затем рисуй блок-схему алгоритма выбора решения по данным юзера и информации в БД. Потом только начинай работать - создавать саму БД.
Добавлено @ 08:58
PS. Начинай. Глаза боятся - руки делают. И учти - тут помогают. Крепко помогают. Но никто ничего не будет делать ЗА тебя. Так что не расслабляйся. И удачи.

Приветствую Вас, уважаемые программисты. Мне предложили использовать в качестве программного продукта экспертную систему. Все бы хорошо, но слишком много значений придется забивать – нерационально и практически невозможно. Был приведен пример, состоящий в следующем. Принимается решение о принятие на работу, исходя из значений пяти параметров кандидата (стаж: нет, менее 3-х лет, более 3-х лет; судимость: есть, нет; и.п.). И там пришлось забивать более 300 значений (там прописывались ВСЕ варианты, которые вообще могут существовать)!!! В таком простом примере. В моем случае в качестве базовой информации выступают электронные функциональные узлы со своими параметрами (а там ГОРАЗДО больше параметров), а пользователь, для кого и пишется данный продукт, по ключевым словам водит запрос и получает готовое решение. Например, из раздела «устройства» он выбирает «измеритель», из раздела «Измеритель чего?» выбирает «измеритель давления», диапазон измеряемых давлений и величину выходного напряжения (пропорционального измеренному давлению). И получает результат: нужно использовать датчик фирмы Ericsson-235, например. Базу данных пользователь может менять, т.е добавлять, удалять различные узлы электроники, вводить новые параметры узлов. Если датчик не способен выдавать нужную величину напряжения (т.е. его необходимо усилить), то разрабатываемый продукт должен автоматически подобрать оптимальный вариант микросхемы усилителя (опять же по характерным ему параметрам). Например, датчик Ericsson-235 с усилителем Toshiba-021.
Возникает вопрос. Может, тот случай (про принятие на работу) реализован нерационально? Имеется ввиду, может на основе этой экспертной системы можно было сделать все более просто? Или по-другому никак? Или есть иные более сложные, но подходящие экспертные системы? Или вообще экспертные системы здесь неприменимы? Ведь информации, вносимой в программу (узлы электроники со своими параметрами различных фирм) колоссально много!!!
Нельзя ли использовать тот же аксесс? Чтоб мог выдавать результат-устройство, состоящее из одного, двух и т.д. узлов, исходя из запроса пользователя и имеющихся в базе элементов? Что проще использовать: Delphi или Access, если Access вообще подходит? Необходимо иметь ввиду тот факт, чтобы при использовании данного продукта не было б необходимости прописывать какие-то командные слова, как в SQL, ведь пользователь может быть кем угодно, и чаще далеко не программистом. Или SQL можно использовать, удовлетворяя вышеописанным условиям?
Заранее премного благодарен.

P.S. Может кто не понял, а может сам упустил: термин «узел» здесь означает элемент БД со своими параметрами (исходные данные), а «устройство» - это результат работы программы, который может состоять из нескольких узлов, а может и из одного.

Цитата(SashaUfa @ 30.11.2005, 22:56)

слишком много значений придется забивать – нерационально и практически невозможно.

А куда ты нафиг денешься? Начальное занесение данных (что словарей, что базы) - всегда работа объемная. муторная и (если заказывать на стороне) совсем даже не дешевая. Смирись.
Единственное чем ты можешь облегчить себе труд - это спереть эти данные где-нить в каком-нить формате и переварить в свой. Скажем собрать в кучу десяток прайсов по тематике - названия-то там есть...

Цитата(SashaUfa @ 30.11.2005, 22:56)

там прописывались ВСЕ варианты

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

Цитата(SashaUfa @ 30.11.2005, 22:56)

Нельзя ли использовать тот же аксесс?

Тебе уже было сказано - можно. Кстати, по поводу

Цитата(SashaUfa @ 30.11.2005, 22:56)

информации, вносимой в программу (узлы электроники со своими параметрами различных фирм) колоссально много!!!

для Аксесса это "колоссально много" начинается где-то после 2 миллионов записей.

Цитата(SashaUfa @ 30.11.2005, 22:56)

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

Вообще-то желательно понимать, что экспертная система - это инструмент. И не более. Микроскоп - это хорошо? А если гвозди забивать? Тебе же по задаче даже такой инструмент не нужен. Тебе нужна тривиальная СУБД и столь же тривиальный интерфейс к ней. Потому что алгоритма, считай, нету - тупой отбор по критериям.

Цитата(SashaUfa @ 30.11.2005, 22:56)

Что проще использовать: Delphi или Access, если Access вообще подходит?

Вопрос из разряда "если слон на кита - кто кого сборет". Аксесс - это хранение данных и, возможно (но не обязательно!), интерфейс пользователя. Интерфейс же может быть создан и на Дельфи, причем интерфейс более "качественный" (более точные определения пока опустим), но Дельфи не может хранить данные. Впрочем, Аксесс тоже не безальтернативная система хранения данных.

Цитата(SashaUfa @ 30.11.2005, 22:56)

Необходимо иметь ввиду тот факт, чтобы при использовании данного продукта не было б необходимости прописывать какие-то командные слова, как в SQL, ведь пользователь может быть кем угодно, и чаще далеко не программистом.

SQL будет использовать создатель программы, наводя мосты меж интерфейсом и данными. А пользователь может вообще не подозревать о существовании какого-то там SQL вообще и в этой БД в частности.

Цитата(SashaUfa @ 30.11.2005, 22:56)

Или SQL можно использовать, удовлетворяя вышеописанным условиям?

Скажем так - можно НЕ использовать. Но при этом сложность создания программы возрастет в разы.

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

Здравия желаю, Akina. Спасибо за развернутый ответ. Понятно, что придется вводить много данных. Но не по несколько раз же, как в том примере используя экспертные системы, на основе которых реализуется ответ, используя всевозможные комбинации входных данных. Например, к стажу, равному менее 3-х лет, прописываются всевозможные комбинации других параметров. Это ж комбинаторика, там эти наборы и комбинации (их количество) – функция степенная, если не ошибаюсь. И все варианты перебрать – дело неблагодарное и в принципе невозможное в моем случае. А вот набрать информацию об узлах и их параметрах, не повторяясь, и занести конечное число алгоритмов синтеза устройств из этих узлов, наверно, можно.
----------------------------------------------------------------------------------------------
Вторая проблема хуже - эти, с позволения сказать, "заносители", колотят в словари все подряд как придется. Не соблюдая никаких соглашений и требований. Гуляющие регистры, опечатки, из-за этого записи начинают дублироваться...
----------------------------------------------------------
Этот вопрос про ВСЯКОГО юзера опустим. Допустим, что управление информацией в базе буду заниматься исключительно я, но используя полученный интерфейс и не влезая в тексты программ. Такое возможно?


----------
Тебе нужна тривиальная СУБД и столь же тривиальный интерфейс к ней. Потому что алгоритма, считай, нету - тупой отбор по критериям...
---------------------------------

И что порекомендуете? Есть ли такие тривиальные СУБД, где можно создать интерфейс и программирование? Извиняюсь, может глупые вопросы задаю, ведь некомпетентен…


----------------------------------
SQL будет использовать создатель программы, наводя мосты меж интерфейсом и данными. А пользователь может вообще не подозревать о существовании какого-то там SQL вообще и в этой БД в частности.
Скажем так – SQL можно НЕ использовать. Но при этом сложность создания программы возрастет в разы.
---------------------------------------


Я так понимаю, что SQL – очень неплохой вариант, да? Насколько знаю, существует далеко не одна версия SQL. Какую лучше версию принять во внимание? И какую литературу бы по ней порекомендовали? Ведь наверняка знаете конкретные источники (автор и название книги).

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

Насчет программирования – этим буду заниматься естественно я. Думаю, возможно научиться, время порядка 1 года. Притом программировал немного раньше на Паскале, Ассемблере. Вопрос в том, что для решения конкретно поставленной задачи, которую нужно решить в срок, сложно изучить несколько сред или/и СУБД. Вот и обратился сюда за советом, рекомендацией насчет конкретного оптимального выбора среды и/или СУБД.
Большое спасибо, жду ответа.

P.S. Цитаты глючили, поэтому отделял их черточками.

Это сообщение отредактировал(а) SashaUfa - 1.12.2005, 14:03

извиняюсь за вмешательство в дискуссию , но - пардон, не удержался,
Александр, имхо, по этому вопросу сказано более чем достаточно

Цитата(SashaUfa @ 1.12.2005, 14:01)

И что порекомендуете? Есть ли такие тривиальные СУБД, где можно создать интерфейс и программирование?

Цитата(Akina @ 8.11.2005, 08:57)

подойдет ли готовая СУБД, в частности аксесс?

Цитата(Akina @ 8.11.2005, 08:57)

подойдет лучше других программных средств.

Цитата(Akina @ 8.11.2005, 08:57)

PS. Начинай. Глаза боятся - руки делают. И учти - тут помогают

так что перечитай внимательно второй пост, отбрось сомненья и - вперед..

Всем привет!

Мб я чего-нить не понимаю, но по-моему SashaUfa хочет разработать что-то типа SAP'а. Над такими проектами работают комманды не только программистов, но и инженеров и т.п. Идея интересная, но реализовать ее....
Мне кажется SashеUfе почитать про это литературы по больше надо, статеек там всяких.

ramzes
SAP? Вы имеете ввиду САПР – систему автоматизированного проектирования? Да, так и есть, точнее планируется. Или SAP – это нечто иное? Если так, то расскажите, пожалуйста об этом, буду весьма признателен.
ramzes