Комментарии 60
Что делать если родителей больше одного?
То есть например классическая родословная — у ребенка есть папа и мама.
То есть например классическая родословная — у ребенка есть папа и мама.
Добавить ссылки на папу и маму в его реквизиты
Я так понимаю, что «родитель» здесь технический термин, а не описание логики взаимосвязей доменной структуры.
Касательно родословной — можно собирать коллекцию семья и описывать взаимоотношения отдельными квинтетами, т.к. у человека может быть и больше одной пары родителей: либо приемные/кровные (возможны ещё варианты), либо мы попросту из документальных источников не можем определить какая пара родителей «истинная» (характерно, когда смотришь в исторические источники — там прям путаница бывает)
Касательно родословной — можно собирать коллекцию семья и описывать взаимоотношения отдельными квинтетами, т.к. у человека может быть и больше одной пары родителей: либо приемные/кровные (возможны ещё варианты), либо мы попросту из документальных источников не можем определить какая пара родителей «истинная» (характерно, когда смотришь в исторические источники — там прям путаница бывает)
То что описано — похоже на движок типа 1с, перед которым тоже очевидно стоит аналогичная задача структурированного и платформонезависимого описания объектов.
К тому же, конкретно та платформа имеет ещё кучу готовых примитивов для описания объектов реального мира, из конкретной предметной области, чтобы разработчик себе голову не ломал.
У Вашей концепции какое дальнейшее развитие будет? Чем она принципиально лучше?
К тому же, конкретно та платформа имеет ещё кучу готовых примитивов для описания объектов реального мира, из конкретной предметной области, чтобы разработчик себе голову не ломал.
У Вашей концепции какое дальнейшее развитие будет? Чем она принципиально лучше?
Вы правильно заметили про движок — здесь описан подход к его разработке.
Для создания платформы нужно развивать инфраструктуру и нарабатывать практики, а это уже следующий этап.
Принципиально, на мой субъективный взгляд, самое важное улучшение — это возможность начать всё с чистого листа, постепенно усложняя прикладную часть и избегая известных ошибок.
Соответственно, развитие сейчас заключается в создании энтузиастами нужных им примитивов, решающих очень простые задачи, коих, если присмотреться очень много. По итогам этих работ появляются артефакты, а сами энтузиасты решают для себя насколько им это нравится или не нравится. Сама концепция при этом получает практическое подтверждение жизнеспособности и позволяет запланировать дальнейшие шаги, решая более сложные задачи.
Для создания платформы нужно развивать инфраструктуру и нарабатывать практики, а это уже следующий этап.
Принципиально, на мой субъективный взгляд, самое важное улучшение — это возможность начать всё с чистого листа, постепенно усложняя прикладную часть и избегая известных ошибок.
Соответственно, развитие сейчас заключается в создании энтузиастами нужных им примитивов, решающих очень простые задачи, коих, если присмотреться очень много. По итогам этих работ появляются артефакты, а сами энтузиасты решают для себя насколько им это нравится или не нравится. Сама концепция при этом получает практическое подтверждение жизнеспособности и позволяет запланировать дальнейшие шаги, решая более сложные задачи.
Чем это принципиально отличается от мивара?
Еще один убийца семантических сетей…
До 1 апреля дотерпеть не удалось.
На forth так и программируют.
TL;TR; Создадим базовый тип Квинтет с тремя дополнительными полями (они не всегда нужны, поэтому иногда не заполняются), и будем использовать DDD.
> привело к чудовищной растрате ресурсов IT-системами
> Квинтет не заменяет байт как таковой, но, будучи сам составлен из байтов, стремится заменить термин «байт» как обозначение минимальный порции данных.
Т.е. вместо старшего и младшего байта в 16ричном слове надо хранить 15 слов неизвестного размера + 2 байта (по 5 каждый байт и 5 на само слово).
Если взять 32битную систему, то 2 байта заменяются 62. Экономия.
Ну или менять нужно не «байт», а «объект» и не как «минимальная единица представления информации», а как «базовая сущность описания предметной области».
> Квинтет не заменяет байт как таковой, но, будучи сам составлен из байтов, стремится заменить термин «байт» как обозначение минимальный порции данных.
Т.е. вместо старшего и младшего байта в 16ричном слове надо хранить 15 слов неизвестного размера + 2 байта (по 5 каждый байт и 5 на само слово).
Если взять 32битную систему, то 2 байта заменяются 62. Экономия.
Ну или менять нужно не «байт», а «объект» и не как «минимальная единица представления информации», а как «базовая сущность описания предметной области».
Спасибо, подправил заголовок и статью.
А байты мы посчитаем в одной из следующих статей и сравним с существующими решениями.
А байты мы посчитаем в одной из следующих статей и сравним с существующими решениями.
Не забудем, что идентификатор неизбежно будет GUIDом, а это само по себе 16 байт. Попытки вместо GUIDа использовать коротенькое число локального идентификатора непременно окончатся крахом.
Хотя, вообще-то, в моделях данных по крайней мере половина объёма — вообще неидентифицируемые объекты (то есть не имеющие выделенного идентификатора).
В общем, ждём реализации, вот ужо оно залетает…
Хотя, вообще-то, в моделях данных по крайней мере половина объёма — вообще неидентифицируемые объекты (то есть не имеющие выделенного идентификатора).
В общем, ждём реализации, вот ужо оно залетает…
Хотя, вообще-то, в моделях данных по крайней мере половина объёма — вообще неидентифицируемые объекты (то есть не имеющие выделенного идентификатора).
Да, это именно так. Они неидентифицируемы, что создает определенные проблемы, когда пользователи хотят их анализировать.
Современный пользователь хочет всего и сразу, и его требования часто меняются быстрее, чем мы успеваем обновить нашу систему: изменить типы реквизитов, размерность, индексировать некоторые поля, используемые для поиска только здесь и сейчас.
Мы часто решаем эти проблемы и придумали способ их уменьшить. Это работает, и принято решение расти.
Они неидентифицируемы,Ну, как — идентифицируемы по обязательной ссылке.
Современный пользователь хочет всего и сразуВсего и сразу требует практика. Вот у вас ссылки однонаправленные, значит, обязательное дерево неустойчиво. С другой стороны — наличие деревянной структуры вообще не требуется в большом количестве случаев. В других — нет единственного дерева-доминанта, что, по сути, то же самое.
Боюсь, это больше похоже на лабораторную работу или (что почти то же самое) занятие интересными ядерными вещами, когда потребитель почему-то ждёт продукт и бизнес-логику.
Ну, как — идентифицируемы по обязательной ссылке.
Не уверен, что понял вас. Вы сами сказали «половина объёма — вообще неидентифицируемы».
Вот у вас ссылки однонаправленные, значит, обязательное дерево неустойчиво.
Ссылки двунаправленные — оба упоминания ID проиндексированы, значит их можно сопоставить в любую сторону, равно как и собрать все связи с заданным ID.
Сами квинтеты хранятся не деревом, а списком. Деревья же используются для быстрого нахождения значения в списке.
Я сильно подозреваю, что спорить с энтузиастом себе дороже…
И вообще непонятно, если уж на то пошло, зачем Вы перегрузили триплы лишней информацией, если, по сути, строите то же самое. Могли бы взять готовое, а не бегать по граблям. Впрочем, и в готовом виде триплы — бяка.
Отсутствует собственный идентификатор, автономно объект не идентифицируем, существует только при наличии обязательной ссылки. Вот как палец: на нём не обязательно наносить татуировку, чтобы можно было утверждать, что этот палец — мой. У вас же и идентификатор, и ссылка. Избыточность, причём ссылка по дереву явно будет работать только в очень узком применении, которое в начале разработки предполагалось основным. По мере строительства продукта обычно оказывается, правда, что это не так :-)Ссылки двунаправленные — оба упоминания ID проиндексированы, значит их можно сопоставить в любую сторону, равно как и собрать все связи с заданным IDНу, как — идентифицируемы по обязательной ссылке.Не уверен, что понял вас. Вы сами сказали «половина объёма — вообще неидентифицируемы».
Ссылки двунаправленные — оба упоминания ID проиндексированы, значит их можно сопоставить в любую сторону, равно как и собрать все связи с заданным IDиндексы не являются обеспечителями надёжности, только скорости. На то они и индексы, что их можно перестраивать независимо от операций с собственно моделью. Альтернатива — обязательные индексы, и тогда у вас не квинтлеты, а уже нагромождение. Чего я, собственно, и ожидал.
И вообще непонятно, если уж на то пошло, зачем Вы перегрузили триплы лишней информацией, если, по сути, строите то же самое. Могли бы взять готовое, а не бегать по граблям. Впрочем, и в готовом виде триплы — бяка.
Избыточность, причём ссылка по дереву явно будет работать только в очень узком применении, которое в начале разработки предполагалось основным. По мере строительства продукта обычно оказывается, правда, что это не так :-)
Ссылки между квинтетами работают при каждом обращении к данным — это связующая информация и другой никакой нет (нет схем, таблиц, полей). Избыточность присутствует, да, как плата за унификацию и удобство работы со структурой и данными.
индексы не являются обеспечителями надёжности, только скорости. На то они и индексы, что их можно перестраивать независимо от операций с собственно моделью. Альтернатива — обязательные индексы, и тогда у вас не квинтлеты, а уже нагромождение. Чего я, собственно, и ожидал.
Пользователи не очень любят перестраивать индексы и платить за это тоже не всегда желают. Избыточность, как я упомянул выше, это достаточно дешевая альтернатива.
И вообще непонятно, если уж на то пошло, зачем Вы перегрузили триплы лишней информацией, если, по сути, строите то же самое. Могли бы взять готовое, а не бегать по граблям. Впрочем, и в готовом виде триплы — бяка.
Я бы не стал привязываться к триплам, и по сути я строю нечто иное и с иной целью.
В общем, ждём реализации, вот ужо оно залетает…
В этой статье описана реализация, там же есть оценка производительности.
не об этой оценке речь, а о том, что реальный объём данных и реальные алгоритмы настолько будут отличаться от идеи, что, при пристальном рассмотрении всё может кончиться, как это неоднократно и происходило, «отлично, а теперь давайте перестанем себя мучать и перенесём всё в sql». Вспомним иерархические и объектные бд, уж как они летали…
Я там сравниваю также объемы данных и, с учетом того, что нормализация в нашем случае обходится дешевле и получается доступнее, объемы получаются примерно одинаковые.
По алгоритмам пока сложно сравнивать из-за большой разницы в подходах. Я планирую сделать построитель процессов в ближайшее время, чтобы показать разработку и использование алгоритмов и определиться с парадигмой, наконец.
Конечно, мы ещё не все грабли прошли, так что будем наблюдать.
По алгоритмам пока сложно сравнивать из-за большой разницы в подходах. Я планирую сделать построитель процессов в ближайшее время, чтобы показать разработку и использование алгоритмов и определиться с парадигмой, наконец.
Конечно, мы ещё не все грабли прошли, так что будем наблюдать.
CIMы (Common Information Model) существуют в изрядном множестве для разных областей. И они показывают, что реальность не может опираться на такие простенькие структуры, как представлено в посте. Ну, разве что очень простые реальности…
А я вот прямиком обратное замечу. Слишком сложные ваши квинтеты, семантик веб вон так и не смог выбраться за пределы универов, а в нем всего лишь триплеты. Считать в промышленности научились пока только до двух, поэтому ещё долго будем описывать реальность на json, парами ключ-значение.
не надо про триплеты! У нас один энтузиаст наворотил на них, и ушло в эксплуатацию. Уже десять(!) лет проблемы огребаем.
прямиком обратное замечу. Слишком сложные ваши квинтетывот-вот, я тоже подобное успел отметить:
вообще-то, в моделях данных по крайней мере половина объёма — вообще неидентифицируемые объекты
CIMы (Common Information Model) существуют в изрядном множестве для разных областей.
Мы не изобретали новую CIM, а реорганизовали представление данных, чтобы с ними было проще и нагляднее работать, не изменяя подход к хранению данных в принципе. Это работает до модели, на уровне квантов данных, без привязки к конкретной области.
И они показывают, что реальность не может опираться на такие простенькие структуры, как представлено в посте. Ну, разве что очень простые реальности…
Для этого и была написана статья — описать подход, применимый к структуре любой сложности, какая может встретиться в современных приложениях.
Поскольку у вас наверняка есть
Для того, чтобы было понятнее и другим, и вам самим, объясните, чем этот подход отличается от достаточно широко (и многим — печально) известных триплов ака EAV.
Зачем вы расширили этот подход, какой выигрыш и где можно получить? «Зачем?» — вообще главный и не-отвеченный вопрос, возникающий по прочтении поста.
А я остаюсь в состоянии глубокого скептицизма.
Зачем вы расширили этот подход, какой выигрыш и где можно получить? «Зачем?» — вообще главный и не-отвеченный вопрос, возникающий по прочтении поста.
А я остаюсь в состоянии глубокого скептицизма.
Для того, чтобы было понятнее и другим, и вам самим, объясните, чем этот подход отличается от достаточно широко (и многим — печально) известных триплов ака EAV.
EAV — это не подход, а структура. Можно сказать, что это подход к представлению данных, и не более.
А здесь описан подход к построению информационной системы, где данные (в т.ч. алгоритмы) хранятся в предельно простом и унифицированном формате.
Зачем вы расширили этот подход, какой выигрыш и где можно получить? «Зачем?» — вообще главный и не-отвеченный вопрос, возникающий по прочтении поста.
Выигрыш может быть в скорости разработки, во всяком случае мы стали быстрее разрабатывать приложения, применяя этот подход. Поскольку система хранения унифицирована, к ней можно прикрутить различные варианты интерфейса, который скроет много тривиальной, черновой работы, устранит часть связанных с этим рисков и снизит порог вхождения для разработчика.
EAV — это не подход, а структура. Можно сказать, что это подход к представлению данных, и не более.
По какому формальному критерию вы разделяете одно и другое?
Выигрыш может быть в скорости разработки, во всяком случае мы стали быстрее разрабатывать приложения, применяя этот подход.
Я и про EAV лет пятнадцать назад то же самое говорил. Причем включая интерфейс. Да что там 15 лет назад, в этом году на хабре обсуждали очередную реинкарнацию, причем вот ровно с теми же обещаниями, что вы тут озвучиваете.
Я и про EAV лет пятнадцать назад то же самое говорил. Причем включая интерфейс. Да что там 15 лет назад, в этом году на хабре обсуждали очередную реинкарнацию, причем вот ровно с теми же обещаниями, что вы тут озвучиваете.
Про интерфейс интересно, о чём вы говорили 15 лет назад. Расскажете в чем суть?
Мы сделали обещанную реинкарнацию и хотим двигаться дальше.
Про интерфейс интересно, о чём вы говорили 15 лет назад. Расскажете в чем суть?
Ровно в том, что вы обещали выше: "поскольку система хранения унифицирована, к ней можно прикрутить различные варианты интерфейса, который скроет много тривиальной, черновой работы, устранит часть связанных с этим рисков и снизит порог вхождения для разработчика" — и что в реальных проектах в моем опыте никогда не работало в обещанном объеме.
А в чем были проблемы?
Общение с базой не требует квалификации IT, интерфейс можно собрать из плагинов, подключаемых до неприличия легко.
Общение с базой не требует квалификации IT, интерфейс можно собрать из плагинов, подключаемых до неприличия легко.
В том, что как только сценарий использования выходит за рамки "вводим данные в плоскую формочку" (в вашей новой статье, собственно, ничего сложнее и нет), сложность реализации зашкаливает.
Кстати, про интерфейс, мы делаем всякие конструкторы, чтобы снизить порог, получается достаточно несложно:
Сделать конструктор, чтобы снизить порог — не очень сложно. Сложно сделать так, чтобы это решало достаточное количество задач.
Задачу вынести данные из экселя, защитить их, дать средства выборки запросами и форму ввода показанные в ролике конструкторы решают на 100%
Вполне возможно. Только информационные системы такой сложности меня не интересуют уже лет десять как.
Да я помню, у вас EAV и номера в каталоге длиной более 900 байт.
Но на хабре разные есть читатели, я для всех пишу.
Но на хабре разные есть читатели, я для всех пишу.
Да я помню, у вас EAV
Нет, у меня не EAV.
Но на хабре разные есть читатели, я для всех пишу.
Ну вот "для всех" — это и для меня, вроде бы как. А получается, что нет.
Квинтетами можно описать любые данные, при этом каждый из них содержит исчерпывающую информацию о себе и о связях с другими квинтетами.
Не, не содержит. Как показано в примере с мамой и папой выше, эта информация содержится не в квинтете, а в других квинтетах.
Возникает неприятный вопрос: а чем это, собственно, отличается от EAV?
Не, не содержит. Как показано в примере с мамой и папой выше, эта информация содержится не в квинтете, а в других квинтетах.
Связь может быть сколько угодно сложной, и квинтет позволяет её проследить, указывая следующее звено этой связи и доводя в итоге до мамы и папы.
Возникает неприятный вопрос: а чем это, собственно, отличается от EAV?
Вы можете называть это EAV. Только к нему ещё добавлены идентификатор и порядок.
Связь может быть сколько угодно сложной, и квинтет позволяет её проследить, указывая следующее звено этой связи и доводя в итоге до мамы и папы.
Неа, квинтет — не позволяет. Конкретную информацию содержит совокупность квинтетов, но не сам квинтет.
Только к нему ещё добавлены идентификатор и порядок.
Идентификаторы в EAV зачастую есть. Порядок… ну да, порядок. В некоторых реализациях тоже есть.
Так где же "новый подход к"?
Описание вызывает противоречивые чувства.
Хватит слов, покажите код!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Квинтет как базовая сущность для описания предметной области