Как стать автором
Обновить

Комментарии 4

А скажите какой из подходов лучше с точки зрения производительности и архитектуры:
1. Set ^CUSTOMER(100)= “Chris Munt”_"~"_«Oxford»
2.
Set ^CUSTOMER(100,«name»)= “Chris Munt”
Set ^CUSTOMER(100,«address»)=«Oxford»

Мне отвечали как правило, что это вопрос предпочтений.
В данном случае речь идёт о записи в БД. Поскольку в первом случае нужно сформировать один индексный элемент, а во втором два, то первый будет работать быстрее.

С точки зрения того, что структуру можно легко менять второй способ предпочтительней, так как в первом мы будем использовать при считывании:
$piece(record,"~",1)
$piece(record,"~",2)

А это приведёт к тому, что при изменении структуры (например мы добавим возраст перед именем или удалим имя) все цифры «поплывут» и MUMPS-программа станет неработоспособна.
На самом деле вариантов не два, а сотни — это же MUMPS. Это именно вопрос предпочтений и архитектуры. Ведь вы здесь спрашиваете о том, как лучше записать в базу. А потом вам обязательно потребуется эти данные прочитать — и снова возникнет вопрос скорости и удобства разработки. Кроме того, если система получится долгоживущей, то ее нужно будет поддерживать, а значит менять структуру данных. Поэтому неплохо бы позаботиться о будущем по возможности безболезненном изменении метаданных.
Что касаемо заданного вопроса — однозначно можно сказать, что в Caché первый вариант реализован эффективнее и универсальнее с помощью списков. В данном случае будет выглядеть как:
set ^CUSTOMER(100)=$LB(«Chris Munt»,«Oxford»)
чтобы потом
name=$LG(^CUSTOMER(100),1)
address=$LG(^CUSTOMER(100),2)
$LG(LISTGET) работает намного быстрее $piece, и не нужно «приносить в жертву» данным символ-разделитель — вдруг вы захотите его использовать в данных?

А если говорить об архитектуре — при разработке любой более-менее серьезной MUMPS системы, разработчики создают собственное API по записи и чтению данных в их придуманную архитектуру данных и потом поддерживают это.

Собственно это одна из причин появления объектной СУБД в Caché — чтобы разработчикам не придумывать и не поддерживать API для работы с глобалами самим, можно возложить это на InterSystems и использовать объектную архитектуру, поддерживаемую и развиваемую компанией, в которой есть и прямой доступ к глобалам (set, get), но есть и ODBC, JDBC, .NET, java, node.js и т.д.
Но если вам не нужна развитая, поддерживаемая архитектура, у вас всегда есть глобалы MUMPS и их скорость и свобода.
Ну и еще раз, отвечая на поставленный вопрос — InterSystems в хранении данных объектов Caché по умолчанию использует именно первый вариант, но на $LB конструкциях.

Часто выбирают первый вариант.
Но если у класса будут тысячи, десятки тысяч свойств — наступит предел для одного значения узла. В разных системах он разный — у Caché такой.

В классах Caché по умолчанию используется первый (но с $LB), но если необходимо, можно поменять структуру хранения на второй вариант или любой какой угодно еще.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории