Comments 60
Что делать если родителей больше одного?
То есть например классическая родословная — у ребенка есть папа и мама.
То есть например классическая родословная — у ребенка есть папа и мама.
Добавить ссылки на папу и маму в его реквизиты
Я так понимаю, что «родитель» здесь технический термин, а не описание логики взаимосвязей доменной структуры.
Касательно родословной — можно собирать коллекцию семья и описывать взаимоотношения отдельными квинтетами, т.к. у человека может быть и больше одной пары родителей: либо приемные/кровные (возможны ещё варианты), либо мы попросту из документальных источников не можем определить какая пара родителей «истинная» (характерно, когда смотришь в исторические источники — там прям путаница бывает)
Касательно родословной — можно собирать коллекцию семья и описывать взаимоотношения отдельными квинтетами, т.к. у человека может быть и больше одной пары родителей: либо приемные/кровные (возможны ещё варианты), либо мы попросту из документальных источников не можем определить какая пара родителей «истинная» (характерно, когда смотришь в исторические источники — там прям путаница бывает)
То что описано — похоже на движок типа 1с, перед которым тоже очевидно стоит аналогичная задача структурированного и платформонезависимого описания объектов.
К тому же, конкретно та платформа имеет ещё кучу готовых примитивов для описания объектов реального мира, из конкретной предметной области, чтобы разработчик себе голову не ломал.
У Вашей концепции какое дальнейшее развитие будет? Чем она принципиально лучше?
К тому же, конкретно та платформа имеет ещё кучу готовых примитивов для описания объектов реального мира, из конкретной предметной области, чтобы разработчик себе голову не ломал.
У Вашей концепции какое дальнейшее развитие будет? Чем она принципиально лучше?
Вы правильно заметили про движок — здесь описан подход к его разработке.
Для создания платформы нужно развивать инфраструктуру и нарабатывать практики, а это уже следующий этап.
Принципиально, на мой субъективный взгляд, самое важное улучшение — это возможность начать всё с чистого листа, постепенно усложняя прикладную часть и избегая известных ошибок.
Соответственно, развитие сейчас заключается в создании энтузиастами нужных им примитивов, решающих очень простые задачи, коих, если присмотреться очень много. По итогам этих работ появляются артефакты, а сами энтузиасты решают для себя насколько им это нравится или не нравится. Сама концепция при этом получает практическое подтверждение жизнеспособности и позволяет запланировать дальнейшие шаги, решая более сложные задачи.
Для создания платформы нужно развивать инфраструктуру и нарабатывать практики, а это уже следующий этап.
Принципиально, на мой субъективный взгляд, самое важное улучшение — это возможность начать всё с чистого листа, постепенно усложняя прикладную часть и избегая известных ошибок.
Соответственно, развитие сейчас заключается в создании энтузиастами нужных им примитивов, решающих очень простые задачи, коих, если присмотреться очень много. По итогам этих работ появляются артефакты, а сами энтузиасты решают для себя насколько им это нравится или не нравится. Сама концепция при этом получает практическое подтверждение жизнеспособности и позволяет запланировать дальнейшие шаги, решая более сложные задачи.
UFO just landed and posted this here
Чем это принципиально отличается от мивара?
Еще один убийца семантических сетей…
До 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 зачастую есть. Порядок… ну да, порядок. В некоторых реализациях тоже есть.
Так где же "новый подход к"?
Описание вызывает противоречивые чувства.
Хватит слов, покажите код!
Sign up to leave a comment.
Квинтет как базовая сущность для описания предметной области