На чём нынче модно делать интерфейс к БД?

Почему-бы и не 1С. Работает относительно нормально. Если понадобиться поправить, то специалистов разной степени криворукости дофига и больше.

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

Необходимо дать ему инструмент, при помощи которого он сам, без сурового погружения в языки программирования, сделает себе СУБД с максимально отвечающим его задачам интерфейсом

А так можно? Мне казалось такие штуки делают либо офистые люди уже более-менее погружённые в программирование, либо специально обученные программисты

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

Тут нужен какой-никакой программист всё-таки, а сотрудник только задачу ему сообщит (и не надо надеяться что там будет чёткое ТЗ). Самое незатратное для примитивных задач, на мой взгляд, это веб с php/mysql. Если у компании нет сервера где его запустить - можно на компе того сотрудника.

Если надо очень быстро, и есть бюджет, я бы взял retool.

По твоему описанию 1с:склад вполне себе готовое решение, которое поставил и прямо сразу работай.

Если у тебя не совсем упоротое кастомизировонное специальное производство, то скорее всего уже есть готовое отраслевое решение. Смотреть на 1с:парикмахерскую и 1с:нефтебазу конечно бессмысленно, но можно подобрать подходящий вариант по каталогам либо просто позвонить продаванам 1с и прямо спросить что они могут предложить из готового под такую задачу (естественно описав её).

Самое незатратное для примитивных задач, на мой взгляд, это веб с php/mysql

По моим впечателниям PHP+MySQL — это лютый секас даже для простого CRUD-а. Да, по простой круд есть готовые решения, но очень быстро ты упрешься в то, что нужен непростой круд. Я неоднократно наблюдал, когда уже на «слегка непростом» уровне пых-мускуль начинали люто пробуксовывать.

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

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

Я давно думаю что-то с этим сделать, поскольку вполне возможно упростить задачу на фундаментальном уровне через переосмысление хранилищ данных, которые давным давно поражены реляционным раком, с самого своего рождения затруднявшим любую возможность эффективно отображать сущности из реального мира в байтики. В общих чертах — это что-то в духе dBase, в том смысле , что данные и код едины, только эти код и данные имеют совершенно иной вид, более современный.

Проблема в том, что как правило никто не может составить нормальное ТЗ, просто потому что никто не знает, как система будет применяться. Всё может 40 раз измениться в процессе эксплуатации, вплоть до исходных данных. Поэтому нанимать специалиста выйдет очень дорого, и придётся оплачивать ему все эти бесконечные правки. А вот если сотрудник сам себе облегчит задачу, сам сможет править код под себя, то это может быть и заработает.

Выглядит прямо хорошо, спасибо.

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

А вот это не важно. Этот же сотрудник сам этой же базой и будет пользоваться, как она выглядит, никого не волнует. Хоть на ncurses пиши.

никто не может составить нормальное ТЗ, просто потому что никто не знает, как система будет применяться. Всё может 40 раз измениться в процессе эксплуатации, вплоть до исходных данных

Дай я тебя расцелую. Именно по этой причине Jira в принципе не способна быть удобной — потому что независимо от конфигурации завтра понадобится другая конфигурация, и всю систему придется перекраивать заново. Никакое ТЗ не спасет, потому что его нет и быть не может. Именно потому так много коммерсов продолжают вести бизнес на экселе.

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

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

А вот это не важно. Этот же сотрудник сам этой же базой и будет пользоваться, как она выглядит, никого не волнует. Хоть на ncurses пиши

Он, наверное, о том, что БД будет дико тормозить спустя время, из-за чего работа будет стоять. Справедливости ради — вся проблема возникает только из-за бессмысленной SQL-реляционной абстракции. В 2022 нет никакой проблемы тупо грузить все данные в оперативную память, выполняя там какие угодно операции с молниеносной скоростью.

Речь конечно не про внешний вид. А про то, что там будет костыль на костыле, в том числе в UI, в итоге и самому сотруднику будет неудобно, он будет (пользуясь) тратить кучу времени на продирание через свои же костыли, но он будет считать что так и надо, это просто задача такая сложная вот и время тратится, а о том, что всё можно было сделать по-другому и нормально - ему даже в голову не придёт.

А, в этом смысле. Ну это тоже решается обнулением базы раз в квартал, первый раз что ли ))

Я выше написал, что сделать сразу нормально это утопия. И, главное, ни у кого нет такой задачи.

Проблема в том, что как правило никто не может составить нормальное ТЗ

ТЗ это что-то из страны фей и единорогов (: Сажаешь сотрудника и разраба в один чатик и заставляешь их обсуждать задачу пока не синхронизируют мозги (или не напьются/подерутся). Я в таком формате писал одну складскую хрень на Laravel (неожиданно вменяемый фрэймворк, учитывая что это пых), основную часть утрясли за день. Правда с тем заказчиком давно работаем, мозги уже изрядно синхронизированы

Ты так рассказываешь, как будто мы никогда так не делали ))

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

Чем же MS Access не угодил? Самый распространенный вариант, кажется.

Я всё понимаю. Но у меня на самом деле другая задача. Моя задача — подсказать людям, на чём они смогут красиво уложить свои костыли. Что они там реально уложат — это уже не моя задача :-)

Вот когда у них станет с одной стороны, невыносимо от костылей, а с другой — они уже будут понимать зачем им это всё и как должно работать, вот тогда они придут ко мне за нормальным решением и я продам им 1С.

К тому же, надо понимать, что это не основная задача бизнеса. Если бы она была основной, то на её оптимизацию и бюджет был бы заметный, и время, и ТЗ нормально составлено. А это побочка, она не обязана быть эффективной.

На линуксе не особо работает.

Если надо очень быстро, и есть бюджет, я бы взял retool

Ох ты ж ё... У меня флешбеки. Я 15 лет назад еще в школе такого говно лепил. В смысле, среду для проектирования тырпрайзных интерфейсов мышкой. Потом участвовал в Glade-Anjuta, потом лепил на делфях подобные системы за деньгу. Я посмотрел туториал retool — я вообще не вижу прогресса за эти 15 лет. Делфи 15 лет назад умел точно так же в процессе разработки показывать данные из табличек, поддерживал кучу разных адаптеров к разным БД. Аналогичные решения были и под VB/C# — не нужно думать, что я здесь делфи рекламирую.

Главный недостаток, в контексте данного треда — лепить приложухи на retool не проще, чем не делфи. SQL — это ни разу не простой язык, особенно если поверх него прилепить костыль в виде JS. Как я уже писал выше, для решения проблемы нужен язык, который близок к данным. То есть, если мы берем JS, то в БД должен лежать JSON, которым мы оперируем через table.push(item). Правда, если вы попытаетесь на полном серьезе это сделать, то узнаете, насколько убог JS. Пример относительно успешного решения в индустрии есть — это Clojure. Как ни странно. Те, кто знакомы с языком, удивятся, почему я поместил его в эту категорию, хотя сама Clojure не особо дружит с персистентностью. Тем не менее, структуры этого языка очень близки к алгоритмам БД с MVCC.

В этом плане попытка retool быть в каждой бочке затычкой является движением ровно в противоположном направлении. То есть, к технологиям минимум 15-летней давности. Но в маркетинговом плане это, безусловно, выгодно, то есть, выгодно закрывать как можно больше ниш, «удовлетворять» хотелки как можно большего числа заказчиков плана «ларису ивановну хочу» (подставьте любую технологиюнейм во фразу).

Сотрудники, материалы, оборудование, работы, и всё это связано - сотрудник такой-то, при помощи материалов таких-то, сделал работы такие-то.

В OpenERP это было искаропки бесплатно. Наверно, в odoo тоже.

ТЗ это что-то из страны фей и единорогов

Жаль, квотезов нет...

Ох ты ж ё… У меня флешбеки. Я 15 лет назад еще в школе такого говно лепил. В смысле, среду для проектирования тырпрайзных интерфейсов мышкой. Потом участвовал в Glade-Anjuta, потом лепил на делфях подобные системы за деньгу. Я посмотрел туториал retool — я вообще не вижу прогресса за эти 15 лет. Делфи 15 лет назад умел точно так же в процессе разработки показывать данные из табличек, поддерживал кучу разных адаптеров к разным БД. Аналогичные решения были и под VB/C# — не нужно думать, что я здесь делфи рекламирую.

Бизнес даёт то, что пользователи хотят, а не то, что правильно. А пользователи хотят, тут не поспоришь.

http://gambaswiki.org/wiki/app/dbreport

Никогда это не видел, но оно есть

О!

JavaScript и только он.

Да хоть bash, формошлёпать-то чем?

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

По моему опыту ретул многократно проще Делфи. То есть, ты можешь конечно сравнивать терминальный случай, когда есть один пользователь, один UI к одной БД — тут можно провести какие-то параллели. Но добавь многопользовательский режим, авторизацию с аутентификацией, интеграции со сторонними сервисами, web ui — который уже есть и работает. В общем, это ушло намного дальше чем билдер интерфейса, особенно если вникать в детали.

В конечном счете, как и всегда, это трейд-офф.

Бизнес даёт то, что пользователи хотят, а не то, что правильно. А пользователи хотят, тут не поспоришь

Бизнес хочет тупящую кривую поделку, которую сложно разрабатывать и поддерживать? Нет. Меня один мудрый чел еще в детстве научил: для успешного внедрения нужно не приходить к бизнесу с вопросами «что вам нужно», а приходить с готовыми предложениями «вам нужно это, и это, и это». Посмотри на самых успешных мира сего — они приходят с готовыми решениями, которые, если подумать, не подходят НИКОМУ, но они «готовые и проверенные». Если говорить про совсем уж успешных мира сего, то они скорее приходят с готовым брендом, чем с решениями, и вместо индусского «чтота» ты получаешь «чтота™».

Такому упоротому идеалисту, как я, в таких условиях работать неприятно. Давно думал, куда податься, чтобы этого не видеть. Руководить разработкой чего-то подобного самому — дохлый номер. По итогу я свалил в системщину, где занимаюсь не впариванием, а написанием софта для тех, кто будет впаривать.

Дыры она затыкает хорошо, и стоит дешевле чем человеко-год (если дыра большая, то годы), который ты потратишь на разработку вменяемого решения

Пф-ф-ф, разве на доведение того же retool для ваших конкретных задач до удобоваримого состояния ты не потратишь те же годы?

Но добавь многопользовательский режим, авторизацию с аутентификацией, интеграции со сторонними сервисами, web ui — который уже есть и работает

Ну да, retool — это тупо актуализированный под веб делфи.

В общем, это ушло намного дальше чем билдер интерфейса

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

Следующая неявная проблема вообще всех подобных интерфейсов, которая аукнется при увеличении числа пользователей дальше одного-двух — это кэширование и решение конфликтов. В туториале retool показывается жалкая табличка на сотню записей, которая грузится секунды три. По классике жанра это делается через last writer wins, пролюбленные обновления и жалобы пользователей «я тут изменил запись, а оно не сохранилось» — но на этом этапе они обычно уже подсели на иглу и их можно спокойно послать дежурным «мы работаем над этим, оставайтесь, пожалуйста, на связи».

1. Доработать эксель. Он гибкий, там можно много чего накручивать.

2. Таки ничего лучше ms access не придумали.

3. Если не пугает saas, то посмотреть там, вариантов много, тема популярная. Смотри по ключевым словам nocode.

Да, можно ещё лазарус попробовать.

Мне когда нечто подобное понадобилось, я взял posgresql + flask + python и наваял. Но естественно совсем без опыта программирования тут никак

Потом участвовал в Glade-Anjuta

О, вот это самое интересное. Чего удалось добиться, на чём остановился?

retool

О!

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

1. Доработать эксель. Он гибкий, там можно много чего накручивать.
2. Таки ничего лучше ms access не придумали

Да. Да. Я сам до конца не могу пояснить, почему так, но это так. Большинство потребностей малого бизнеса с лихвой закрываются MS Access, который может работать тупо с сетевой шары. Zero configuration != SaaS. Не в последнюю очередь именно пыхорешения привели к поверью, что «либо готовое и на чужих серверах, либо свое и трахаешься с настройкой-деплоем больше, чем с самой разработкой». С Access ты делаешь связанные таблицы даже не зная ничего про JOIN-ы, при этом у тебя таблички работают, и, более того, работают на запись — тот же упомянутый Delphi не умеет изменять содержимое запроса из двух табличек.

К сожалению, когда кастомизация углубляется и нетехнические пользователи начинают совать костыли в БД, то начинается печаль.

К слову, нагуглил большой список полудохлых альтернатив Access-e:
https://news.ycombinator.com/item?id=15246848

Я могу не знать всех деталей и юз-кейзов, но я на «выходе» получаю бэкенд, завёрнутый в докер.

О, вот это самое интересное. Чего удалось добиться, на чём остановился?

Удалось добиться понимания того, что делфопобобные среды программирования мышкой — это путь вникуда. Я потом даже на самом делфи писал текстом интерфейсы. Второе понимание — не нужно писать на сишке высокоуровневую логику. И даже на C++ лучше этого не делать. Так уж они устроены, что по уровням абстракции не масштабируются.

Конкретно мои заслуги перед проектом небольшие — я пофиксил груду багов, которые мешали развивать проект, в частности, делать отдельно стоящие деревья и невизуальные компоненты.

И уже сильно позже мне пришло в голову решение обоих проблем: REPL, где юзерокодер из семантически богатых блоков с рычажками собирает целевую систему, причем, вполне возможно, что рычаги модификации программы никогда не скрываются, аля MS Excel. В каком-то смысле это весьма похоже на Retool и ему подобные, но красивым и удобным оно остается только пока ты движешься по узкому коридору изначально заложенных фич. И то периодически приходится сталкиваться с SQL. А если задача еще сложнее, то привет JS — и вот ты «мышкой» пишешь уже на двух ЯП.

В общих чертах — это что-то в духе dBase, в том смысле , что данные и код едины, только эти код и данные имеют совершенно иной вид, более современный.

Перацкая Visual Studio Pro сгенерирует по БД на MS SQL Server систему классов, и на C# будешь просто объекты создавать, и гонять данные.

А по сути - зависит от задачи и объёма данных. Хоть в Access. Я себе так и сделал, много позже перенёс на C# и PostgreSQL. Для простых вещей C# - не хуже дельфи, и грид весьма функциональный.

На линуксе не особо работает.

Прикинуть можно и на Access, а потом переписать на C# и любом другом SQL Server’e. Почему на C#? Там весьма функциональный grid.

Перацкая Visual Studio Pro сгенерирует по БД на MS SQL Server систему классов, и на C# будешь просто объекты создавать, и гонять данные

Во-первых, тебе таки нужен сервер. Во-вторых, в сложных сценариях ты довольно быстро окажешься в дерьме, поскольку язык C# по устройству своих структур данных далек от многопользовательских данных и методов работы с ними. Да, MS всунула в C# SQL-подобный DSL... как раз когда вся индустрия отходит от SQL. Я не знаю как для вас, а для меня SQL автоматически значит «немасштабируемая БД, ограниченная одним сервером и одним потоком обработки данных». Я когда искал работу недавно, так охренел с того, что в индустрии реально до сих пор никто этого не понимает, и с того, что вакашки по распределенным системам требуют знания оптимизации SQL-запросов.

Но если задача стоит «сделать как-нибудь» — тут, бесспорно, нужноделать на том, что ближе, проще, быстрее.

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

Необходимо дать ему инструмент, при помощи которого он сам, без сурового погружения в языки программирования, сделает себе СУБД с максимально отвечающим его задачам интерфейсом.

Мировая практика подсказывает, что оно так не работает. Либо человек может подпилить под себя и значит он может и код подправить либо не может и значит ему нужен саппорт.

Так то и на том же экселе с вба можно много чего напилить.