-->видел - мы тоже хотели пойти этим путем хранения методанных - но на количестве скважин более 2-3 тысяч сервер умирает.
Что ты здесь имеешь в виду под метаданными? У нас сейчас есть проект некой базы данных "унифицированного" представления объектов. Это некая самостийная оболочка и база метаданных, эмулирующие, как бы ООБД.
примерно тоже у нас и было. база - station oriented
данные были искусственно поделены на категории
-Description (описание к станции/скважине)
-Geologic Description
-Well Construction
- Soil Testing
- Soil Sampling
- Monitoring Event
- Mining/Exploration
- Geophysics
- Well History
- User Category
на каждую категорию был набор таблиц вида.
table_int (id int, value int)
table_float (id int, value float)
table_string (id int, value string)
...
table_fdata (id_field int, name string)
table_tdata(id_user_table int, name string)
у а дальше методом связывания можно сделать любую таблицу на лету из этого набора. и было совершенно безопасно для юзера и базы создавать/удалять вируальные тбалицы. гибкость была невероятная
Пока были требования по хранению невысокие - работало быстро и без переделок чуть ли не с любыv сервером.
но потом наш консалтинг стал говорить они не понимают где таблица lithology, casing, ...
обьяснить что все делается на лету так и не удалось. даже пример ESRI, которая к тому моменту стало продвигать свою обьектно-ориентированную базу их не убедил.
--А почему у вас то сервер дохнет? Не могу понять
потому что предпологалось что софт расчитан будет еще и непртязательный компьютер пользователя. а конструкция запроса размером в несколько килобайт требовала до 20-30 минут на средней машине в MSAccess чтобы построить таблицу в 10000 записей с 30 полями (потому как в запросе будут 30 подзапросов в такой идеалогии).
позже от универсальности поддержки всех DB отказались - от MS Access особенно.
--А вот интересно, например, чтение покрытия ARC/INFO и его отображение вы пишете руками, без дополнительного тузла ESRI? Ну, то есть, читаем эн-байт, первые два байта - это то, второй байт - это сё.и т.д.?
как раз MApObject 2.1 поддерживание чтение всех форматов данных и преобразование координат/проекций. Ну и отображение на экране.
также библиотека манипуляций с изображеними. Все то что нам и надо. А написать интерфейс к этому - 1-2 месяца работы среднего программиста.
--Раскроешь секрет? Как? Извини за нескромность.
я ввел понятие template для баз данных.
собственно это XML - отображающий пользовательскую структуры базы данных и позволяющий добавлять специфичные аттрибуты - типа unit для храния данных - unit отображения в конкретном template.
ну и массу вещей, которые делают жизнь юзера приятной.
Я пробовал сделать так, как вы, несколько лет назад. В инете было много ссылок на похожие решения. Кто – то даже регистри так моделировал (не понятно - зачем). Конечно, это будет работать не быстро, т.к. тебе в этом случае придётся запросы писать накрученные, по существу, включая туда каждое поле из таблиц элементарных типов для записей с id объекта. View-сы тоже не помогут.
Я сделал по-другому. Решил, что должны быть классы и объекты. Ниже упрощенный вариант части главы Приложения к тех.заданию для одного из проектов, вернее отрихтованные выдержки из него (на самом деле частично это уже вариант реализации проекта. Сделана демонстрашка). В реализации всего этого запросы несложные. Работает достаточно быстро. Могу прислать демонстрашку и пояснения как её установить, чтобы не угробить комп.
К сожалению, нет возможности на форуме вставить картинки (движок форума не позволяет вставлять картинки с компов юзеров), чтобы показать структуру базы, окна проги, диалоги и т.д. Так просто читать, конечно, может быть очень кисло. Но может будет и понятным, что то из того, что ниже.
Объект содержит информацию о каждой сущности КО (каталог объектов). Объект представлен группой записей в таблицах СУБД. Объекты сгруппированы в более крупные информационные структуры – классы. Каждый объект принадлежит к некоторому классу объектов. Классы представляют совокупность информационных структур (таблиц), содержащих описание:
данных, позволяющих идентифицировать класс объектов и получить информацию общего характера о классе. Данные включают имя и идентификатор класса, которые должны быть уникальными во всём множестве классов. Классы могут иметь дополнительные атрибуты для хранения в текстовом виде описаний и примечаний. Имя, идентификатор, дополнительные атрибуты классов могут храниться в одной или нескольких системных таблицах, совокупность которых, далее называется реестром классов.
данных о структуре атрибутивной информации объектов класса. Структура атрибутивной информации объектов класса храниться в дополнительных системных таблицах, отдельно от реестра классов. При описании классов созданы системные таблицы для следующих описаний:
таблиц, в которых размещены атрибуты объектов данного класса. Указанная системная таблица (таблицы) называется далее реестром таблиц атрибутов класса. Реестр таблиц должен содержать имена источников данных объектов, например, имёна таблиц, просмотров, алиасы таблиц, необходимые примечания и др. В простейшем случае реестр таблиц может быть представлен одной таблицей, например sys_Table.
полей таблиц, занесённых в реестр таблиц. Указанная системная таблица (таблицы) называется далее реестром полей атрибутивных таблиц класса. В реестре полей могут быть указаны их имена, алиасы, типы данных и детальные описания (длина поля, число десятичных знаков для дробной и целых частей), ограничения на фактические значения данных, значения по умолчанию и др.
данных о методах (функциях), которые применяются для обработки информации, ассоциированной с объектами класса. Системные таблицы, содержащие указанную информацию, называются далее реестром методов (функций). Реестр методов содержит информацию о библиотеках функций, именах и алиасах имён функций. В простейшем случае реестр методов может состоять из одной таблицы, например sys_Method.
служебных данных, определяющих взаимосвязи класса с существующими классами. Информация, определяющая соподчинённость классов, храниться непосредственно в реестре классов, см. выше. Для описания сложных иерархических взаимосвязей классов созданы дополнительные информационные структуры, называемые далее реестром отношений классов. В простейшем случае он может состоять из одной таблицы, например sys_Back.
Классы определяют, какова структура данных, ассоциированных с объектами класса, и какие методы должны быть использованы для обработки данных. Классы - абстрактные описания сущностей. При решении задач модернизации не накладывается ограничений на количество вновь разрабатываемых классов объектов.
Объекты являются конкретными реализациями абстрактных описаний, которые приведены в классах. Например, класс в целом описывает структуру данных и функции их обработки для объектов типа “рудопроявление”, а множеством объектов является множество рудопроявлений.
Объекты представляют совокупность информационных структур, содержащих:
данные для оперативного управления, позволяющие идентифицировать объект и получить о нём информацию общего характера. Данные включают имя и идентификатор объекта, которые должны быть уникальными для подмножества объектов данного класса. Объекты могут иметь дополнительные атрибуты для хранения в текстовом виде описаний и примечаний. Имя, идентификатор, дополнительные атрибуты объектов могут храниться в одной или нескольких системных таблицах, совокупность которых, далее называется реестром объектов. В простейшем случае он может состоять из одной таблицы, например sys_Object.
атрибуты объектов, представляющие дополнительную информацию, необходимую для решения прикладных задач. Атрибуты объектов хранятся в таблицах СУБД, которые определены в соответствии с реестром таблиц класса, и которые называются в дальнейшем таблицами атрибутов объектов.
Реестры объектов, атрибутивные таблицы и реестры классов связаны реляционными отношениями. Таблицы реестров класса не изменяются при создании, модификации, уничтожении объектов. Изменяются только записи в таблицах реестра объектов и таблицах атрибутов.
К классам объектов предъявляются следующие требования:
инкапсуляция данных и методов их обработки. Формальное описание структуры данных и методов класса включено непосредственно в специальные информационные структуры определения класса: реестры таблиц, полей и методов, см. выше. Описание структуры включает описание множества данных (имена, алиасы, таблиц и составляющих их полей, типы полей) и множества методов (имена библиотек и функций). Объекты содержат информацию о классе и фактические значения атрибутов, перечень которых определён в описании класса. Объекты не содержат информации о методах класса. При создании класса автоматически должны быть созданы все информационные структуры, содержащие описание класса. Эти структуры не изменяются при создании, модификации и уничтожении объектов класса. При создании, модификации и уничтожении объекта вся необходимая информация извлекается из описаний соответствующего класса. Инкапсуляция необходима для того, чтобы обеспечить возможность эффективного унифицированного описания многообразия сущностей. Структура класса (реестр классов, см. выше) может содержать дополнительную информацию общего характера, облегчающую решение задач управления и модернизации.
наследование, в том числе множественное, свойств (структур данных) и методов (функций) обработки данных. Это требование заключается в том, что могут быть созданы производные (дочерние) классы на базе уже существующих (родительских) классов. Дочерние классы должны аккумулировать структуры данных и информацию о функциях родительских классов. Объекты дочерних классов должны содержать объединённую атрибутивную информацию с учётом данных родительских классов. Наследование структур данных и методов их обработки должно быть обеспечено по всей иерархической родительских классов. Множественное наследование означает, что может быть создан класс, имеющий в качестве родительских классов два и более иерархически независимых классов. Наследование необходимо для обеспечения эффективности модернизации и масштабирования, сокращения трудозатрат сторонних разработчиков, привлекаемых к работам по поддержке системы, снижения стоимости работ. Эффективность масштабирования достигается за счёт повторного использования кода и структур данных уже разработанных (родительских) классов. Эффективность модернизации достигается за счёт возможности модификации родительских классов. Модификация родительского класса влечёт изменение свойств объектов всех дочерних классов.
полиморфизм. Это требование означает, что функции родительских классов могут быть переопределены (перекрыты) одноимёнными функциями дочерних классов. При переопределении функций родительских классов должна быть вызвана функция, определённая а дочернем классе, а не одноимённая функция, унаследованная от родительского класса. Полиморфизм повышает гибкость при решении задач модернизации.
Для размещения таблиц реестров и таблиц атрибутов объектов используют промышленные СУБД.
Для обеспечения эффективности решения задач адаптации следует унифицировать типы данных системных и атрибутивных таблиц реестров описаний классов и реализаций объектов. Унификация должна быть обеспечена за счёт «группировки и укрупнения» типов данных СУБД в унифицированные типы. Например, типы данных smallint, integer, word могут быть представлены в КО унифицированным типом данных integer. Число и состав используемых типов должно быть минимальным и достаточным для организации эффективного управления данными объектов КО. В атрибутивных и системных таблицах следует использовать следующие основные типы данных:
string - для хранения строк, длиной до 255 символов.
integer – для хранения целых значений, в том числе ссылок на ключевые поля таблиц.
float – для хранения десятичных дробей.
memo – для хранения неформатированного текста произвольной длины.
…
…
…
Ну и т.д. Общие идеи, надеюсь, тебе понятны.
PS. Если это окажется полезным - буду рад.
--Объект содержит информацию о каждой сущности КО (каталог объектов). Объект представлен группой записей в таблицах СУБД. Объекты сгруппированы в более крупные информационные структуры – классы. Каждый объект принадлежит к некоторому классу объектов.
больше усложнений, но в сущности то же самое. ты мен привел устройство базы ArcGIS. Это делает запросы в некоторых случаях проще, но усложняет устройство в необьятное устройство раз.
И если таблицы не имеют близких (subsets) внутри себя, то их количество будет таким же что и без использования это идеалогии.
>>Я пробовал сделать так, как вы, несколько лет назад. В инете --запросы писать накрученные
не такие уж и накрученные. В обшем по настоянию пользователей сделали им таки а-ля MS Enterprise Manager, ограниченный пользовательскими таблицами. Картинки ты видел выше.
xml-template позволяет задать специфику пользовательскиx таблиц для каждого юзера с заданным порядком полей таблиц, делать часть полей невидимыми, накладывать функции, и многое-многое.
В общем компромисс был найден.
Собственно это часть всего комплекса. Был также сделан а-ля DTS позволяющий зачитывать чужие базы и переводить их в свою station-oriented DBMS. С переводом в полей в юниты, координаты, пребразованием top-bottom слои в depth слои. встроенные формулы и многое-многое другое.
Последний раз редактировалось Lepsik 01 июл 2003, 15:06, всего редактировалось 1 раз.
--запросы писать накрученные
не такие уж и накрученные.
Я про то, что не пользователь пишет накрученные запросы, а твой манагер будет создавать громоздкие запросы, если следовать той "универсальной" идеологии, о которой ты писал, и от которой, как ты писал, часть клиентов отказалась (или ваша контора).
Я постил только про то, что если "фундаментальные" данные хранить в отдельных таблицах, то для сборки "виртуальной" таблицы (мы с этого начали тему разговора) манагеру потребуются генерить запросы типа:
" select I.val as FIELD1, F.val as FIELD2, ..... " +
" from i_valuesTable I, f_valuesTable F ..... " +
" where " +
" I.id = " + IntToStr(ID_скважины_из_контрола_манагера) +
" AND " +
" F.id = " + IntToStr(ID_скважины_из_контрола_манагера) +
...
...
Реальный же запрос, который возвращает не всю "виртуальную" таблицу, а хотя бы что нибудь полезное с практической точки зрения - будет гораздо, гораздо накрученнее. Накрученнее - не в том смысле, что его трудно программно сформировать, а в том смысле, что его тяжело быстро выполнять серваку. Тем более, что MS SQL Server 2000 - как оказывается, не такая уж быстрая штука для запросов из таблиц с числом записей, например, под миллион.
Как я постил, поэтому мы и отказались от такого способа формирования "универсальных" таблиц, а сделали так, как я писал выше.
PS. Прости, если неправ или не в тему здесь вставляю свои 5 копеек. Вообще обсуждать или делиться впечатлениям о проге, которой не видел - сложно. В таких обсуждениях люди часто говорят о разных вещах, не понимая друг друга. А вообще радует, что и в Канаде народ творчески подходит к работе. Я как то работал с америкозами, так они творчества на дух не переносят.
--запросы писать накрученные
не такие уж и накрученные.
PS. Прости, если неправ или не в тему здесь вставляю свои 5 копеек. Вообще обсуждать или делиться впечатлениям о проге, которой не видел - сложно. В таких обсуждениях люди часто говорят о разных вещах, не понимая друг друга.
я уже писал, что мы отказались от Object-oriented структуры в стиле ESRI и работает напрямую с набором пользовательских таблиц. Все работает максимально быстро. никаких view теперь
---- А вообще радует, что и в Канаде народ творчески подходит к работе. Я как то работал с америкозами, так они творчества на дух не переносят.
творчество необходимо на определенном уровне. когда все начинают заниматься творчеством это сакс.... это вредит делу. если не переваривали творческтва то значит ты не был на том уровне когда тебе разрешали принимать решения. это нормально и ничего плохого в этом нет. ты работаешь за деньги. точка тут.
При этом ты можешь сохранить работу. Это хорошо. Не дай Бог, обратного. Я уже старый. Вот тебе совет старого человека. Бейся, но осторожно, не наступая людям на ноги. Люди злопамятны. Звиняй за советы. Я из страны Советов.
Мужики! У меня такое впечатление, что движок форума глючит. Ну не первый раз. Прикол - читал час назад пост Lepsika, так там была только половина!!! его поста. Честно говорю. Вчера много не пил...
Lepsik!
Доотвечаю на твой пост.
ты мен привел устройство базы ArcGIS
Да ну! Ты не прав. Хотя, конечно, в моём постинге не было картинок со структурой нашей базы (это теперь уже не ноу хау), и тебе трудно судить наверняка. В части деклараций - да ,похоже на то, что сделал ESRI в ArcGIS (через два года, как это сделали мы!). В части реализации и особенно функционала - нет. Например, посмотри ArcGIS, когда ты, создавая дочку, наследуешь от папы, то в таблице дочки ты увидишь все поля - (от папы) + (то, что добавилось от дочки). Например, если поля папы p1 и p2, а в дочке ты добавляешь d1 и d2, то таблица дочки ArcGIS будет содержать p1,p2,d1,d2.!!! (это при том-то, что структура папы уже сужествуется, и туда можно было бы писать данные для экземпляров дочек тоже! Болваны.).
У меня, если ты мою нудятину выше читал внимательно, не так реализовано. Кинь своё мыло, не бойся, писать любовные письма не стану. Я тебе картинки пришлю со структурой пререлиза базы. Выставишь их на форуме в этом топике (я понял, что для тебя это не проблема). Тогда и обсуждать будем.
А так - разговор в пустоту.
папа Карло писал(а):творчество необходимо на определенном уровне. когда все начинают заниматься творчеством это сакс.... это вредит делу.
выше меня только Вице и Сам в принятии решений по стратегической части. А творчество - это за то что мне платят.
папа Карло писал(а):если не переваривали творческтва то значит ты не был на том уровне когда тебе разрешали принимать решения. это нормально и ничего плохого в этом нет. ты работаешь за деньги. точка тут.
vg писал(а): Мужики! У меня такое впечатление, что движок форума глючит. Ну не первый раз. Прикол - читал час назад пост Lepsika, так там была только половина!!! его поста. Честно говорю.
странно то что я когда начал редактировать, свой то твоего поста не было, а когда добавил - увидел, что ты ответил 4 часами ранее! вот так-то
ты мен привел устройство базы ArcGIS
vg писал(а):Да ну! Ты не прав. Хотя, конечно, в моём постинге не было картинок со структурой нашей базы (это теперь уже не ноу хау), и тебе трудно судить наверняка. В части деклараций - да
я не спорю, просто внешне похоже. про функциональность, как ты справедливо заметил мне трудно судить.
в общем требование клиентов было сохранить flat-таблицы, хотя в самых начальных требованиях было - наша база и наша структура внутри. Из этого и исходили.
Платят - переделываем.
У меня, если ты мою нудятину выше читал внимательно, не так реализовано. Кинь своё мыло, не бойся, писать любовные письма не стану. fast # null net.
Я тебе картинки пришлю со структурой пререлиза базы. Выставишь их на форуме в этом топике (я понял, что для тебя это не проблема). Тогда и обсуждать будем.
после просмотра структуры ArcGIS мы поняли что в ту сторону двигаться точно не будем. Дело в том что мы делаешь generic инструмент и ArcGIS обломался на этом, заточив структуры под каждый вид деятельности. для enviroment одна структура, для maintane для geophisics третья и т.д.
предоставляя пользователю самому разбираться в каше, которую они заварили плюс навесить пользователя дополнительную боль в виде разработки софта под новую структуру.
у нас задача несколько друго плана - позволить пользователю нашими средствами
-выбрать из списка нужную конфигурацию или стандарт базы и модифицировать существующий.
при чем делается это несколькими движениями мыши.
- без видимых затрат и программирования перенести из пользовательской базы в выбранную пользователем.
уж какие мне стандарты довелось видеть - в дрожь бросает от восхищения фантазиями создателей таких баз.
В старом стандарте MOE (ministry of enviroment) Canada в таблице Lithology (да и в ряде других) слои хранят в СТОЛБЦАХ sic!
ну и ряд других извращений.......
собственно у нас куча компонент, часть их которых размером с ArcGIS
А вообще радует, что и в Канаде народ творчески подходит к работе. Я как то работал с америкозами, так они творчества на дух не переносят.
Я уже старый. Вот тебе совет старого человека. Бейся, но осторожно, не наступая людям на ноги. Люди злопамятны. Звиняй за советы. Я из страны Советов. 
Мужики! У меня такое впечатление, что движок форума глючит. Ну не первый раз. Прикол - читал час назад пост Lepsika, так там была только половина!!! его поста. Честно говорю. Вчера много не пил...