Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
возможно ли определить собственную процедуру доступа к индексам? И сразу второй вопрос - кто знает где лежит описание вообще работы с этими Storage? ( Using Caché Studio - Storage Definitions не предлагать) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 15:18 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
авторвозможно ли определить собственную процедуру доступа к индексам? Кто-нибудь понимает эту фразу? Поясните авторИ сразу второй вопрос - кто знает где лежит описание вообще работы с этими Storage? посмотрите глобалы odd*, например oddCOM, oddMAP ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 17:40 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
еще вариант - сделайте таблицу с индексами, сделайте программу из одной строки &sql(select * from table1 where prop1=value1) и посмотрите int-код. Там вы увидите, что каше просто преобразует запрос в m-код. Данные о том, какой m-код делать, компилятор берет кажется из oddCOM (но это не утверждаю). Или ваш вопрос был о другом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 17:48 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
Суть проблемы состоит в том, что с 1937 года осталась структура хранения которую изменить невозможно, но хочется иметь объектный и SQL доступ. и если на структуру данных можно натянуть определение класса то индексы, здесь, хранятся в совершенно чуждой буржуазии структуре: ^Индекс("Имя_Индекса" , значение_индекса , Служебные_данные , ID) (тогда как родной индекс хранится в формате: ^Индекс("Имя_Индекса",значение_индекса , ID) ) Хочу заставить Cache писать индекс в нужный мне глобал и в нужном формате. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 19:10 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
Блок А.Н. и посмотрите int-код. Там вы увидите, что каше просто преобразует запрос в m-код. Данные о том, какой m-код делать, компилятор берет кажется из oddCOM (но это не утверждаю). Можно попробовать, но это будет через зад, а хочется чистого. Свято верю в Sql Storage Map, но информация скудна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 19:13 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
Что значит не предлагать ? Если открыть хранение не через Вид - а через брайзер свойств (Alt-2 кажись) - там хранение - там map там [...] то открывается мастер анологичный 4-шному. Там индексные карты и определяют.... Как они заполняться будут нужно смотреть - но в крайнем случае создается три триггера где пишется своя логика .... Пара стаааарых примеров - например в pdf-ке SqlStorage.pdf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 21:33 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
u78^Индекс("Имя_Индекса" , значение_индекса , Служебные_данные , ID) Если то что обозначено как "значение_индекса" и "Служебные_данные" это значения атрибутов, то это составной индекс по этим полям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2007, 10:25 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
PtnЧто значит не предлагать ? я имел в виду раздел справки InterSystems, там скудно. PtnТам индексные карты и определяют.... Как они заполняться будут нужно смотреть - но в крайнем случае создается три триггера где пишется своя логика .... записать то можно куда хочешь, а могу я сам определить процедуру поиска ID по какому то индексу? Ptn Пара стаааарых примеров - например в pdf-ке SqlStorage.pdf это просмотрел первым делом, но с тех пор здорово поменялся интерфейс определения этих карт, не осилил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2007, 11:15 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
>>это просмотрел первым делом, но с тех пор здорово поменялся интерфейс определения этих карт, не осилил. Разве ? (приложение) ЗЫ: хотя откровенно говоря не пользовался ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2007, 14:37 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
Я так понимаю, главная проблема - это "Служебные_данные" в составе индекса. Нельзя ли их сделать полем класса? Что это за данные, можно подробнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2007, 16:47 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
Еще вариан, если карты натянутся на глобал данных, но не натянутся на глобал индексов - сделать отдельный класс и натянуть его на глобал индексов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2007, 15:53 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.Нельзя ли их сделать полем класса? Так и сделал, хотя честно сказать, не нравится. а про служебные данные вот: все индексы всех справочников хранятся в одном большом глобале: ^Глобал(Название_индекса,значение_индекса,Справочник те самые служебные данные,ID) где: Название_индекса - идентификатор индекса (например "ClientIndex") значение_индекса - значение поля по которому индексируем (например id клиента - 1101) Справочник - индексируемый справочник (например справочник дисконтных карт у которого есть поле Client) вот это и есть служебные данные ID - id записи индексируемого справочника (то есть ID дисконтной карты, например 101) в этом случае индекс будет выглядеть: ^Глобал("ClientIndex",1101,"DscCard",101) В принципе структура похожа если не считать лишнего 3 пункта. Почему и хотелось бы руками определять процедуру поиска. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2007, 19:18 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
PtnРазве ? (приложение) тот pdf во многом оформлен "делайте вот так а потом вот так" и отклонение дизайна даже на одно-два поля меня сбило с толку, я вообще толком не понимаю что это за карты такие. И рассказов нет нигде про эти карты (((((( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2007, 19:21 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
давайте пример глобала и его индекса - попробую накидать sql-storage map - много с ним накувыркался но до конца так и не понял - слишком мало информации. Судя по всему намеренно ИСЦ не хочет поддерживать серъезно этот вид стораджа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2007, 23:28 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
Rus000Судя по всему намеренно ИСЦ не хочет поддерживать серъезно этот вид стораджа А оно надо? Наверняка было сделано для поддержания перехода от своего хранения к классовому т.с. для совместимости... Но пора и честь знать! :) Сколько уже лет Кащей гуляет постране?... Мало того. Сами разработчики так мудрили с хранением (мы тоже не исключение) что и на словах-то его трудно описать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2007, 08:44 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
имхо, если уж заявили - то будьте любезны тщатаельно задокументировать. Опять же управление структурой хранения в скл-сторадж более прозрачно, нежели кашесторадж. Попробуйте сделать класс со стандартным хранением с парой свойств (A,B) . Откомпилируйте. Потом удалите одно из свойств(B) и добавьте новое (С). А теперь посморите как каша собирается хранить: $LB(a,b,c) а не $LB(a,c) хотя мы еще продукт не выпускали в продакшн. Вроде понятно почему так а неприятно. В скл-сторадже все останется так как написано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2007, 07:42 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
А по-моему, очень логично. В поле "B" уже могут лежать данные, которые ни в коем случае не должны лежать в поле "C". Скомпилированные SQL запросы бращаются к номеру поля, а не к его имени. "Лишнее" поле практически не увеличивает базу Если данных там нет, программы и классы с SQL вы котовы все перекомпилить и вы понимаете принципы хранения в каше, вы ее можете поправить структуру хранения руками на свой страх и риск - cachestorage правится также, как и sqlstorage, как мне помнится. Также по вашей логике, если удалить из класса поле "A", то должны сдвинуться все поля ;-)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2007, 07:45 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
не обязательно, если задать структуру полей в именованных узлах например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2007, 18:50 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
Что вы имеете ввиду? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2007, 07:59 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
в приведенном мной примере смещения не будет есди задать хранение полей в виде ^GLOBAL(ID,"A")=valA ^GLOBAL(ID,"B")=valB ^GLOBAL(ID,"С")=valC в случае удаления поля B из декларации класса мусор также легко можно подчистить удалив ветку "B" Все я это говорю не имея ввид что скл-сторадж лучше стандартного, просто в нем проще контроллировать структуру хранения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2007, 09:05 |
|
||
|
Sql Storage Map - доступ к индексам
|
|||
|---|---|---|---|
|
#18+
разговор ведь был про $LB(a,b,c)? Контролировать структуру хранения нужно не так часто, если вы не делаете систему полностью на чистом M. Но даже в чистом M при большом количестве полей для каждого поля делать свой узел уже неудобно. Это мое мнение К тому же хранение каждого поля в отдельном узле, занимает лишнее место в базе и тормозит систему в целом за счет большего числа ссылок, мне так показалось по крайней мере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2007, 10:27 |
|
||
|
|

start [/forum/topic.php?fid=39&msg=34573582&tid=1559311]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
88ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 230ms |
| total: | 388ms |

| 0 / 0 |
