Надо сделать базу данных для хранилища биологических образцов. Грубо говоря - попросту таблица, в которую заносится штрих-код пробирки, дата, автор, название образца и прочие его характеристики. И чтобы можно было по всем этим полям искать. И чтобы несколько человек могли одновременно с разных компьютеров (в одной сети) с этим делом работать. Совсем хорошо было бы, ежели бы дата и автор проставлялись при редактировании автоматически, дабы можно было отследить, кто и когда что делал. А ежели бы сохранялась история редактирования, как в вики - это было бы и вовсе превосходно. Ну и желательно, чтобы оно само бекапилось при каждом вводе или каждые несколько минут (хотя это можно и отдельно организовать). На клиентских машинах винда, сервер на убунте.
Попытался поискать готовые программы для этого дела - их миллионы, причём почти все облачные (а значит, надо делиться информацией с добрым дядей плюс непонятно как бекапить), и к тому же стоят настолько неприличных денег, что цену даже стесняются рисовать на сайте. И функционал у каждой программы свой и необъятный, так что пытаться выбрать между ними чревато уподоблением буриданову ослу.
Вот я и подумал - а нельзя ли это как-то попроще сделать? Попробовал завести многопользовательское редактирование в libreoffice calc - не получилось, так и не понял отчего. Эксель вроде как требует лицензии на офис 365, каковой у нас нет. Я так подозреваю, что это можно сделать в libreoffice base/microsoft access, но я их только на картинках видел.
Посему вопрос. Как можно сделать вышеописанное малой кровью? Base/access (если да, то просьба кинуть в меня толковое руководство для чайников)? Или есть какой-то серверный софт для совместного редактирования таблиц? Быть может, складской софт? Или, быть может, кто-то знает специализированный софт под эту задачу? Желательно free software или хотя бы не очень дорогой.
roswell, и какие же там ужасные требования?
Авторизация, которых - жопой жуй готовых?
Хранение в той табличке каждой редакции записи, с айдишником автора и таймштампом?
Или бэкап, который на Убунте без проблем делается одним скриптом в кроне?
Впрочем, частично соглашусь: если задачу будет решать Константин Нагибович и натащит в нее продуктов 1С - это будет очень дорого. Причем не только в начале, но и в дальнейшем рабстве.
Либо гуглотаблицы, либо какое-нибудь решение для 1С, либо что-то своё запилить, но это однозначно на старте будет дороже (примерно раз в 100 дороже, чем пара лицензий для одной лаборатории)
Например: 1С:Медицина. Клиническая лаборатория
А MS Access и Libreoffice base не являются многопользовательскими базами.
Кстати, да, не обратил внимание, что ТС нужно многопользовательское. Ну тогда либо самому костылить на мускле, либо купить готовое решение. 1C неплохой вариант.
libreoffice base конечно же (в винде делается ессно на access). Качается книжка для чайников, читается, и лабается. Как-то мне понадоиблось, я (вообще нуль в access) через пару часов уже что-то лабал.
Движков-то БД-шных - тыщи, но это же самому писать.
Вики-движок DokuWiki с плагинами Struct (либо же аналоги: Data, Strata) и Bureaucracy (для создания формы быстрого ввода информации и создания страницы).
Одна пробирка — одна страница в вики. (убиццаапстену)
Если задача стоит именно так, как изложена в вопросе - под нее на хрен не нужны готовые комбайны, а Офисы и их злокачественные опухоли типа Акцесса создадут больше проблем, чем решат. Не говоря уже о монстрах от 1С.
LEMP на Убунте.
Бэк на Ларавеле, например, чтобы не изобретать велосипеды насчет авторизации.
Фронт - хоть на голом JS, хоть на модном Vue.
За дизайн сойдет бутстрап, благо тут работать, а не продавать.
Одна страничка, где юзер вводит данные, вторая страничка, которая готовые данные показывает.
История обеспечивается тем, что записи в таблице не переписываются, а добавляются, если данные изменились.
И все...
К сожалению, я не веб-программист (был бы им - быть может, и вопроса бы не возникло). А искать стороннего веб-программиста - тоже отдельное искусство, мне не подвластное, плюс это наверняка долго и дорого.
> Офисы и их злокачественные опухоли типа Акцесса создадут больше проблем, чем решат
wormball, веб-программистов тут - квантум сатис, искать не требуется. Вот меня вы нашли, легче стало?
В вашем случае вполне возможно "долго", но не по той причине, о которой вы думаете. Вы сами не сможете быстро превратить ваши хотелки в нормальное техзадание. А исполняется-то оно довольно быстро (и если действительно похоже на изложенное вами в вопросе - отнюдь не дорого).
С офисами... ну, вот "архитектура, при которой первый же голубь может снести здание" - это как раз про работу с данными в офисах. Такой же удачный инструмент.
Расширю до полноты этот ответ. Воспользуйтесь low-code решением. Существуют универсальные СУБД с симпатичными мордами и скромными ценами на потребление, а то и вообще можно в локальной сети поднять за зеро. Я обычно предлагаю клиентам для эффективного использования https://demo.rowy.io Ну, а для локального - https://www.nocodb.com, не так круто как первое, но имеет много типов данных и работает даже с утюгом в многопользовательском режиме.
Alexander Ivanov, на первый взгляд эти "решения" имеют все недостатки упомянутой мной "архитектуры", свойственной с работой с данными в офисах. Только сложнее для конечного пользователя и администратора.
Не совсем ответ. Slava Rozhnev = Google Sheets
Самый простой, но чтобы "дата и автор проставлялись при редактировании автоматически" - это сложнее CityCat4 = libreoffice base и Василий Банников = А MS Access и Libreoffice base не являются многопользовательскими базами.
Далее извращение:
Надо поднять сервер баз данных. На MS Access создаем базу с подключением к ядру базы данных (mssql, mysql, postgresql) через драйвера ODBC или DDE - Есть такая опция в Access. Таблиц в файле Access не будет, будут ссылки на таблицы. Если всем Access ставить = дорого. Открывать Access файл через libreoffice = глючно. И чтобы "дата и автор проставлялись при редактировании автоматически" опять надо что то придумывать.
НО 15 лет назад так работало )))
Правда, уже тогда было бездарным решением родом из прошлого века.
Не согласен. ))) Для начала 2000х решение было нормальным.
Joomla 1.7 появилась насколько я помню в 2007.
2001-2003 nginx только появился.
И интернет был модемным )))
Александр, а при чем тут Джумла?
SQLite, например, в начале 2000-х уже был.
Да даже ФоксПро тогда был более оправдан для таких задач, чем Акцесс.
Как вспомнишь, сколько боли было в "нулевых" - чтобы завести работу с акцессовскими "базами" из какого-нибудь нормального языка, а потом в "десятых" - вытянуть из этого кадавра данные в приличный SQL, когда стало окончательно понятно, что так больше нельзя...
