На чем наформошлепить учетную систему?

Там нет денег

Есть. Но такие, что лучше бы их небыло. Даже на иде не хватает. Мука. Как вспомню, аж трясёт.

Есть. Но такие, что лучше бы их небыло. Даже на иде не хватает. Мука. Как вспомню, аж трясёт

Ну так-то если подходить к вопросу, то денег нет почти нигде. Потому макаки повсюду. Зачем далеко ходить — вспомню свою контору: проект, который делаелся за год, по итогу делается три, и то еще не ясно, станут ли эти три пятью. А почему? Потому что вместо норм программистов «нету денег, на иде не хватает» — и сроки растягиваются в пять раз. ХЗ как убедить заказчика в том, что я работаю минимум в 3 раза быстрее, чем их средний программист.

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

P.S. поздравляю с потерей четырёх лет жизни.

Рано. Рано. Пусть женится, лялю заведёт и возьмёт ипотеку – тогда уж помянем.

P.S. Потом ещё нужно будет развестись, делить имущество, и платить львиную долю своей зп в качестве алиментов.

Rust в вакансиях тоже слабо фигурирует, дальше что?

Не слушай паскалистов, вебчик тащит.

Хотя… для диплома — не все ли равно.

Какая именно — он и сам не знает толком, о чём честно написал.

Но обычно под учётной системой понимают не «два поля на веб-странице», а базу данных из N табличек (пусть даже 5-6 в самом-самом простейшем случае), одну или несколько программ их заполнения и одной или нескольких программ по аналитике (в простейшем случае — отчёты, но может быть и посложнее).

Базу надо спроектировать. При написании программы из базы надо дёргать данные, надо сделать формы по их заполнению и др.

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

Тем, кто предлагал веб-фреймворки, я верю как-то больше. Хотя и там не уверен, что это для программиста проще дельфеподобных десктопных RAD, это надо щупать самому. (Для внедренца/интегратора конечно проще по понятным причинам.)

Во первых я всегда за простоту.

Во вторых вот пример кода над которым работаю

	$query = "SELECT * FROM data WHERE field1 = $gz AND field2 = $zz";
	$st = $db -> prepare($query);
	$st -> execute();	
	$res = $st -> fetchAll();

Что вы называете обвязкой в данном случае я не очень понял.

Мне кажется Idris лучше подойдет.

Во первых я всегда за простоту.

Я только за.

Во вторых вот пример кода над которым работаю

Обвязка отвечает за то, куда и как результат этого селекта пойдёт дальше. Тут же по результатам fetch табличка на экране или там формочка ввода не нарисуется волшебным образом, правильно?

Понял тебя многоуважаемый hobbit ну данные попадут в array а дальше надо писать саму процедуру обвязки в зависимости от того как представить результат....

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

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

Не лучше ли сразу в ORM-модель с POJO - здесь всё-таки валидация данных в обе стороны работает и не надо ничего врукопашную парсить из какого-то массива (фффууу).

Так что тут думать? Пиши веб на лиспе (https://github.com/picolisp/picolisp.git).

В app/ лежит готовая ERP система. Покури доки, выкинь лишнее, допили чего не хватает и будет тебе диплом и full stack референс-проектик, чтоб работу искать.

А где перспектива другая?

Какой парсинг? Нет никакого парсинга просто sql-запросы

Где угодно, интересных задач полно.

ладно, предположим, что СУБД меняться никогда не будет

Создать класс для работы с СУБД, а у него можно создать конкретные подклассы для работы с конкретной БД. Раскидывать по всему коду куски для работы с БД — не хорошо.

Создать класс для работы с СУБД, а у него можно создать конкретные подклассы для работы с конкретной БД.

Угу, и что характерно — что для Qt, что для Delphi/Lazarus это сделано давным-давно из коробки. Не через подклассы, а через драйвера, правда.

Сделано ли это в библиотеках для пыха, и в каких именно — с интересом послушаю.

P.S. Наверное, под «СУБД» ты имел в виду «любой реляционной СУБД», а под «конкретной БД» — «с конкретной СУБД».

Лучше на python подобную систему писать в pyqt есть некое подобие таблицы (qtablewidget)туда можно выводить всякие данные.

Прежде всего, есть встроенный (скорее стандартный) ПДО.

Ну и ДБАЛ и АДОДБ.

P.S. Наверное, под «СУБД» ты имел в виду «любой реляционной СУБД», а под «конкретной БД» — «с конкретной СУБД».

Да.

• С++ + Qt - вполне актуально и плюсы без извращений, самое то для старта с минимум боли в этом языке.
• Java - всё что надо есть (что-то его тут совсем забыли).

З.Ы.: Pascal+Lazarus стоит отбраковать. На паскале идеально изучать алгоритмы и структуры данных, что бы без боли и всё ручками реализовать. Но потом надо переходить на следующий язык программирования. Ещё 20 лет назад считалось правильным изучить минимум 4 языка программирования.

В Pascal+Lazarus вообще-то мышкой можно приложение для работы с БД создать.

Лучше на python подобную систему писать

в pyqt есть некое подобие таблицы (qtablewidget)

Эгркрхруммм :)

Вообще-то оно сначала на C++, а потом уже прибиндено к питону (хотя может и не прибиндено, а переписано). И в данном случае целесообразнее не QTableWidget (это для небольших, заполняемых вручную и, как правило, неизменяемых табличек), а QTableView с повешенной на него QSqlQueryModel, а в некоторых случаях — и наследницей от неё.

ты прав, даже диаграммы можно нарисовать если понадобится

Можно, но объём полученных знаний какой? А потом с этим куда?

Паскаль хорош что бы изучить базовые алгортмы, базовые структуры данных, базовый ООП и понимать как работать с динамической памятью. Дальше надо переходить на другие языки. В первую очередь для собственного развития.

IZEN ты не пробовал в скретч (Scratch) подключить к БД? может даже мышкой? 😵😆

Ну кастомизировать на лазаре сложнее, одно действие добавления кастомного контрола потребует много приседаний. В то время как на этих всяких электронах поправил CSS и уже получил rich design.

Объём полученных знаний зависит от того, как глубоко нужно погрузиться в модель предметной области и выразить это на представленном ЯП. Чем проще модель и легче выразить, тем меньше знаний требуется.

Ведь от ТС по сути требуется лишь демонстрация понимания проблематики работы с сохраняемыми структурами данных. И уровень представления (демонстрации) знаний здесь должен быть по принципу «чем проще реализация, тем легче для восприятия» - берём готовые компоненты и связываем их между собой.

Ну кастомизировать на лазаре сложнее, одно действие добавления кастомного контрола потребует много приседаний.

Да нет же. Для этого книжку нужно прочитать, а не языком трепать.

скретч (Scratch) подключить к БД?

Что такое «скретч»? Очередная модная «технология» от гуманитариев-погромистов, не осиливших компилируемые ЯП?

А что там за сокровенные знания дает паскаль про динамическую память?

визуальный язык программирования

А что там за сокровенные знания дает паскаль

Он даёт боль и страдания. Это как: не служил – не мужик.

Ну не так, указатели в паскале, читай динамическая память, это как армия в 27 лет, string,string,string и хренак приплыли ^^^, чо это, где я.

Цена вопроса?

Вы серьёзно?

Цена вопроса?

Лет пять жизни, писали же уже.

Ну не так, указатели в паскале, читай динамическая память, это как армия в 27 лет, string,string,string и хренак приплыли ^^^, чо это, где я.

😂😵

а ну ка IZEN заколбась нам программу, правда там функций нет, досадно https://scratch.mit.edu/

Думаешь, существует что-то лучше, чем DevExpress XAF?

https://docs.devexpress.com/eXpressAppFramework/112559/overview/architecture

https://cslanet.com/

ты не пробовал в скретч (Scratch) подключить к БД? может даже мышкой?

Клоун, какое отношение говноскрэч имеет к лазарусу?

Делать на Lazarus плохая идея и не обязательно использовать именно его. Есть достойные альтернативы. Кроме того я так пошутил над IZEN который всюду пропихивает это говно мамонта.

Java же.
Все что тебе нужно есть изкоробки

Есть достойные альтернативы

Давай дошколёнок, назови эти альтернативы, которые не являются говном мамонта

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

Было бы лучше если бы ТС сформулировал что ему собственно надо.

Собственно мне нужен был совет по сабжу и я его получил, Спасибо. Потихоньку просмотрел все связки, упоминаемые в этой теме, думаю оптимальнее будет web, а именно nodejs (разницы между пхп, питоном и js особо нет, воняет одинаково везде свои проблемы). В js вбухали тонны нефти, большая часть бизнеса в интернете, и неспроста.