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

Сегодня с Хабра принесло такое:
"Универсальный UI, логика на основе простых кодов, автоматические действия, права доступа, логирование, API и куча всего остального 👍
На вашем сервере, легко изучаемая и масштабируемая вместе с ростом бизнеса 🎉
Вместо целой команды проект могут вести 1-2 специалиста ✌️
Минимальные требования к стартовой квалификации специалиста — вы можете научить разрабатывать на Totum вашего сисадмина, тестировщика, продакта, проджекта, инженера, юриста или финансиста. Или научиться сами.
Тотум — это не готовое решение, это набор кубиков, из которых можно собрать абсолютно разные решения под задачу.
Лицензия: MIT (бесплатно)"

https://habr.com/ru/post/666184/
https://ru.totum.online/
(не реклама, ибо опенсорс и бесплатное)

Кто-то тут активно искал "что-то простое, но не как 1С" - вот, экспериментируйте.
Пока 1С пилит свой "Элемент", тут уже люди напилили.
Судя по статьям и роликам выглядит весьма привлекательно.

Внутре у ней ̶н̶е̶о̶н̶к̶а̶  PHP, а снаружЫ - React.

Интересно?

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

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

Опять свой язык изобрели.
Зачем???

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

-"Уровень вложенности для Селект-дерева"
-"Позволяет передать хэш строки добавления во временную таблицу и потом из нее вернуть данные в поле строки добавления используя параметр hash функции set. Или выполнить set в поле строки добавления без вызова временной таблицы. Используется в строке добавления совместно с параметром поля buttonActiveOnInsert." --- это шедевр, Клавдия Ильинична из снабжения сразу начнет код писать, родной язык

(0) напоминает какую-то студенческую поделку.

(4) а что такое хэш ???

(6) хороший вопрос, там есть описание что такое set - " Изменяет значения в полях ", а что такое хэш я сходу не нашел

ну и опять они наступают на теже грабли. Кубики никому не нужны. Нужны готовые решения

(6) простите, вас в яндексе забанили?

(8) зря вы так, кубики, это весело и задорно) Если бы кубики были не нужны, то майкрософт явно бы майнкрафт не купила а вагон денег)

(8) у фузины есть целое ERP бесплатно. но как выяснилось даже готовое решение ну такое.... сырое еще

(9) "вы можете научить разрабатывать на Totum вашего сисадмина, тестировщика, продакта, проджекта, инженера, юриста или финансиста".

Я допускаю, что сисадмин знает, что такое хэш. Хотя не уверен.
Насчет остальных - сильно сомневаюсь.
Тогда вопрос - для кого писалась документация?
Предполагается, что люди будут гуглить каждое третье слово в приложении, кроме предлогов?

(9) тут дело не в яндексе, а в том что в рамках этого проекта это может значить не совсем то что все думают
потому что hash там часто упоминается с явным контекстом что 'все знают что это и где используется'
например вот параметр у ф-ции select, "hash — строка, hash таблицы для обращения к временной таблице."
причем тут хештаблица во временной таблице, да еще и в селекте? кто здесь? что это?

(11) Там ЕРП без планирования и себеса, так, учет операций склада и пары ККМ

(0) Интерфейс унылый, нужно больше скинчиков!

(14) и декларировалось как быстрая хуякивпродакшная среда разработки. типа студенты как два байта переслать

Г1С не осилил

(0) ага, не для программистов.

Да там только программист и разберется.

(16) ну и как оказалось люди стали очень избалованными 1С - поиски хитрые им подавай, красоту формочек и прочие бантики типа красивых отчетов и СКД

(18) я вообще сейчас думаю что для всей этоq ниши типовых 1С вполне достаточно было бы дос-подобного фейса.

Дальше вы работаете с базой через браузер.
Глобально это выглядит так:
Создаете мышкой нужные вам таблицы и поля;
Для некоторых пишете формулы, вычисляющие значения;
Для некоторых полей пишете, что они должны сделать автоматически при наступлении условий;
.
т.е. тотум этот - типа простейших связей по таблицам без фозможности сложной логики взаимодействия, а если надо -0 то лезть внутрь и прогать на всей этой вебомордопомойке

(20) поздравляю. ты придумал платформу 1С8.3 и Конфигуратор

PR вот потыкал мышкой немного и целую пофигурацию тестовую в споре с фузиной выкатил

(21) в (20) это с Тотума
.
видео глянул - ниче так, веселенько.
.
но фузина прикольнее. по подходу.

(22) сорри, думал это "мысли вслух и прямая речь" :)

(12) ето да, тут я с вами полностью согласен.

(12) есть такой анекдот.

Генсек Леонид Ильич Брежнев встречается с западногерманским деятелем Хойзингером. Разговаривают. Хойзингер спрашивает:
- Леонид Ильич, вы согласны с Брандтом?
- А кто такой Брандт?
После окончания разговора референт решил подольститься к Брежневу:
- Ох, Леонид Ильич, а все-таки здорово вы ответили Хойзингеру!
- А кто такой Хойзингер? 8-O

Вот и применительно к этому тексту не сильно замутненный человек может спросить - а кто такой хэш?

(22) кто такая Фузина?

(26) простите, вас в яндексе забанили?

(26) Красивая тайская девушка на вид, но стоит заглянуть за ширму - отпадает желание дальше с ней взаимодействовать)

"вы можете научить разрабатывать на Totum вашего сисадмина," - Кто это "Вы"? Руководитель знания с молоком матери впитывал? Или директор фирмы лично будет обучать сисадмина?

(20) Вы описали Access!

Из их видео: "Математические операции идут по десятичной модели, поэтому с копейками будет всё в порядке, бухгалтерия оценит".
Большое спасибо, что свою систему исчисления не изобрели! :)))

(31) ну так, по привычке 0xFF, а тут приятное бухам

// Пример кода вычисляющего значение

= : listSum(list: $list) + #fixed_costs

list: selectList(table: 'orders'; field: 'cost'; where: 'number' = $listNumbers)

listNumbers: selectList(table: 'orders'; field: 'number'; where: 'date' >= #first_day_months; where: 'orderStatus' = #final_status)

точно для недопрограммистов?

(33) Любой поймет. Только 1Сники испорчены русскими буквами :)

(34) а отладчик есть? как баба Маня поймет, где накосячила с русской букой с?

Люди пишущие на ПХП, освоили жс и реакт уже герои. Лично я неосилил жс, посмотрел на знак равно "мамой клянусь" выглядит так "===" и понял что не смогу писать на этом языке. Про пых с ихним ? $  я вообще молчу, не знаю, почему то меня очень раздражают какие то бесполезные надписи в коде.

(28) В основном из-за сутенеров, которые под видом совершеннолетней девочки подсовывают несовершеннолетнего мальчика загримированного...

(35) шрифт нормальный поставь (то ли ТормозИТ сделал то ли еще ктото - у меня стоит, видно! - автоматизация наше всё!)

(36) динамическая типизация она такая)

(36) а мне $ в Perl когда я на нем малость прогал - зашел! прикольно!

Программа для проектирования новой системы

Я бы эту тему объединил с моей предыдущей. Спасибо Asmody, интересуюсь такими "убийцами" 1С.

(41) тут даже круче, она и цену может рассчитывать) магия)

"Больше всего за это время мы потратили на учебные материалы — это реально так"

"если вам вдруг выпал warning, так-как есть миллион комбинаций использования, мы проверили не все 100% просто потому, что пользователи выдумывают такие, про которые мы не догадывались;"

"не успела марьиванна слезть с трибуны, как на неё взобрался председатель"

(0) В чем отличие от Excel?

90% процентов пользователей в екселе максимум формулы на пару действий пишут и то мышкой. то есть тыкнуть по ячейке нажать равно и дальше тыкать по ячейкам нажимать нужное математическое действие им еще как то по силам. а написать с клавы = B1*C1 это уже высшая математика. а вы от них = : listSum(list: $list) + #fixed_costs
хотите. не взлетит

(45) логирование, апи, удалённый доступ
Как бы вроде написано что мол для тех коме ексель мало и хочется приключений на вторые 90

(0)
Для "не программистов" в своё время 7.7 выкатилась. Имеем что имеем.

Ребята еще и политически ненадежные https://wampi.ru/image/RZYZniZ

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

Тройное равно? Долларовые переменные? -это зачем такое?
Понимаю, двойное равно - указывает на сравнение, а не присвоение - это, прям, должно быть так. Тройное?... что может означать?

(51) см (36)

ну так что? когда уже Тотум станет нашим Тотемом?

(51) а как же тождественно равно

Я - за Фузину! Может я неправильно понял, но идея "пишу цикл - получаю единый запрос" - мне нравится! Вот, только, понять не могу, как такому смогли придумать реализацию. Сильно не погружался, но идея эта преследует уже десяток лет

Ой, не... с универа ещё - добрых 20 лет!

Интерфейс похож на Элемент. Учитывая что тут команда какихто альтруистов писала, а Элемент корпорация со штатом размеров в ПГТ, то очень круто!
Но вряд ли жизнеспособно. Безумству храбрых мы слагаем дифирамбы!

(0)  нормально . Таблица и формы при ней . Все в веб .  Постгри бесплатный с боку . Норм.

Очередной Access

надо будет пощелкать

(59)   акцесс на посгтри ?

(61) так-то Access может крутиться на MS SQL Server

(51) одно равно - это присвоить, два равно -это "ну типа как равно", а три равно - это "чисто конкретно равно, зуб даю в натуре"

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

Проблема современных реляционных БД в том, что нужно формализовывать таблицы.
Вот в 1С есть Контрагенты, Партнеры, ДоговорыКонтрагентов но СоглашенияПокупателей и СоглашенияПоставщиков.

В интуитивно понятной БД (нереляционной) не должно быть НСИ, как таковых (я об этом слушал на недавнем выступлении на инфостарте).

Т.е. да, Аксесс не нужен. В 2022 не нужен.

(65) "не должно быть НСИ,"
- правда, втсает проблема агрегации данных. Как, в отсутствии НСИ, собрать данные по ООО "Шмитцельхугендархентрах"
если продаж на этот "Шмиц..." N раз, и в каждой продаже этот "Щильц..." назван по разному...
?

(67) там (в Росатоме) используют домены. Информационные домены вместо НСИ. Проблем собрать нет

(68)
1. Один хрен как это назвать
2. Каждый раз собирая - зачем каждый раз собирать, если можно собрать один раз, а потом пользовать?
.
Варианты разные могут быть.
НСИ м.б. "не нужна" если формализовать затруднительно,
если достаточно легко формализовать - почему бы не юзать НСИ..?
.
или я что-то не так понимаю?

(65) "не должно быть НСИ" - ты всё не так понял.

(65) >>В интуитивно понятной БД (нереляционной) не должно быть НСИ, как таковых

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

(68) Учитесь, юноша, зарабатывать деньги на простом переименовании одного в другое. А вы все кодите, кодите... только мозги сушите

(71) Не надо представлять. Это уже реализовано.
Вот тебе коммерческое решение даже: https://nfp2b.ru/services/pmk-granat/

Вот тут можешь про МДМ и Домены почитать, окультуриться: https://habr.com/ru/post/324148/

(69) да, ты мыслишь еще реляционными базами данных. Они, конечно, эффективны в плане производительности, но не очень эффективны в плане формализаци. банальный пример - соглашения поставщиков и покупателей в 1С это разные таблицы, потому что состав полей немного разный. Ну и т.п. Архитектору приходится как-то формализировать сущености, вместо того, чтобы об этом не париться особо.

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

(72) нет, юноша, паразитирование - это не мой жизненный стиль. Я слишком ценю себя, чтобы жить глистом

(73) нереляционные данные имеют смысл когда каждый договор  имеет свой набор полей.
А когда есть четкие виды (поствщики, покупатели и тд) тог смысла нет

(76) например характеристики номенклатуры плохо в реляционные таблицы ложится

Базу можно представить как набор обънктов и связей между ними,тогда,как каковой отдельной НСИ нету - все идет в кучу.
Получается,что вместо НСИ описание объектов и оно тоже объекты.
И очень много интересных ситуаций с циклическими связями и т.п.

(76) сегодня - поставщик, завтра - покупатель, послезавтра - учредитель. Какая разница? Деньги одни и те же

(79) речь про договоры была

(76) не скажи, одна таблица Контрагенты или две customer, vendors. даже на этом банальном примере понятно, что формализация - всегда кастрация.
(78) да, это уже ближе. Тогда один объект может иметь свойства нескольких типов объектов.
(79) А в табличке у тебя Покупатели и Поставщики, придется дублировать. Вот тебе и "кака разница"

(80) а почему договоры контрагентов одна таблица, но соглашения покупателей и соглашения поставщиков две? ггг. Вот в чем слабость устаревающей реляционной модели.

Я так понимаю, понятие ссылки остается. но сылка может представлять объект нескольких типов.

Например, ссылка на соглашение, как базовый тип (интерфейс), но может быть детализирована как ссылка на соглашение с поставщиком или покупателем.

ну это по мотивам ООП, которое я в универе учил 20 лет назад

(73) ещё разок: "ссылки на НСИ всё равно будут в БД". И никуда ты от этого не денешься

(76) не-а. Нереляционные данные и в других случаях имеют смысл, даже если структура у объектов повторяется. Допустим, ты делаешь интернет-магазин. Товары, их атрибуты, фотографии, отзывы, рейтинги, чаты... В реляционке тебе придётся сделать туеву хучу плоских таблиц, связанных друг с другом. В Firebase или MongoDB ты можешь сразу хранить всё в JSONах удобной структуры. При открытии страниц интернет-магазина просто считывается готовый JSON. И не нужно писать никаких монстроузных запросов, данные сразу хранятся в удобном виде. Да, мир не крутится вокруг реляционки

вот если открыть маркетплейсы - там как разв ообще трэш и угар. Никакого нормального НСИ нет. Потому что все эти витрины на МП - по сути большая куча, где позиционирвоание на нужное чтото можно только поиском сделать. причем поиск по всему идет. Пишешь "шапка-балаклава" - в карточке товара у разных продавцов на МП это миожет быть где угодно - начиная от наименования и заказнчивая характеристиками или цветом. И, в принципе, все норм. для нетребовательных покупателей покатит.
.
но если открыть какой-то фид - можно видеть, как представлена инфа, которая рожалась изначально без архитектуры, кучей.
и куда ни прыгай - все равно всплывает ссылка/идентификатор оффер_ид, chain_id, fbsskuid, fdoskuid и прочее. до 4-х идентификаторов для поддержки связей на один товар. ИТипа нормально. Нахер все реляционные базы.
.
а фид от WB - вообще шедевр...
.
могу ошибаться

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

(0) 1С то же начиналась с существенно элементарных версий, типа шестой, и возможно тех что до нее были. А потом куда-то ее не туда понесло. Или туда наоборот, куда нужно. В общем, начинают все с простых вещей, а заканчивают как всегда.

+ там уже даже планируют более сложную версию - PRO, типа коммерческая, будет в конце 2022.

(87) так это было в 90-х, когда примитив вроде FoxPro был на марше. Сейчас другие времена, другая притязательность в автоматизации

(85) А ты видел нормальные витрины на рынках?

(83) ссылки будут, но таблиц не будет.

(89) вот не надо грязи! FoxPro был полноценной РСУБД и RAD-системой

(84) А в случае изменения структуры нужно перемалывать всю БД и конвертировать JSON?

(93) а зачем структура должна измениться?

На данный момент есть две лучшие "база данных для непрограммистов"
Это Эксель и 1С.

(95)+ Следующая "лучшая" будет объектной (по типу CouchDB на основе JSON но проще) а не табличной

(95) А как же теплый ламповый Access?

(97) Слишком сложен и ограничен
И требует уже программиста

(98) sql - общепринято считается ЯП

На данный момент на практике непрограммисты используют эксель и универсальные отчеты 1С

(92) так я и пишу про то что был. В 90-х и начинающий гугл катал всякий примитив по современным меркам. Времена-то меняются

(95) не смеши мои тапки, в Экселе до сих пор нет функционала добавления "новой строки"

...как ни добавляешь - всё старую строку получаешь?

(0) показал двум непрограммистам на работе

они не понял что я от них хочу ))0

к этому Тотуму чтобы его "дома" попробовать надо еще кучу обвески поставить.
нежизненно без погромиста

(94) Ничто не вечно в этом мире, учет тем более. Решили добавить/изменить новые данные для номенклатуры или контрагента или вы всегда на 100 лет вперед все предусматриваете?

и как выборку по таким данным - где все лежит в куче - делать?
выбрать все реализации где контрагент = Вася Пупкин и номенклатура.характеристика = хрень?
тянуть из нереляционной базы везде где упоминается васяпупкин (полнотекстовым поиском?), потом фильтровать то, где это ненужные документы итд..?
.
Сколько такой движок для рядовой лавочной конторы в 15 человек персонала будет стоить? или все бесплатно?

конечно, было бы охеренно заманчиво не кучевряжиться со схемами данных, а надо тебе дополнительную колонку в документ для вот этого клиента - херак всунул, записал и все... захотел документ отметить "флажком" - херак навесил/отметил. Главное чтобы потом другой юзер знал что такой флажок есть... и данные по ниуе отбирал... а не как поисковая машина - ты ей запрос, она тебе 99% говна...

И почему если неряляционные базы - такая няшность - не юзаются в учетных системах?

(109) Виной кризис IT, информатика как наука в спячке. Коммерция сама по себе не может делать развитие.

(109) используются.
Например, SAP HANA имеет смешанную архитектуру: реляционную и колоночную одновременно,
ClickHouse - колоночная, Caché - объектная. Как говорится, "зависит от".
1С вон тоже что-то эдакое пилит под названием "дата-акселератор".

(106) вы решили добавить поле для  _новых_ контрагентов или для всех собранных за десятки лет тоже?

(111) 1С лучше бы типовые пилил.

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

(112) Древовидная БД. Как Каше?

Вообще Каше на востоке нашей страны популярна была. Сейчас не знаю. По производительности на больших БД тягалась с Ораклом. Объекты хранятся там где и используются. Министерство здравоохранения США на этой БД реализовано было. Сейчас, скорее всего на ней же.

Представьте, что у вас есть задача вести расчеты населения, пусть за электричество (льготы, квоты) по всей Москве в одной базе на 1С.
1С потянет 3-5 миллионов абонентов? Для Каше это мелочи. И будет всё летать.

(112) Поле необходимо добавлять по мере внесения данных. Если данные не вносят, то чего лезть в старые элементы справочника, а на языке Каше это наверное будет называться экземпляры объекта или узел дерева.

(117) на самом деле,основное преимущество key-value database в том,что ее легко разделить на части,в отличие от базы sql,которую,конечно,можно разнести по дискам,но скорости это не добавит.

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

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

Ну и,если мы говорим про sql,то просто сказав,что все индексы,кроме первичного ключа - это отдельные объекты,мы спокойно базу sql превращаем в key-value.
И обратное тоже просто.

Сюда же до кучи (ранit было уже и вот опять)
https://ideav.online/ru/#rec168819550 - ИНТЕГРАЛ...

(118)  почемуже это не добавит в sql?

(93) зачем перемалывать всю БД? Это тебе не реляционка, в одной "таблице" могут храниться JSON разного формата. Это абсолютно нормально и естественно. Как таковой структуры хранения и нет. Но если сильно хочется, можно пройтись и пропатчить старые документы

(106) ты мыслишь категориями реляиционки, где нужно делать реструктуризацию таблицы при изменении структуры. В NoSQL с этим проще
https://www.youtube.com/watch?v=5uiBQy3RveY

(0) анекдот про "сто Х тебе в панамку, сиди и складывай" уже был?

(122) И тебе нужно будет самому проверять в коде все соответствия полей 100500 форматов которые хранятся в базе.
Получается это одна большая мусорная куча. Можно и в SQL базе сделать одну таблицу и туда все пихать, поиск только по ID.

(124) нет, задвинь!

(125) нет, не получается. С чего ты взял?

я даже больше скажу, для целого ряда задач та же MongoDB рвёт традиционную реляционку по простоте и удобству. Связи данных становятся понятными и очевидными, а кодовая база для работы с данными значительно уменьшается. А в популярные РСУБД (Oracle, MS SQL Server, PostgreSQL) уже давно завезли механизмы из нереляционных СУБД. Например, в них можно хранить данные в виде документов JSON или XML

(128) Приведи пример плиз.

(129) уже приводил в (84)

(128) так и раньше можно было :) кидаешь в мемо или блоб XML и хранишь...

(130) Ну судя по описанию у тебя там будет туева хуча объектов также связанных между собой и не всегда там будет готовый json.

(132) нет, не будет.

Реляцинка: данные хранятся во множестве таблиц. По запросу с фронта ты делаешь 100500 select к этим таблицам, из выборок долго и нудно собираешь json

MongoDB: данные сразу хранятся в виде готового json. Тебе остается лишь вернуть их фронту

Чувствуешь разницу?

(133) а как выбрать эти готовые джсоны...? по условию на какой-нибудь "реквизит-значение" из этих джсонов?

100500 постов по теории баз данных!
Кто-нибудь (0) живьем-то хоть посмотрел?
Я - нет

(134) простейший запрос по id вернет json. В (123) всё наглядно показано

(136) а мне не нужен запрос по ИД к документу
мне нужна выборка "получить список документов Реализация где Контрагент = (ссылка)РогаиКопыт и СпособДоставки = самовывоз."
в нерялиционных как такой список документов будет из базы выбираться?

(135) я потыкал малость. чисто как юзер. есть что-то зудяще-раздражающее во всех этих вебфейсах...

(137) проверить на равенство как раз проблем нет. бубны возникают со сложными условиями, типа: которые красненькие или синенькие или ростом отсюда и до обеда

(137) Да все также. Отличие MongoDB от того, к чему ты привык всего лишь в отсутствии метаданных

(137) Справедливости ради, там вроде это есть, если смотреть следующее видео из (0), то там об этом рассказывает.
(133) Получается что у тебя карточка товара будет формироваться из jsonа который выдает база, там и данные товара и характеристики и изображения все о одном JSONе?

(140) При поиске он же все равно ведет поиск по каким то индексам, так? Он же не будет шерстить всю базу на вхождение строки.

(141) >>карточка товара будет формироваться из jsonа который выдает база, там и данные товара и характеристики и изображения все о одном JSONе?

Да. Всё будет лежать в одном древовидном толстом json'е. Это удобно

(142) есть индексы. Можно проиндексировать какую-то ветку внутри json и поиск по ней отработает быстро

на первый взгляд весьма не дурно. но они опять со своим для не программистов не понимают самого главного: для не программистов нужно делать функционал (базовый хотя бы) из коробки

(142) По индексам. В чем вопрос?

(143) А если нужно список из номенклатуры построить, без учета всех характеристик и изображений, он будет грузить весь json и закодированным изображением и потом вырезать из него нужные данные?
(145) И можно самому настраивать индексы?

(146) [И можно самому настраивать индексы?] - в общем случае ответ "зависит от". Этих nosql сейчас как грязи, там уже свою классификацию можно вводить. Если брать монгу, как де-факто "пром.стандарт", то да, можно.
А в какой-нибудь простенькой memcachedb индексов нет - она сама себе hash-table

(143) <Да. Всё будет лежать в одном древовидном толстом json'е. Это удобно >
==чуть чаем не поперхнулся==

сгенери себе json размером 300 мегабайт, а потом попробуй в 10 потоков его читать и парсить.
Я уже такое проходил, в итоге все свелось к sqlite

(148) ну оно ж там внутре не в текстовом файле хранится. оно тоже умеет всякие гитики со постраничным чтением и всё такое

(149) это всё от объемов зависит и от типов запросов
всё это весело и задорно пока запросы по 10-20 обхектов, а как только тысячами и сотнями тысяч пойдёт, будет весело.
...когда запросы по 20 минут выполняются и всякое такое...я когда в мейле работал была задачка по выдергиванию меты из json-ов в обычные поля БД чтобы оно работало а не тупо проц жрало часами на десериализацию json полей

(150) У eBay запросы по 10-20 объектов? Ну да, ну да...

(146) можно указывать конкретные атрибуты

(150) а зачем делать json на 300 Мб? Ты не понял, это не файл, в котором json это единый гигантский json. Считай что одна запись БД это отдельный json, и ничего парсить не надо

(152) а как из этой записи-джсон вытащить какой-нибудь "реквизит" для отбора джоснов удовлетворяющих фильтру по этому реквизиту? джсон в таких нереляционных базах как хранится? тупо как "запись-джсон = строка"? или в виде деревьев и ключей-значений..?

(153) https://www.mongodb.com/docs/manual/tutorial/query-embedded-documents/#query-on-nested-field

У меня, кстати, сайт монги без VPN не открывается. Тоже ссучились, гады

Постгрес тоже умеет JSON https://www.postgresql.org/docs/14/functions-json.html

На самом деле,получение записи таблицы из страницы базы чем-то похоже на парсинг json,только это делается на сервере,а json можно не парсить,а тупо отдать на клиента.
Опять же,по ключпм индексы,ну и,при желании,json можно поделить на части.
Тут опять нужно понимать,что пользователям более удобен полнотекстовый поиск и поиск по взождению,а он очень плохо индексируется.

(150) Вам там выше Злопчинский давал ссылку на сервис, где больше полумиллиарда записей в таком режиме живет и всё это довольно шустро работает:
https://youtube.com/watch?v=l0eg2xuC9Ks
Вроде как кроме этого сервиса ТЗ зарубы 1С vc Еёйный киллер никто не реализовал.

Оказалось таки по сути платное. В рекламном ролике в конце на 04:00 сообщается https://youtu.be/OwILcen7WtY?t=240 что в платной версии будет
- поиск (!!!)
- динамические таблицы (видимо динамические списки)
Так что опен сорс только для рекламной версии.

Нашел первый косяк https://i.imgur.com/1JdmmM2.png
В принципе в бесплатной версии достаточно возможностей, чтобы вести небольшую базу.
Фильтры достаточно удобны. Так что платный поиск (видимо имеется ввиду полнотекстовый) не особо нужен.
Ну и постраничный вывод таблиц вместо динамического для небольшой базы наверное можно пережить.

Это моя демобаза
Логин: admin
Пароль: 500559
Страница входа: https://n-d696e94-49661.demoru.totum.online/Auth/Login/

Ширину колонок нельзя изменять перетаскиванием - показалось довольно неудобно.

Еще показалось неудобно множественное выделение строк только диапазоном (с SHIFT), а по одной (с CTRL) не работает.
Зато есть универсальная пометка строк в крайней левой колонке, но такие строки не подсвечиваются, поэтому в широких таблицах сложно понимать какие строки помечены при просмотре правых колонок.
Выделенный диапазон строк не нашел как сделать помеченными. https://i.imgur.com/FKcD7W0.png

Почему то нельзя менять размеры блокирующих отдельных окон. А некоторые такие окна высоту съедают с больших перерасходом.
https://i.imgur.com/fM4kYlC.png

Диапазоны выделения ячеек (с зажатым SHIFT) можно объединять по вертикали и горизонтали
https://i.imgur.com/jcr3ulQ.png
Не понял зачем такое нужно

Пометки строк при переключении страниц не сохраняются. Кажется не так уж сложно было бы их хранить на клиенте.

(162) " поэтому в широких таблицах сложно понимать какие строки помечены при просмотре правых колонок."
- и хрен это сделают...

Текущую строку списка клавишами курсора хрен подвигаешь

(166) А разве самому нельзя морду поправить? Она ж на реакте, должно быть можно добавлять свои фишки в шаблон или хуками поверх него, не?

(168) В списке полей данных, доступных в условии условного оформления нет поля "Пометка".
https://i.imgur.com/yrn9Ypf.png

(168) если погромист - наверное можно. если девелопер - ну его нахрен

Какой смысл сейчас в еще одной бд, не от крупного игрока?

(160) неплохо. Но думаю, что будущее не за реляционными БД

(172) Так здесь не за будущее, а за настоящее =)

(172) с чего это вдруг?
будущее - каждой задаче свой тип БД

пока что например то же самое демо ТормозИТ по интерфейсу выглядит, извините, "ублюдочно" (надеюсь понятно что это претензию не к тормозИТ). "для дома, для семьи" - норм, для продакшена в своей конторе - норм. для тиражного решения - я сразу скажу - нафиг такое тиражное решение...
.
на этот Тотуме я может быть сделал бы маленкую инфу ситсему для себя "складовку". что где дома есть/лежит. например, у жены целяа коллекция сумок, туфель и шляпок - уже надо каталог составлять, чтобы "посмотрел и все понятно."
.
в Тотуме штатно есть объект для харнения фото и загрузки фото в базу?

(175) а что готовых программ каталогизаторов нет?

(172) Ой какой вы такой умный. А за какими БД будущее?

(176) например, растяни баян

(177) Postgres выбился в лидеры по тренду.
Скоро они перестанут хранить данные в таблице при использовании покрывающих индексов, и тогда у них совсем всё пойдёт в гору.
Предыдущий их прорыв был как раз связан с JSON и его индексированием. Следующий - убьёт всю инициативу конкурентов, как сделала в своё время IBM с этим вашим IBM-PC-совместимым компьютером.

(176) Туева хуча
Можно за вечер сделать: https://ideav.pro/download/shara/Inventory_1.0.pdf

(179) "Предыдущий их прорыв был как раз связан с JSON и его индексированием"
А в чем прорыв то? В любой реляционной БД можно хранить JSON

(181) Индексировать нельзя, бро

(182) А кто запрещает? Конвенция какая то?

(183) Никто не запрещает, но эти перцы позволили искать по индексированному ключу JSON, в то время как другие реляционные олдскул-конкуренты это не давали делать.

(184) Это типа как XML индексы в MS SQL чтоли?

(0) Внутре у ней ̶н̶е̶о̶н̶к̶а̶  PHP, а снаружЫ - React.
Внутри у ней птичий язык (автор называет это Totum-код), ограниченный возможностями этого конструктора.
Плюс вот это:
"коды пишутся в специальных окнах в настройках поля"

Еще в лохматовосьмидесятые во всяких xbase можно было в индекс чего угодно запихать. Был бы тогда JSON и его бы индексировали. Какой же это прорыв.

Прорыв это когда реляционные БД изобрели. Вот это прорыв. Или когда Btree придумали.

(187) Осмелюсь предположить, вы не понимаете, это другое.
Не индекс по значению, а индекс по значению поля, коий был распознан в структуре типа json, хранимой в поле типа json.

(188) Это первая половина прошлого века, не позже. Да, мегамОзги уже тогда просекли фишку.

(189) Ну и я об том же.

Ну а в обычной БД просто добавить в таблицу поле, в котором вся запись хранится в виде JSON. Места будет занимать больше, но и гемора меньше. И проиндексировано, что нужно и хошь JSON отдавай, хошь так.

(192) а джсоны в такой базе как храняться? тупо как строка? или как-то иначе?

(175) Картинки можно делать полем типа "файл", но на демо сервере загрузка файлов заблокирована.
Вот как это выглядит https://github.com/totumonline/totum-ru-issues-and-discussions/discussions/194#discussioncomment-3390755

(193) ясен пень строка. если не строка, то это и не JSON

(195) допустим, в джонсах хранится документы. в документе в шапке клиент, и в строках клиенты. Причем в одном Документе Иванов может быть в шапке, а в другом документе Иванов - в ТЧ. И надо из базы вытащить документы где Иванов в ТЧ. и что: будут тащиться джосоны где упоминается Иванов, потом парсятся и отсеиваются те, где иванов в шапке. Как вообще выборки по условиям работают в нереляционных базах? никогда не сталкивался, интересно.

(196) Понятия не имею как они работают. Для систем, типа 1с, есть реляционные БД. А всякие прочие БД используют для всякого прочего.

(196) получаешь данные и кодом проверяешь подходят или нет
map-reduce

(198) а данные получают по принципц поисковой машины - кучу шлака, в котором уже кодом надо найти? распарсить, вытащить нужный ключ-значение..?

(199) либо поиск по индексу либо все.
В обычных базах, если индекса нет, то тоже все записи просматриваешь

(196) https://postgrespro.ru/docs/postgrespro/9.5/datatype-json#json-indexing

(108) Ты прям конструктор Интеграл описал - там ровно так, плюс ещё ВСЕ данные проиндексированы.
Вот, полюбуйся на стенд - миллионы записей о 60+ колонках в таблице
https://ideav.pro/sber

При этом можно добавлять колонки на лету и фильтровать по любому полю за десятки миллисекунд:
(пример фильтра по полю Code из 7 млн записей)
https://ideav.pro/sber/object/282/?F_286=111111

И про индексы пользователь вообще не парится - он и не знает о них.

(200) По индексу чего? Индекс для строки, в которой лежит весь джсон?

(203) разные индексы бывают. Собственно индекс - это примерно как выделенная колонка

Те твоя база - это
Ключ- жсон - значение1 - значение2 - ...

(204) ты о том, что джсон парсится, по полям строятся индексы? и потом в запросе по этим индексам, вытаскивается нужный джсон?

(206) типа того

(207) хм.. то есть по сути джсон раскладывается на многоколоночную таблицу или много таблиц.
и в чем здесь преимущество перед реляционками?

(208) все поля не раскладываются, только нужные. Сколько у тебя индексов в обычной таблице?

(209) немного

Все убийцы 1С и NoSQL я не использовал, поэтому догадываюсь чисто из прочитанного. Судя по всему для бизнеса гораздо проще хранить данные (например по номенклатуре) в нестрогом JSON, который также содержит все поля, который легко расширить (новыми характеристиками) и быстро загрузить в Web, чем содержать уйму специалистов 1С, которые будут решать вопросы с блокировками, соединениями 1000 таблиц, реструктуризациями и т.п. А вопросы быстрого поиска они видимо решают такими же индексами, только их альтернативной реализацией. Не так уж важно для них иметь возможность отбора по любому их полей, как иметь возможность быстрой работы оперативной базы и гибкость разработки.

(211) Точно. И положить большой Х на транзакции и целостность данных)

Идея интересная, на деле какая-то фигня. Где демка то?
Как код выглядит? А все, нашел... Лучше б не находил, лсфьюжн привет

Реакт - круто, но почему на бэке пыха?
Фронт дорабатывать можно? Чтобы прям в реакте

Демку еще никто не развернул? Я бы потыкался

(212) Демка в (160)

(213) От души.

Короче, очередной скуль на стероидах.

Фронт тормозит, хотя обещали реакт - никуда не годится.