|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
В свое время реализовали архитектуру следующим образом Код: python 1. 2. 3. 4. 5. 6.
Т.е. все они храняться в разных глобалах, ID везде по-умолчанию икрементальные. Довольно беспонтово получилось..... Нужно сливать все в базовое хранение, т.е. привести к архитектуре Код: python 1. 2. 3. 4. 5. 6.
Проблема в том что в этом случае часть данных начнет храниться под другими ID (во изббежание дублей), а ссылки из других классов останутся на "старый ID". Как можно провернуть такую миграцию? Есть ли какие-то встроенные средства? Идеи? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2013, 03:02 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
И еще один влопрос в тему: При смене idKey класса, как правильно престраиваются ссылки на этот класс, находящиеся в других классах? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2013, 03:04 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
А разве можно изменить IdKey? Вам нужно будет искать все ссылки на объект и переделывать их. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2013, 04:20 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
Блок А.Н. , А разве можно изменить IdKey? Да, если хранение кильнуть - то получится. ))) Вам нужно будет искать все ссылки на объект и переделывать их. Почему то так и думал, но надежда теплилась ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2013, 05:55 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
sigmovНужно сливать все в базовое хранение, т.е. привести к архитектуре Не очень хороший подход на самом деле. Всё отлично только на бумаге и в абстракции ООП. Рекомендую посмотреть как каше реализует хранение таких классов. 1 - Среди этих классов должны будут быть только уникальные индексы, если в классе AA и AB - будет индекс I1 - то компилятор даже не ругнется, а вот когда начнете заполнять данные будет весело. Так же особенно весело когда в потомках нужно завести индексы с разной уникальностью. Уникальность сразу распространяется на потомков. 2 - Может возникнуть путаница в какой последовательности нужно ребилдиить индексы, по идее должен сохраняться порядок от предков к потомкам, а дальше уже насколько сильно вы наследование намутите. 3 - Все данные и индексы потомков первого хранимого класса, будут содержать полное имя класса потомка, то есть каждая запись будет содержать дополнительную текстовую строку на 10-20 символов. 4 - Предположим у вас есть 10E5 записей A, 10E4 записей AА, 10 записей AАА, что бы получить запись ААА, вам, грубо придется промотать 110000 предстояших записей А и АА, если конечно у вас не хватило индекса sigmovКак можно провернуть такую миграцию? Есть ли какие-то встроенные средства? Идеи? Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2013, 08:49 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
sigmov, полностью поддержу Ptn. Рекомендация Олега Оленина со Школы 2012 - "для нагруженных систем используйте анемичную модель данных". ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2013, 11:40 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
PtnНе очень хороший подход на самом деле. Всё отлично только на бумаге и в абстракции ООП. Рекомендую посмотреть как каше реализует хранение таких классов. Хранение идет в глобали базового класса(первого %Persistent), данные относящиеся к потомкам хранятся в subscript'ах той же глобали PtnСреди этих классов должны будут быть только уникальные индексы, если в классе AA и AB - будет индекс I1 - то компилятор даже не ругнется, а вот когда начнете заполнять данные будет весело.У меня ругается.... 2013.1 PtnТак же особенно весело когда в потомках нужно завести индексы с разной уникальностью. Уникальность сразу распространяется на потомков.Должо быть Вы имели ввиду "индексы с уникальностью отличной от предков". И это правильно что уникальность распространяется на потомков в неизменном виде. PtnМожет возникнуть путаница в какой последовательности нужно ребилдиить индексы, по идее должен сохраняться порядок от предков к потомкам, а дальше уже насколько сильно вы наследование намутите.Не вижу тут никакой путаницы, по крайней мере сверх той что и так присуща Каше. PtnВсе данные и индексы потомков первого хранимого класса, будут содержать полное имя класса потомка, то есть каждая запись будет содержать дополнительную текстовую строку на 10-20 символов.Верно. Но не вижу тут ничего страшного. PtnПредположим у вас есть 10E5 записей A, 10E4 записей AА, 10 записей AАА, что бы получить запись ААА, вам, грубо придется промотать 110000 предстояших записей А и АА, если конечно у вас не хватило индексаЭто решается с помощью объявления индекса с такими же полями в классе-потомке. Ptn Код: sql 1.
Проблема ссылочной целостности..... ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2013, 12:18 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
doublefintsigmov, полностью поддержу Ptn. Рекомендация Олега Оленина со Школы 2012 - "для нагруженных систем используйте анемичную модель данных". Для высоконагруженных систем использовать нужно Oracle, Postgres. Ну а уж если Cache' вынуждены юзать - то никаких объектов и даже без SQL, только ^G. Каждый выбирает для себя оптимальный вектор характеристик..... ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2013, 12:23 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
sigmovdoublefintsigmov, полностью поддержу Ptn. Рекомендация Олега Оленина со Школы 2012 - "для нагруженных систем используйте анемичную модель данных". Для высоконагруженных систем использовать нужно Oracle, Postgres. Ну а уж если Cache' вынуждены юзать - то никаких объектов и даже без SQL, только ^G. Каждый выбирает для себя оптимальный вектор характеристик.....Что для вас высоконагруженная система, можно в цифрах ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2013, 12:44 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
sigmovДля высоконагруженных систем использовать нужно Oracle, Postgres. Ну а уж если Cache' вынуждены юзать... толсто ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2013, 13:05 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
sigmovКаждый выбирает для себя оптимальный вектор характеристик.....Объекты в нагруженных местах я бы с осторожностью использовал, по крайней мере точно запретить объекты со ссылками, вложенными объектами, массивами. А какие проблемы с SQL? Если у вас проблемы с производительностью SQL, то что-то вы не то делаете. Чистое хранение на глобалах слишком негибко, плохо документируется, плохо модифицируется, программа выглядит страшно. В общем, использовать его стоит в каких-то очень локальных вещах. Если аналог системы изх 200 таблиц вы сделаете чисто на глобалах, то ад при поддержке и развитии почти обеспечен. Разница по скорости между SQL и глобалами обычно не настолько велика, чтобы жертвовать преимуществами SQL. А уж если есть необходимость работать с глобалами (не все SQL делает хорошо), то лучше делать отображение на класс, запихивать методы работы с глобалом в класс. Таким образом можно получить преимущества глобалов не сильно страдая от их недостатков. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2013, 15:55 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
Блок А.Н.Объекты в нагруженных местах я бы с осторожностью использовал, по крайней мере точно запретить объекты со ссылками, вложенными объектами, массивами. Это, вероятно, про объекты в понимании ООП, а не объектно-ориентированных БД. Блок А.Н.А какие проблемы с SQL? Если у вас проблемы с производительностью SQL, то что-то вы не то делаете. При использовании СУБД SQL, практически, бесполезен. Поэтому никаких проблем с ним не может быть, конечно. Но при использовании СХОД проблемы с "реляционной технологией" известны. Это и необходимость в архитектуре "модель верхнего уровня+маппинг+РМД", и неизбежное перманентное программирование... Блок А.Н.Чистое хранение на глобалах слишком негибко, плохо документируется, плохо модифицируется, программа выглядит страшно. В любой системе на основе MUMPS осуществляется именно " чистое хранение на глобалах". Нужно по-другому сформулировать. Блок А.Н....Таким образом можно получить преимущества глобалов не сильно страдая от их недостатков. Да, обращаться непосредственно к глобалам крайне не желательно (поддержка ОЦ и др. проблемы). --- Что касается исходного вопроса, раньше считалось, что лучше иметь много "маленьких" глобалов, чем один "большой". ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2013, 17:07 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
sigmovЭто решается с помощью объявления индекса с такими же полями в классе-потомке. Это не решается, это выкручивается. Потому что для оптимизатора SQL получиться два относительно равноправных индекса. Для академического интереса еще куда ни шло. На реальных данных более менее приличного объема >2-4Гб - выкручиваться ради "красивого ООП" быстро надоедает. sigmovПроблема ссылочной целостности..... Я отвечал только на вопрос о переносе данных. Ссылочная целостность в вашем случае не решается никак. И если я не ошибаюсь, средств обхода этой проблемы в вашем сценарии, нет ни в одной СУБД ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2013, 21:12 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
sigmov,Хранение идет в глобали базового класса(первого %Persistent), данные относящиеся к потомкам хранятся в subscript'ах той же глобали Как то вы странно ответили. Как на экзамене ... Вы понимаете что данное хранение приведет к тому что блокировка какой либо таблицы потомка - может заблокировать таблицы всего семейства ? В каше, напоминаю, при работе со встроенным SQL, по умолчанию индивидуально блокируются только первые 1000 записей, потом лочиться вся таблица. А блокировка не снимается пока не закрывается до конца последней транзакции. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2013, 21:20 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
PtnКак то вы странно ответили. Как на экзамене ... Вы понимаете что данное хранение приведет к тому что блокировка какой либо таблицы потомка - может заблокировать таблицы всего семейства ? В каше, напоминаю, при работе со встроенным SQL, по умолчанию индивидуально блокируются только первые 1000 записей, потом лочиться вся таблица. А блокировка не снимается пока не закрывается до конца последней транзакции. Понимаем. Правда насчет 1000 не уверен, по умолчанию 10к вроде. Но вообщем %NOLOCK - это наш вечный спутник SELECT и UPDATE ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2013, 03:04 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
Ptn1 - Среди этих классов должны будут быть только уникальные индексы, если в классе AA и AB - будет индекс I1 - то компилятор даже не ругнется, а вот когда начнете заполнять данные будет весело. Так же особенно весело когда в потомках нужно завести индексы с разной уникальностью. Уникальность сразу распространяется на потомков. 2 - Может возникнуть путаница в какой последовательности нужно ребилдиить индексы, по идее должен сохраняться порядок от предков к потомкам, а дальше уже насколько сильно вы наследование намутите. 3 - Все данные и индексы потомков первого хранимого класса, будут содержать полное имя класса потомка, то есть каждая запись будет содержать дополнительную текстовую строку на 10-20 символов. 4 - Предположим у вас есть 10E5 записей A, 10E4 записей AА, 10 записей AАА, что бы получить запись ААА, вам, грубо придется промотать 110000 предстояших записей А и АА, если конечно у вас не хватило индекса 1 - Вам сложно индексы обзывать уникально? Мне - нет. В иерархии могут быть сотни уникальных индексов - практически это не грузит систему. 2 - Эта проблема существовала кажись до 2012 версии - сейчас не парьтесь - да прибудет Интерсистемз с Вами. 3 - ??? о ужас, кошмар! 4 - наследоваться и не делать на наследниках Extent индекса - воплощенное зло. В общем же скажу аккуратно - пока Вам неудобно (запрещено, неприятно и проч.) делать хранимое наследование, мои приложения будут уделывать ваши и далее. Видел тут широко открытые глаза конкурента: "У Вас что, все документы в одном глобале, это-ж не должно работать???" Мля, это говорил чел, у которого в нескольких классах НИ ОДНОГО ИНДЕКСА НЕТ ваще. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2013, 08:36 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
ptn3 - Все данные и индексы потомков первого хранимого класса, будут содержать полное имя класса потомка, то есть каждая запись будет содержать дополнительную текстовую строку на 10-20 символов. kolesov 3 - ??? о ужас, кошмар! Типа тест. Создаем две области ( с новыми БД ) и три класса в каждой. Область №1 - в одной используем общее хранение Код: vbnet 1. 2. 3. 4. 5.
Область №2 - раздельное хранение Код: vbnet 1. 2.
В каждой области выполняем Populate(100000) для каждого класса. Сравниваем размеры баз write $p($zu(49, $zu(12,"") ),",",4) Для zv 2013.1 Unicode: общее хранение 31мб, раздельное хранение 11мб ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2013, 13:31 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
Я прошу прощение. Вопрос вроде был такой: Как можно провернуть такую миграцию? Соответственно вроде как дальше должны были пойти примеры, что-то типа скрипта для посроения INSERT ... SELECT ..., решения вопроса по генерации новых сквозных surrogate pk key и апдейта FK полей. Казалось бы, при чем тут наследование? Можно конечно спросить, в чем причина смены архитектуры хранения - но либо я не заметил, либо никто не спросил. PS Немного огня ))) Наследование - зло. Наследование в хранимых классах в Cache - зло в кубе. Со злом надо осторожно - так же, как и с добром. В меру. Это как первый принцип построения распределенных систем - не делай систему распределенной. Однако если человеку надо, то может есть у него объективные причины? Может он делает злую систему? ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2013, 13:58 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
Oleg OleninКазалось бы, при чем тут наследование? Можно конечно спросить, в чем причина смены архитектуры хранения - но либо я не заметил, либо никто не спросил.sigmovТ.е. все они храняться в разных глобалах, ID везде по-умолчанию икрементальные. Довольно беспонтово получилось..... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2013, 14:24 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
servitOleg OleninКазалось бы, при чем тут наследование? Можно конечно спросить, в чем причина смены архитектуры хранения - но либо я не заметил, либо никто не спросил.sigmovТ.е. все они храняться в разных глобалах, ID везде по-умолчанию икрементальные. Довольно беспонтово получилось..... Причина - понты? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2013, 15:10 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
Oleg OleninPS Немного огня ))) Наследование - зло Ага ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2013, 15:25 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
Oleg OleninПричина - понты?Я чего-то другого пока не вижу. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2013, 15:32 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
kolesov,Видел тут широко открытые глаза конкурента: "У Вас что, все документы в одном глобале, это-ж не должно работать???" Спасибо позабавило. Я уточню на всякий случай. Мы уже не храним все документы в одном глобале. Надеюсь вы правильно поймете слово "уже" И да, несмотря на то что это действительно работает, выполнено поверх стандартных классов каше данный подход не несет перед собой каких либо особых преимуществ. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2013, 15:47 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
doublefint,В каждой области выполняем Populate(100000) для каждого класса. Это у вас еще по сути нет ни одного индекса, кроме экстента :) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2013, 16:09 |
|
Слияние классов в одну глобаль
|
|||
---|---|---|---|
#18+
PtnМы уже не храним все документы в одном глобале. Мы тоже, вначале хранили, потом не хранили, теперь снова храним. Догоняйте! Во всех смыслах ;) Трудно спорить с аргументами типа "А я с мамой в баню хожу!" или "А зато мой брат бросит твоего брата через во-он тот забор!". Считаю наследование на уровне хранения непревзойденным положительным качеством нашей СУБД. Проверяю это последние немного больше 10 лет - системных проблем не наблюдаю. Плюсы описывать пока не готов. Ибо, повторюсь, мне удобно , что конкуренты боятся такого наследования. И не умеют его использовать Собственно сюда написал только в качестве поддержки ТС, которого, как мне показалось, попытались отговорить от вполне разумного и эффективного шага. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2013, 16:16 |
|
|
start [/forum/topic.php?fid=39&msg=38332424&tid=1557093]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
147ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 268ms |
0 / 0 |