Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Допустим есть классы A, B, C. Класс B был создан на основе супера А. Некоторое время мы создавали экземпляры В... в любой момент мы могли сделать выборку Код: plaintext Шло время... нам потребовалось внести коррективу и у В появился новый супер С. Но теперь при Код: plaintext 1) Это нормально, как вы считаете? 2) Если нет, то, что я делаю неправильно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2010, 18:03 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Да, это фича. Наследование хранения (глобалов, где оно будет храниться, индексов и т.д.) идет только от первого суперкласса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2010, 18:07 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Блок А.Н. , а в ваших проектах пригодилось бы распространение наследование хранения на все суперы? З.Ы. :( Капец... Только думал, что всё прекрасно, а тут оказывается есть "фичи". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2010, 18:15 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Я технически не представляю себе это. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2010, 18:54 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
ZLOI13З.Ы. :( Капец... Только думал, что всё прекрасно, а тут оказывается есть "фичи". Можете привести пример систем где есть подобные фичи ? Поди документ-ориентед причем на самом деле у всех документов там один невидимый предок ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2010, 21:01 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Блок А.Н. Я технически не представляю себе это. Но если можно для всех первых родителей, то почему нельзя для всех? Ладно, Видимо вы знаете структуру Cache глубоко, поэтому вам виднее, конечно, и я не вижу каких-то камней. Теперь надо будет искать альтернативу Cache. Но чувствую, что её нет. Ptn Можете привести пример систем где есть подобные фичи ? Поди документ-ориентед причем на самом деле у всех документов там один невидимый предок ? Если нет альтернативы, это не означает, что это нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 05:10 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Ну смотрите Класс А хранится в хранилище ^AD Класс С хранится в хранилище ^CD Где предлагаете хранить класс ^B? Запросы для класса C делаются на основе данных о его структуре, а не данных о структуре его наследников, правильно? Значит делая запрос по классу С мы не знаем, что один из унаследованных классов хранится в хранилище ^AD, поэтому он запросе будет невиден. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 06:18 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.Ну смотрите Класс А хранится в хранилище ^AD Класс С хранится в хранилище ^CD Где предлагаете хранить класс ^B? Запросы для класса C делаются на основе данных о его структуре, а не данных о структуре его наследников, правильно? Значит делая запрос по классу С мы не знаем, что один из унаследованных классов хранится в хранилище ^AD, поэтому он запросе будет невиден. ^В у нас хранится в ^AD? Тогда очевидно надо хранить ссылки на него в ^CD. Он же ведь не боком для С, тот ведь тоже папа, как и А. В общем я понял, что инфраструктура Cache не позволяет реализовать то, что мне нужно. Обидно, что потратил время на изучение сей системы. Ушёл от реляционной модели как раз потому что там многие вещи нельзя было реализовать или только с большими сложностями. Получается, чтобы найти экземпляры какого-то класса, надо прошерстить все классы на предмет входимости его к ним в суперы, сформировать запрос с их участием и убрать дублированные. Т.е. и работа со строками здесь и циклы и куча запросов... :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 08:07 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Ну попробуйте наследовать все от одного класса, будет все в одном хранилище. А если вы так завязаны на объектной парадигме, то почему так упираете на SQL? Там тогда все в методах реализовывать (правда помедленнее будет через объекты, но IS вроде говорили, что сильно оптимизировали работу с ними) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 09:10 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
И вообще, после >>Шло время... нам потребовалось внести коррективу и у В появился новый супер С. Создает ощущение, что у вас давно работает промышленная система на каше после >>Обидно, что потратил время на изучение сей системы. Ушёл от реляционной модели кажется, что вы что-то про каше почитали и что-то маленько попробовали, но до конца в ней не разобрались Есть подозрение, что вы немного преувеличиваете свои потери. Если бы вы работали с каше реально и дольше, то увидели, что там очень много вещей, которые сделаны ЛОГИЧНО, а не ТАК КАК МНЕ ХОЧЕТСЯ. И, я считаю, это правильно. И это не проблема каше, это проблема того, кто не понимает логику ;-) И более того, это свойство, наверное, всех серьезных систем. При работе реальными, уже конкретными проектами часто получается так, что разработчики идут на поводу "хотелок" заказчика, которые с его точки зрения совершенно незначительные и абсолютно нормальные, а с точки зрения системы ломающие логику, создающие заплатки или заложенные мины в будущем. Я думаю, каше не из этих :-) Ни в коем случае не хотел вас обидеть. В вашем случае скорее всего решение просто в другом, а не в множественном наследовании. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 09:34 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.Ну попробуйте наследовать все от одного класса, будет все в одном хранилище. А если вы так завязаны на объектной парадигме, то почему так упираете на SQL? Там тогда все в методах реализовывать (правда помедленнее будет через объекты, но IS вроде говорили, что сильно оптимизировали работу с ними) Ну у меня примерно так и получается. Есть общий класс Entity от него прочие идут, например, Document, ну а от документа наследуется схема и т.д. Но вот допустим у меня есть класс от Entity, но он ещё и реальный объект. Т.е. имеет координаты и массу. Вот допустим есть у меня проект автоматизации (я пишу расширение для автокада, чтобы ускорить процесс проектирования систем АСУ ТП), хочу я узнать какие объекты реального мира в нём участвуют, чтобы допустим по их координатам и 3д моделям создать общую 3д модель всего проекта. Чтобы получить все экземпляры классы которых наследуются от реального объекта придётся перетрести все ClassDefinition, сформировать единый запрос, выкинуть дубли и т.д. Причём Super - это строка, т.е. придётся ещё со строками работать. Конечно, всё это реализуемо, но не так просто, как хотелось бы, вот я о чём. На SQL я не упираюсь, просто как пример привёл. Вообще хочется создать систему, чтобы она хранила не просто данные, а полную информацию о сущностях, с которыми оперирует система, их отношения и проч. И чтобы потом можно было внести информацию из справочников и использовать её как систему принятия решений. Ну типа чтобы она могла сама предложить установить такие-то лотки на таких-то стенах, провести такой-то кабель, потому что помещение скажем с высокой влажностью и там ЭМ помехи высокие. И всё это на основе знаний о данном помещении, его плане, лотках, правилах установки лотков и т.д. Просто я сначала делал систему на основе РСУБД и меня достало добавлять новые сущности и переписывать запросы при малейшем изменении системы. Всё упёрлось в создание объектно-реляционной структуры БД, тогда я и решил найти готовые реализации ОО подхода. Мне не нравится, что в Cache мало информации об отношениях между классами, Super - это строка... а почему не массив строк? Почему нет списка дочерних классов, это тоже бы не хило помогло при написании методов. Вообще удивительно, что никто из мамонтов (Misrosoft) не занимается развитием ООСУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 10:08 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Блок А.Н. >>Обидно, что потратил время на изучение сей системы. Ушёл от реляционной модели кажется, что вы что-то про каше почитали и что-то маленько попробовали, но до конца в ней не разобрались ... И более того, это свойство, наверное, всех серьезных систем. Согласен. Я просто попробовал. Написал несколько приложений. Не правильно излагаю свои мысли, пожалуй. С этим проблема. Пока всё в начале и я хочу быть уверенным, что в будущем не будет фатальных проблем. Просто по мере роста системы её классы будут расширятся новыми свойствами, отношениями, старые будут заменяться и т.д. Вот мне понравилось, что я уже сейчас смог сделать универсальную форму для создания/редактирования объектов. Используя РСУБД я бы такого не смог. Однозначно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 10:18 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Блок А.Н., Ну и спасибо за ваши комменты. У меня совсем нет желания спорить, мне нужна помощь. Кстати, а какого рода вы систему разрабатываете на Кашэ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 10:20 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
СибирьЭнерго, система работы с населением. Там много всего, гораздо больше, чем кажется на первый взгляд. Разрабатывали не мы, мы только дорабатываем и поддерживаем, правда объем переработок уже, пожалуй, превысил объем начальной системы ;-) Как минимум один из первоначальных разработчиков на форуме есть. В вашем случае не совсем понял, что у вас не получается, я так понял, что у вас так и так все наследуется от класса А? Не совсем понятно, что значит в каше мало информации о взаимодействии классов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 11:34 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
ZLOI13, Такая реализация хранения данных в БД. Было много обсуждений о специфике множественного наследования когда Каше только вышла и еще как-то не устоялось, что там будет внутри. Чисто логически большинство, насколько я помню (или потому что я так думал), пришли к выводу, что множественное наследование имеет смысл только для методов. Множественное наследование структур хранения данных и хранимых свойств приводит к множеству логических проблем как при первоначальном проектировании, так и при внесении изменений в готовый проект. Самое простое - одинаковые имена свойств в суперклассах - уже приводит к фейерверку фантастических предположений, как это будет работать. То есть дополнительно наследовать имеет смысл только классы - библиотеки методов. И лучше следить за именами методов, чтобы не было одинаковых в наборе суперклассов. А то опять фантазии, зависящие от версии Каше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 11:45 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Мысли вслух: Судя по встроенной системе документации на классы, получить список наследников не представляется большой проблемой... Множественное наследование в большинстве распространенных ОО языков не поддерживается, а тут база данных... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 11:46 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.СибирьЭнерго, система работы с населением. Там много всего, гораздо больше, чем кажется на первый взгляд. Разрабатывали не мы, мы только дорабатываем и поддерживаем, правда объем переработок уже, пожалуй, превысил объем начальной системы ;-) Как минимум один из первоначальных разработчиков на форуме есть. Круто :) А у вас есть какая-то концептуальная схема вашего проекта? Имеется ввиду вы пользуетесь каким-то средствами моделирования? Блок А.Н. В вашем случае не совсем понял, что у вас не получается, я так понял, что у вас так и так все наследуется от класса А? Да, наверное,тут вопрос в реализации, если я не буду ошибаться в последовательности суперов, то и проблем не будет. Да, зря я начал панику. Блок А.Н. Не совсем понятно, что значит в каше мало информации о взаимодействии классов? Упс, SubclassOf для этого есть. Не посмотрел в запросах ClassDefinition. :\ Ладно, буду ковырять дальше. Извините, что запаниковал. Спасибо за комменты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 12:04 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
И точно, в версии 2008 у %Dictionary.ClassDefinition есть запрос SubclassOf(super As %String, initval As %String = "") Selects Name As %String(MAXLEN=256) As ClassName The SubclassOf query produces a list of classes that are subclasses of the super class starting the search at initval. For example this allows you to find all the subclasses of %CSP.Page very easily. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 12:07 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
В общем, всем спасибо за ваши замечания. Просто я малость растерялся, потому что не знаю как правильно. Хочется чтобы в базе были все онтологии, с которыми будет работать система. И столько вариантов их реализации, что голова кругом. Постараюсь больше глупости не писать. Хороших вам выходных :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 12:10 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Примерко в помощь Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Код: plaintext 1. Код: plaintext 1. Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 12:31 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
doublefint, угу у меня нечто подобное получилось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 12:47 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
ZLOI13Но если можно для всех первых родителей, то почему нельзя для всех? Почему нельзя ? Можно - вводите одного мега -супер-предка и вуаля. Вот только будьбе готовы что если вам захотеться вынести объекты таблицы С в отдельную базу/машину у вас ничего не получиться. Вы поймите простую вещь когда вы пишете SELECT вы работаете с реляционной СУБД которая знать ничего не знает про ООП. Без единого супер предка ваше требование означает хранить ДВЕ записи для ОДНОГО объекта - одну в таблице потомков А, вторую в таблице потомков С. А две записи для РСУБД - это уже лажа. Все подобные техники одним ООП реализуются только на бумаге и в ряде случаем в оперативной памяти в момент выполнения. На уровне СУБД требуемое решается отдельными архитектурными решениями - например введением таблицы индекса по все документам/ классом. Либо просто приложение строиться таким образом что бы необходимость в одновременных запросах select * from A и select * from С не возникало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 14:31 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
doublefintМысли вслух: Судя по встроенной системе документации на классы, получить список наследников не представляется большой проблемой... Не представляет сложности построить граф и в момент выполнения выяснить предков и потомков на уровне метаданных - то есть вы на уровне имен классов узнаете кто от кого наследуется. Но как только вы опускаетесь до данных - до конкретных экземляров классов - будьте готовы к работе с разными таблицами. doublefintМножественное наследование в большинстве распространенных ОО языков не поддерживается, а тут база данных... На самом деле можно написать интеллектуальный запрос - который будет выяснять всех классы потомки и делать запросы самостоятельно. Например select DocumentNum,Summ from С выясняет что его потомки на уровне кода (то есть ООП) имеются в таблице класса А и собственно таблицы С и сам выполняеться select DocumentNum,Summ from C union select DocumentNum,Summ from A where x__classname="~B~" Но это имеет смысл только для заранее известных запросов. Оформляется в виде Query MyUinionExtent в классе C и пользуетесь через %ResultSet или call в ODBC ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 14:42 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
ZLOI13Имеется ввиду вы пользуетесь каким-то средствами моделирования? Полгода рисовали схемки в Rational Rose в начале проекта - прикольно, но IMXO оно того не стоило. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 14:45 |
|
||
|
Супер всего один :( ?
|
|||
|---|---|---|---|
|
#18+
Ptn, палитесь, вопрос мне был Нет, не используем, тз на доработку тоже далеко не всегда есть, обычно приходят и говорят - "вот тут у вас проблема". Мы говорим "ага, понятно", и переделываем. А если нам кажется, что нам предлагают сделать что-то нехорошее и противоестественное, или оно вносит какую-то нелогичность в систему, а потом мы сами же будет виноваты, то можем потребовать и ТЗ. К слову сказать, это больше способ отсрочить выполнение и заставить человека разобраться, чего же он хочет. В итоге делаем стараемся делать все "по понятиям" а не "по документам". Так получается лучше и быстрее. Правда у нас группа маленькая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2010, 14:57 |
|
||
|
|

start [/forum/topic.php?fid=39&msg=36629929&tid=1558073]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
59ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
81ms |
get tp. blocked users: |
2ms |
| others: | 231ms |
| total: | 417ms |

| 0 / 0 |
