Доброго времени суток. Я не профессиональный программист, но пишу мелочёвку для себя. Вот захотел написать небольшую учёную программу по рабочему оборудованию и комплектующим. Для простоты, скажу так, нечто похожее на складской учет.
Я не силен в программировании. В своей небольшой практике я встречал три похода.
Первый. База данных отдельно, программный код отдельно, интерфейс отдельно.
Видел такое в Python, PHP. Сама БД разрабатывается отдельно. После пишется программный код который реализует всю логику работы с БД. Отдельно разрабатывается интерфейс. Для Python я использовал PyQt и рисовал в QT Designer, для PHP обычные веб страницы. Логика работы обяно была такая. В программном коде формуем и отправляем запрос. Получаем массив данных с БД. Полученные данные выводим в интерфейс(тут обычный цикл крутим). Посмотрели, чего надо ввели. Забираем данные с интерфейса(тоже тут обычный цикл крутим). Собираем запрос для обновления(вставки) на сервер. Оправляем запрос. И по новой.
Второй. База данных, программный код, интерфейс все в одном флаконе. В качестве примера приведу Microsoft Access. Тут достаточно просто расписать структуру базы данных, накидаьб форму. Сам программа неким «магическим способом» будет вносит данные в БД и наполнять интрефейс(формы).
Третий. База данных отдельно, программный код и интерфейс совместно. Здесь к у меня Дельфи. Здесь возможно реализовать, как и первый подход и так частично второй. На эту тему даже ведется длительные полемики в ветке по Дельфи. Как писать с или без DB-aware компонентами. Также это поход могут реализовать и многие фреймворки.
Как правильно писать программу для работы с БД?

Ситуация с ПО на текущий момент у меня такая.
Я познакомился с программированием в ВУЗе, курс информатики базировался на Pascal 5.5. Я сразу раскусил перспективы превратить компьютер в суперкалькулятор, и в дальнейшем все расчеты перевел на него. Потом был Delphi, MathCAD, Matlad, сейчас я со всей математикой перешел на Python с его шикарными математическими пакетами. А вот как сделать GUI Python я пока не осилил, работаю в консоли. Это всякие инженерные расчётные работы. Тут я пока не ничего не планирую менять, меня все вполне устраивает, ну может GUI осилю.
Учеты заявок на обслуживание, ремонты и решения прочих проблем с оборудованием. Это у меня БД планово-предупредительного ремонта(ППР). Тут сборная солянка. Изначально было написана на Аксесе, потом он захлебнулся. Попытался переписать на Дельфи, но не смог освоить работу с БД на dbf файлах. Позже набрел на(теперь мой любимый сервер) Firebird. Более менее сделал, неоптимальное конечно, но работает. Но надо переписывать, куча костылей, да и опыта теперь больше. Для работы через браузер сделал упрощённый веб интерфейс, на PHP. У сотрудников много планшетов и смартфонов, они через них заявки на ремонты и разные вопросы технические задают. Т. е. типа небольшого форума. Тут мы ведем все записи о ремонтах, заявки, техническую информацию, что сделано, что кто делает, кто и где находится, что в работе, что остановлено. Сроки облуживания контролируем автоматом. Все тоже все пока нравится. Работает в основном мое подразделение, это шесть человек, остальные сидят через веб интерфейс – тут в пике человек 300.
Также есть база на 1С 8.2 по учету ТМЦ, реализован простой складкой учет. Изначально росли ноги из 1С7.7 ТиС, которую под меня адаптировали наши, местные, программисты 1С. Но с временем мне надоело с ними воевать, освоил 1С самостоятельно. Последний вариант – полностью переписал под УФ на 8.2 файловый вариант БД. С этим работают в основном отдел снабжения, кладовщики и мое подразделение, эпизодически экономисты, бухгалтерия. В пике 50-60 человек, обычно 20-30. Большой плюс, это работа в браузере. Очень удобно работать с планшета, завод-то большой, ноут не натаскаешься. Минусы данного решения, сама платформа довольно тяжелая, работает это все медленно, очень высокая цена как приобретения так и эксплуатации, да и нет нет, но все же нарываюсь на ограничения в самой платформе 1С. Хотелось бы уйти от 1С . Тут решаются задачи подачи заявок на материалы и расходники, их закупка, оприходование, списание, ведение складского остатка, инвентаризации. Хотелось бы добавить автоматический расчет стоимости ремонтных работ, и различных модернизации оборудования. Номенклатура около миллиона позиций, количество документов 50-80 в день по 30-50 позиций.
Есть еще внутренняя база знаний, на Вики и Друпал сделали. Пока не понятна дальнейшая судьба этого решения.
Что хочется. Переписать и переделать часть на 1С. Тут пока все работает как надо. Но для практики самое оно, не горит, решения откаты, идеи реализации проверены. Вторым этапом, после того как здесь поднатаскаюсь как программист, добавить сюда ППР.

White OwlА это смотря чё тебе надо. Обычно пляшут от того что умеют.Умеют ковыряться в Access - пишут все в нем. Получается в 99% паршиво, но все-же иногда работает. Умеют на Дельфях компоненты таскать - делают толстого клиента.

Паршиво уже есть. Теперь хочется красиво. Да и лучше программировать хочу научиться.

White OwlНо если хотят более-менее масштабируемого решения, то идут по пути тонких клиентов и двух-трехзвенных решений. (твой подход номер один).
Там тоже есть варианты.
Самый надежный - всю бизнес-логику делают на хранимых процедурах.

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

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

Поэтому я и начал писать на форуме. До этого мне хватало уже готовых ответов. С благодарностью приму любой совет, вариант.

Max_ХацкерНачни с составления ТЗ. Просто что бы понять рамки твоего "проекта". Детально распиши что твоя прога будет делать и как. Будет она сетевой или нет? Многопользовательской или нет? Какой запас прочности по объёму данных?
Исходя их ответов на эти вопросы и получается план разработки и критерии выбора тех или иных технологий и инструментов.
:))

План у меня есть. А вот с критериями тяжко. Кругозор у меня в программировании пока мал.
Однозначно сетевой, многопользовательской с выделенным сервером БД.
И очень нужен веб интерфейс, хотя бы минимальный.
Объемы небольшие(пока объем данных за пять лет 300 гиг), но аппетит приходит во время еды.

egorychkot275А вот как сделать GUI Python я пока не осилилпопробуй PyQt , например

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

White Owlkot275А одному реально осилить написание тонких клиентов и двух-трехзвенных решений?Ээээ... в принципе реально...
В 80ые была телепередача, ... не помню как называлась, там показывали людей которые делали самодельные автомобили, амфибии, даже вертолеты были. Вот взял человек и сделал себе машину сам. И ездит на ней. Все смотрели и восхищались.
Намек понятен? :)
"Это вы можете" передача называлась. Намек понятен. Нет ничего невозможного.

White Owlkot275 Я много читаю это форум. Ту получается одни пишут сервера приложений, другие тонких клиентов. Или один пишет первое звено, второй второе, третий третье.Командой это действительно делать проще и быстрее. Естественно если лидер в группе есть опытный.

Команда пока не предвидится. Так пока я одинок. Мне надо что-то попроще наверно искать.

White Owlkot275 Мой основной сервер FireBerd, там есть возможность написание хранимых процедур. Но не все на них можно реализовать. Возможно, это функционал у него слаб. Может, порекомендуете что-то на эту тему? Может другой сервер БД?ээээ..... я не большой спец по этому серверу. Последний раз с ним работал еще 90-х, да и видел его в живую в те-же времена. Так что я все же посоветую сменить на что-либо более распространенное, на что будет проще найти спецов, когда будешь набирать свою команду. А что именно - смотри по рынку труда. FB это все-же детище Борландов и если в округе сплошняком дельфисты, то FB можно будет и оставить.

На что можете посоветовать сменить? Сейчас сморю на PostgreSQL, благо он как бы родной для Python, для PHP MySQL.
Я спецов искать не буду так точно, руководству по барабану на автоматизацию, особенно после кризиса 2008, сейчас вообще мысль у них порезать на метал. Им главное максимально выжать деньги с завода. Так что это мое хобби. Если совсем меркантильно походить к этому вопросу, может и сделать хобби профессией. По 1С я понемногу подрабатываю, да и сайты небольшие делаю.

ZukoraСвязка Delphi + FireBird позволит писать приложение любой сложности, красоты и типа. Хоть тонкое хоть толстое. Но не думаю, что в Вашем случае надо писать трехзвенку. Вопрос не в инструменте, а в умении программировать.

Delphi нынче для любителя дороговат. Я лично себе купить его позволить не могу. Последняя купленная версия Delphi 7.
То что вопрос не в инструменте а в умении им пользоваться, мне как инженеру прекрасно понятно. Учусь вот, благо в Интернете море материала на любой уровень и вкус. Но вот завис на выборе направления.

Max_ХацкерТяга к программированию - это конечно хорошо, но может стоит посмотреть на готовые решения в области управления сервисом, активами, ремонтами и т.д.? Начать хотя бы с изучения предложений в мире Freeware и OpenSource. Потом глянуть в сторону платного ПО, если ничего не приглянется. Вдруг найдётся подходящее решение за приемлемое количество дензнаков.
С чего вдруг решил сам писать?

Готовые решения есть. Но с коммерческими получается либо недостаток функционала. Либо все в одном флакон за невменяемые деньги. Да и на тот момент когда я начинал все это - готовых решений не было. OpenSource конечно на порядок более интересен, но опять же, что подогнать под себя надо уметь программировать. OpenSource у меня пока прижился в расчетных задачах и в базе знаний.
Ну а решил писать сам - потому что для меня программирование хобби. А тут приятное с полезным, и голову поломать и работу себе облегчить.

Chop kot275 , моя ИМХА:
допилите свою 1С, ваш любимый Firebird, она, вроде поддерживает,
чтобы не платить дурные деньги за пользовательские лицензии,
сделайте к ней не веб-интерфейс (разобраться со структурой БД 1с-а не такая тривиальная задача, как хотелось бы),
а сайт, который будет обмениваться с 1с-ом данными,
хоть на пхп-е, хоть на чем
1с " работает это все медленно " у тех, кто не умеет ее готовить,
50-60 человек она должна нормально тянуть,
остальные будут в вебе

любое другое решение - будет дороже и сложнее

Дело в том что 1С нелюбимая. Да и дорогое это удовольствие.
По поводу медленно. Ну нет у меня дата-центра своего, и крутой серверной стойки. А в файловом варианте нормально не больше десятка пользователей тянет.
Да и фигня получается. 8,3 нормально сама веб интерфейс рисует уже. Но я для себя не вижу перспектив в 1С.

Я как-то размыто вопрос задал. Попробую немного его сфокусировать.
Для любой системы нужно некое хранилище набора данных. Тут идеальный кандидат различные SQL сервера, благо их много сейчас можно выбрать на любой вкус. И работать с ними очень удобно, ты им запрос, они прошуршали и выдали ответ. Да и в хранимые процедуры много чего напихать можно.
Второе. Нужен программный код на котором будет написано общение пользователя с БД. Так называемое система управлении базой данных(СУБД). Но тут проблем нет, языков программирования на любой вкус сейчас наделали. Да, я Java хотел освоить, курс прочитал. Пока простые вещи были, вроде просто было, но когда начали рассказывать про фабрики которые делают фабрики, тут я уже скис.
Общение программного кода с севером БД довольно просто сейчас, библиотеки написаны на любой вкус и цвет. Соединился, оправил запрос, получил ответ.
Третье. Интерфейс. Графический конечно. А вот тут у меня сплошные засады и непонятки. Попробую подробно расписать .
Получить список данных и вывести на экран. К примеру, возьмем список номенклатуры.
Тут я должен сделать лирическое отступление. Список номенклатуры обычно имеет огромное количество записей, у меня их около миллиона. Для сервера БД выбрать одну запись или несколько десятков труда не составляет, он как раз под это и заточен. Но вот проблема с пользователями. Пользователям надо обязательно вывести весь список на экран, и они там, несмотря на мощную систему фильтрации и поиска, любят крутить колёсико мышки и искать глазками. Особенно этим страдают бухгалтерия у нас. И очень часто им кажется что такую запись они не нашли и давай лепить дубли. В моих программках доступ к НСИ обычному пользователю запрещен. А в общезаводской системе, я постоянно выгребаю дубли. Конец лирического отступления
Да понимаю что вопрос организационного характера работа с НСИ. И больше чем 30-50 записей пользователю видеть на экране за раз не нужно, этого достаточно, чтобы получить преставление о наборе данных и запросит средствами поиска нужные записи.
И вот мы хотим запросить список записей. Простой запрос на выборку с неким условием. С точки зрения кода это простой запрос к серверу БД, он возвращает массив данных(или по научному курсор), дальше мне надо нарисовать интерфейс. По первому варианту, я бегу в цикле по полученному набору данных и рисую картинку пользователю. По второму варианту, мне рисует это сам компонентs(это в Delphi например), ну там DataSet+dbGrid разные. Думается там тоже цикл, но утверждать не берусь, на 100% их работа не понятна мне пока. Особо умные DataSet помимо явно прописанного запроса еще и генерируют свои. Например, вытаскивают из метаданных БД название полей, автообновляют набор данных. Я так один раз подвесил сервер, пока в тестовом режиме сам работал эффекта автобновления не заметил, когда зашло с десяток пользователей, а запрос на выборку компонент оправлял на выборку раз в секунду, сервер подвис.
В третьем варианте, все это на себя берет сам среда. И что она там крутить только Боги знают. Я когда с 1С7.7 разбирался, а у нее тоже есть автообноление и она тянет вес набор записей на клиента, постоянно получал ошибку блокировки таблиц в MS SQL.
Так вот я к чему. В любой программе получается два цикла. Первый на сервер БД, когда он выбирает данные, но тут проблемы не вижу. Там все оптимизировано и под это заточено. А вот второй цикл вывод полученного массива данных на экран, меня и напрягает. Циклы ведь вещь медленная. Да и еще цикл возможен в самой библиотеке работы с БД. Соответственно и в обратную сторону тоже циклы. Считываем с интерфейса введённые пользователем данные, отправляем в БД. Получается, что у меня в программе крутятся сплошные циклы. Пока данных мало я граблей с таким подходом не вижу, но при больших объёмах грабли наверняка будут. Везде пишут циклы медленные и лучше обойтись без них. А другого варианта я не нашел.
Я понимаю, что я пишу для участников этого форума очевидные вещи, но я привык максимально описывать непонятную ситуацию(да и сам требую), чтоб спецы понимали куда я там залез и чем при этом руководствовался. Чуть позже еще другие грабли распишу.