|
|
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовВ идеале мне нужна БД которая бы хранила отдельно каждый объект со его полной историей с непосредственным доступом к нему и его историческим копиям, плюс могла бы их классифицировать по заданным правилам статически и/или динамически и обеспечила бы автодоступ в обеих направлениях. Это только первый шаг. Предположим что он уже сделан. А что делать дальше с этими объектами ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2007, 11:40 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
мод Сахават ЮсифовВ идеале мне нужна БД которая бы хранила отдельно каждый объект со его полной историей с непосредственным доступом к нему и его историческим копиям, плюс могла бы их классифицировать по заданным правилам статически и/или динамически и обеспечила бы автодоступ в обеих направлениях. Это только первый шаг. Предположим что он уже сделан. А что делать дальше с этими объектами ? Например конфигурировать изделии исходя из имеющиеся сети технологических маршрутов, создавать и назначить группы взаимозаменяемых ресурсов на операцию, создавать иерархии. А IP - маршрутизация сложная штука. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2007, 12:41 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовНапример конфигурировать изделии исходя из имеющиеся сети технологических маршрутов, создавать и назначить группы взаимозаменяемых ресурсов на операцию, создавать иерархии. Это все сводится к манипуляциям над свойствами отдельных объектов, т.е. шаг 1. 2 шаг - алгоритмы обработки этих объектов/свойств. Если объекты и св-ва создавал/менял пользователь, то и алгоритмы должен писать тоже он, а вот это проблема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2007, 15:22 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Если обратиться к устройству ОРСУБД Оракл, то в этой СУБД задача решена так. Мы можем создавать древовидные иерархии классов (пользовательских объектных типов). Для хранения экземпляра определённого типа, мы можем использовать отдельную таблицу или таблицу используемую для хранения экземпляров супертипа (фактически, супертип может и не иметь экземпляров, т.е. быть абстрактным). Рассмотрим второй вариант. Поскольку тип наследует все атрибуты супертипа, то в для хранения этих атрибутов в реляционном ядре БД используются теже колонки, что используются для хранения атрибутов супертипа. Для атрибутов которые определены в нашем типе, в реляционной таблице создаются новые колонки. Эти колонки используются ТОЛЬКО для хранения значений атрибутов самого нашего типа и любых его подтипов, которые так же их наследуют. Такая схема несколько расточительна, когда дерево типов широкое, а из супертипа наследуется относительно небольшое число атрибутов (относительно количества атрибутов в его подтипах). Но, если между типами так мало общего, то и таблицы для хранения экземпляров скорее всего мы выберем разные. Т.е. Оракл считает, что в реляционной БД каждая колонка должна отвечать только за один атрибут объектного типа данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2007, 20:56 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
mcureenab ... Интересно то, что объект как бы рождается и развивается. По очень похожим схемам, но все же разным. В конце пути все они друг от друга не очень-то отличаются. Все вроде люди, но одни узкоглазые, другие черножопие, а третьи желтоухие. Иногда их надо иденцифициравать под одним ракурсом, а иногда под другим. И в отличии от чека, который и рождается по подобию, эти твари рождаются без рук, ног..., а наращивают их по росту, а иногда могут пойти на дрова недорослями. И каждое из их состояний значима и подлежит идентификации. Вобщем, я сделал так - при рождении уникальный идентификатор и читабельное имя. Дальше наследуемые и приобретенные свойства по ходу роста. (Для декомпозиции-конфигурации). Наследуемые свойства значений не имеют. А приобретенные имеют. Не знаю насколько это хорошо, но меня пока устраивает. Дальше по ходу будет видно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2007, 21:45 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
мод Сахават ЮсифовНапример конфигурировать изделии исходя из имеющиеся сети технологических маршрутов, создавать и назначить группы взаимозаменяемых ресурсов на операцию, создавать иерархии. Это все сводится к манипуляциям над свойствами отдельных объектов, т.е. шаг 1. 2 шаг - алгоритмы обработки этих объектов/свойств. Если объекты и св-ва создавал/менял пользователь, то и алгоритмы должен писать тоже он, а вот это проблема. Пользователь алгоритм и пишет - в виде графа технологий и графа связей на этом графе. А прога интерпретирует и упаковывает экземпляры возможно плотно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2007, 21:48 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовИнтересно то, что объект как бы рождается и развивается. Это я так понял речь идёт о динамической типизации объектов, когда в процессе жизненного цикла объект приобретает или теряет типы (и связанные с ними атрибуты и операции). ИМХО, статическая типизация (как в C++) в отличии от динамической (как в JavaScript) хоть и менее гибкая, но более управляемая. В любом случае, используя даже статическую типизацию можно строить сложные объекты. Просто эти функции будут реализованы не в языке, а в библиотеке. Рожать только имя объекта, наверное не имеет большого смысла. Всё таки после создания объект должен быть инициализирован и готов к использованию. Более того, по спецификации OMG, далеко не все объекты имеют честь носить уникальное имя, большинство объектов в системе идентифицируются только по ссылке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2007, 22:54 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
mcureenab Рожать только имя объекта, наверное не имеет большого смысла. Всё таки после создания объект должен быть инициализирован и готов к использованию. Более того, по спецификации OMG, далеко не все объекты имеют честь носить уникальное имя, большинство объектов в системе идентифицируются только по ссылке. Дело в том, что растущий объект не всегда может быть инициализирован полностью. Инициализируются полностью только те объекты, которые дальше развиваться не будут. Я раньше говорил - инициализуруются приобретенные-собственные, ни от чего не зависимые свойства, а унаследованные свойства остаются пустыми. Они будут инициализироваться во время конфигурации сверху вниз. Т.е., в конце роста иногда получается тип, а иногда объект. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2007, 00:36 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовПользователь алгоритм и пишет - в виде графа технологий и графа связей на этом графе. Я имел ввиду совсем простой случай: пользователь добавил новый атрибут (не просто так) и хочет задействовать его в каком-то расчетном алгоритме (уже написанном). Как ему это сделать, ведь пользователь не программист. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2007, 09:37 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
TRJВ базе, с которой я имею дело, имеет место следующая ситуация. Имеется таблица, в которой хранятся данные "объектов" разных "классов". [...] Насколько это приемлемо? На мой взгляд, это приемлемо там, где существует достаточно много "классов" - как, например, в аналитическом учёте бухгалтерских проводок. Если не использовать такой подход, для каждого класса проводок нужно было бы создавать таблицы под хранение их особенностей. Фактически, такие таблицы выполняли бы функции комментариев к особенностям проводок некоторого типа и приводили бы к увеличению стоимости сопровождения системы. Но если таких "классов" не очень много, то я не вижу пользы от использования такого подхода. Для полей типа "дата, время" такой подход считаю вредным, т.к. он также увеличивает стоимость сопровождения системы, не обеспечивая при этом никаких существенных преимуществ. Оценка необходимости применения такого подхода ( таблица, в которой хранятся данные "объектов" разных "классов" ) для решения конкретной задачи, на мой взгляд, должна осуществляться именно с точки зрения обеспечения минимизации стоимости сопровождения системы, реализованной с применением такого подхода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2007, 10:51 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
мод Сахават ЮсифовПользователь алгоритм и пишет - в виде графа технологий и графа связей на этом графе. Я имел ввиду совсем простой случай: пользователь добавил новый атрибут (не просто так) и хочет задействовать его в каком-то расчетном алгоритме (уже написанном). Как ему это сделать, ведь пользователь не программист. В моем конкретном случае пользователь может применить свойства в формулах инициализации унаследованных свойств. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2007, 12:11 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов В моем конкретном случае пользователь может применить свойства в формулах инициализации унаследованных свойств. Примеры: 1. в формулах для расчета сумм проводок 2. расчетные атрибуты объектов (похоже на ваш случай) 3. некоторые виды отчетов 4. при написании пользовательских хранимых функций 5. т.н. "вставки пользователя" - что-то типа триггеров при обработке объектов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2007, 12:45 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовДело в том, что растущий объект не всегда может быть инициализирован полностью. Полностью тоже не надо. Например, существует ленивая инициализация. Но, после инициализации объект должен находится в непротиворечивом состоянии, в противном случае его поведение будет непредсказуемым. Если объект растёт, то каждое его состояние должно допускать дальнейший рост. Объект без состояния это пустышка, NULL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2007, 15:23 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовТ.е., в конце роста иногда получается тип, а иногда объект. Класс объекта можно описать с помощью метакласса и т.д. Точно так же структура данных может быть описана метаданными. Обычно, классы конструируются из метаклассов на этапе разработки, а объекты на этапе выполнения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2007, 15:56 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
mcureenab Сахават ЮсифовТ.е., в конце роста иногда получается тип, а иногда объект. Класс объекта можно описать с помощью метакласса и т.д. Точно так же структура данных может быть описана метаданными. Обычно, классы конструируются из метаклассов на этапе разработки, а объекты на этапе выполнения. Да кто спорить то? :) Я просто хотел сказать, что приходится изголятся вместо того, что бы сказать стандартным хранилищам типа SQL Server - создай такой объект (может быть по какому то шаблону, с переопределением, добавлением, удалением свойств), отметь определенные его свойства конфигурируемыми и включи его в нужные классификаторы. Ведь нужда в этом везде и всюду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2007, 17:39 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов Да кто спорить то? :) Я просто хотел сказать, что приходится изголятся вместо того, что бы сказать стандартным хранилищам типа SQL Server - создай такой объект (может быть по какому то шаблону, с переопределением, добавлением, удалением свойств), отметь определенные его свойства конфигурируемыми и включи его в нужные классификаторы. Ведь нужда в этом везде и всюду. Да вроде с этим нет проблем. Например, Оракл поддерживает типы XML, anyData, anyType. В общем смешение данных и метаданных (тэгов) в одной записи, динамическая типизация - объективная реальность. Как то исторически сложилось, что каталог БД могут изменять только разработчики системы. Фактически, любой квалифицированный пользователь системы в состоянии самостоятельно менять структуру БД. К сожалению, очень немногие прикладные программы и средства разработки поддерживают такую возможность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2007, 19:46 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
> К сожалению, очень немногие прикладные программы > и средства разработки поддерживают такую возможность. Не "к сожалению", а "к счастью". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2007, 23:26 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
guest_20040621> К сожалению, очень немногие прикладные программы > и средства разработки поддерживают такую возможность. Не "к сожалению", а "к счастью". Нет. К сожалению. Дело другое, что эти изменения должен вносится не напрямую, а через владелеца схемы, а тот должен контролировать непротиворечивость и целостность своего слоя схемы. А так ерунда все эти хранилища, толку от них мало, а гемора полный вагон. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2007, 23:35 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
>> Не "к сожалению", а "к счастью". > Нет. К сожалению. Эта борьба обычно вполне безнадежна...(цитата из этой старенькой статьи ) ТЕЗИС 2. Основная проблема программирования 2.1. Сложность есть мера неоднородности. Чем более разнообразны составляющие нечто части, чем более разнообразны образуемые между частями связи - тем выше сложность этого нечто. Сложность вселенной, состоящей из сложенных одинаковым образом одинаковых кирпичей, равна сложности одного кирпича и образуемых им с соседями связей (теорема редукции сложности). Таким образом, сложность выражает не массоэнергетические характеристики мира (см. E=m*c**2), а структурные его свойства, причем весьма емкО и общО. 2.2. Все разработчики программ имеют дело исключительно со сложностью. Программы не имеют ни массы, ни энергии (если отвлечься от параметров исполняющего их hardware). Программы - это чистые структуры, и сложность является одним из основных интегральных параметров этих структур. Борьбе со сложностью и посвящают программисты свою жизнь. Эта борьба обычно вполне безнадежна для программистов, поскольку они не понимают законов мира, в котором пытаются оперировать структурными конструкциями, иерархиями классов или словарями. Программисты - герои "невидимого фронта" боев с колоссальными объемами незнания; герои, которых вооружают негодными погремушками вместо настоящих инструментов постижения истины. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 00:59 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
> Нет. К сожалению. ... > А так ерунда все эти хранилища, толку от них мало, а гемора полный вагон. Я не могу позволить тупым юзерам писать все, что им взбредет в голову. Разумеется, Вы имеете право иметь другую точку зрения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 01:20 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовЯ просто хотел сказать, что приходится изголятся вместо того, что бы сказать стандартным хранилищам типа SQL Server - создай такой объект (может быть по какому то шаблону, с переопределением, добавлением, удалением свойств), отметь определенные его свойства конфигурируемыми и включи его в нужные классификаторы. Ведь нужда в этом везде и всюду. Нужда есть. Только это не функция СУБД, они не этого предназначены. Работа с объектами - функция фреймеворков (и они это все делают неполохо). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 09:25 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Нет. К сожалению. ... > А так ерунда все эти хранилища, толку от них мало, а гемора полный вагон. Я не могу позволить тупым юзерам писать все, что им взбредет в голову. ... Тоже самое можно сказать про тупых программистов, которые пишут что им взбредет в голову. Нет программистов и юзеров. Есть люди более или менее грамотные в области ИТ. Если чел прошёл обучение, сдал экзамен, то почем бы не дать ему право вносить изменения в конфигурацию или даже код системы??? Тут скорее вопрос в защите от дурака, он неправильных или злонамеренных действий пользователя, администратора, разработчика и т.д. и т.п.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 15:27 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
> Тоже самое можно сказать про тупых программистов, которые пишут что им взбредет в голову. Вы будете смеяться, но в данном случае я отчасти готов разделить Вашу точку зрения. Тупых юзеров примерно столько же, сколько и тупых кодеров. В процентном отношении от общего количества. > Нет программистов и юзеров. Программистов вообще нет. Как класса. Есть разработчики и кодеры с разной специализацией и квалификацией. А вот юзеры есть. > Есть люди более или менее грамотные в области ИТ. ;) Вы можете предложить критерии оценки такой грамотности? > Если чел прошёл обучение, сдал экзамен "Пройти обучение" и "сдать экзамен" - это не критерий грамотности. Есть абсолютно тупые люди и с высшим образованием, и с кучей сертификатов, и с хорошей заработной платой. > то почем бы не дать ему право вносить изменения в конфигурацию или даже код системы??? Незачем. Отчеты - пожалуйста. Любые, в пределах прав аккаунта. > Тут скорее вопрос в защите от дурака, он неправильных или злонамеренных действий > пользователя, администратора, разработчика и т.д. и т.п. Бороться с явным вредительством просто. А вот побороть тупость - невозможно. Ни организационно, ни административно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 17:28 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
> Программистов вообще нет. Как класса. Есть разработчики и кодеры с разной специализацией и квалификацией. А вот юзеры есть. Врёшь. Моя должность звучит "... программист". Это официальное название. > ;) Вы можете предложить критерии оценки такой грамотности? ИТ очень широкая область знания. Но для выполнения конкретной работы сформулировать конкретные требования не сложно. > "Пройти обучение" и "сдать экзамен" - это не критерий грамотности. Есть абсолютно тупые люди и с высшим образованием, и с кучей сертификатов, и с хорошей заработной платой. В данном случае IQ человека никого не интересует. Если тупой тупо справляется со своими обязаностями, то это хорошо. Если умный творчески порет косяки, то это плохо. > Незачем. Отчеты - пожалуйста. Любые, в пределах прав аккаунта. Если тебе незачем, то это не значит, что это вообще никому не нужно. Разделение труда пользователя и разработчика это скорее зло чем благо. Если человек знает, что хочет, и может это сделать достаточно хорошо, отпадает нужда объяснять свои желания комуто ещё. > Бороться с явным вредительством просто. А вот побороть тупость - невозможно. Ни организационно, ни административно. Ещё раз повторю. В данном случае IQ человека никого не интересует.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 18:22 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Программистов вообще нет. Как класса. Есть разработчики и кодеры с разной специализацией и квалификацией +1 :) guest_20040621 А вот юзеры есть. ну, у "них" тоже есть ранжирование :) авторРуководство пользователя, являясь документом техническим, не преследует цели завоевать расположение читателя. В то же время руководство пользователя не должно вызывать негативных эмоций у представителей любой из перечисленных групп пользователей. Как же описывать последовательность действий при работе с графическим интерфейсом пользователя? Users и Power (Advanced) users следует «вести через перевал» согласно подходу «делай, как я сказал» по жесткой схеме «действие - результат». Для выполнения операции ТАКОЙ-ТО (или «указанной операции» - помним о шаблонном построении фраз, формализации и унификации) следует («следует» - вежливая отстраненность: хочешь получить результат - делай, как я сказал, не хочешь - не мои проблемы): взять (действие в повелительном наклонении) отвертку в правую руку (рисунок, поясняющий результат); вставить отвертку куда-нибудь (рисунок, поясняющий результат); повернуть отвертку на 90 градусов по часовой стрелке (рисунок, поясняющий результат); и так далее. И все получится, бездумно и без напряжения. И все будут счастливы. Не следует детально расписывать, как «согнуть пальцы», чтобы удержать отвертку. Хватательный рефлекс в равной степени развит и у Users, и у Power (Advanced) users с пеленок. (Неспроста же дети мгновенно осваивают действия с графическим интерфейсом пользователя). Сведения о выполнении операций вида «drag-and-drop» и им подобных читатель сможет самостоятельно почерпнуть из руководства пользователя операционной системы. Administrators, которым подобная детализация никчему, вопреки цели руководства будут испытывать «ощущение авторитетности изложения» по-Кагарлицкому. http://authorit.ru/?c=8&b=6&t=HTML/dd_gui/toc.htm&o=HTML/dd_gui/dd_gui.htm&n=HTML/dd_gui/dd_gui.htm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 18:36 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34310884&tid=1544690]: |
0ms |
get settings: |
6ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
204ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
82ms |
get tp. blocked users: |
2ms |
| others: | 211ms |
| total: | 541ms |

| 0 / 0 |
