Читал.

С метаданными я б делал не так.

Мой вариат:
1. Все метаданные - пользовательские классы (классы написаные в конфигураторе на встроенном языке)
соответственно каждый класс должен реализовывать метод хранения, изменения, модификации структуры , отображению данных, добавление форм, тестирование данных....
таким образом кому какие метаданные нужны тот такие и рисует + разработка классов и метаданных - фактически одно и тоже.
2. Все классы (метаданные) хранятся в БД вместе с данными

Phoenix писал(а) 16. Января 2008 :: 07:13:


по поводу модулей, прав, форм и описаний согласен - т.е одна таблица под тексты модулей, 2 -я под формы, 3-я под описания. Хотя про формы нужно думать в зависимости что из себя представляют формы.

по поводу все виды метаданных в одной таблицы - так я тоже самое имел ввиду:
класс метаданные от него наследуем все остальные классы, соответственно описания - ссылки на наследников и на таблицы с данными наследников хранятся в таблицы данных класса "Метаданные" и так далее

Про реквизиты не понял - для всех методанных одна таблица реквизитов?

Цитата:


насчет модулей не совсем так.

Таблица - BlobData
используется для хранения модулей, форм, описаний, печатных форм и прочей подобной информации
Поля:
ID - (INT) - Уникальный идентификатор записи
Identifire - (text) - Наименование объекта
IsMain - (INT) - Признак главной формы
TypeID  - (INT) - Тип данных владелец
KindID - (INT) - Вид метаданных
SubKindID - (INT) - Владелец внтуренний (например форма владелец текущего модуля)
ValueType - (INT) - Тип информации, 0-Форма. 1 - модуль, 2 - таблица. 3 модуль объекта, 4 - описание ...
Value - (blob) - Значение
DateTimeLastUpdate - (datetime) - Дата время последней модификации объекта

Таблица - Атрибуты (Details)
Используется для хранения списка реквизитов
Поля:
ID (INTEGER) - Уникальный номер реквизита
Identifire text NOT null - Наименование реквизита
TypeID INT - ИД типа данных
KindID INT - Ид вида метаданных
Position INT, - Номер позиции у владельца
Synonyme text - Представление
AviliableOn INT - Доступен у... Только для справочников: 0 - везде, 1 - для элемента, 2 - для группы
ValueTypeKind Text - Тип+Вид значения реквизита
IsComposite INT - Признак составного реквизита, используется когда реквизит может принимать значение разных типов, видом метаданных
Len INT - Длина, для чисел и строк
Exactness INT - Точность, для чисел
Positive INT - Признак только положительного значения
Obligatory INT - Признак обязательного реквизита
Indexed INT - Признак индексации значения
IsTable INT - Признак того, что это Табличная часть документа
ParentTable INT - Ид табличной части документа

Таблица - Метаданные (Metadata)
таблица для хранения видов метаданых
Поля:
ID INTEGER PRIMARY KEY - Ид метаданного
TypeID INT - Тип метаданного
ParentID INT - владелец, предок
Identifire Text - Идентификатор
Synonyme Text - Синоним
State INT - Состояние, скорее всего будет в виде
Params Text - Параметры, уникальны для каждого типа данных, разделябтся <|>
Comments Text - Комментарий
DateTimeLastUpdate Text - Дата время последней модификации

вот так примерно.

наследование от базового класса и создание типов метаданных на уровне конфига - гуд, но мне кажется сложно, и так или иначе достаточно базовых классов объектов которые есть в той же 1С для большинства задач.
мое видение системы - задача максимум - среда быстрой разработки бизнес-приложений. задача минимум - фреймворк (набор классов) для разработки на том же C++(QT).
информация о метаданных в подобном виде в любом случае будет удобна и нужна.

Nick писал(а) 16. Января 2008 :: 05:09:

Для всего перечисленного тебе хватит VBScript+WEB+SQL-сервера.
Ты фактически описал вебориентированную среду разработки.
ПС. Такое не планируется. И вообще кончайте холивар разводить. Проблема того не стотит.

На счет метаданных в 1 таблице поддерживаю.


Так для информации к размышлению:
в Cache при объявлении класса можно указать какие реквизиты хранятся в базе данных, какие есть индексы по этим реквизитам. Есть, правда, ограничения и по подобным классам (какие точно не помню).

Phoenix писал(а) 16. Января 2008 :: 07:13:

Используя не самодельный модуль работы с БД, а интегрируя готовый кирпичик (согласно #0), *что мешает* нам интегрировать его не напрямую и жестко, а через некий интерфейс? Пусть этот плагин так на всегда и останется единственным, но пусть это будет *опция* а не данность?

Интегрируя движок языка и реализуя виртуальную машину, *что не дает нам* сделать это не намертво, а придумать интерфейс, и воткнуть в него этот плагин?

Это дополнительная работа. Да.
Но прикиньте, какого объема ожидается проектик? Не шибко меньше 7.7. При этом, мы сидим не в одном офисе, как авторы 7.7, а раскиданы по городам и странам. Поиск багов и отладка должны быть проще при модульной структуре, особенно если сделать переключение интерфейсов в отладочный режим, так ведь?

Чем вариант 2С плох?
Чем вариант "всё в одном и намертво" хорош?

dnp писал(а) 16. Января 2008 :: 10:03:


Не понял  , пожалуйста по пунктам