Здравствуйте Keizer, Вы писали:

K> Например необходимо реализовать следующее:
K>Имеются данные, хранимые в одном справочнике, по номенклатуре, которая может иметь разновидности:
K>Каждая разновидность (например товар или услуга) имеет свой набор свойств.
K>Каждое свойство имеет свой способ представления. Например

K> I II III

K> Товар — Алкоголь — [ литраж, цвет бутылок, сертификат ...]
K> Товар — Кондит. изделия — [процент сахара, тип упаковки ...]

K> ......

K> Услуга — Транспортные услуги- [ расход бензина ... ]
K> Услуга — Консультации — [ временные затраты ]
K>
K>Видно, что множество свойств (III) может быть представлено разными типами
K>Дата, число, строка, ссылка на объект таблицы данных.

K>Существуют ли примеры реализации подобной схемы с учетом того, что свойства могут добавляться пользователями
K>Например у товара типа "Алкоголь" появится новое свойство, допустим,"содержание спирта" ?
K>Все это разумеется без изменения структуры БД, или модернизации src.

K> Интересуют не столько готовые реализации сколько идеи

Насчет отображения объектов на РСУБД можно посмотреть здесь.
Что касается свойств, добавляемых пользователем — один из главных вопросов здесь — скорость обработки этих данных. Можно придумать много способов хранения пользовательских свойств в БД — тот же XML и т.д., но как только объем введенных данных превысит определенную величину, обрабатываться это все будет медленно. Поэтому при добавлении полей пользователя желательно еще добавлять и индексы в БД, причем количество индесков и поля, входящие в них, должны зависеть от наиболее часто выполняемых запросов. Либо этим должен заниматься админ, либо должен быть какой-то инструментарий, который по определениям полей при необходимости перестраивает структуру БД ,хотя здесь остается вопрос — какие индексы при этом создавать. В некоторых БД есть wizard'ы, которые "подсказывают" админу, какие индексы содавать, исходя из статистики выполненных запросов, но если будут добавляться поля пользователя, кто-то должен периодически мониторить БД, добавляя при необходимости новые индексы.

Например необходимо реализовать следующее:
Имеются данные, хранимые в одном справочнике, по номенклатуре, которая может иметь разновидности:
Каждая разновидность (например товар или услуга) имеет свой набор свойств.
Каждое свойство имеет свой способ представления. Например

I II III

Товар — Алкоголь — [ литраж, цвет бутылок, сертификат ...]
Товар — Кондит. изделия — [процент сахара, тип упаковки ...]

......

Услуга — Транспортные услуги- [ расход бензина ... ]
Услуга — Консультации — [ временные затраты ]

Видно, что множество свойств (III) может быть представлено разными типами
Дата, число, строка, ссылка на объект таблицы данных.

Существуют ли примеры реализации подобной схемы с учетом того, что свойства могут добавляться пользователями
Например у товара типа "Алкоголь" появится новое свойство, допустим,"содержание спирта" ?
Все это разумеется без изменения структуры БД, или модернизации src.

Интересуют не столько готовые реализации сколько идеи

Заранее благодарен

Здравствуйте Keizer,

Сабж в объектной модели в этом форруме обсуждался пару месяцев назад.

С другой стороны описания идей или реализации persistence layer + O/R mapping для такой модели лично я не видел, хотя найти пытался

Здравствуйте Nikita Dolgov, Вы писали:

ND>Здравствуйте Keizer,

ND>Сабж в объектной модели в этом форруме обсуждался пару месяцев назад.

ND>С другой стороны описания идей или реализации persistence layer + O/R mapping для такой модели лично я не видел, хотя найти пытался


Спасибо за ответ Только я не совсем понял насчет persistence layer + O/R. Если не затруднит, поясните что под этим подразумевалось.

Здравствуйте Keizer,

Буквально сабж. Динамическим свойствам в объектной модели должна соответствовать схема БД и соответственно мэппинг из объектной модели в реляционную. Насколько я понимаю из наличия динамических свойств следует

1) "Тривиальный" подход — постоянно меняющаяся схема (представляю себе перманентную миграцию базы:)) )

либо

2) Некая схема представляющие собой ядро с сущностями типа "property", "type" ... на основе которой создаются реальные сущности за счет чего схема остается стабильной.

Собственно по 2 пункту ничего стоящего мне и не попадалось.

Здравствуйте Keizer, Вы писали:

K> Например необходимо реализовать следующее:
K>Имеются данные, хранимые в одном справочнике, по номенклатуре, которая может иметь разновидности:
K>Каждая разновидность (например товар или услуга) имеет свой набор свойств.
K>Каждое свойство имеет свой способ представления. Например

K> I II III

K> Товар — Алкоголь — [ литраж, цвет бутылок, сертификат ...]
K> Товар — Кондит. изделия — [процент сахара, тип упаковки ...]

K> ......

K> Услуга — Транспортные услуги- [ расход бензина ... ]
K> Услуга — Консультации — [ временные затраты ]
K>
K>Видно, что множество свойств (III) может быть представлено разными типами
K>Дата, число, строка, ссылка на объект таблицы данных.

K>Существуют ли примеры реализации подобной схемы с учетом того, что свойства могут добавляться пользователями
K>Например у товара типа "Алкоголь" появится новое свойство, допустим,"содержание спирта" ?
K>Все это разумеется без изменения структуры БД, или модернизации src.

K> Интересуют не столько готовые реализации сколько идеи

K>Заранее благодарен

Я как раз сейчас пытаюсь реализовать подобную структуру — динамические свойства для объектов.

Каждый объект есть контейнер для свойств и методов, и текущее значение этих свойств хранится в глобальном каталоге объектов. При создании нового объекта читается его схема (свойста по умолчанию для данного типа). При этот каждый "живой" объекты имеет уникальный адрес в каталоге.

Идея очень занимательная, но с реализацией возникают некоторые проблемы.

Здравствуйте Nikita Dolgov, Вы писали:

ND>Здравствуйте Keizer,

ND>Буквально сабж. Динамическим свойствам в объектной модели должна соответствовать схема БД и соответственно мэппинг из объектной модели в реляционную. Насколько я понимаю из наличия динамических свойств следует

ND>1) "Тривиальный" подход — постоянно меняющаяся схема (представляю себе перманентную миграцию базы:)) )

ND>либо

ND>2) Некая схема представляющие собой ядро с сущностями типа "property", "type" ... на основе которой создаются реальные сущности за счет чего схема остается стабильной.

ND>Собственно по 2 пункту ничего стоящего мне и не попадалось.


Сейчас я как раз и пытаюсь реализовать подход №2.
Но если говорить о простых свойствах разного типа, то в принципе выкрутиться можно, но допустим вдруг появляется товар, который имеет некое составное свойство (состоящее из подствойств), как быть ?. Это, собственно, не теория, а реальная практика нашей организации. У нас товары могут иметь массу свойств и подствойств, причем иногда некие множества свойств (группы) могут пересекаться. Причем спрогнозировать появления нового вида товара, будь то конд. изделия или бензопилы "Дружба" порой бывает затруднительно.

Здравствуйте Keizer, Вы писали:

K> Например необходимо реализовать следующее:
K>Имеются данные, хранимые в одном справочнике, по номенклатуре, которая может иметь разновидности:
K>Каждая разновидность (например товар или услуга) имеет свой набор свойств.
K>Каждое свойство имеет свой способ представления. Например

K> I II III

K> Товар — Алкоголь — [ литраж, цвет бутылок, сертификат ...]
K> Товар — Кондит. изделия — [процент сахара, тип упаковки ...]

K> ......

K> Услуга — Транспортные услуги- [ расход бензина ... ]
K> Услуга — Консультации — [ временные затраты ]
K>
K>Видно, что множество свойств (III) может быть представлено разными типами
K>Дата, число, строка, ссылка на объект таблицы данных.
K>Существуют ли примеры реализации подобной схемы с учетом того, что свойства могут добавляться пользователями
K>Например у товара типа "Алкоголь" появится новое свойство, допустим,"содержание спирта" ?
K>Все это разумеется без изменения структуры БД, или модернизации src.

Интересный вопрос! Если свойства могут только добавляться, то подобную схему можно смоделировать путем наследования. Подобный подход насколько я знаю исповедуют Объектно-Ориентированные БД. Но схему БД модифицировать скорее всего прийдется. Что касается реляционных баз, в них тоже можно смоделировать наследование.
Хотя есть еще одна возможность динамически менять свойства, если хранить их как кортежи отношения. Естественно возникает проблема с типами, тогда нужно их явно указывать в кортеже и вся обработка/преобразование типов ложится на программиста.

BR
Sergey

ND>С другой стороны описания идей или реализации persistence layer + O/R mapping для такой модели лично я не видел, хотя найти пытался
Уважаемый Nikita Dolglov! Только не кидайтесь тапочками !
В самой что ни на есть обычной 1С (которая "Торговля", а не "Бухгалтерия") это дело вполне успешно реализовано и используется повсеместно на широких просторах нашей Родины уже года как полтора.
Сорри за "приземленность", но это действительно так.

ND>>С другой стороны описания идей или реализации persistence layer + O/R mapping для такой модели лично я не видел, хотя найти пытался
G>Уважаемый Nikita Dolglov! Только не кидайтесь тапочками !
G>В самой что ни на есть обычной 1С (которая "Торговля", а не "Бухгалтерия") это дело вполне успешно реализовано и используется повсеместно на широких просторах нашей Родины уже года как полтора.
G>Сорри за "приземленность", но это действительно так.

1С говорите ? А что это! А что это такое ? А если серьезно, то у нас есть сертифицированные специалисты по 1С. В настоящий момент когда 1С (между прочим SQL) с треском провалилась (после 2х лет постоянных мучений и доработок) как по скороти так и по реализации по-настоящему динамических свойств возник собственно вопрос на этом форуме. А что касается 1С, то я питаю уважение к этой системе, ее открытости, методам, НО динамика нашего бизнеса высока даже для 1С

Да я не призываю ее использовать. Я ж не изверг какой
Просто в ее промежуточной логике есть неплохие идеи. И перенести их на нормальное ядро не так уж сложно.
В "Торговлю" советую заглянуть.

Здравствуйте grad,

>В самой что ни на есть обычной 1С (которая "Торговля", а не "Бухгалтерия") это дело >вполне успешно реализовано

Во первых я имел в виду что грамотного и пространного изложения сабжа (скажем в формате pattern language) я не видел. Понятно что придумано это давно — стоит посмотреть на работы скажем с OOPSLA, но именно на персистенс лэйер ..

Во вторых где ж взять эту 1С? Тем более интересен именно теоретический анализ а не реверсение кода даже если там все прозрачно.

Здравствуйте grad, Вы писали:

G>Да я не призываю ее использовать. Я ж не изверг какой
G>Просто в ее промежуточной логике есть неплохие идеи. И перенести их на нормальное ядро не так уж сложно.
G>В "Торговлю" советую заглянуть.

Да 2 года заглядываем в "Торговлю" но нормальной модели реализации сабжа там
увы нет. Еще раз повторю, что не поверхносто мы работали и писали конфиги под "Торговлю".

>но нормальной модели реализации сабжа там
А что подразумевается под НОРМАЛЬНОЙ реализацией? Если цель — оптимизировать быстродействие на выборках, ИМХО от динамических свойств надо держаться подальше и вообще проще надо выступать.
А если — "свойства могут добавляться пользователями без изменения структуры БД", "вдруг появляется товар, который имеет некое составное свойство" и.т.д — дык оно там есть (в типовом релизе). Причем в предельно доступной для пользователя форме.
P.S.: кстати по поводу извечной темы пинков в сторону 1С. Полгода наблюдаю под боком натужные попытки заставить заработать Oracle Applications и ей же ей особенных преимуществ не наблюдаю, ни в быстродействии и устойчивости,ни в возможностях адаптироваться под задачу. Причем работают не студенты. Вот и не знаю — то ли 1С хорошая программа, то ли OA — :down:

Здравствуйте grad, Вы писали:


>>но нормальной модели реализации сабжа там
G>А что подразумевается под НОРМАЛЬНОЙ реализацией? Если цель — оптимизировать быстродействие на выборках, ИМХО от динамических свойств надо держаться подальше и вообще проще надо выступать.
G>А если — "свойства могут добавляться пользователями без изменения структуры БД", "вдруг появляется товар, который имеет некое составное свойство" и.т.д — дык оно там есть (в типовом релизе). Причем в предельно доступной для пользователя форме.
G>P.S.: кстати по поводу извечной темы пинков в сторону 1С. Полгода наблюдаю под боком натужные попытки заставить заработать Oracle Applications и ей же ей особенных преимуществ не наблюдаю, ни в быстродействии и устойчивости,ни в возможностях адаптироваться под задачу. Причем работают не студенты. Вот и не знаю — то ли 1С хорошая программа, то ли OA —

Откройте глаза. Помимо 1С есть еще системы как SAP R/3 работающие под ORACLE. В том же Киеве массовый отказ средних и больших фирм от систем 1С:Предприятие приобрел характер тенденциозности. И дело не в моде и не от хорошей жизни. Вопрос: Сколько измерений свойств товара заложено в 1С ? В 1с есть разрез (если не брать партии и склады)
Признак товара (услуга, товар, ГСМ...), свойства (цена, простые характеристики, ед измерения, валюта учета). И тут у вас появляется алкоголь, в котором требуется инфо о сертификате, содержании спирта признак слабоалкоголка или алкоголка, и еще ряд. Первое что вы, одинэсники сделаете, добавите в справочник поля, Затем у вас появится кондитерка со своими приколами и вы опять полезете кроить метаданные. Это красиво ??? Это профессиональный подход ???

Здравствуйте Leon_o, Вы писали:

LO>Здравствуйте Keizer, Вы писали:

K>> Например необходимо реализовать следующее:
K>>Имеются данные, хранимые в одном справочнике, по номенклатуре, которая может иметь разновидности:
K>>Каждая разновидность (например товар или услуга) имеет свой набор свойств.
K>>Каждое свойство имеет свой способ представления. Например

K>> I II III

K>> Товар — Алкоголь — [ литраж, цвет бутылок, сертификат ...]
K>> Товар — Кондит. изделия — [процент сахара, тип упаковки ...]

K>> ......

K>> Услуга — Транспортные услуги- [ расход бензина ... ]
K>> Услуга — Консультации — [ временные затраты ]
K>>
K>>Видно, что множество свойств (III) может быть представлено разными типами
K>>Дата, число, строка, ссылка на объект таблицы данных.

K>>Существуют ли примеры реализации подобной схемы с учетом того, что свойства могут добавляться пользователями
K>>Например у товара типа "Алкоголь" появится новое свойство, допустим,"содержание спирта" ?
K>>Все это разумеется без изменения структуры БД, или модернизации src.

K>> Интересуют не столько готовые реализации сколько идеи

LO>Насчет отображения объектов на РСУБД можно посмотреть здесь.
LO>Что касается свойств, добавляемых пользователем — один из главных вопросов здесь — скорость обработки этих данных. Можно придумать много способов хранения пользовательских свойств в БД — тот же XML и т.д., но как только объем введенных данных превысит определенную величину, обрабатываться это все будет медленно. Поэтому при добавлении полей пользователя желательно еще добавлять и индексы в БД, причем количество индесков и поля, входящие в них, должны зависеть от наиболее часто выполняемых запросов. Либо этим должен заниматься админ, либо должен быть какой-то инструментарий, который по определениям полей при необходимости перестраивает структуру БД ,хотя здесь остается вопрос — какие индексы при этом создавать. В некоторых БД есть wizard'ы, которые "подсказывают" админу, какие индексы содавать, исходя из статистики выполненных запросов, но если будут добавляться поля пользователя, кто-то должен периодически мониторить БД, добавляя при необходимости новые индексы.

Огромное спасибо за полезный link !!!
Неплохое описание persistent layer

Разговор слепого с глухим...

K>Откройте глаза. Помимо 1С есть еще системы как SAP R/3 работающие под ORACLE.
Плавали, знаем... Мимо кассы. Система 35-летней давности, по возможностям держать данные слабже Access, по встроенным програмным средствам — Cobol, требующая дорогущего железа, AS/400 и целого штата админов для 50 рабочих мест. В ней даже репорт билдера встроенного нет, Crystal Reports всовываются через одно место. Зато по деньгам за консалтинг!!! Между прочим у нас несколько отделов на этом консалтинге кормятся. Годами рисуют бизнес-процессы под неработающий софт.

K>В том же Киеве массовый отказ средних и больших фирм от систем 1С:Предприятие приобрел характер тенденциозности. И дело не в моде и не от хорошей жизни.

А в той же Москве переход средних и крупных фирм на 1С тоже принимает характер тенденциозности. А также переход многих IT консалтерских фирм на работу по внедрению 1С. Просто она в отличие от многих других систем работает. Руки должны расти откуда надо. Проблемы с производительностью? Есть. Причем вполне решаемы. Знаю базу на 200 активных пользователей on-line, знаю базу 25 Гб.

Вопрос: Сколько измерений свойств товара заложено в 1С ? В 1с есть разрез (если не брать партии и склады)
K>Признак товара (услуга, товар, ГСМ...), свойства (цена, простые характеристики, ед измерения, валюта учета). И тут у K>вас появляется алкоголь, в котором требуется инфо о сертификате, содержании спирта признак слабоалкоголка или K>алкоголка, и еще ряд. Первое что вы, одинэсники сделаете, добавите в справочник поля, Затем у вас появится кондитерка K>со своими приколами и вы опять полезете кроить метаданные. Это красиво ??? Это профессиональный подход ???

1) мы не одноэсники. Хотя и общались весьма плотно.
2) непрофессиональным ИМХО можно считать подход когда нечто поливается грязью на основе неполных данных, неумения работать с системой, просто упрямства.
3) повторю еще раз. Последний раз. Крупным шрифтом.
В ТИПОВОЙ 1С ДАВНЫМ-ДАВНО РЕАЛИЗОВАНА ВОЗМОЖНОСТЬ РАБОТЫ С ДИНАМИЧЕСКИМИ СВОЙСТВАМИ. ДЛЯ ЗАВЕДЕНИЯ НОВОГО СВОЙСТВА НЕ НАДО ВНОСИТЬ ПРОГРАММНЫЕ НАСТРОЙКИ В СИСТЕМУ. ВСЕ ПРОИСХОДИТ ИСКЛЮЧИТЕЛЬНО В ПОЛЬЗОВАТЕЛЬСКОМ РЕЖИМЕ И БЕЗ ВСЯКИХ ТАМ "КОНФИГУРАТОРОВ". ЗНАЧЕНИЙ СВОЙСТВА МОГУТ ЗАДАВАТЬСЯ ПО ВЫБОРУ ИЗ:
1)ЗАДАННЫХ В СИСТЕМЕ ПЕРЕЧИСЛЕНИЙ
2)НОВЫХ ЗНАЧЕНИЙ СКАЛЯРНОГО ТИПА
3)НОВЫХ ЗНАЧЕНИЙ МНОЖЕСТВЕННОГО ТИПА
ВО ВСЕ ОТЧЕТЫ УЖЕ ВСТРОЕНА ВОЗМОЖНОСТЬ ОТБОРА ПО СВОЙСТВАМ. ЛЮБЫМ!!! О КОТОРЫХ ПРОГРАММИСТ ЗНАТЬ НЕ ЗНАЕТ И ВЕДАТЬ НЕ ВЕДАЕТ.
Возьмите типовую поновей и убедитесь сами.
Изобретение велосипеда — вещь хорошая с точки зрения повышения квалификации, но для реальной практики мало подходящая.
Задачи учетного типа являются простейшими и средствами 1С решаемы вполне.

Все больше не хочу возвращаться к этому разговору. Начинает напоминать рекламу. Тем более на таком сайте и на таком форуме это вовсе ни к чему.
Удачи!

Здравствуйте grad.

Извините что затрагиваю больную тему 1С: если вдруг есть под руками та самая типовая конфигурация, будьте добры, закиньте на mgx@ukr.net.
Хотелось бы подискутировать на тему 200 пользователей и базы в 25Гб, но к сожалению этот вопрос выходит за рамки темы форума.
Собственно о динамических свойствах: судя по всему Keizer не сегодня на свет народился и SAP R/3 здесь привёл лишь в качестве примера 'чего-то' работающего под ORACLE, а также знаком с реализацией подобных вещей в 1С, да к тому же знает каким образом в 1s_const хранятся различные типы приведенные к VARCHAR с использованием 36-ричной системы счисления, но это не важно. Человек у нас с вами спрашивает что собственно мы делаем в таких случаях, идею ему подкинуть надо, а с детальной реализацией он и без нас с вами справится. А идеями ни кто делится не хочет или не может?...

mgx> Извините что затрагиваю больную тему 1С
да что уж там, так уж и больная. :shuffle: Нормальная софтина, качественно написана(ну ладно, не везде) для соего времени, своих задач и своей цены.
Конфигурации под рукой нет, да и вообще давненько я 1С уже не видал. Любая торговля начиная с 8.7 релиза. Если появится зашлю.
mgx> Хотелось бы подискутировать на тему 200 пользователей и базы в 25Гб
Естественно там много чего кроме Конфигуратора используется. Авторы сих чудес к дискуссиям кстати не предрасположены — они за оптимизацию денег берут.
mgx> SAP R/3 здесь привёл лишь в качестве примера
Вот это действительно больная тема. Просто работаю сейчас в некоем московском интеграторе, достали уже консалтеры и вся это болталогия. Чуть что: R3! Oracle Applications! А знакомы с ними преимущественно по статьям в рекламных мурзилках. Реально сабжем владеют единицы. И у этих то господ настроение как раз не такое радужное.
mgx> хранятся различные типы приведенные к VARCHAR с использованием 36-ричной системы счисления
1sblob.dbf — помню еще чего-то ;) Да уж кривовато.
mgx> А идеями ни кто делится не хочет или не может
Увы, pattern language затребованным не владею, да и в форум этот залез достаточно случайно. Однако как это реализовано в 1С представляю, и как таблицы в этом случае вяжутся, и как система это обрабатывает. На пальцах не покажешь. Вот я посоветовал посмотреть, в конце концов 1С сама себе CASE средство. А мне в ответ не удосужившись даже посмотреть "его там нет" да еще и в столь категоричной манере! Обидно, да?