Какие есть примеры построения большой организационной структуры?
Ищу пример построения и разбора приложения для описания организационной структуры предприятия, в котором есть более 1 миллиарда объектов (отделы, должности, работники, рабочие места, оборудование и т.д.). Т.е. по сути это гигантский граф, где каждый объект (сотни разных типов объектов) может быть связан с множеством других объектов на основании каких-то правил.
Интересует как хранить такие данные. Скорее всего не в двух таблицах "объекты" и "связи". Судя по всему даже 1 миллиард объектов в таблице "объекты" уже убьет производительность, не говоря уже о таблице "связи", где будет 100 миллиардов строк.
Ох и амбиции. И что за перфекционизм в отношении Postgresql?
Не знаю как автор посчитал миллиард. Это если все население планеты Земля составляет порядка 8 млрд.
И что мы возьмем целую страну и инвентаризируем ее чтоб получить такое число?
Для графовых БД существует не Postgresql а специальные БД типа Neo4j. Но еще до того как ты доберешся
до графовых БД - задание может многократно измениться и выйдет что граф - рудимент. Так часто бывало.
Вообще очень малое число задач требуют именно графов. Если табличка отражает семантику модели
то можно и ее использовать. Только с условием не решать в ней задачи о рукопожатиях.
По поводу того что в таблице что-то там кого-то убивает на 1 млрд. Я отвечу так что если вы строите OLTP
систему то в ней этот миллиард никогда не будет использоваться целиком. Там будут горячие области.
Их можно каким-то образом кешировать или алгоритмически пред-выбирать. Или брать key-value системы если ТЗ позволяет. Для них что миллиард что триллион все безразлично. Не забывайте только поднимать новые ноды и подкидывать диски в облачко. Или если речь идет
о BigData к примеру то там есть свой техно-стек. Например Apache Spark / GraphX. Хотя я с модулем GraphX
не работал ни разу. Но биг-дата запросы обычно никогда не запрашивают одного физ-лица или одну
единицу тех-средства. Биг дате ставят задачу собрать всё про всех и отгрузить отчет в виде другой таблички
или DataMart. И на это ей дадут пару часиков а то и день. Поэтому разговоры относительно убивания
производительности - очень можно смягчить.
Вообще такие сложные системы не обязаны строиться поверх Postgres или Neo или Spark. В их разработке
вполне можно использовать целый pipeline из технологий где например Postgres будет просто одним
из элементов. Или одним stage.
Миллиарды получаются очень просто - если взять вас как рабочий объект, то у вас будут: рабочее место, рабочее оборудование, место работы, рабочий проект, задание, должность, специальность и еще сотня других объектов, с которыми вы связаны. Таких работников как вы 200 тысяч. Также есть неодушевленные объекты, которых более 600 тысяч. Думаю, с миллиард - это начальное число объектов.
Ага, но в некоторых компаниях возникают идеи построения учёта по тому принципу, который описывает автор вопроса - вместо кучи деревьев просто один огромный граф где перечислены все сущности и все возможные взаимоотношения.
У каждой сущности свои свойства - у сотрудников ФИО и табельный номер, а у оборудования производитель, заводской номер и срок ввода в эксплуатацию. И так далее... Связи тоже имеют специфику "рабочие место - оборудование" - это признак, где физически станок находится, а "работник - рабочие место" - это уже запись в журнале рабочего времени (сегодня в одном цеху, а завтра в другом).
Как раз о замене SAP идет речь.
Да, у каждой сущности будут свои ссылочные таблицы - всё правильно, у станка количество оборотов, а у машины мощность двигателя, у сотрудника адрес рабочего места. Таких таблиц тысячи. Вы всё правильно поняли.
Дешевле будет купить какую-то 1C:ERP чем пытаться на коленке повторить настолько сложную систему. У вас год уйдет только на одну работу аналитиков и не факт, что на выходе будет законченное ТЗ.
Если не 1С и интересует Java (судя по тегам), то можете попробовать Jmix. В то время пока маркетологи от 1С ходят по сообщества саперов и предлагают импортозаместится, маркетологи от Jmix (ex-Cuba) точно так же ходят в сообщества одинесников и предлагаю вырасти в более зрелые технологии.
Средний
Средний
