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

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

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

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

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

Интересно?

(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) От души.

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

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