ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Объектная надстройка над релационной СУБД
438 сообщений из 438, показаны все 18 страниц
  все  
Объектная надстройка над релационной СУБД
    #32763868
_White
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_White
Гость
Здравствуйте! Подскажите пожалуйста какие вам известны объектные надстройки над реляционной СУБД. Если можно дайте URL на данные системы.
Спасибо за информацию
Александр.
...
Рейтинг: 0 / 0
01.11.2004, 18:09
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32763902
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
Не флейма ради - тема интересная - а расширения кругозора для, - вопрос, если позволите: если не секрет, для какой цели нужен такой монстр? Псевдообъектная структура в реляционной СУБД чем-то глобально не устраивает?
...
Рейтинг: 0 / 0
01.11.2004, 18:34
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32763983
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
_WhiteЗдравствуйте! Подскажите пожалуйста какие вам известны объектные надстройки над реляционной СУБД. Если можно дайте URL на данные системы.
Спасибо за информацию
Александр.

У меня есть такая надстройка собственного изготовления. Жду заинтересованных вопросов.
...
Рейтинг: 0 / 0
01.11.2004, 19:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32764050
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
funikovyuri
Участник
Programmer_Ortodox

У меня есть (Это что такое?) Т.е. мне хотелось бы услышать какое-либо определение, потому как ваше решение я знаю - правда я бы назвал его шаблоном клиентского приложения для РСУБД, а не "ОО надстройкой"...
...
Рейтинг: 0 / 0
01.11.2004, 20:49
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32764084
Фотография Vladimir M Sklyar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vladimir M Sklyar
Участник
2 Programmer_Ortodox
А как насчет показать, рассказать что да как, под какую СУБД ?

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
01.11.2004, 22:16
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32764251
tchn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchn
Гость
может это нужно?
...
Рейтинг: 0 / 0
02.11.2004, 08:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32764442
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
tchnможет это нужно?

Вам и Vladimir M Sklyar отправил доп.инфу по мылу
...
Рейтинг: 0 / 0
02.11.2004, 10:46
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32764994
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
МОжно и мне отправить на s h t o ck зверь ma i l .ру?
...
Рейтинг: 0 / 0
02.11.2004, 14:04
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32765030
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
NEXUS
...
Рейтинг: 0 / 0
02.11.2004, 14:22
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32765072
tchn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchn
Гость
Programmer_Ortodox tchnможет это нужно?

Вам и Vladimir M Sklyar отправил доп.инфу по мылу

что-то нет ничего по мылу...
а что там за доп.инфа?
...
Рейтинг: 0 / 0
02.11.2004, 14:44
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32765188
Фотография mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mv
Участник
Bold for Delphi/Bold for C++
...
Рейтинг: 0 / 0
02.11.2004, 15:47
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32765222
Alexey Kudinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Kudinov
Участник
MS ObjectSpaces
...
Рейтинг: 0 / 0
02.11.2004, 16:06
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32765296
Фотография Vladimir M Sklyar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vladimir M Sklyar
Участник
Где можно на него посмотреть на MS ObjectSpaces ? (на мелкософте чего-то не
нашел)

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
02.11.2004, 16:43
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32765327
Alexey Kudinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Kudinov
Участник
Vladimir M Sklyar
Где можно на него посмотреть на MS ObjectSpaces ? (на мелкософте чего-то не
нашел)

Из статьи по ссылке
ObjectSpaces В .NET Framework 1.2 для этих целей есть специальный набор классов из пространства имен System.ObjectSpaces.*.
...
Рейтинг: 0 / 0
02.11.2004, 16:58
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32765396
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
ShtockМОжно и мне отправить на s h t o ck зверь ma i l .ру?

Запостил
...
Рейтинг: 0 / 0
02.11.2004, 17:33
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32765398
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
tchn Programmer_Ortodox tchnможет это нужно?

Вам и Vladimir M Sklyar отправил доп.инфу по мылу

что-то нет ничего по мылу...
а что там за доп.инфа?

Еще запостил
...
Рейтинг: 0 / 0
02.11.2004, 17:34
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32765403
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621Не флейма ради - тема интересная - а расширения кругозора для, - вопрос, если позволите: если не секрет, для какой цели нужен такой монстр? Псевдообъектная структура в реляционной СУБД чем-то глобально не устраивает?

Хех...монстр, да там все предельно просто и доступно пониманию человека не отличающего тампакс от сникерса!
...
Рейтинг: 0 / 0
02.11.2004, 17:37
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32765652
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Хех...монстр, да там все предельно просто и доступно пониманию человека не
> отличающего тампакс от сникерса!

Хм... тогда это фуфло, уважаемый. Или - в крайнем случае - частное решение ограниченного применения.
...
Рейтинг: 0 / 0
02.11.2004, 20:23
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32768573
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> Хех...монстр, да там все предельно просто и доступно пониманию человека не
> отличающего тампакс от сникерса!

Хм... тогда это фуфло, уважаемый. Или - в крайнем случае - частное решение ограниченного применения.

За фуфло, - одним зубом загрызу! :)
...
Рейтинг: 0 / 0
04.11.2004, 13:05
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32768778
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> За фуфло, - одним зубом загрызу! :)

Хм... извините, у меня не было намерений Вас обидеть. Поясню: по моему скромному мнению маппинг _произвольных_ объектов на реляционную структуру - не есть простая задача. Простые же решения в данном случае имеют ограниченное применение. Такая формулировка более корректна?
...
Рейтинг: 0 / 0
04.11.2004, 14:05
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32769335
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> За фуфло, - одним зубом загрызу! :)

Хм... извините, у меня не было намерений Вас обидеть. Поясню: по моему скромному мнению маппинг _произвольных_ объектов на реляционную структуру - не есть простая задача. Простые же решения в данном случае имеют ограниченное применение. Такая формулировка более корректна?

Хех...А Кубик-Рубика изобрести, это по-вашему сложная задача?
"маппинг _произвольных_ объектов на реляционную структуру" - как жаль что я не знал про это раньше...:)
...
Рейтинг: 0 / 0
04.11.2004, 17:27
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32769379
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Хех...А Кубик-Рубика изобрести, это по-вашему сложная задача?

Не могу сказать, не пробовал.

> "маппинг _произвольных_ объектов на реляционную структуру" - как жаль что я
> не знал про это раньше...:)

А что Вас в этой формулировке не устраивает? Есть объект. Он хранится в реляционной бд. В случае произвольного объекта это хм... геморрой. В том смысле, что структура данных не будет способствовать быстрым манипуляциям с объектами. А в общем случае помимо собственно маппинга объектов есть: 1. связи, 2. классификация, 3. локализация, 4. история изменений (как объектов, так и метаданных). Если при этом (в смысле реализации всех четырех пунктов) Ваша разработка в состоянии обеспечить хоть какую-то производительность, - я с удовольствием ее куплю. Огласите, пожалуйста, результаты тестирования и цену.
...
Рейтинг: 0 / 0
04.11.2004, 17:45
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32769430
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Тестировать производительность пока не довелось,всему - свое время, но осмелюсь предположить(как вы уже поняли,я с этим вопросом немножко знаком), она будет очень даже ничего,т.к. только индексированный доступ.
Сейчас приделываю тип данных OLE, потом можно будет и пообсуждать, жаль только, что заниматься этим приходится только после основной работы, а это уже совсем другие темпы...Ой, горе мне...:)
...
Рейтинг: 0 / 0
04.11.2004, 18:10
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32769454
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Тестировать производительность пока не довелось,всему - свое время,

Хм... судя по Вашему ответу связи, классификация, локализация, история изменений реализованы? Очень любопытно. Подробнее, если нетрудно. Особенно про классификацию. Интересует возможность множественной и параллельной классификации. Кроме того, сильно рассчитываю на то, что ограничение доступа сделано у Вас не с помощью ACL.

> т.к. только индексированный доступ.

И что из этого следует? Невероятная производительность? Позвольте усомниться.

> Сейчас приделываю тип данных OLE

Поясните, пожалуйста, для какой цели объектной задаче прикручивать форточное изобретение?
...
Рейтинг: 0 / 0
04.11.2004, 18:18
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32769479
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> Тестировать производительность пока не довелось,всему - свое время,

Хм... судя по Вашему ответу связи, классификация, локализация, история изменений реализованы? Очень любопытно. Подробнее, если нетрудно. Особенно про классификацию. Интересует возможность множественной и параллельной классификации. Кроме того, сильно рассчитываю на то, что ограничение доступа сделано у Вас не с помощью ACL.

> т.к. только индексированный доступ.

И что из этого следует? Невероятная производительность? Позвольте усомниться.

> Сейчас приделываю тип данных OLE

Поясните, пожалуйста, для какой цели объектной задаче прикручивать форточное изобретение?

Историю пока не сделал,но сделаю,технических сложностей никаких,триггер пихает текущую запись в соотв.теневую таблицу. И все.
Разграничение доступа пока не сделал,но сделаю достаточно быстро,на меня поалияла очень дельная статья на эту тему на www.ib.ru
Все прочее проработано "по самое не балуйся", аж самому страшно...:)
Почему ввожу тип OLE? Для того,чтобы пользователь мог создавать объекту свойства типа OLE и хранить там оригиналы документов, всякие там CAD
...
Рейтинг: 0 / 0
04.11.2004, 18:32
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32769496
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Историю пока не сделал,но сделаю,технических сложностей никаких,триггер
> пихает текущую запись в соотв.теневую таблицу. И все.

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

Что-то не слышно о связях, классификации и локализации. Вы отвечаете на избранные вопросы?

> Разграничение доступа пока не сделал,но сделаю достаточно быстро,на
> меня поалияла очень дельная статья на эту тему на www.ib.ru

;) Там не все так дельно, как кажется.

> Все прочее проработано "по самое не балуйся", аж самому страшно...:)

Не бойтесь. Уверяю Вас, ничего особенного.

> Почему ввожу тип OLE? Для того,чтобы пользователь мог создавать объекту
> свойства типа OLE и хранить там оригиналы документов, всякие там CAD

У-у-у... Спасибо, можете не продолжать.
...
Рейтинг: 0 / 0
04.11.2004, 18:44
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32769509
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> Историю пока не сделал,но сделаю,технических сложностей никаких,триггер
> пихает текущую запись в соотв.теневую таблицу. И все.

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

Что-то не слышно о связях, классификации и локализации. Вы отвечаете на избранные вопросы?

> Разграничение доступа пока не сделал,но сделаю достаточно быстро,на
> меня поалияла очень дельная статья на эту тему на www.ib.ru

;) Там не все так дельно, как кажется.

> Все прочее проработано "по самое не балуйся", аж самому страшно...:)

Не бойтесь. Уверяю Вас, ничего особенного.

> Почему ввожу тип OLE? Для того,чтобы пользователь мог создавать объекту
> свойства типа OLE и хранить там оригиналы документов, всякие там CAD

У-у-у... Спасибо, можете не продолжать.

Дать точные и исчерпывающие ответы не могу,для этого нужно потратить много времени,если описывать все мелкие детали,взять хотя бы слежение за историей,все значения свойств имеют временную отметку,для которой они актуальны,ну и т.д. А вот конктетные пожелания/хотения хотелось бы услышать. Про OLE зря вы так пренебрежительно,это очень многое упрощает,в противном случае нужно уметь поддерживать тучу всяких форматов, не шмагу я...:)
...
Рейтинг: 0 / 0
04.11.2004, 18:54
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32769547
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Дать точные и исчерпывающие ответы не могу,для этого нужно потратить много
> времени,

Исчерпывающе - не нужно. Вкратце. Чтобы стало понятно.

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

Как это должно быть организовано - я в курсе, спасибо. Интересно, как Вы это сделали.

> А вот конктетные пожелания/хотения хотелось бы услышать.

См. выше. Четыре пункта + разделение доступа - это минимум. И - производительность.

> Про OLE зря вы так пренебрежительно,это очень многое упрощает,в противном
> случае нужно уметь поддерживать тучу всяких форматов, не шмагу я...:)

Хранить файлы в базе данных - это ошибка. Поддерживать "тучу форматов" необходимости нет.
...
Рейтинг: 0 / 0
04.11.2004, 19:16
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32770348
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> Дать точные и исчерпывающие ответы не могу,для этого нужно потратить много
> времени,

Исчерпывающе - не нужно. Вкратце. Чтобы стало понятно.

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

Как это должно быть организовано - я в курсе, спасибо. Интересно, как Вы это сделали.

> А вот конктетные пожелания/хотения хотелось бы услышать.

См. выше. Четыре пункта + разделение доступа - это минимум. И - производительность.

> Про OLE зря вы так пренебрежительно,это очень многое упрощает,в противном
> случае нужно уметь поддерживать тучу всяких форматов, не шмагу я...:)

Хранить файлы в базе данных - это ошибка. Поддерживать "тучу форматов" необходимости нет.

Увы, времени пока нет. Могу кинуть на мыло файлик с кратким описанием и скриншотами, правда он странький,апрельский...сейчас уже много доработано.
...
Рейтинг: 0 / 0
05.11.2004, 12:07
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32770568
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Увы, времени пока нет.

;) Ну, на нет и суда нет.

На всякий случай (вдруг у Вас появится свободное время?): вообще говоря, описанный минимум - это imho функционал для несложного практического применения. Для полноценной реализации потребуется ссылочная целостность, ограничения, значения по умолчанию, схемы объектов, типы данных и прочая, прочая, прочая. ;))
...
Рейтинг: 0 / 0
05.11.2004, 13:23
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32770797
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> Увы, времени пока нет.

;) Ну, на нет и суда нет.

На всякий случай (вдруг у Вас появится свободное время?): вообще говоря, описанный минимум - это imho функционал для несложного практического применения. Для полноценной реализации потребуется ссылочная целостность, ограничения, значения по умолчанию, схемы объектов, типы данных и прочая, прочая, прочая. ;))

Пишите на мыло,при необходимости созвонимся и все обсудим. Сейчас только скажу, что, все принципиальные вопросы позади, причем где-то с 1998 года,так уж сложилось. В партнерских взаимоотношениях заинтересован, на мог взгляд,есть шанс создать любопытный продукт,причем быстро. Потенциальный пользователь документооборота(инженерного в том числе) мне тоже будеть очень интересен...
-------------------------------
P.S. Не мешало бы и представиться, а то наша дискуссия стала меня как-то легкомысленно настраивать:)
...
Рейтинг: 0 / 0
05.11.2004, 14:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32773346
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> Увы, времени пока нет.

;) Ну, на нет и суда нет.

На всякий случай (вдруг у Вас появится свободное время?): вообще говоря, описанный минимум - это imho функционал для несложного практического применения. Для полноценной реализации потребуется ссылочная целостность, ограничения, значения по умолчанию, схемы объектов, типы данных и прочая, прочая, прочая. ;))

Ссылочная целостность была с самого начала, т.е. это декларации типа
CONSTRAINT PAR_NODE FOREIGN KEY(nParent) REFERENCES NODE(nID)
ничто не мешает ссылаться nID на nParent даже если они находятся в одной таблице.
...
Рейтинг: 0 / 0
09.11.2004, 12:50
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32773799
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> т.е. это декларации типа CONSTRAINT PAR_NODE FOREIGN KEY(nParent) etc

Я немного не то имел в виду. В данном случае imho поддержка целостности может быть построена не средствами SQL, а с помощью метаинформации, причем, это не будет целостностью в привычном понимании.

Проблема в том, что метаописаниями придется воспроизвести практичести все объекты реляционной СУБД, - очень геморройное и в общем не самое простое занятие.
...
Рейтинг: 0 / 0
09.11.2004, 15:25
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32773831
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> т.е. это декларации типа CONSTRAINT PAR_NODE FOREIGN KEY(nParent) etc

Я немного не то имел в виду. В данном случае imho поддержка целостности может быть построена не средствами SQL, а с помощью метаинформации, причем, это не будет целостностью в привычном понимании.

Проблема в том, что метаописаниями придется воспроизвести практичести все объекты реляционной СУБД, - очень геморройное и в общем не самое простое занятие.

Что-то до меня не дошло,зачем в sql-сервере нужно делать ссылочную целостность не средствами sql...зачем это нужно?
...
Рейтинг: 0 / 0
09.11.2004, 15:37
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32773838
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
А у меня есть такая штука и отрабатывает всего одной хранимой процедурой. Процедура вызывается в момент удаления объекта. Только не покажу - это ноу-хау и защита от воровства. Поставляю свои исходники для просмотра и пробы как раз без этой процедуры.
...
Рейтинг: 0 / 0
09.11.2004, 15:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32774148
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Что-то до меня не дошло,зачем в sql-сервере нужно делать ссылочную
> целостность не средствами sql...зачем это нужно?

Два уровня представления: реляционный и объектный (псевдообъектный). Два уровня ссылочной целостности: реляционная и мета-. Затем, чтобы можно было говорить об объектах, а не о некотором промежуточном состоянии данных. ;) И чтобы оперировать объектами.

> Процедура вызывается в момент удаления объекта.

Это простая операция. Если есть метаописание, значит, есть зависимость между объектами (в смысле, есть (должна быть) схема, позволяющая такие зависимости найти); получаем перечень зависимых объектов, смотрим, есть ли кросс-зависимости, если нет - маркируем зависимые объекты как удаленные. Вообще логику на основе метаописаний можно придумать любую.

Все плохо при добавлении или изменении объекта.

> Только не покажу - это ноу-хау и защита от воровства.

Хм... вроде никто и не просил показать? Интересен не конкретный код конкретной процедуры или конкретная структура данных, а общий подход.
...
Рейтинг: 0 / 0
09.11.2004, 17:21
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32779700
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
...
Рейтинг: 0 / 0
12.11.2004, 14:12
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32779725
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
...
Рейтинг: 0 / 0
12.11.2004, 14:20
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32779729
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Ловкость рук и никаких дискуссий:)
...
Рейтинг: 0 / 0
12.11.2004, 14:20
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32779878
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Мне бы хотелось услышать соображения по классификации информации. Любой и всякой, а также классификации свойств,которые ее описывают.
Каких-то ограничений по иерархиям и тапам того и другого не существует,так же,как и по программной реализации, любые кубы,любых измерений - для этого привел эти картинки. Есть желающие?
...
Рейтинг: 0 / 0
12.11.2004, 14:57
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32779894
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Ловкость рук и никаких дискуссий:)

;) Надеюсь, Ваш продукт будет иметь коммерческий успех.
...
Рейтинг: 0 / 0
12.11.2004, 15:00
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32779905
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> Ловкость рук и никаких дискуссий:)

;) Надеюсь, Ваш продукт будет иметь коммерческий успех.

Спасибо на добром слове! Но пока я подыскиваю себе работу,сейчас можно сказать,работаю не по специальности,-системным аналитиком...
...
Рейтинг: 0 / 0
12.11.2004, 15:04
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32779921
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Но хотелось бы все-таки по существу,т.е. о классификации всего и вся.
Мне сейчас нравится идея ввести тип данных "Script", который будет на основе многоязычного интерпретатора типа FastScript или подобного, ну и дизайнер форм...
...
Рейтинг: 0 / 0
12.11.2004, 15:07
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32779951
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Еще одна картинка по применению универсального хранилища,хотя это очень частный случай
...
Рейтинг: 0 / 0
12.11.2004, 15:13
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32779967
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Мне бы хотелось услышать соображения по классификации информации. Любой и
> всякой, а также классификации свойств,которые ее описывают.

Хороший вопрос. ;) Imho подхода два:
1. сущность - классификация - характеристики (как функция от от некоторых признаков сущности);
2. глобальный перечень сущностей - глобальная классификация - глобальный перечень характеристик (зависимость чуть сложнее);

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

В свое время продуктивным мне показался подход, аналогичный используемому при построении тезауруса, - позволяет не зацикливаться на предметной области.

> Каких-то ограничений по иерархиям и тапам того и другого не существует,так
> же,как и по программной реализации,

Схема объектов на основе метаописаний. Вроде это уже обсуждалось?
...
Рейтинг: 0 / 0
12.11.2004, 15:17
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780001
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> Мне бы хотелось услышать соображения по классификации информации. Любой и
> всякой, а также классификации свойств,которые ее описывают.

Хороший вопрос. ;) Imho подхода два:
1. сущность - классификация - характеристики (как функция от от некоторых признаков сущности);
2. глобальный перечень сущностей - глобальная классификация - глобальный перечень характеристик (зависимость чуть сложнее);

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

В свое время продуктивным мне показался подход, аналогичный используемому при построении тезауруса, - позволяет не зацикливаться на предметной области.

> Каких-то ограничений по иерархиям и тапам того и другого не существует,так
> же,как и по программной реализации,

Схема объектов на основе метаописаний. Вроде это уже обсуждалось?

А кому нужна такая схема и зачем?
...
Рейтинг: 0 / 0
12.11.2004, 15:26
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780068
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> А кому нужна такая схема и зачем?

Кому - вопрос, видимо, риторический? ;)

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

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

Наиболее близкая аналогия - xml файл и dtd. Представьте, что данные у Вас храняться где угодно (в любых таблицах базы данных или файловой системе), - а в dtd Вы описываете зависимости, типы данных и пр., - т. е., все, что Вам необходимо для манипулирования данными.
...
Рейтинг: 0 / 0
12.11.2004, 15:46
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780105
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> А кому нужна такая схема и зачем?

Кому - вопрос, видимо, риторический? ;)

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

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

Наиболее близкая аналогия - xml файл и dtd. Представьте, что данные у Вас храняться где угодно (в любых таблицах базы данных или файловой системе), - а в dtd Вы описываете зависимости, типы данных и пр., - т. е., все, что Вам необходимо для манипулирования данными.

Что касается схемы,то я опять не понял о чем речь. Если о таблицах в БД и связях между ними, то здесь жесткая и постоянная схема,она не меняется никогда. Я связываю вопрос классификации именно с вопросом наполнения хранилища.
...
Рейтинг: 0 / 0
12.11.2004, 15:57
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780129
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Programmer_Ortodox guest_20040621> А кому нужна такая схема и зачем?

Кому - вопрос, видимо, риторический? ;)

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

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

Наиболее близкая аналогия - xml файл и dtd. Представьте, что данные у Вас храняться где угодно (в любых таблицах базы данных или файловой системе), - а в dtd Вы описываете зависимости, типы данных и пр., - т. е., все, что Вам необходимо для манипулирования данными.

Что касается схемы,то я опять не понял о чем речь. Если о таблицах в БД и связях между ними, то здесь жесткая и постоянная схема,она не меняется никогда. Я связываю вопрос классификации именно с вопросом наполнения хранилища.
Вдогонку добавлю,что если мы имеем дело с постоянной и неизменной структурой, то это сильно облегчает жизнь всего прогрессивного ИТ-человечества:):) , так как в течение долгого времени может создаваться масса приложений, не заботясь о том.что структура вдруг изменится!
А при введении типа данных "Script", сами мозги,т.е.целые приложения,написанные на нем,могут храниться там же,т.е. в БД, которая может иметь глобально распределенную структуру
...
Рейтинг: 0 / 0
12.11.2004, 16:02
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780173
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Что касается схемы,то я опять не понял о чем речь. Если о таблицах в БД и
> связях между ними, то здесь жесткая и постоянная схема,она не меняется
> никогда.

Хм... никто ничего менять не предлагает. Помните про два уровня представления - объектный и SQL? - это все о том же. Есть у Вас какая-то структура данных, - очень хорошо, не надо ее менять. Надо ее просто описать. И строить классификатор(ы) на основании этого описания. Вы же говорили про объектный подход? - ничего более объектного и придумать нельзя. ;)

> Я связываю вопрос классификации именно с вопросом наполнения хранилища.

Количественного? Напрасно. _Правильно_ построенная классификация не зависит/слабо зависит от количества классифицируемых сущностей. От времени она зависит гораздо больше.
...
Рейтинг: 0 / 0
12.11.2004, 16:12
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780231
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> Что касается схемы,то я опять не понял о чем речь. Если о таблицах в БД и
> связях между ними, то здесь жесткая и постоянная схема,она не меняется
> никогда.

Хм... никто ничего менять не предлагает. Помните про два уровня представления - объектный и SQL? - это все о том же. Есть у Вас какая-то структура данных, - очень хорошо, не надо ее менять. Надо ее просто описать. И строить классификатор(ы) на основании этого описания. Вы же говорили про объектный подход? - ничего более объектного и придумать нельзя. ;)

> Я связываю вопрос классификации именно с вопросом наполнения хранилища.

Количественного? Напрасно. _Правильно_ построенная классификация не зависит/слабо зависит от количества классифицируемых сущностей. От времени она зависит гораздо больше.

1. Сам факт, что структура работает,говорить о том,что она описана. И она писана,на уровне sql-деклараций,с ограничениями ссылочной целостности и т.д. Сами же приложения, написанные на скрипте могут следовать какой угодно идеологии, в любом случае этим скриптам доступен как локальный,так и глобальный контекст,т.е. значения свойств,их идентификация,так же,как и самих объектов.
2.Наполненное и первоначально классифицированное хранилище можно реорганизовывать со временем,даже простым перетаскиванием веток дерева,без какого либа ущерба для идентификации.Это работает уже.
...
Рейтинг: 0 / 0
12.11.2004, 16:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780264
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Сам факт, что структура работает,говорить о том,что она описана.

По-моему, я выражаюсь предельно недвусмысленно. :( У Вас есть некоторое количество таблиц. Это _физический уровень_ (или SQL, или реляционный, - как угодно). Метаописание этих таблиц у Вас есть? Какие сущности они содержат? Из чего состоят? Вы понимаете, что здесь объектами даже и не пахнет? Вы говорите про набор таблиц, - а они ничем более набора таблиц _не являются_.

> Наполненное и первоначально классифицированное хранилище можно
> реорганизовывать со временем,даже простым перетаскиванием веток дерева

Возможность представления - это не то же самое, что способ организация данных (особенно, если речь о классификации).
...
Рейтинг: 0 / 0
12.11.2004, 16:41
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780297
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> Сам факт, что структура работает,говорить о том,что она описана.

По-моему, я выражаюсь предельно недвусмысленно. :( У Вас есть некоторое количество таблиц. Это _физический уровень_ (или SQL, или реляционный, - как угодно). Метаописание этих таблиц у Вас есть? Какие сущности они содержат? Из чего состоят? Вы понимаете, что здесь объектами даже и не пахнет? Вы говорите про набор таблиц, - а они ничем более набора таблиц _не являются_.

> Наполненное и первоначально классифицированное хранилище можно
> реорганизовывать со временем,даже простым перетаскиванием веток дерева

Возможность представления - это не то же самое, что способ организация данных (особенно, если речь о классификации).

Вот такого типа метаданные,если выражаться на языке sql
CREATE TABLE NODE(
nID IDENT64 DEFAULT 0 NOT NULL,
nParent IDENT64 DEFAULT 0 NOT NULL,
nName dName NOT NULL,
....
PRIMARY KEY(nID),
CONSTRAINT PAR_NODE FOREIGN KEY(nParent) REFERENCES NODE(nID)
);
.....
CREATE GENERATOR nID_NODE_GEN;
...
Рейтинг: 0 / 0
12.11.2004, 16:49
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780307
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Programmer_Ortodox guest_20040621> Сам факт, что структура работает,говорить о том,что она описана.

По-моему, я выражаюсь предельно недвусмысленно. :( У Вас есть некоторое количество таблиц. Это _физический уровень_ (или SQL, или реляционный, - как угодно). Метаописание этих таблиц у Вас есть? Какие сущности они содержат? Из чего состоят? Вы понимаете, что здесь объектами даже и не пахнет? Вы говорите про набор таблиц, - а они ничем более набора таблиц _не являются_.

> Наполненное и первоначально классифицированное хранилище можно
> реорганизовывать со временем,даже простым перетаскиванием веток дерева

Возможность представления - это не то же самое, что способ организация данных (особенно, если речь о классификации).

Вот такого типа метаданные,если выражаться на языке sql
CREATE TABLE NODE(
nID IDENT64 DEFAULT 0 NOT NULL,
nParent IDENT64 DEFAULT 0 NOT NULL,
nName dName NOT NULL,
....
PRIMARY KEY(nID),
CONSTRAINT PAR_NODE FOREIGN KEY(nParent) REFERENCES NODE(nID)
);
.....
CREATE GENERATOR nID_NODE_GEN;

CASE-средствами я не пользуюсь,поэтому их терминологией тоже,
а кстати, можно ли создавать рекурсивные структуры данных CASE-средствами?
Мне очень интересно,кто-то подскажет?
...
Рейтинг: 0 / 0
12.11.2004, 16:54
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780479
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Почитал я тут дискуссию и решил вклиниться.

В моей системе метаданные есть. Частично это метаданные самого MSSQL, а частично собственные. Например тип атрибута у меня определяется по метаданным сервера, а наименование атрибута уже по моим собственным метаданным. Если точнее, то вот так выглядит скрипт создания таблицы для класса Журнал задач

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
create table Journal_Tasks
(
  OID           DBOContact  not null,
  ID            int identity( 1 ,  1 ) not null,
  TaskOID       DBOTask     not null,
  ContactOID    DBOContact  not null,
  ManagerOID    DBOAUser    not null,
  InitiatorOID  DBObject    not null,
  PeriodOID     DBOPeriod   not null,
  Date          datetime    not null,
  Description   String      not null,
  OwnerOID      DBOUser     not null,
  primary key clustered ( OID, ID )
)
go

Все что атрибуты, заканчивающиеся на OID - это ссылки на объекты, в качестве типа указаны названия соответствующих классов. Именно через эту информацию работает процедура, проверяющая возможность удаления объекта (т.е. если нет на объект ни одной ссылки в системе)

Кроме того все наименования процедур строго регламентированы и правило выглядит так
<Class>_<Method>

Зная как работать с метаданными сервера я всегда могу найти нужную процедуру для виртуального метода объекта.

Сейчас реализую возможность по созданным метаданным для класса с помощью механизма компиляции получать конкретные таблицы и хранимые процедуры.
...
Рейтинг: 0 / 0
12.11.2004, 18:02
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780502
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Кстати, забыл самое главное сказать.

В моей системе есть такие объекты, как Класс, Метод и Атрибут, естесственно по одному экземпляру для каждого класса, каждого метода и каждого атрибута. Это самые главные метаданные, да и строгая регламентация названий - это тоже очень хорошие метаданные.

--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
12.11.2004, 18:11
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780520
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Увы, у меня в базе не декларируются какие-либо описания, связанные с предметной областью, только древесные структуры в самом общем виде. И ничего больше.
...
Рейтинг: 0 / 0
12.11.2004, 18:18
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780650
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Вот такого типа метаданные,если выражаться на языке sql

Это метаданные системных таблиц dbms и они не подойдут для описания объектов. См. сообщение Old Nick, - должно быть примерно так.

> CASE-средствами я не пользуюсь

В данном случае они ничем не помогут.

> Сейчас реализую возможность по созданным метаданным для класса с помощью
> механизма компиляции получать конкретные таблицы и хранимые процедуры.

Интересная задача. Для какой dbms пишете, если не секрет?

> В моей системе есть такие объекты, как Класс, Метод и Атрибут

Еще иногда удобны коллекции. :)

> Увы, у меня в базе не декларируются какие-либо описания, связанные с
> предметной областью, только древесные структуры в самом общем виде.

;) Древесные? Хорошее определение. ;))
...
Рейтинг: 0 / 0
12.11.2004, 21:21
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780720
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
И все таки мне бы очень хотелось услышать мнения людей, набивших руку в использовании CASE-средств, можно ли проектировать рекурсивные (самоописывающиеся) структуры данных или нет!?
...
Рейтинг: 0 / 0
12.11.2004, 23:29
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780822
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
Набивая оскомину...

Прежде, чем говорить об "объектной надстройке", следует различать, как минимум, три понятия: иерархия, классификация и наследование.
Иерархия - это структура, где один элемент может включать в себя другой элемент. При этом включенный элемент или те, элементы, которые он включает в себя, не могут включать исходный включающий элемент.
Классификация - это деление на основе одного или более признаков. Признаки могут образовывать иерархию (один признак включает в себя другой признак или, другими словами, включаемый признак детализирует включающий признак). Если признаки образуют иерархию, то имеем иерархическую классификацию, если признаки не образуют иерархии, то имеем не иерархическую классификацию. Например, если классифицировать людей по цвету кожи, то получим линейную классификацию. Таблица Менделеева - пример матричной классификации. Есть пространственные (3х-мерные) классификаторы, и, в принципе, можно построить классификаторы любой размерности.
Наследование (как парадигма ООП) - это частный случай иерархической классификации (про МН лучше не вспоминать!), основанной на иерархии признаков (свойств объекта). То есть, любое наследование - это иерархическая классификация, но не всякая иерархическая классификация - это наследование. Характерной особенностью наследования является не только детализация свойств включающего элемента во включаемом элементе, но и появление у включаемого элемента новых свойств, отсутствующих у включающего элемента.
К сожалению, можно столкнуться с ситуацией, когда любая иерархия или классификация принимается за наследование, что является заблуждением. Другое распространенное заблуждение основано на бытовом понимании термина наследование, например, ребенок наследует состояние родителей, или ребенок унаследовал нос отца, а глаза матери. Ребенок наследует свои свойства не от родителей, а от своего класса "Номо sapiens", от родителей он получает значения свойств (форма носа, цвет глаз и пр.).

Если термины иерархия, классификация и наследование понятны, то, наверное, понятно и то, что в этой дискуссии речь не идет об "объектной надстройке", речь, в основном, идет о классификации и методах ее реализации.

По всей видимости, понятие объектной надстройки должно включать в себя и другие парадигмы ООП: инкапсуляция и полиморфизм, только тогда название "объектная надстройка" будет соответствовать своему содержанию. И, возможно, тогда объектная надстройка будет не только удовлетворять честолюбие разработчика, но и быть действительно полезной.
...
Рейтинг: 0 / 0
13.11.2004, 10:30
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780937
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
Ув. ASU,

> При этом включенный элемент или те, элементы, которые он включает в себя,
> не могут включать исходный включающий элемент.

иерархия не обязана быть исключающей;

> Например, если классифицировать людей по цвету кожи, то получим линейную
> классификацию.

отнюдь; как минимум есть мулаты;

> речь, в основном, идет о классификации и методах ее реализации.

Programmer_Ortodox действительно говорит скорее о классификации; если Вы заметили, обсуждение не было монологом;

> понятие объектной надстройки должно включать в себя и другие парадигмы
> ООП: инкапсуляция и полиморфизм, только тогда название "объектная
> надстройка" будет соответствовать своему содержанию.

разве где-то шла речь о _полном_ соответствии объектной модели?
...
Рейтинг: 0 / 0
13.11.2004, 15:22
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780945
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
guest_20040621 ASUПри этом включенный элемент или те, элементы, которые он включает в себя, не могут включать исходный включающий элементиерархия не обязана быть исключающейВ моем сообщении ничего не говорилось об "исключающих" иерархиях.
guest_20040621 ASUНапример, если классифицировать людей по цвету кожи, то получим линейную классификациюотнюдь; как минимум есть мулатыЧто это меняет?
guest_20040621 ASUпонятие объектной надстройки должно включать в себя и другие парадигмы ООП: инкапсуляция и полиморфизм, только тогда название "объектная надстройка" будет соответствовать своему содержаниюразве где-то шла речь о _полном_ соответствии объектной модели?Неполное соответствие чем-то напоминает выражение "быть слегка беременной". Либо речь идет об объектной надстройке, либо о какой-то иной, тогда надо сказать о какой (желательно в титуле).
...
Рейтинг: 0 / 0
13.11.2004, 15:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32780997
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> В моем сообщении ничего не говорилось об "исключающих" иерархиях.

Действительно. Невнимательно читал, прошу прощения.

> Что это меняет?

Неудачный пример линейной классификации. Кроме того, ничего более.

> Либо речь идет об объектной надстройке, либо о какой-то иной, тогда надо
> сказать о какой (желательно в титуле).

Хм... начальный вопрос треда был, по-видимому, именно об объектной; на частности перешли позже.

Вызывает сомнения необходимость строгой реализации объектной модели в реляционной dbms.
...
Рейтинг: 0 / 0
13.11.2004, 16:44
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32781194
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
guest_20040621 ASUЧто это меняет?Неудачный пример линейной классификации. Кроме того, ничего болееБелый - желтый - красный - светло коричневый - коричневый - темно коричневый - черный. Линейно? guest_20040621 ASUЛибо речь идет об объектной надстройке, либо о какой-то иной, тогда надо сказать о какой (желательно в титуле)Хм... начальный вопрос треда был, по-видимому, именно об объектной; на частности перешли позже.
Вызывает сомнения необходимость строгой реализации объектной модели в реляционной dbmsУ меня подобных сомнений нет. Есть хорошая реляционная модель, есть хорошая объектная модель, включающая в себя понятие "объектной фабрики" (object factory). OF инкапсулирует в себе работу с любым хранилищем данных, в том числе, и с RDB. Все разговоры об объектных СУБД, "надстройках" над RDBMS и т.п. - это профанация либо объектной парадигмы, либо реляционной модели (это в полной мере относится и к IBM, и к Oracle и другим грандам программной индустрии).
...
Рейтинг: 0 / 0
14.11.2004, 09:45
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32781318
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Белый - желтый - красный - светло коричневый - коричневый - темно коричневый
> - черный. Линейно?

;) А, в этом смысле, - тогда конечно. Я подумал о расовой принадлежности.

> Есть хорошая реляционная модель, есть хорошая объектная модель, включающая
> в себя понятие "объектной фабрики" (object factory). OF инкапсулирует в себе
> работу с любым хранилищем данных, в том числе, и с RDB. Все разговоры об
> объектных СУБД, "надстройках" над RDBMS и т.п. - это профанация либо
> объектной парадигмы, либо реляционной модели (это в полной мере относится и к
> IBM, и к Oracle и другим грандам программной индустрии).

Не могу похвастать, что знаком с концепцией Oracle или IBM. Что хотелось отметить (к воспросу о том, почему imho неоправданна строгая реализация объектной модели в реляционной dbms): структура данных для объектной модели в реляционной dbms в общем случае не оптимальна. Если есть необходимость хранить объекты, - нужны другие инструменты, не реляционные.
...
Рейтинг: 0 / 0
14.11.2004, 16:30
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32781604
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
guest_20040621 ASUЕсть хорошая реляционная модель, есть хорошая объектная модель, включающая в себя понятие "объектной фабрики" (object factory). OF инкапсулирует в себе работу с любым хранилищем данных, в том числе, и с RDB. Все разговоры об объектных СУБД, "надстройках" над RDBMS и т.п. - это профанация либо объектной парадигмы, либо реляционной модели (это в полной мере относится и к IBM, и к Oracle и другим грандам программной индустрии)Не могу похвастать, что знаком с концепцией Oracle или IBM. Что хотелось отметить (к воспросу о том, почему imho неоправданна строгая реализация объектной модели в реляционной dbms): структура данных для объектной модели в реляционной dbms в общем случае не оптимальна. Если есть необходимость хранить объекты, - нужны другие инструменты, не реляционныеРеляционные модели (расширенная, в том числе), описанные Коддом, довольно богаты по своим возможностям. Реляционные СУБД - частные взгляды на модели Кодда, взгляды более узкие, накладывающие ограничения, отсутствующие в исходных моделях. Поэтому Вы правильно говорите о неоптимальности хранения в RDBMS, но напрасно, IMHO, распространяете это утверждение на все "реляционные инструменты".
Есть и другие проблемы при хранении объектов в любом хранилище. Например, должна поддерживаться инкапсуляция, а значит атрибуты объектов не должны быть видимы. Как в таком случае найти объекты, обладающие нужными свойствами (в данном случае, соответствующими значениями атрибутов)? Загружать в память каждый объект и инициализировать его, только для того, чтобы узнать значение атрибута? Накладно, но как иначе обеспечить инкапсуляцию? И подобных вопросов достаточно много...
...
Рейтинг: 0 / 0
15.11.2004, 09:33
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32781867
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
ASU guest_20040621 ASUЕсть хорошая реляционная модель, есть хорошая объектная модель, включающая в себя понятие "объектной фабрики" (object factory). OF инкапсулирует в себе работу с любым хранилищем данных, в том числе, и с RDB. Все разговоры об объектных СУБД, "надстройках" над RDBMS и т.п. - это профанация либо объектной парадигмы, либо реляционной модели (это в полной мере относится и к IBM, и к Oracle и другим грандам программной индустрии)Не могу похвастать, что знаком с концепцией Oracle или IBM. Что хотелось отметить (к воспросу о том, почему imho неоправданна строгая реализация объектной модели в реляционной dbms): структура данных для объектной модели в реляционной dbms в общем случае не оптимальна. Если есть необходимость хранить объекты, - нужны другие инструменты, не реляционныеРеляционные модели (расширенная, в том числе), описанные Коддом, довольно богаты по своим возможностям. Реляционные СУБД - частные взгляды на модели Кодда, взгляды более узкие, накладывающие ограничения, отсутствующие в исходных моделях. Поэтому Вы правильно говорите о неоптимальности хранения в RDBMS, но напрасно, IMHO, распространяете это утверждение на все "реляционные инструменты".
Есть и другие проблемы при хранении объектов в любом хранилище. Например, должна поддерживаться инкапсуляция, а значит атрибуты объектов не должны быть видимы. Как в таком случае найти объекты, обладающие нужными свойствами (в данном случае, соответствующими значениями атрибутов)? Загружать в память каждый объект и инициализировать его, только для того, чтобы узнать значение атрибута? Накладно, но как иначе обеспечить инкапсуляцию? И подобных вопросов достаточно много...

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

В предложенной реализации эти вопросы решены,причем радикально.
Атрибуты всегда хранятся отдельно от объектов. Можно бросить взгляд(т.е.создать ракурс) на все хранилище, с точки зрения наименования конкретного свойства,и увидеть,у какаих объектов такое свойство есть; можно "бросить взгляд" на хранилище,с точки зрения конкретного значения(значений) и увидеть у каких свойств эти значения и,каким объектам эти значения и св-ва принадлежат.
-----------------------------
При работе,лично я исхожу из реальных объектов,существующих в реальной жизни,а формализм наверное приложится.
...
Рейтинг: 0 / 0
15.11.2004, 11:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32781871
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
На выходных посидел над своей системой и написал механизм генерации кода по метаданным, а то надоело руками писать процедуры.

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

Таблица - это объект, у которого есть атрибуты, каждый атрибут описывается Наименованием (обычно на русском), именем поля, типом, нулл/не нулл, РК/не РК.

Нажимаем кнопочку и получаем процедуры для Select, Insert, Update и Delete, при желании можно код поправить, что иногда бывает нужно, а можно просто указать готовые процедуры для таблицы. Теперь разработка прикладной части пойдет несколько быстрее.

Еще посижу как-нибудь и сделаю форму, которая сама будет открывать все атрибуты класса. Вот только кому это нужно кроме меня?
...
Рейтинг: 0 / 0
15.11.2004, 11:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32781874
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
В ближайшие дни я приведу здесь наглядные и работающие иллюстрации к сказанному.
...
Рейтинг: 0 / 0
15.11.2004, 11:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32781888
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Извиняюсь, написал так:
Теперь чтобы создать новый класс, нужно указать его наименование, системное имя, наследника и таблицы

А нужно так:
Теперь чтобы создать новый класс, нужно указать его наименование, системное имя, родителя и таблицы
--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
15.11.2004, 11:44
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32781889
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
ASU guest_20040621 ASUЕсть хорошая реляционная модель, есть хорошая объектная модель, включающая в себя понятие "объектной фабрики" (object factory). OF инкапсулирует в себе работу с любым хранилищем данных, в том числе, и с RDB. Все разговоры об объектных СУБД, "надстройках" над RDBMS и т.п. - это профанация либо объектной парадигмы, либо реляционной модели (это в полной мере относится и к IBM, и к Oracle и другим грандам программной индустрии)Не могу похвастать, что знаком с концепцией Oracle или IBM. Что хотелось отметить (к воспросу о том, почему imho неоправданна строгая реализация объектной модели в реляционной dbms): структура данных для объектной модели в реляционной dbms в общем случае не оптимальна. Если есть необходимость хранить объекты, - нужны другие инструменты, не реляционныеРеляционные модели (расширенная, в том числе), описанные Коддом, довольно богаты по своим возможностям. Реляционные СУБД - частные взгляды на модели Кодда, взгляды более узкие, накладывающие ограничения, отсутствующие в исходных моделях. Поэтому Вы правильно говорите о неоптимальности хранения в RDBMS, но напрасно, IMHO, распространяете это утверждение на все "реляционные инструменты".
Есть и другие проблемы при хранении объектов в любом хранилище. Например, должна поддерживаться инкапсуляция, а значит атрибуты объектов не должны быть видимы. Как в таком случае найти объекты, обладающие нужными свойствами (в данном случае, соответствующими значениями атрибутов)? Загружать в память каждый объект и инициализировать его, только для того, чтобы узнать значение атрибута? Накладно, но как иначе обеспечить инкапсуляцию? И подобных вопросов достаточно много...

Интересно узнать какие лично Вы можете сформулировать требования к универсальному ХРАНИЛИЩУ информации(любой!)?
...
Рейтинг: 0 / 0
15.11.2004, 11:44
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32781908
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Универсальное ХРАНИЛИЩЕ уже есть :-)
Это RDBMS

Наверное имелось ввиду хранилище для объектов?

--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
15.11.2004, 11:47
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32781922
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Мне кажется нет смысла делать именно объектную базу. Так как действительно слишком накладно будет инициализиаровать каждый объект.

Гораздо лучше сочетание объектного движка ( на среднем слое например ) и хранилища не объектов, а состояний объектов. А вот для состояний то как раз и не нужна инкапсуляция. Только хорошо было бы чтобы доступ был только на чтение, а изменение состояний объектов происходило бы через методы объектов.

Ведь прямой доступ к хранилищу состояний объектов нужен только для одной цели - быстрая выборка нужных состояний, а для этого эффективен только SQL.
--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
15.11.2004, 11:53
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32782831
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> но напрасно, IMHO, распространяете это утверждение на все "реляционные инструменты".

Я не сталкивался с практической реализацией реляционной модели нигде кроме реляционных dbms. Поэтому, собственно, и обобщил. Если Вы знаете о таких реализациях, буду признателен за информацию.
...
Рейтинг: 0 / 0
15.11.2004, 17:18
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32782927
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Гораздо лучше сочетание объектного движка ( на среднем слое например ) и
> хранилища не объектов, а состояний объектов.

Не понимаю, чем радикально отличается хранение объектов от хранения состояний объектов? Imho состояние - это набор значений некоторых признаков объекта.

> Ведь прямой доступ к хранилищу состояний объектов нужен только для одной
> цели - быстрая выборка нужных состояний, а для этого эффективен только SQL.

Поясните, пожалуйста, что Вы подразумеваете под прямым доступом? Неиспользование сервера приложений?
...
Рейтинг: 0 / 0
15.11.2004, 18:00
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32783194
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> Историю пока не сделал,но сделаю,технических сложностей никаких,триггер
> пихает текущую запись в соотв.теневую таблицу. И все.

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

Что-то не слышно о связях, классификации и локализации. Вы отвечаете на избранные вопросы?

> Разграничение доступа пока не сделал,но сделаю достаточно быстро,на
> меня поалияла очень дельная статья на эту тему на www.ib.ru

;) Там не все так дельно, как кажется.

> Все прочее проработано "по самое не балуйся", аж самому страшно...:)

Не бойтесь. Уверяю Вас, ничего особенного.

> Почему ввожу тип OLE? Для того,чтобы пользователь мог создавать объекту
> свойства типа OLE и хранить там оригиналы документов, всякие там CAD

У-у-у... Спасибо, можете не продолжать.
>У-у-у... Спасибо, можете не продолжать.
Нет, все-таки использование технологии OLE может здорово облегчить жизнь, лично мне так кажется. А окончательно должен решать сам пользователь, что именно ему хранить в самой базе, а что в файловой системе. Он должен быть волен создавать свойста как типа OLE,так и типа URL, или даже их комбинацию. Мне кажется, если все лежит непосредственно в базе, то через интернет будет проще работать,в смысле вопросов админства. Средний, например, документ Worl может сжиматься в 10 раз, так что документ размером в 100к превращается всего в 10к, а это не очень накладно при работе через инет,CAD-овские файлы,то же самое,они по природе текстовые и степень сжатия высокая. В любом случае пользователь должен выбирать сам.
...
Рейтинг: 0 / 0
15.11.2004, 23:06
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32783248
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> использование технологии OLE может здорово облегчить жизнь,

Например?

> должен решать сам пользователь

Функции файловой системы лучше выполнять файловой системе. Не очень понятно, что именно пользователь должен решать.

> Он должен быть волен создавать свойста как типа OLE,

Нет такого свойства. Есть технология связывания объектов, причем, платформо-зависимая.

> так и типа URL, или даже их комбинацию.

На OLE уже есть rfc? Т. е. Вы полагаете, что этот механизм связывания стандартизован и описан?

> Мне кажется, если все лежит непосредственно в базе, то через интернет будет
> проще работать,в смысле вопросов админства.

Посчитайте время бэкапа/восстановления базы данных без документов и базы данных с документами. С большим количеством документов.

> Средний, например, документ Worl может сжиматься в 10 раз,

Документ Open Office изначально хранится в сжатом виде. Может, в консерватории что-то подправить? ;)
...
Рейтинг: 0 / 0
16.11.2004, 01:25
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32783630
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Под прямым доступом в данном контексте я понимаю возможность обращения прямо к таблицам для использования SQL конструкций.

Ведь если взять Hibernate, то там запросы пишутся в объектно-ориентированном виде, это очень удобно для получения несложных запросов, но не всегда эффективно для тонкой оптимизации. Хотя наверное и там возможно писать запросы напрямую к таблицам. Это и есть прямой доступ (в моем понимании в данном контексте)
...
Рейтинг: 0 / 0
16.11.2004, 10:36
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32783788
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
funikovyuri
Участник
Programmer_Ortodox

А как вы позиционируете ваш продукт ( в сравнении с тем же Hibernate или Code)?
...
Рейтинг: 0 / 0
16.11.2004, 11:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32784370
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
Old NickУниверсальное ХРАНИЛИЩЕ уже есть :-)
Это RDBMS
Наверное имелось ввиду хранилище для объектов?Да, наверное, Programmer_Ortodox имел ввиду хранилище для объектов (по крайней мере, я буду исходить из этого предположения).
Объектное хранилище (OW) - это часть объектной фабрики (OF). Если в метаданных реляционных СУБД описываются таблицы, то в OW - классы. Между описанием таблиц и классов есть существенная разница:
1. Таблицы не поддерживают иерархической классификации;
2. Таблицы не имеют поддержки интерфейса;
3. У таблиц нет ассоциированных с ними методов.
Первый пункт создает трудности при реализации наследования у классов. Второй пункт толкает на нарушение инкапсуляции. Третий пункт усложняет реализацию классов. Надо также заметить в развитие третьего пункта, что в реляционных СУБД нет поддержки полиморфизма.
Существо работы с OW также отличается от работы с RDBMS, что определяется семантикой кортежа и объекта. Кортеж предназначен для хранения информации, то есть, его роль пассивна, объект играет активную роль, он сам обрабатывает информацию.
Как следствие, создание классов не тождественно созданию таблиц. Таблицы создаются для того, чтобы хранить/предоставлять семантически однородную информацию (с учетом правил нормализации, естественно). Классы должны предоставлять интерфейсы, то есть, понятие класса более абстрактно. Чтобы было понятнее поясню примером. У OW можно запросить информацию такого рода: "Найти классы, которые обладают следующими интерфейсами". К RDBMS обычно не обращаются с запросом: "Найти все таблицы, имеющие перечисленные поля". Используя полученный от OF класс, программа может создать, использовать и сохранять объекты данного класса.
Кортежи RDBMS, как правило, не хранят идентификатор того, объекты должны «знать» кому они принадлежат (имеется ввиду не пользователь, а объект-контейнер). OW должна помнить контролировать протяженность хранения информации об объектах, с учетом того, что какие-то объекты могут быть разделяемыми. Что опять-таки связано с различием в семантике кортежей и объектов.
Список различий можно продолжать достаточно долго, но проще попробовать понять истоки этих различий. К сожалению, в литературе по системам хранения информации этому вопросу уделяется незаслуженно мало места. И в результате продолжаются нескончаемые попытки сделать некую «объектную» надстройку над RDBMS...
...
Рейтинг: 0 / 0
16.11.2004, 14:06
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32784796
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Меня удивляет, почему поголовно все говорят о том что есть сложность с интерфейсами у классов в базе.

Мне например, ни разу не понадобилось чтобы объект одного класса обладал свойствами и другого тоже. Хотя такое реализовать совершенно не проблема. Ведь объект может принадлежать не одному классу, а нескольким, и это реализуется очень просто.

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

Один мой знакомый, который разработал несколько ОО фреймворков для работы с базой сделал такую штуку:
Клиент работает с базой только через вьюхи, вьюхи редактируемые с использованием инстед-триггеров. Причем все это дело он генерил автоматов в Ервине. Описывал сущности и получал код таблиц, вьюх и триггеров.
...
Рейтинг: 0 / 0
16.11.2004, 16:05
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32784802
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Кстати, вот вам и ответ на вопрос о инкапсуляции.

--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
16.11.2004, 16:07
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32785298
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
Вопрос к ASU относительно примеров реализации реляционной модели безотносительно rdbms в силе.
...
Рейтинг: 0 / 0
16.11.2004, 19:46
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32785351
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Под прямым доступом в данном контексте я понимаю возможность обращения
> прямо к таблицам для использования SQL конструкций.

Я так и думал.

Основных посылок треда imho две: 1. в реляционных базах данных затруднительна полная реализация объектной модели; 2. вместе с реализацией объектной модели (пусть частичной) испольуется "прямой" доступ к данным посредством SQL.

Imho (это я и пытался донести) объектную модель в реляционной СУБД оправданно реализовать в той мере, в которой это а. не противоречит основным принципам проектирования (по Дейту), б. не противоречит п. 2 предыдущего абзаца.
...
Рейтинг: 0 / 0
16.11.2004, 20:47
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32785456
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
funikovyuri Programmer_Ortodox

А как вы позиционируете ваш продукт ( в сравнении с тем же Hibernate или Code)?

Увы, Уважаемый коллега, пока никак, поскольку продукта пока нет,т.е. продукта,в его коммерческом понимании. Возможно именно сейчас необходимо зафиксировать некий объем функционала и сделать законченную программу со всеми полагающимися атрибутами. Может будут предложения по набору функций для первой версии первого продукта? Разумеется,исходя из уже сделанного. А сделано пока только универсальное хранилище данных,которое не зависит от конкретных специфик конкретного sql-сервера. Немного раньше была такая зависимость,т.к. использовались рекурсивные хранимые процедуры для обработки таблиц с древесной организацией,потом,переводя это решение на mssql, пришлось эти процедуры переписать в нерекурсивном духе,т.к.должной поддержки рекурсии в mssql нет, чего не скажешь об Oracle или Interbase, - там с этим вопросом порядок. Мне представляется, что сначала можно предложить программу примерно в таком виде: "Электронный архив", "Документооборот", "CRM", или даже все в одном флаконе? А после этого можно будет сделать следующий шаг: Создать внутренний язык, например, введя базовый тип "SCRIPT". Вот такие вот бродят в голове мысли...

PS
Про Hibernate раньше не слышал, нашел в гугле, посмотрел на сайте,первое впечатление,-совершенно что-то другое,заточенное на Java-разработчиков.
Найти Code не удалось,уж больно словечко ходовое, киньте ссылочку пожалуйста.
...
Рейтинг: 0 / 0
17.11.2004, 00:05
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32785459
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Programmer_Ortodox funikovyuri Programmer_Ortodox

А как вы позиционируете ваш продукт ( в сравнении с тем же Hibernate или Code)?

Увы, Уважаемый коллега, пока никак, поскольку продукта пока нет,т.е. продукта,в его коммерческом понимании. Возможно именно сейчас необходимо зафиксировать некий объем функционала и сделать законченную программу со всеми полагающимися атрибутами. Может будут предложения по набору функций для первой версии первого продукта? Разумеется,исходя из уже сделанного. А сделано пока только универсальное хранилище данных,которое не зависит от конкретных специфик конкретного sql-сервера. Немного раньше была такая зависимость,т.к. использовались рекурсивные хранимые процедуры для обработки таблиц с древесной организацией,потом,переводя это решение на mssql, пришлось эти процедуры переписать в нерекурсивном духе,т.к.должной поддержки рекурсии в mssql нет, чего не скажешь об Oracle или Interbase, - там с этим вопросом порядок. Мне представляется, что сначала можно предложить программу примерно в таком виде: "Электронный архив", "Документооборот", "CRM", или даже все в одном флаконе? А после этого можно будет сделать следующий шаг: Создать внутренний язык, например, введя базовый тип "SCRIPT". Вот такие вот бродят в голове мысли...

PS
Про Hibernate раньше не слышал, нашел в гугле, посмотрел на сайте,первое впечатление,-совершенно что-то другое,заточенное на Java-разработчиков.
Найти Code не удалось,уж больно словечко ходовое, киньте ссылочку пожалуйста.

Хотя есть примеры, когда продается решение с не очень четкими границами, я имею ввиду, что нет законченной программы,инсталлятор и т.д., а естькомплекс решенных вопросов, по крайней мере мне так показалось, когда я ознакомился вот с этим:
http://www.intertech.ru/Production/ok.asp

Слышал,что есть что-то аналогично этому у фирмы Ланит
В общем люди хотят единых баз, где все их нижнее белье собрано в одном месте (на логическом уровне) , иначе почему это покупается...
...
Рейтинг: 0 / 0
17.11.2004, 00:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32785464
Один
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Один
Участник
2 Programmer_Ortodox
" универсальное хранилище данных,которое не зависит от конкретных специфик конкретного sql-сервера "

Лично я, как только слышу подобного рода фразы, сразу настораживаюсь и подсознательно настраиваюсь против продукта.... Это не "наезд" на вашу систему, так, замечание в сторону.

PS: недавно мой знакомый, которого я считаю грамотным специалистом, искал как раз "Объектную надстройка над реляционной СУБД", просто чтобы посмотреть у кого что реализовано и как это работает. Я не знаю на что он смотрел, по каким критериям отбирал и т.п., короче говоря не следил я за процессом. Но результат - он махнул рукой, т.к. это были, по его словам "поделки, толком не реализующие ни объектный, ни реляционный подход и накладывающие на разработку огромное количество странных ограничений"
...
Рейтинг: 0 / 0
17.11.2004, 00:30
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32785486
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> http://www.intertech.ru/Production/ok.asp

А при чем здесь объекты?
...
Рейтинг: 0 / 0
17.11.2004, 02:01
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32785507
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Один2 Programmer_Ortodox
" универсальное хранилище данных,которое не зависит от конкретных специфик конкретного sql-сервера "

Лично я, как только слышу подобного рода фразы, сразу настораживаюсь и подсознательно настраиваюсь против продукта.... Это не "наезд" на вашу систему, так, замечание в сторону.

PS: недавно мой знакомый, которого я считаю грамотным специалистом, искал как раз "Объектную надстройка над реляционной СУБД", просто чтобы посмотреть у кого что реализовано и как это работает. Я не знаю на что он смотрел, по каким критериям отбирал и т.п., короче говоря не следил я за процессом. Но результат - он махнул рукой, т.к. это были, по его словам "поделки, толком не реализующие ни объектный, ни реляционный подход и накладывающие на разработку огромное количество странных ограничений"

В данном случае всего лишь пример того, что структура данных проработана более тщательно, чем обычно (я имею ввиду решение подобных задач "в лоб" с использованием популярных CASE-средств), только и всего. Это дает возможность не возвращаться к этому вопросу впредь (перепроректирования данных), как это бывает при традиционном подходе, когда ситуация меняется и приходится создавать новые таблицы, поля, ограничения и привязывать это к уже эксплуалирующимся данным,т.е. как бы решать задачу вновь и, зачастую ее решать очень не просто. Речь не идеть о методологии программирования,как это дурно воспринимается некоторыми участниками обсуждения. Речь идет об организации данных.Любых. И слобо "объект" я употребляю здесь именно в этом контексте,т.е. хранится в базе объект,любой объект,даже если это кусок кода.
...
Рейтинг: 0 / 0
17.11.2004, 03:59
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32785512
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Старина Аристотель говорил: "Давайте договоримся о терминах!" Вполне уместное напоминание, не так ли??? Так вот я и предлагаю последовать его примеру. Если говорить об организации (структуре) хранимых в базе данных, то,с моей точки зрения все-таки будет рациональнее придерживаться общепринятой терминологии,а именно,если хранение данных организуется средствами распространеннных sql-серверов,то употреблять такие понятия,как: Таблица, поле, тип поля, первичный ключ, внешний ключ, ограничение ссылочной целостности, хранимая процедура/функция. Все-таки эта терминология более первична в данной области,чем та,которая используется case-средствами. Так вот, в представленном решении речь идет об организованном хранении любой информации,поэтому я и употребил слово объект. Объект может быть простым (один составной элемент, так и сколь угодно сложным, содержать в себе любую иерархию других объектов, как простых, так и сложных,причем, содержать как прямым включением,так и ссылкой. Любой объект,независимо от его места в общей иерархии или в иерархии другого объекта, может иметь дерево свойств,т.е. аналогичную структуру,с точки зрения организации,но несущего уже другую смысловую нагрузку, т.е. описывать уже конкретные признаки(свойства). Каждое свойсто имее свой тип данных, которое имеет значение этого типа. Каждый объект может иметь свое,совершенно индивидуальное дерево свойств, а не обязятельно точно такой же набор своест,который имеют его соседи по разделу(папке). После разработки такой структуры,ее тестировании, оказывается, ято клиентским программам совершенно не обязательно иметь доступ к какому-то sql, нет просто такой необходимости, хранилище данных может развиваться в любую сторону и без этого.

А что касается методологии программирования,то это для меня следующий этап, этап формализации требований к встроенному языку программирования. Скорее даже скрипту,-они сейчас стали многоязычными. Я этим хочу сказать следующее: Ничто не мешает ввести такой базовый тип данных 'script, свойства объектов такого типа могут хранить этот скрипт как в виде исходного текста скрипта,так и в еого скомпилированном виде(P-код). Скрипт поддерживает ООП, ему нужно сделать доступным окружающий его контекст и вот тогда наша плодотворная :) дискуссия имеет все шансы выйти на новый уровень. Или нет?
...
Рейтинг: 0 / 0
17.11.2004, 04:24
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32785551
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Так вот, в представленном решении речь идет об организованном хранении любой
> информации,поэтому я и употребил слово объект.

Хм... чем дальше в лес, тем толще партизаны. :( Информацию Вы трактуете так же, как Шеннон? Или у Вас есть отдельные соображения на этот счет?

Прочтите, пожалуйста, первое сообщение г-на ASU еще раз; совершенно очевидно, что обсуждение развивается в двух никак не связанных направлениях. Вы совершенно безосновательно называете объектной надстройкой систему классификации, а Вам пытаются рассказать, что объектная модель как бы совсем не то, о чем Вы говорите.
...
Рейтинг: 0 / 0
17.11.2004, 07:02
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32787752
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
funikovyuri
Участник
Programmer_Ortodox


ОК. Как я понял сейчас это что-то типа конструктора, позволяющего строить определенную схему БД. При этом он оперирует "определениями" большей частью из ОО-мира. Т.е. мы моделируем "типы" которые могут быть "связаны" определенными типами связей - опять же "наследованием/generalization", "ассоциацией/агрегацией" (к стати - они как-то отличаются друг от друга в данной реализации или нет?)
Что еще - есть ли инкапсуляция и в каком виде. Что с методами/поведением - возможет ли динамический полиморфизм в самой БД - т.е. какие-то механизмы для его использования на стороне сервера.

Все, теперь насчет клиентской части.
Что из себя представляет клиент - набор классов, сохраняющих себя в БД? Они создаются автоматически? А у них динамических полиморфизм возможен?

Как я себе представляю - тот же эффект в принципе можно достичь с помощью
1 - CASE средства. С его помощью получим ОО-модель и схему бд.
2 - используя ORM получаем сохраняемые классы на каком-либо оо-языке


ORM - это Object-Relational Mapping - т.е. объектно-реляционное отображение. Сейчас существует большое количество продуктов выполняющих его автоматически. В мире java есть JDO - Java Data Objects http://java.sun.com/products/jdo/. Это спецификация на средства ORM в java. По этой спецификации уже создано куча средств - от бесплатных до не очень. Например, Hibernate http://www.hibernate.org , kodo (code -это моя опечатка) http://solarmetric.com
...
Рейтинг: 0 / 0
17.11.2004, 19:01
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32787780
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
funikovyuri Programmer_Ortodox


ОК. Как я понял сейчас это что-то типа конструктора, позволяющего строить определенную схему БД. При этом он оперирует "определениями" большей частью из ОО-мира. Т.е. мы моделируем "типы" которые могут быть "связаны" определенными типами связей - опять же "наследованием/generalization", "ассоциацией/агрегацией" (к стати - они как-то отличаются друг от друга в данной реализации или нет?)
Что еще - есть ли инкапсуляция и в каком виде. Что с методами/поведением - возможет ли динамический полиморфизм в самой БД - т.е. какие-то механизмы для его использования на стороне сервера.

Все, теперь насчет клиентской части.
Что из себя представляет клиент - набор классов, сохраняющих себя в БД? Они создаются автоматически? А у них динамических полиморфизм возможен?

Как я себе представляю - тот же эффект в принципе можно достичь с помощью
1 - CASE средства. С его помощью получим ОО-модель и схему бд.
2 - используя ORM получаем сохраняемые классы на каком-либо оо-языке


ORM - это Object-Relational Mapping - т.е. объектно-реляционное отображение. Сейчас существует большое количество продуктов выполняющих его автоматически. В мире java есть JDO - Java Data Objects http://java.sun.com/products/jdo/. Это спецификация на средства ORM в java. По этой спецификации уже создано куча средств - от бесплатных до не очень. Например, Hibernate http://www.hibernate.org , kodo (code -это моя опечатка) http://solarmetric.com

Увы, "истина где-то рядом":). На самом же деле, это "нечто" представляет собой структуру базы данных, построенную стандартными средствами sql, структуру неизменную, с жесткими ограничениями ссылочной целостности. Эта структура может обслуживать любую предметную область в смысле хранения какой угодно информации. Т.е. можно вообще забыть про вопросы проектирования структуры базы, имея эту, универсальную и неизменную. Все остальное - уровнем выше,т.е. наполнение хранилища информацией, ее структуризация и реструктуризация, введение каких либо интерпретирующих систем и т.д. Можно забыть про работу с субд на нижнем уровне и работать с готовой документированной структурой. И все.
...
Рейтинг: 0 / 0
17.11.2004, 19:22
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32787796
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
funikovyuri
Участник
Т.е. можно вообще забыть про вопросы проектирования структуры базы, имея эту, универсальную и неизменную.

А эту структуру строят изходя из каких знаний/соображений?
...
Рейтинг: 0 / 0
17.11.2004, 19:33
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32787846
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
funikovyuriТ.е. можно вообще забыть про вопросы проектирования структуры базы, имея эту, универсальную и неизменную.

А эту структуру строят изходя из каких знаний/соображений?

На сегодня это пока так:
Подключаемся с sql-серверу, выполняем готовый sql-скрипт. Все, стуктура готова. Для наполнения/реорганизации используется клиентская программа, получается, что это как бы админская утилита. Дальше можно разрабатывать разнообразные приложения, которые при работе с базой пользуются одной и той же структурой, получается такое связующее эти приложения звено. По моему мнению это очень хорошо.
...
Рейтинг: 0 / 0
17.11.2004, 20:26
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32787852
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
funikovyuriТ.е. можно вообще забыть про вопросы проектирования структуры базы, имея эту, универсальную и неизменную.

А эту структуру строят изходя из каких знаний/соображений?

На сегодня это пока так:
Подключаемся с sql-серверу, выполняем готовый sql-скрипт. Все, стуктура готова. Для наполнения/реорганизации используется клиентская программа, получается, что это как бы админская утилита. Дальше можно разрабатывать разнообразные приложения, которые при работе с базой пользуются одной и той же структурой, получается такое связующее эти приложения звено. По моему мнению это очень хорошо.
...
Рейтинг: 0 / 0
17.11.2004, 20:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32787859
Фотография ЗоринАндрей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЗоринАндрей
Участник
Programmer_OrtodoxМожно забыть про работу с субд на нижнем уровне и работать с готовой документированной структурой.

ИМХО, перекладывание с больной головы на здоровую.
Отказаться от услуг DBMS по контролю соответствия типов, осмысленной индексации, осмысленной с точки зрения домена ссылочной целостности,
только ради того чтобы потом иметь геморрой с реализацией всего этого иными средствами "уровнем выше"?

Все это напоминает попытки сложить данные так чтобы "больше не работать".
Бесперспективно. Есть работа по проектированию структуры - не важно как хранятся данные - кто-то все равно должен этим заниматься и на пользователей переложить это не удастся.
И проблем традиционного подхода это не решает никак вообще - ибо если мне скажут вот вместо привычного SQL и разработки нормализованной структуры данных есть некий доморощенный скрипт-язык и некие средства описания "объектов".
Естественно я отвечу - ну и зачем это все?
Устроить помойку в которую можно сваливать все что угодно, из-за нежелания заниматься проектированием структуры БД?

Так о чем мы говорим? Об объектной надстройке над НОРМАЛЬНОЙ реляционной базой или о некоем репозитории для хранения данных который в силу своей универсальности всегда будет тормозным и слабо-управляемым с прикладной точки зрения?

Вот уж действительно меткое наблюдение - программисты не связанные проектом и дедлайнами сразу начинают писать супер-пупер универсальный движок "Эта-штука-может-все-только-настроить-надо-правильно".
...
Рейтинг: 0 / 0
17.11.2004, 20:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32789016
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
guest_20040621Вопрос к ASU относительно примеров реализации реляционной модели безотносительно rdbms в силеВ моем сообщении речь шла не о реализациях, а именно о моделях, как реляционных, так и объектных. Каких примеров Вы от меня ждете?
...
Рейтинг: 0 / 0
18.11.2004, 13:12
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32789858
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> В моем сообщении речь шла не о реализациях, а именно о моделях, как
> реляционных, так и объектных. Каких примеров Вы от меня ждете?

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

Кроме того, было бы крайне интересно как, по-Вашему, должны сосуществовать семантическое проектирование и объектная модель в реляционных СУБД (с той точки зрения, что семантическая модель - imho модель параметрическая).
...
Рейтинг: 0 / 0
18.11.2004, 17:19
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32790010
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
guest_20040621 ASUВ моем сообщении речь шла не о реализациях, а именно о моделях, как реляционных, так и объектных. Каких примеров Вы от меня ждете?Вы писали: "...распространяете это утверждение на все "реляционные инструменты"", - из чего я сделал вывод, что существует программное обеспечение, реализующее реляционную модель, отличное от реляционных СУБД. Собственно, было бы интересно узнать, что это за программное обеспечение и что в этом программном обеспечении позволяет говорить о радикальном отличии реализации реляционной модели по сравнению с реляционными СУБДБыло достаточно много исследований в области реализаций реляционных моделей, большая часть этих работ не имеет коммерческой основы. Для примера, ни Кодд, ни реляционная алгебра не требуют, чтобы информация сохранялась в БД именно по кортежам, а не по атрибутам. Хранение по атрибутам имеет свои плюсы и минусы, но, насколько я знаю, коммерческих СУБД такого вида не было. Хотя это вполне реляционный инструмент.
guest_20040621Кроме того, было бы крайне интересно как, по-Вашему, должны сосуществовать семантическое проектирование и объектная модель в реляционных СУБД (с той точки зрения, что семантическая модель - imho модель параметрическая)Семантическая модель - декларативна, но ничто не мешает параметризовать декларацию (в принципе, конструкции любого макроязыка - есть ничто иное, как параметризованная декларация).
В основе любой инфологической модели должна лежать семантическая модель (под инфологической моделью понимается формальное описание предметной области). Инфологическую модель, в свою очередь, можно спроецировать на различные инструментальные средства, например, на ER- или IDEF-диаграммы, UML и т.п. Вполне допустима и последовательность проекций, сначала, например, на UML, потом на IDEF (хотя и не очень понятно зачем это делать, но я допускаю, что иногда это может быть полезно). Таким образом, связь может быть примерно такой: семантическая модель - инфологическая модель - UML - IDEF. Но быть именно такой связь не обязана! В более общем случае связь между моделями правильнее было бы описать так: семантическая модель - инфологическая модель - модели полученные проекцией ИМ на разные методологии проектирования. Первые два элемента (семантическая и инфологическая модели) объективны, они не зависят от точки зрения исследователя. Третья, методологическая (инструментальная) модель субъективна, поскольку она отражает точку зрения с позиции определенной методологии. С позиции иной методологии получим иную модель.
...
Рейтинг: 0 / 0
18.11.2004, 18:19
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32790264
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> насколько я знаю, коммерческих СУБД такого вида не было. Хотя это вполне
> реляционный инструмент.

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

> семантическая модель - инфологическая модель - модели полученные проекцией
> ИМ на разные методологии проектирования

Т. е. под "объектностью" Вы подразумеваете исключительно метод[ологию] проектирования собственно базы данных?
...
Рейтинг: 0 / 0
18.11.2004, 22:56
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32790488
AlbertG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlbertG
Гость
Мое видение
...
Рейтинг: 0 / 0
19.11.2004, 09:13
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32790625
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
guest_20040621 ASUнасколько я знаю, коммерческих СУБД такого вида не было. Хотя это вполне реляционный инструментНаправление рассуждений понятно, спасибо. Достаточно давно этим не интересовался; подумал, что какие-то реализации могли появитьсяДругой пример: реляционные языки вместо SQL. Много интересных попыток, но... они так и остались на уровне "лабораторий".
guest_20040621 ASUсемантическая модель - инфологическая модель - модели полученные проекцией ИМ на разные методологии проектированияТ. е. под "объектностью" Вы подразумеваете исключительно метод[ологию] проектирования собственно базы данных?Объектная технология имеет преимущество именно на стадии проектировании. Преимущества при кодировании - это только следствие хорошего проектного решения, если нет хорошего проектного решения, то ОО-код проигрывает обычному коду (по срокам кодирования, по скорости исполнения, по объему кода, по удобству отладки и пр.).
Но я не говорю о проектировании БД, речь о проекте в целом. Проект может включать в себя создание/использование БД, но может и не включать.
...
Рейтинг: 0 / 0
19.11.2004, 10:18
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32790679
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
AlbertG Мое видение Мне кажется, что Вы не совсем правильно формулируете задачу: AlbertGЦель - минимизация затрат по построению интерфейса пользователяВы никогда не достигните поставленной цели, по той простой причине, что не сможете сформулировать критерии ее достижения (хотя можно сказать и наоборот, что Вы, добавив всего один оператор, к коду автоматически достигаете поставленной цели, поскольку не составит труда доказать, что этот оператор минимизирует затраты). Если интересно, то посмотрите эту статью , хотя она довольно старая (1994 г.).
...
Рейтинг: 0 / 0
19.11.2004, 10:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32791398
AlbertG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlbertG
Гость
ASUВы никогда не достигните поставленной цели, по той простой причине, что не сможете сформулировать критерии ее достижения (хотя можно сказать и наоборот, что Вы, добавив всего один оператор, к коду автоматически достигаете поставленной цели, поскольку не составит труда доказать, что этот оператор минимизирует затраты). Если интересно, то посмотрите эту статью, хотя она довольно старая (1994 г.).

Цель - минимизировать затраты, а не изобрести универсальную волшебную палочку. Универсальных решений не бывает.
Цели я бы скорректировал так: стандартизация проектирования базы данных наряду с уменьшением затрат по проектированию пользовательского интерфейса. И это остается частным решением.

ASUЕсли интересно, то посмотрите эту статью, хотя она довольно старая (1994 г.).

Я знаком с этой статьей. И нахожу ее очень полезной. Мой словарь метаданных похож на словарь в данной статье. Это уже практически велосипед, хоть и потертый :)
...
Рейтинг: 0 / 0
19.11.2004, 14:07
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32791847
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
ASU guest_20040621 ASUнасколько я знаю, коммерческих СУБД такого вида не было. Хотя это вполне реляционный инструментНаправление рассуждений понятно, спасибо. Достаточно давно этим не интересовался; подумал, что какие-то реализации могли появитьсяДругой пример: реляционные языки вместо SQL. Много интересных попыток, но... они так и остались на уровне "лабораторий".
guest_20040621 ASUсемантическая модель - инфологическая модель - модели полученные проекцией ИМ на разные методологии проектированияТ. е. под "объектностью" Вы подразумеваете исключительно метод[ологию] проектирования собственно базы данных?Объектная технология имеет преимущество именно на стадии проектировании. Преимущества при кодировании - это только следствие хорошего проектного решения, если нет хорошего проектного решения, то ОО-код проигрывает обычному коду (по срокам кодирования, по скорости исполнения, по объему кода, по удобству отладки и пр.).
Но я не говорю о проектировании БД, речь о проекте в целом. Проект может включать в себя создание/использование БД, но может и не включать.


>Объектная технология имеет преимущество именно на стадии >проектировании. Преимущества при кодировании - это только следствие >хорошего проектного решения, если нет хорошего проектного решения, то >ОО-код проигрывает обычному коду (по срокам кодирования, по скорости >исполнения, по объему кода, по удобству отладки и пр.).

Браво, коллега! Для таких заявлений нужно изрядное мужество! Уже слышу крик и топот беотийцев. Частенько и меня посещала такая мысль. Знайте, что Вы не один!
...
Рейтинг: 0 / 0
19.11.2004, 15:59
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32791864
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
ASU guest_20040621 ASUнасколько я знаю, коммерческих СУБД такого вида не было. Хотя это вполне реляционный инструментНаправление рассуждений понятно, спасибо. Достаточно давно этим не интересовался; подумал, что какие-то реализации могли появитьсяДругой пример: реляционные языки вместо SQL. Много интересных попыток, но... они так и остались на уровне "лабораторий".
guest_20040621 ASUсемантическая модель - инфологическая модель - модели полученные проекцией ИМ на разные методологии проектированияТ. е. под "объектностью" Вы подразумеваете исключительно метод[ологию] проектирования собственно базы данных?Объектная технология имеет преимущество именно на стадии проектировании. Преимущества при кодировании - это только следствие хорошего проектного решения, если нет хорошего проектного решения, то ОО-код проигрывает обычному коду (по срокам кодирования, по скорости исполнения, по объему кода, по удобству отладки и пр.).
Но я не говорю о проектировании БД, речь о проекте в целом. Проект может включать в себя создание/использование БД, но может и не включать.


>Объектная технология имеет преимущество именно на стадии >проектировании. Преимущества при кодировании - это только следствие >хорошего проектного решения, если нет хорошего проектного решения, то >ОО-код проигрывает обычному коду (по срокам кодирования, по скорости >исполнения, по объему кода, по удобству отладки и пр.).

Браво, коллега! Для таких заявлений нужно изрядное мужество! Уже слышу крик и топот беотийцев. Частенько и меня посещала такая мысль. Знайте, что Вы не один!
...
Рейтинг: 0 / 0
19.11.2004, 16:02
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32792081
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
AlbertG ASUВы никогда не достигните поставленной цели, по той простой причине, что не сможете сформулировать критерии ее достижения (хотя можно сказать и наоборот, что Вы, добавив всего один оператор, к коду автоматически достигаете поставленной цели, поскольку не составит труда доказать, что этот оператор минимизирует затраты). Если интересно, то посмотрите эту статью, хотя она довольно старая (1994 г.).Цель - минимизировать затраты, а не изобрести универсальную волшебную палочку. Универсальных решений не бываетВсе зависит от того, что понимать под словом "универсальность"... Если один и тот же болт можно применить в тысяче изделий, то можно ли его считать "универсальным"? Если один и тот же закон физики применяется при расчете самых разных инженерных конструкций, то можно ли считать такой закон универсальным? Если один и тот же метод применим для решения многих задач, то правильно ли его считать универсальным?
AlbertGЦели я бы скорректировал так: стандартизация проектирования базы данных наряду с уменьшением затрат по проектированию пользовательского интерфейса. И это остается частным решениемОх... как это может быть опасно!.. Помните, чем вымощена дорога в ад? Если стандартизация касается выполнения рутинных операций, то я готов согласиться с Вами. Но! Посмотрите на методики а-ля CMM... они выхолащивают творчество под тем же флагом стандартизации. Мне страшновато...
Что касается пользовательского интерфейса, то мы решаем эту задачу без всякой стандартизации. Есть дизайнер, который отвечает за то, чтобы пользовательский интерфейс был единым, простым и эргономичным. Из первонального огромного многообразия пришли к небольшому количеству видов и типоразмеров. А разработчики просто используют заготовки дизайнера. Никаких стандартов на бумаге нет, но интерфейс "стандартизован". При этом, никто никого не заставляет следовать формальностям, дизайнер творит форму, программист - содержание.
...
Рейтинг: 0 / 0
19.11.2004, 17:20
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32792092
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
Programmer_OrtodoxБраво, коллега! Для таких заявлений нужно изрядное мужество!Мужество? Нет, просто чуть-чуть здравомыслия.
Programmer_OrtodoxУже слышу крик и топот беотийцев. Частенько и меня посещала такая мысль. Знайте, что Вы не один!Спасибо.
...
Рейтинг: 0 / 0
19.11.2004, 17:24
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32792176
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Но я не говорю о проектировании БД, речь о проекте в целом. Проект может
> включать в себя создание/использование БД, но может и не включать.

Понятно. Спасибо. В общем, это и хотелось услышать. ;)

С общей концепцией проекта проблем нет (в смысле, полное понимание количества моделей, их связей и назначения). Остаются нюансы реализации. ;)

Imho количества метаинформации, описанной, в частности, в статье, ссылку на которую Вы привели, - недостаточно. Недостаточность imho имеет два источника: 1. метаинформация привязана к dbms, 2. метаинформация не рассматривается как средство описания дополнительных задач (int18, история изменений etc). Хотя вполне допускаю, что в примере дополнительные задачи просто опущены.
...
Рейтинг: 0 / 0
19.11.2004, 18:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32792365
AlbertG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlbertG
Гость
ASUВсе зависит от того, что понимать под словом "универсальность"... Если один и тот же болт можно применить в тысяче изделий, то можно ли его считать "универсальным"? Если один и тот же закон физики применяется при расчете самых разных инженерных конструкций, то можно ли считать такой закон универсальным? Если один и тот же метод применим для решения многих задач, то правильно ли его считать универсальным?
Все вокруг относительно! Все портится ..., что не может испортится, портится тоже ... :) (с) Мерфи

ASUОх... как это может быть опасно!.. Помните, чем вымощена дорога в ад? Если стандартизация касается выполнения рутинных операций, то я готов согласиться с Вами. Но! Посмотрите на методики а-ля CMM... они выхолащивают творчество под тем же флагом стандартизации. Мне страшновато...
Согласен с вами. Но именно рутинные операции "объектность" и решает.
Например ведение логов, перенос объекта, надобность в котором отпадает в архив, удаление его наконец с учетом логических связей с другими объектами.
Передача объектов между разными базами данных, передача самих изменений описаний классов наконец. Что еще осталось ? А - универсальные механизмы получения - записи объектов из/в БД. Помните посты с примерами Анатолия Тенцера на эту тему ? Где то есть в архивах новостей.
ASUЧто касается пользовательского интерфейса, то мы решаем эту задачу без всякой стандартизации. Есть дизайнер, который отвечает за то, чтобы пользовательский интерфейс был единым, простым и эргономичным. Из первонального огромного многообразия пришли к небольшому количеству видов и типоразмеров. А разработчики просто используют заготовки дизайнера. Никаких стандартов на бумаге нет, но интерфейс "стандартизован". При этом, никто никого не заставляет следовать формальностям, дизайнер творит форму, программист - содержание.
Насчет дизайна форм понятно, отдельный дизайнер - просто замечательно. У нас каждый отдельный разработчик пытается следовать стандарту, выработанному в ранние годы, и это почти всегда получается. Однако внутренний стандарт не менее важен. И тут объектная точка зрения на RDBMS может принести свои дивиденды IMHO.
...
Рейтинг: 0 / 0
19.11.2004, 21:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32792521
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
guest_20040621Imho количества метаинформации, описанной, в частности, в статье, ссылку на которую Вы привели, - недостаточно. Недостаточность imho имеет два источника: 1. метаинформация привязана к dbms, 2. метаинформация не рассматривается как средство описания дополнительных задач (int18, история изменений etc). Хотя вполне допускаю, что в примере дополнительные задачи просто опущены.Не понимаю, о чем идет речь. Что понимается под метаинформацией? Каков критерий достаточности?
...
Рейтинг: 0 / 0
20.11.2004, 10:01
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32792540
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
AlbertG ASUВсе зависит от того, что понимать под словом "универсальность"... Если один и тот же болт можно применить в тысяче изделий, то можно ли его считать "универсальным"? Если один и тот же закон физики применяется при расчете самых разных инженерных конструкций, то можно ли считать такой закон универсальным? Если один и тот же метод применим для решения многих задач, то правильно ли его считать универсальным?Все вокруг относительно! Все портится ..., что не может испортится, портится тоже ... :) (с) МерфиДля меня так и осталось загадкой Ваше высказывание
AlbertGЦель - минимизировать затраты, а не изобрести универсальную волшебную палочку. Универсальных решений не бываетЧто Вы этим хотели сказать?
AlbertG ASUОх... как это может быть опасно!.. Помните, чем вымощена дорога в ад? Если стандартизация касается выполнения рутинных операций, то я готов согласиться с Вами. Но! Посмотрите на методики а-ля CMM... они выхолащивают творчество под тем же флагом стандартизации. Мне страшновато...Согласен с вами. Но именно рутинные операции "объектность" и решаетХм... Вы в этом уверены? У меня совсем иное представление об «объектности». AlbertGНапример ведение логов, перенос объекта, надобность в котором отпадает в архив, удаление его наконец с учетом логических связей с другими объектами.
Передача объектов между разными базами данных, передача самих изменений описаний классов наконец. Что еще осталось ? А - универсальные механизмы получения - записи объектов из/в БД. Помните посты с примерами Анатолия Тенцера на эту тему ? Где то есть в архивах новостейЕсли Тенцер для Вас авторитет, то продолжать разговор не имеет смысла. AlbertG ASUЧто касается пользовательского интерфейса, то мы решаем эту задачу без всякой стандартизации. Есть дизайнер, который отвечает за то, чтобы пользовательский интерфейс был единым, простым и эргономичным. Из первоначального огромного многообразия пришли к небольшому количеству видов и типоразмеров. А разработчики просто используют заготовки дизайнера. Никаких стандартов на бумаге нет, но интерфейс "стандартизован". При этом, никто никого не заставляет следовать формальностям, дизайнер творит форму, программист - содержаниеНасчет дизайна форм понятно, отдельный дизайнер - просто замечательно. У нас каждый отдельный разработчик пытается следовать стандарту, выработанному в ранние годы, и это почти всегда получается. Однако внутренний стандарт не менее важен. И тут объектная точка зрения на RDBMS может принести свои дивиденды IMHOМне кажется, что мы говорим о принципиально разных вещах. Вы уверены в том, что стандарты – это хорошо. Но это объективно не так. Стандарты, как воплощение (передового) опыта и знания имеют не только положительную, но и отрицательную сторону. Любое знание относительно, и новое знание неизбежно отрицает старое знание. Чем глубже укоренилось «старое» знание, тем тяжелее перейти к новому, а стандарты помогают укоренению. Жизнь очень динамична (в программировании особенно). Если стандарты будут меняться столь часто, как этого требует жизнь, то они перестанут быть стандартами (утратят смысл). Зачем ориентироваться на какой-то стандарт, если он сменится раньше, чем закончится проект. Если будем ориентироваться на стандарт, то мы не сможем завершить проект, поскольку придется переделывать под новый стандарт, пока переделываем, выйдет еще более новый и т.д. Аналогично, можно говорить и об опыте, опыт безусловно полезен, пока не изменились условия работы. Как только они поменялись, опыт будет мешать освоить новые приемы, которые в большей степени соответствуют изменившимся условиям (более прогрессивны). Все понимают, что освоить что-то проще, чем переучиться. Чем больше груз знаний и опыта, тем консервативнее человек.
Поэтому мы не следуем стандартам, мы следуем условиям. Дизайнер, который разрабатывает внешний вид форм, отчетов и документации – это не стандарт, это Творец. Программист, который вырабатывает приемы эффективного создания кода, - это не стандарт, это Творец. Если Вы пойдете по пути создания стандартов, то Вы убьете Творчество, Вы закостенеете раньше, чем осознаете это. «Жизнь творит порядок, но порядок жизнь не творит» Антуан де-Сент Экзюпери.
...
Рейтинг: 0 / 0
20.11.2004, 10:47
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32792631
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Что понимается под метаинформацией?

Описание структуры данных.

> Каков критерий достаточности?

Хм... я русским по белому написал: "...по моему скромному мнению..." далее по тексту. Из чего следует совершенно однозначный вывод: мне такого описания структуры данных мало. Потому что я не смогу описать с ее помощью то, что хотел бы.

Пара копеек в Ваш диалог с member AlbertG, если позволите.

> Вы уверены в том, что стандарты – это хорошо. Но это объективно не так.

Стандарты - это не хорошо и не плохо. Это стандарты. Вам не приходит в голову ездить на автомобиле так, как хочется, а не так, как написано в правилах дорожного движения? - ровно ту же роль играют стандарты. Вот что именно понимать под стандартами, - это вопрос.

> Дизайнер, который разрабатывает внешний вид форм, отчетов и документации
> – это не стандарт, это Творец. Программист, который вырабатывает приемы
> эффективного создания кода, - это не стандарт, это Творец.

Ой, ну вот только не надо про творцов. Их настолько мало, что и говорить об этом глупо.

Дизайнер, программист - это ремесленники. Точно такие же, как и кассир супермаркета. Есть хорошие, есть посредственные, есть дауны. Даунов - сильно больше.
...
Рейтинг: 0 / 0
20.11.2004, 14:26
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32792671
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
guest_20040621 ASUЧто понимается под метаинформацией?Описание структуры данныхВ статье есть описание структуры.
guest_20040621 ASUКаков критерий достаточности?Хм... я русским по белому написал: "...по моему скромному мнению..." далее по тексту. Из чего следует совершенно однозначный вывод: мне такого описания структуры данных мало. Потому что я не смогу описать с ее помощью то, что хотел быНо я не знаю, чего бы Вы хотели. Структура данных, насколько я понимаю, соответствовала задаче, решаемой в статье. guest_20040621Пара копеек в Ваш диалог с member AlbertG, если позволитеДа, конечно. guest_20040621 ASUВы уверены в том, что стандарты – это хорошо. Но это объективно не такСтандарты - это не хорошо и не плохо. Это стандартыС моей точки зрения, стандарты – это и хорошо, и плохо одновременно. Мне кажется важным понимание плюсов и минусов.
guest_20040621Вам не приходит в голову ездить на автомобиле так, как хочется, а не так, как написано в правилах дорожного движения? - ровно ту же роль играют стандарты. Вот что именно понимать под стандартами, - это вопросЕздить не так, как положено приходит в голову любому, кто
а) часами простаивает в пробках;
б) имеет необычный автомобиль (например, спортивный/гоночный, которые не предназначены для того, чтобы ездить, «как положено»).
Теперь представьте, что тех, кто недоволен правилам становится все больше, а правила меняются редко (иначе они не могут быть правилами). Возможности, предоставляемые новыми технологиями, нарастают быстрее, чем формируются и принимаются новые стандарты. Посмотрите в соседних обсуждениях нарекания в адрес SAP, BAAN и пр. С чем связано недовольство? В частности с тем, что стандарты, принятые на этих фирмах, входят в противоречие с потребностями пользователей. guest_20040621 ASUДизайнер, который разрабатывает внешний вид форм, отчетов и документации – это не стандарт, это Творец. Программист, который вырабатывает приемы эффективного создания кода, - это не стандарт, это ТворецОй, ну вот только не надо про творцов. Их настолько мало, что и говорить об этом глупоМало? Каждый человек творец. По крайней мере, я не испытываю недостатка в творческих людях. guest_20040621Дизайнер, программист - это ремесленники. Точно такие же, как и кассир супермаркета. Есть хорошие, есть посредственные, есть дауны. Даунов - сильно большеЛюди являются ремесленниками ровно в той мере, в какой их возможности скованы устаревшими стандартами, нормами, правилами.
Каков критерий отнесения человека в разряд даунов Вы используете?
...
Рейтинг: 0 / 0
20.11.2004, 15:51
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32792693
AlbertG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlbertG
Гость
ASUПоэтому мы не следуем стандартам, мы следуем условиям. Дизайнер, который разрабатывает внешний вид форм, отчетов и документации – это не стандарт, это Творец. Программист, который вырабатывает приемы эффективного создания кода, - это не стандарт, это Творец. Если Вы пойдете по пути создания стандартов, то Вы убьете Творчество, Вы закостенеете раньше, чем осознаете это.
Да, творчество это замечательно. Однако даже внутри кода должна быть стандартизация. Иначе очень проблематично разбираться с кодом другого программиста, другого творца. Ведь многие полагают, что "правильный" код только у них. Объектность и может здесь присутсвовать как стандарт.
Если же тот же дизайнер делает формы на основе объектов, то он в равной степени мог бы и легко изменить их внешний вид в угоду новому веянию.
Цель объектности для непосредственно программиста вижу в уменьшении числа изменеий кода, для реализаций новых возможностей.
Как пример: сделали возможность задавать какую-то функциональность - фильтр определяемый пользователем, далее продвинутый пользователь уже сам может сконструировать для себя критерии отбора данных.
ASUВсе вокруг относительно! Все портится ..., что не может испортится, портится тоже ... :) (с) Мерфи
Для меня так и осталось загадкой Ваше высказывание
Я имел в виду что это тупиковая ветка, нетсмысла обсуждать универсальность чего бы то ни было, просто потому что все относительно.
ASUЕсли Тенцер для Вас авторитет, то продолжать разговор не имеет смысла.
Я не хотел Вас обидеть. Я просто упомянул его как автора практического решения.
...
Рейтинг: 0 / 0
20.11.2004, 16:24
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32792775
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Структура данных, насколько я понимаю, соответствовала задаче, решаемой в
> статье.

Да, в [1122011] я отметил, что статья носит достаточно общий характер. ОК, детали не настолько существенны, чтобы рассматривать их отдельно. Вопрос снимается.

> Ездить не так, как положено приходит в голову любому, кто

В нормальных странах для любителей ездить как вздумается есть специально отведенные для этого места. За отдельные деньги. Социальный договор, имеющий в данном случае форму правил дорожного движения, никто не отменяет.

> Теперь представьте, что тех, кто недоволен правилам становится все больше,
> а правила меняются редко (иначе они не могут быть правилами).

Ну отчего же не могут? - очень даже могут. Дело не в частоте изменений, а в обязательности их выполнения. Независимо от наличия/отсутствия денег, амбиций, спортивного автомобиля и прочего.

> Возможности, предоставляемые новыми технологиями, нарастают быстрее, чем
> формируются и принимаются новые стандарты.

Например?

> Посмотрите в соседних обсуждениях нарекания в адрес SAP, BAAN и пр. С чем
> связано недовольство? В частности с тем, что стандарты, принятые на этих
> фирмах, входят в противоречие с потребностями пользователей.

Значит, то, что они считают стандартами, таковыми не является. Или имеет кривую реализацию. Для меня SAP, BAAN и прочие монстры не являются эталоном.

> Каждый человек творец. По крайней мере, я не испытываю недостатка в
> творческих людях.

Не нужно подменять понятия. Меня не интересуют абстрактные творческие наклонности абстрактного человека. Художник? - устраивай персональные выставки, продавай работы, преподавай, - да мало ли как можно зарабатывать на жизнь творчеством. Кодируешь? - продаешь некоторое количество своих знаний по вполне конкретной цене, определяемой наличием аналогичных услуг аналогичных специалистов. Разница не очевидна?

> Люди являются ремесленниками ровно в той мере, в какой их возможности
> скованы устаревшими стандартами, нормами, правилами.

А что мешает людям перестать быть ремесленниками и начать быть творцами? Религия? ;)

> Каков критерий отнесения человека в разряд даунов Вы используете?

Обычно - на глазок. Имел бы алгоритм - запатентовал бы.
...
Рейтинг: 0 / 0
20.11.2004, 21:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32792866
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
AlbertG ASUПоэтому мы не следуем стандартам, мы следуем условиям. Дизайнер, который разрабатывает внешний вид форм, отчетов и документации – это не стандарт, это Творец. Программист, который вырабатывает приемы эффективного создания кода, - это не стандарт, это Творец. Если Вы пойдете по пути создания стандартов, то Вы убьете Творчество, Вы закостенеете раньше, чем осознаете это.Да, творчество это замечательно. Однако даже внутри кода должна быть стандартизацияНаверное, имеет смысл уточнить понятие стандарта. Стандарт – это изложение правил и нормативов обязательных для исполнения (помните, что было написано в ГОСТах: «Не соблюдение стандарта преследуется по закону»). Есть международные стандарты (например, ISO), есть государственные стандарты (например, ГОСТы), есть отраслевые стандарты (ОСТ), и, наконец, есть стандарты предприятия (например, ТУ – технические условия). В основе феномена стандартизации лежит желание упорядочить процессы производства, тестирования, управления и т.п., дать критерии соответствия. Нет никаких причин, чтобы говорить, что деятельность разработчиков программного обеспечения нельзя было стандартизовать. Можно строго регламентировать структуру кода, применяемые инструменты, методики и пр. Можно заставить («кнутом и пряником») разработчика следовать предписаниям. С точки зрения исполнения отдельного проекта экономический эффект будет великолепен. И чем больше похожих проектов, тем выше экономический эффект. Именно это положение и лежит в основе CMM и аналогичных стандартов. Действительно, становится возможным достаточно точный прогноз и сроков, и бюджета, и трудозатрат, и, в целом, себестоимости проекта. Чего же еще может желать руководитель проекта? Наверное, только одного... чтобы каждый последующий проект был «как две капли воды» похож на предыдущий. Но в проектных организациях это лишено смысла, если новый проект является копией предыдущего, то... надо просто скопировать файлы. А если жизнь подбрасывает новые задачи, то стандартизация начинает мешать. Что толку знать, что на решение какой-то другой задачи потребовался месяц, ведь надо знать сколько времени потребуется на решение этой, а не другой, задачи. И чем больше новизны, тем выше неопределенность, тем меньше помощи от стандартов, тем больше вреда от них. Стандарты сохраняют свою полезность только при выполнении рутинных операций. Но в проектном производстве в отличие от промышленного производства при правильной организации работ рутины крайне мало. К сожалению, приемы промышленного производства прямо переносят на проектное производство, без учета специфики последнего.
AlbertGИначе очень проблематично разбираться с кодом другого программиста, другого творца. Ведь многие полагают, что "правильный" код только у них. Объектность и может здесь присутсвовать как стандартКак ни странно, но программисты, которые считают, что правильный код только у них... правы. Понимаю, что это кажется нелепостью, но... это так. Когда-то Тейлор, занимаясь нормированием труда (помните: «научная система выжимания пота»?), отметил странный феномен. Если двух рабочих, не обучая предварительно, поставить на одну и ту же операцию, но так чтобы они не видели друг друга и даже не общались, то со временем у них вырабатываются одинаковые приемы. Схожесть приемов и ритма выполнения операции тем выше, чем более похожи рабочие по своим физическим параметрам, чем более схож их инструмент (оборудование). При этом каждый рабочий сам вырабатывал свои приемы, ничего не зная о приемах своего коллеги. И эти приемы были правильными, с той точки зрения, что они были оптимальны для данных условий работы.
Нет, я совсем не предлагаю ставить перед всеми разработчиками одинаковые задачи, давать им одни и те же инструментальные средства и т.п. Но, по моему мнению, к выработке навыков, приемов надо относится очень серьезно. Все разработчики имеют уникальные навыки и это нормально. Конечно, можно заставить программистов следовать каким-то правилам/стандартам. И при появлении новой проблемы они будут ждать от руководителя проекта новых указаний, новых правил, новых стандартов. И чем далее будет развиваться проект, тем чаще будут возникать вопросы несоответствия принятых стандартов новым задачам и новым условиям. Если проект достаточно сложный, то можно только гадать, что произойдет раньше: проект зайдет в тупик или он все же успеет завершиться.
Переход к разработке на основе семантических моделей имеет свою особенность. Здесь нет необходимости сковывать инициативу и творчество разработчиков, нет необходимости бояться того, что проект превратиться в очередную «вавилонскую башню». Строители вавилонского чуда утратили общий язык и это положило конец строительству. Это не метафора – это суть. Семантическая модель дает разработчикам общий язык, язык смысла. Дайте им возможность общаться на этом языке и общие принципы работы появятся сами собой... из неоткуда. Можно проложить дорожки к институту и закатать их асфальтом, но можно подождать, пока люди проложат наиболее удобный для них путь и только потом класть асфальт. И, что важно, путь пройдет не там, где ходят аккуратные и рассудительные люди. Путь пройдет там, где бегают те, кто постоянно опаздывает на работу, те кто неорганизован и рассеян. При разработке правил и внутренних стандартов можно следовать «умным» книгам, советам «мастеров», можно прокладывать дорожки и заставлять ходить по ним. Но все советы рано или поздно войдут в противоречие с жизнью. Надо следовать жизни, а не советам. И нет в этом ничего сложного, если понимается смысл.
Понимание «объектности», как стандарта, мне кажется неверным. Для меня «объектность» важна, как инструмент моделирования, как средство проецирования моделей на различные предметные области.
AlbertGЕсли же тот же дизайнер делает формы на основе объектов, то он в равной степени мог бы и легко изменить их внешний вид в угоду новому веянию.
Цель объектности для непосредственно программиста вижу в уменьшении числа изменеий кода, для реализаций новых возможностей.
Как пример: сделали возможность задавать какую-то функциональность - фильтр определяемый пользователем, далее продвинутый пользователь уже сам может сконструировать для себя критерии отбора данныхС моей точки зрения, «объектность» хороша там, где она сопряжена с постижением смысла, раскрытием этого смысла с самых разных точек зрения и, наконец, там где она подводит к пониманию композиции.
AlbertG ASUЕсли Тенцер для Вас авторитет, то продолжать разговор не имеет смысла.Я не хотел Вас обидеть. Я просто упомянул его как автора практического решенияВы меня не обидели. Гераклит сказал: «Дорога вверх и дорога вниз – одна и та же дорога». Если мы с Вами идем в разных направлениях, один вверх, а другой вниз, то у нас нет шанса понять друг друга. Один будет говорить о трудностях и красоте восхождения, второй – о сложностях и опасности спуска. Надо ли говорить, если нет возможности понять друг друга?
...
Рейтинг: 0 / 0
21.11.2004, 11:33
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32792871
ASU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASU
Гость
guest_20040621 ASUВозможности, предоставляемые новыми технологиями, нарастают быстрее, чем формируются и принимаются новые стандартыНапример?Достаточно давно существует возможность построения распределенных слабосвязных систем с высоким уровнем параллелизма (MPP-систем). Но стандартов нет до сих пор. Сейчас делаются попытки разработать GRID, но, во-первых, это еще далеко не то, что нужно/возможно, во-вторых, попытки явно опоздали (лет на 25-30), в-третьих, полезность будущих стандартов еще надо будет доказать.
guest_20040621 ASUПосмотрите в соседних обсуждениях нарекания в адрес SAP, BAAN и пр. С чем связано недовольство? В частности с тем, что стандарты, принятые на этих фирмах, входят в противоречие с потребностями пользователейЗначит, то, что они считают стандартами, таковыми не является. Или имеет кривую реализацию. Для меня SAP, BAAN и прочие монстры не являются эталономРечь не обо мне и не о Вас, а о сотрудниках этих фирм. Для них внутренние стандарты существует и отступление от них карается.
guest_20040621 ASUКаждый человек творец. По крайней мере, я не испытываю недостатка в творческих людяхНе нужно подменять понятия. Меня не интересуют абстрактные творческие наклонности абстрактного человека. Художник? - устраивай персональные выставки, продавай работы, преподавай, - да мало ли как можно зарабатывать на жизнь творчеством. Кодируешь? - продаешь некоторое количество своих знаний по вполне конкретной цене, определяемой наличием аналогичных услуг аналогичных специалистов. Разница не очевидна?Хм... Мне не приходило в голову рассматривать творчество, как... средство зарабатывания на жизнь. Творчество - это, в простом случае, самореализация. Вы случайно не перепутали понятия творца и продавца? (Кстати, и продавец может быть творцом, то есть, реализовывать себя посредством торговли).
guest_20040621 ASUЛюди являются ремесленниками ровно в той мере, в какой их возможности скованы устаревшими стандартами, нормами, правиламиА что мешает людям перестать быть ремесленниками и начать быть творцами? Религия? ;) Нет, наверное, не религия, но вера. Слепая вера в инструкции, предписания, методики. Человеку очень сложно отрешиться от всего того, что раньше регламентировало его жизнь. Лет десять назад в армиях стран НАТО проводились исследования. Казалось, что в армии в значительной части должны быть люди с сильным характером, люди, способные на риск, на принятие решений. Оказалось, что все строго наоборот. Основу армий составляли социально дезориентированные люди, люди со слабым характером, с подавленной волей, неспособные мыслить самостоятельно. Зачем в армии мыслить? Кому там нужен характер? Там нужна слепая вера в приказ, в командира. Представьте, что завтра этих людей "выпустят" в нормальную жизнь. Они будут чувствовать себя брошенными, никому не нужными. Не будет завтрака по расписанию, никто не отдаст распоряжения, все придется делать самому. Это действительно страшно...
guest_20040621 ASUКаков критерий отнесения человека в разряд даунов Вы используете?Обычно - на глазок. Имел бы алгоритм - запатентовал быВ раннем творчестве А. Макаревича была песня "Битва с дураками", она заканчивается словами:
Код: plaintext
1.
2.
3.
Когда последний дурак упал,
Труба победу проиграла.
И лишь тогда я осознал,
Насколько нас осталось мало.
Экзюпери говорил, что стоит только начать бороться с горбунами, как станет заметно, что действительно прямоходящих людей очень мало...
...
Рейтинг: 0 / 0
21.11.2004, 12:09
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32793032
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
ASUНе будет завтрака по расписанию, никто не отдаст распоряжения, все придется делать самому.Офтоп, но сразу вспомнилось, как перед дембелем, с одной стороны - хотелось на "волю", с другой стороны - в армии все так просто и привычно, а на гражданке придется снова думать, делать выбор и нести за него ответственность. Предполагаю, что в той или иной степени такое ощущение приходило ко всем бывшим "срочникам".
...
Рейтинг: 0 / 0
21.11.2004, 17:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32793102
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Достаточно давно существует возможность построения распределенных слабосвязных систем с высоким уровнем
> параллелизма (MPP-систем). Но стандартов нет до сих пор.

А для какой цели здесь стандарты?

> Речь не обо мне и не о Вас, а о сотрудниках этих фирм. Для них внутренние стандарты существует и отступление от них
> карается.

Это их бизнес, - пусть сами в своем дерьме и ковыряются. Почему Вы считаете, что меня это должно заботить?

> Творчество - это, в простом случае, самореализация.

Ничего похожего. Творчество - суть уникальный процесс с уникальными результатами. Попробуйте, например, написать что-нибудь похожее на "Идиота" или "Собачье сердце". Все буквы - в Вашем распоряжении, как и у авторов.

А реализовать функционал, который есть в Вашей программной разработке - вопрос времени и денег.

> Нет, наверное, не религия, но вера. Слепая вера в инструкции, предписания, методики.

Суть на самом деле в том, что творчество не имеет (ну, или практически не имеет) денежного эквивалента. И очень немногие могут себе позволить этим самым творчеством заниматься, потому как кушать иногда хочется.

> ...она заканчивается словами:

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

> Стандарт – это изложение правил и нормативов обязательных для исполнения

Именно. Я ГОСТы к ним не отношу.

> Понимание «объектности», как стандарта, мне кажется неверным.

Хм... по-моему, никто не говорил о стандартах. Речь шла о методике. Imho достаточно полезной.
...
Рейтинг: 0 / 0
21.11.2004, 21:09
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32793240
AlbertG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlbertG
Гость
guest_20040621Хм... по-моему, никто не говорил о стандартах. Речь шла о методике. Imho достаточно полезной.

Присоединяюсь, я говорил именно о методике. Так никто не мешает проектировать конкретные приложения для разных областей, просто в основе может быть "ядро". При этом это ядро можно развивать, внося коррективы как в будущие проекты, так и в ранее выполненные. Это плюс.

2 ASU
Я не отрицаю вашего подхода к реализации, если он подразумевает разделение диалогов и логики на уровне интерфейсов или классов.
Это весьма полезный подход. Мне он нравится.
Но он отнюдь не отрицает как использование стандартов и паттернов программирования, так и использование объетного ядра.
А утверждение что стандартны убивают творчество, это извините несерьезно. Если фирма занимается бизнесом и необходимо решать задачи, то не надо строить бизнес вокруг программиста, программист - это всего навсего обслуга. И надо это понимать. И здесь управление проектами о котором вы упомянули имеет место. Иначе будет анархия и неразбериха.
...
Рейтинг: 0 / 0
22.11.2004, 07:59
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32841205
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
Тема интересная, но разговор ушел несколько в сторону и она наверно поэтому заглохла.

Если кому еще интересно - есть готовая система типа "Объекты на SQL" -
www.s-q.ru (SQ-конструктор, Extracod)

Сразу предупреждаю, что это не реклама, и я к ним отношения не имею :)
Был интерес, нашел. Теперь разбираюсь - что они натворили.
В двух словах - двухуровневая система с тонким клиентом (вэб-интерфейс для клиента и разработчика). Сервер M$ или Oracle + IIS или Apache.
Смотрю дему для M$ SQL.
В фундаменте наверняка идеи Тенцера или кого-то другого, пришедшего к тем-же выводам, по крайней мере очень похоже.
Я и сам подобную структуру обдумывал (в плане гимнастики ума) довольно долго. С моими выводами и "требованиями" к реализации подобной системы ЭТО кореллирует очень сильно, хотя и расхождения есть.

Надеюсь обсуждение будет продолжено... :)
...
Рейтинг: 0 / 0
23.12.2004, 12:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32842376
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Тема интересная, но разговор ушел несколько в сторону и она наверно поэтому
> заглохла.

Имеющие что-то сказать по этому поводу - сказали.

> Если кому еще интересно - есть готовая система типа "Объекты на SQL" -
> www.s-q.ru (SQ-конструктор, Extracod)

Кроме пиара на s-q.ru ничего нет. Нечего обсуждать.
...
Рейтинг: 0 / 0
23.12.2004, 17:12
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32842810
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Здесь: http://www.sql.ru/forum/actualthread.aspx?tid=146123
некоторое развитие разговора, а именно опасения по поводу нежелательности(непонятно почему?) хранить большие обекты в самой базе, а не в файлах, не находят подтверждения. Все работает отлично, это по факту...Пока правда, только под IB
...
Рейтинг: 0 / 0
23.12.2004, 22:08
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32842861
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> опасения по поводу нежелательности(непонятно почему?) хранить большие обекты в самой базе

Нет опасений. И нежелательности нет. И речь шла не об объектах, а именно о файлах. Лучший способ хранения файлов - файловая система. По определению.

> а не в файлах, не находят подтверждения.

Хм... цифры и тесты - в студию.

> Все работает отлично, это по факту...Пока правда, только под IB

Еще раз: хранить файлы в базе данных - это ошибка. Хотите ходить по граблям - ходите, лично мне это проблем не создает.
...
Рейтинг: 0 / 0
23.12.2004, 23:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32843392
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Я бы и сам не прочь изучить "грабельные" аспекты вопроса, связанного с использованием BLOB, но пока никакого безобразия ни откуда не вылезло..
...
Рейтинг: 0 / 0
24.12.2004, 11:41
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32843403
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Дык все слышали о граблях, но никто не видел :))

-- Tygra's --
...
Рейтинг: 0 / 0
24.12.2004, 11:45
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32844466
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Rovdo
Гость
И хотя тема топика уже давно отошла от того, с чего она начиналась, все-таки хотелось бы немножко к ней вернуться.
Тут уже упоминался стандарт JDO. Правда какого-то ответа я так и не нашел. Поэтому хотел бы задать такой вопрос.

Существует такая группа ODMG, которая и занимается стандартизацией хранения объектов, в т.ч. и отображением их на реляционные БД. Помимо наработок для Java существуют и достаточно четко формализованные принципы и для других языков (например, C++). Как уже было отмечено, существует и большой выбор продуктов O/R мэппинга (Versant Open Access, Solarmetric KODO, ...). Упоминавшиеся в разговоре Object Factory тоже можно связать с реляционными хранилищами (например, FastObjects SQL Object Factory). Разумеется теоретическое обсуждение оптимальных способов проектирования и разработки имеет ценность и само по себе. Но насколько вообще разумно делать продукт, который (насколько я понял) во многом (понял что не во всем) повторяет функциональность давно присутствующих на рынке продуктов известных компаний? Не будет ли более рациональным опираться на существующие в мире наработки с тем, чтобы пойти дальше? Именно в этом случае продукт может привлечь значительный интерес и иметь успех.
ИМХО.
...
Рейтинг: 0 / 0
24.12.2004, 18:11
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32844548
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Не будет ли более рациональным опираться на существующие в мире наработки с
> тем, чтобы пойти дальше? Именно в этом случае продукт может привлечь
> значительный интерес и иметь успех.

Если говорить о маппинге как таковом - есть не только наработки, но и продакшн решения (hibernate, например). Проблема в том, что imho задача много шире маппинга.
...
Рейтинг: 0 / 0
24.12.2004, 19:18
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32850682
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
Programmer_OrtodoxЯ бы и сам не прочь изучить "грабельные" аспекты вопроса, связанного с использованием BLOB, но пока никакого безобразия ни откуда не вылезло..

"Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса)
...
Рейтинг: 0 / 0
30.12.2004, 01:53
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32850836
Dik76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dik76
Участник
vybegallo"Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса)"Вымывание" это конечно здорово, но только при неграмотном использовании.... конечно если блобы дергаются лишь для того чтоб в гриде их отобразить, то тогда да..
...
Рейтинг: 0 / 0
30.12.2004, 09:20
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32851644
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
vybegallo Programmer_OrtodoxЯ бы и сам не прочь изучить "грабельные" аспекты вопроса, связанного с использованием BLOB, но пока никакого безобразия ни откуда не вылезло..

"Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса)
Хе-хе...Я бы пожалуй с вами и согласился бы, если бы не мой собственный эксперимент! Он не подтверждает вашу теорию. Эксперименты с mssql и opacle впереди, есть у меня ощущение (не могу пока этого доказать), что раскрученные марки Oracle и Mssql в данном конкретном аспекте окажутся позади...
...
Рейтинг: 0 / 0
30.12.2004, 14:52
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32851927
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
Dik76 vybegallo"Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса)"Вымывание" это конечно здорово, но только при неграмотном использовании.... конечно если блобы дергаются лишь для того чтоб в гриде их отобразить, то тогда да..

Для борьбы с "вымыванием" Информикс придумал хранение и использование блобов отдельно от остальных данных (это, правда, ведет к отдельному геморрою) - но я что-то никак не придумаю, каким образом "грамотное" их использование (не только для "отображения в гридах - это, кстати, тут при чем ?) поможет вам сохранить индексные страницы в буферах. Пример приведете, а то я, может, чего не понимаю в internals ?
...
Рейтинг: 0 / 0
30.12.2004, 17:00
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32851937
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
Programmer_Ortodox vybegallo Programmer_OrtodoxЯ бы и сам не прочь изучить "грабельные" аспекты вопроса, связанного с использованием BLOB, но пока никакого безобразия ни откуда не вылезло..

"Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса)
Хе-хе...Я бы пожалуй с вами и согласился бы, если бы не мой собственный эксперимент! Он не подтверждает вашу теорию. Эксперименты с mssql и opacle впереди, есть у меня ощущение (не могу пока этого доказать), что раскрученные марки Oracle и Mssql в данном конкретном аспекте окажутся позади...

И в чем заключался ваш эпохальный эксперимент, позвольте поинтересоваться ? Вы меряли суммарную производительность сервера ? отмечали изменения hit ratio для чтения и записи до и после использования блобов ?
...
Рейтинг: 0 / 0
30.12.2004, 17:04
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32853034
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Programmer_Ortodox funikovyuriТ.е. можно вообще забыть про вопросы проектирования структуры базы, имея эту, универсальную и неизменную.

А эту структуру строят изходя из каких знаний/соображений?

На сегодня это пока так:
Подключаемся с sql-серверу, выполняем готовый sql-скрипт. Все, стуктура готова. Для наполнения/реорганизации используется клиентская программа, получается, что это как бы админская утилита. Дальше можно разрабатывать разнообразные приложения, которые при работе с базой пользуются одной и той же структурой, получается такое связующее эти приложения звено. По моему мнению это очень хорошо.

Блин! Мужик, верной дорогой идешь! На протяжении многих лет стараюсь сделать то же самое. Давай объединяться!
Вкратце:

Пользователю важен результат. Не важно как, не важно с помощью чего. Ему важен результат. Все-равно как. Пользователью нужно готовое решение.

Разработчику бизнес-правил также не важно как хранятся данные, где хранятся, в каком виде. Ему важны правила обработки данных. Логические связи м/у данными. Разработчику нужна платформа.

Разработчику нужна универсальная платформа. Универсальная насколько это возможно. Созданное Programmer_Ortodox хранилище данных подходит для этих целей. Такое хранилище - нижний слой.
Теперь нужно сделать процедуры добавления/обновления/удаления, истории (версий документов)

Сделать версии процедур. Т.е. историю программ обрабатывающих данные.

История - это отдельный разговор...

И все-таки без описания объектов, их связей (какие объекты куда разрешается вкладывать), их свойств (вязкость можно применить только к жидкостям...) не обойтись. Нужны метаданные.
Возможно эти метаданные будут в виде бизнес-правил.
Надо подумать...

И правильно, что не придерживаешься никакой парадигмы!
Это новое. Такого еще не было. И готового решения нет.

Напиши мне: ICQ 230979104.
...
Рейтинг: 0 / 0
03.01.2005, 10:25
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32853134
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Нужны метаданные.
> Возможно эти метаданные будут в виде бизнес-правил.
> Надо подумать...

Это бред, вызванный новогодней алкогольной интоксикацией?

> И правильно, что не придерживаешься никакой парадигмы!
> Это новое. Такого еще не было. И готового решения нет.

Готового решения чего? Метаданных в виде бизнес-правил?
...
Рейтинг: 0 / 0
03.01.2005, 13:34
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32853154
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
guest_20040621> Нужны метаданные.
> Возможно эти метаданные будут в виде бизнес-правил.
> Надо подумать...

Это бред, вызванный новогодней алкогольной интоксикацией?

> И правильно, что не придерживаешься никакой парадигмы!
> Это новое. Такого еще не было. И готового решения нет.

Готового решения чего? Метаданных в виде бизнес-правил?

Парирую Ваши нападки молчанием.
...
Рейтинг: 0 / 0
03.01.2005, 14:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32853386
Фотография mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mv
Участник
adisk
Блин! Мужик, верной дорогой идешь! На протяжении многих лет стараюсь сделать то же самое. Давай объединяться!
Вкратце:

Пользователю важен результат. Не важно как, не важно с помощью чего. Ему важен результат. Все-равно как. Пользователью нужно готовое решение.

Разработчику бизнес-правил также не важно как хранятся данные, где хранятся, в каком виде. Ему важны правила обработки данных. Логические связи м/у данными. Разработчику нужна платформа.

Разработчику нужна универсальная платформа. Универсальная насколько это возможно. Созданное Programmer_Ortodox хранилище данных подходит для этих целей. Такое хранилище - нижний слой.
Теперь нужно сделать процедуры добавления/обновления/удаления, истории (версий документов)

Сделать версии процедур. Т.е. историю программ обрабатывающих данные.

История - это отдельный разговор...

И все-таки без описания объектов, их связей (какие объекты куда разрешается вкладывать), их свойств (вязкость можно применить только к жидкостям...) не обойтись. Нужны метаданные.
Возможно эти метаданные будут в виде бизнес-правил.
Надо подумать...

И правильно, что не придерживаешься никакой парадигмы!
Это новое. Такого еще не было. И готового решения нет.



Во! Наконец-то была озвучена основная задача девелопмента!

И вариант решения есть:

Братцы, я с августа месяца активно работаю с Bold for Delphi / Bold for C++.

Совершенно чумовой подход – девелопер разрабатывает объектную модель приложения, на основе ее генерирует базу (Фактически, база данных становится объектной и прозрачной для разработчика.) и строит приложение (обеспечивая автоматизированный переход от модели на UML к функциональному коду). Вплоть до GUI.
Поддерживаются совершенно различные варианты – 1 – 2 – 3 – 4 – 5 – … - звенка.

Поддерживаются самые экзотические связи между данными.
Поддерживается версионность данных (документов).
Поддерживается версионность модели (переход от одной модели к другой).
Поддерживается версионность структуры базы (переход от одной структуры к другой).
Чумовой GUI (контекстно – чувствительный к контексту drag-n-drop, например), полная синхронизация состояния объектного пространства и его визуального представления (никаких датасетов с их рефрешами и проч).
Реализация синхронизации между клиентами системы (например, это можно выразить в возможности совместного редактирования данных с синхронным отображением сделанных удаленными клиентами изменений).
Реализация
Легко создаются новые контролы.
Превосходная поддержка third – party компаниями – технологии, компоненты, расширения…
Реальное разработки проекта сокращается десятикратно.
Дальнейшее развитие – для дот – Net – ECO называется.

Обеспечивает единый архитектурный подход для различных разрабатываемых задач.
Позволяет без особых трудозатрат реализовать программирование систем со сложными логическими взаимосвязями между объектами, практически не реализуемое или очень трудно реализуемое при использовании традиционных методов проектирования/разработки.

Поглядите здесь , чтобы не повторяться.


Подводные камни – да, есть. Пару синяков набил. Но уже научился обходить.

Да, отмечу, что с первых шагов система производит весьма несерьезное впечатление своей простотой.
…
Но потом!

Посмотрите в сторону Bold, не поздно еще – 2005 год только начался!
...
Рейтинг: 0 / 0
04.01.2005, 03:34
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32853619
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Перед всеми неоднократно вставала задача:
Нужно описать новый предмет (товар, материал, услугу,...).
Предмет имеет свои, свойственные только ему признаки-атбриуты (свойства).

Как хранить описания предмета?
Добавляем новый справочник!

С добавлением справочника необходимо:
1) сделать форму для ввода данных
2) процедуры проверки правильности вводимых данных
3) форму редактирования
4) форму выбора строки из справочника
5) написать процедуру добавления данных
6) процедуру модификации
7) процедуру удаления
8) процедуры-тригеры проверки целостности данных в базе
9) процедуры для обеспечения истории справочника
10) написать/изменить процедуры для отчетов, где будет нужен справочник
11) изменить/написать сами отчеты
12) Обязательно напишите мне, что еще нужно сделать. Все предложения
будут учтены.

Неоднократно добавляя справочники, документы, создавая процедуры,
формы, отчеты, мы замечаем, что действия однообразны (подобны).
Однообразие и лень подталкивает нашу творческую натуру занятся упрощением
работы. Ее совершенствованием.
Через это проходят все программисты и разработчики БД. Все задумываются
над обобщением данных и над созданием чего-то универсального...

Разные люди справляются по-разному:
1. усидчивые - старательно пишут процедуры, рисуют формы, отчеты.
на это требуется время. аккуратность. увеличивается объем кода и
соответственно процент ошибок.
2. хитрые - копируют куски кода, копируют формы, отчеты. 90% работы
сводится к поиску и замене. все происходит быстро. вроде бы приемлемо
для всех. Человек работает, выполняет работу в срок...
3. смекалистые - (и самые хитрые) накопировавшись вдоволь, обобщают данные,
делают шаблоны для процедур, форм, отчетов. Создают классы. (возможно,
здесь и рождается ООП) Создают генераторы процедур, форм, отчетов.
Все происходит быстро и удовлетворяет всех, но...

Достигнув третей стадии програмеры задумываются: как сделать так, чтобы
ничего не делать? Нельзя ли написать единое хранилище для всех данных?
Создать единые формы ввода? Написать универсальный генератор?

Глядя на файловую систему, понимаем, что единое хранилище возможно.
Кстати, что такое файл?
Это те же данные... Данные с именем. И комбинация ПУТЬ+ИМЯ - это
уникальный код.
Не хватает возможности быстро извлекать данные по разным признакам.
Решается созданием индексов.
Не хватает на файловой системе и самих признаков (атрибутов, свойств,
описывающих данные) Кстати, WinFS, разрабатываемая MicroSoft файловая
система, позволяет добавлять файлам различные атрибуты и искать по атрибутам.

Это не в коем случае не реклама WinFS. MicroSoft как всегда сделает все
очень медленным, требующим Пентиум 10 и Терабайт памяти. За примерами
далеко ходить не надо ;)


Вернемся к нам, к простым смертным.
Дальнейшие пути развития:
Путь 1. Написать единый генератор, использующий метаданные.
Генерировать структуры базы данных, процедуры, формы, отчеты (конечно,
90% отчетов надо будет рисовать ;))
Путь 2. Создать единое хранилище, общие для всех процедуры, формы, отчеты.

Как будем действовать?


adisk
---
PS: Мы все делаем одно дело.
...
Рейтинг: 0 / 0
04.01.2005, 13:21
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854520
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
ОО надстройка над РБД или Универсальное хранилище данных
(Опираясь на структуру Тенцера)

Для примеров будем использовать небольшой набор данных:
фамилия  имя    отчество    предмет
-------- ------ ----------- -------
Иванов   Иван   Иванович 
Смирнов  Семен  Семенович 
Петров   Петр   Петрович 
                            лопата

Два объекта: 
  человек и предмет.

В привычном для ОО виде:
  Человек
    фамилия
    имя
    отчество
  Предмет
    название

Хранить данные будем в таблице:
DATAS
ID   DATA
---- ---------
1    Иванов
2    Иван
3    Иванович
4    Смирнов
5    Семен
6    Семенович
7    Петров
8    Петр
9    Петрович
10   лопата

Все лежит хорошо, но...
Где фамилия? Где имя? Где предмет?. Непонятно.

Вводим код свойства и таблицу для расшифровки свойств:
PROPERTIES
ID   NAME
---- ---------
1    фамилия
2    имя
3    отчество
4    предмет

Получаем:
DATAS
ID   ID_P DATA
---- ---- ---------
1    1    Иванов
2    2    Иван
3    3    Иванович
4    1    Смирнов
5    2    Семен
6    3    Семенович
7    1    Петров
8    2    Петр
9    3    Петрович
10   4    лопата

Имеем данные и можем понять, что это за данные.
Как отсюда выяснить кто есть кто? Иванов Иван, Иванов Семен, 
Иванов Петр – как правильно? Непонятно.
Для связывания данных введем код экземпляра.
По аналогии с простой таблицей, код экземпляра (ID_S)– это номер
строки. Код свойства (ID_P) – это поле.

Получаем:
DATAS
ID   ID_S ID_P DATA
---- ---- ---- ---------
1    1    1    Иванов
2    1    2    Иван
3    1    3    Иванович
4    2    1    Смирнов
5    2    2    Семен
6    2    3    Семенович
7    3    1    Петров
8    3    2    Петр
9    3    3    Петрович
10   4    4    лопата


В привычном понимании таблица выглядела бы так:

  | 1(фамилия)  2(имя)  3(отчество) 4(предмет)
--|-----------  ------  ----------- -------
1 | Иванов      Иван    Иванович 
2 | Смирнов     Семен   Семенович 
3 | Петров      Петр    Петрович 
4 |                                 лопата

Следует отметить, что в универсальной таблице данные 
хранятся “как есть”, то есть поле DATA не имеет типа!
В этом заключается сложность построения универсальной модели
в существующих реляционных БД.
Можно данные хранить в строковом поле (varchar) или в 
универсальном (BLOB), но перед операциями над полями (SUM, 
конкатенация строк,...) необходимо будет преобразовать данные.
Нужно универсальное поле. 
Может кто знает такое?
...
Рейтинг: 0 / 0
05.01.2005, 15:37
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854527
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
В данная структуре можно хранить «перечисления»!
DATAS
ID   ID_S ID_P DATA
---- ---- ---- ---------
1    1    1    Иванов
12   1    1    Ивановский

Две фамилии у одного человека одновременно!
С фамилиями, конечно, казус, но пример показывает возможность
хранения «перечислений».


Как узнать, кому принадлежит лопата?
В реляционной базе понадобится добавить поле – код родителя.
Что если лопата принадлежит двум людям?
(связь многие ко многим)
Добавляем таблицу с двумя полями: код родителя и 
код предмета. (более универсальный способ)
В нашей базе для описания связей между данными добавим таблицу 
(LINKS). В LINKS два поля: код родителя и код предмета.
Логически связь можно описать как: Иванов владеет лопатой,
или, если прочитать наоборот: лопата принадлежит Иванову.
Получаем:
LINKS
ID_1  ID_2
----  ----
1     4


История.
Легко реализуется добавлением двух дат:
дата начала и дата окончания.
Получаем период достоверности информации

Получаем:
DATAS
ID   ID_S ID_P  DATEON   DATEOFF  DATA
---- ---- ----  -------- -------  ---------
1    1    1     01/01/05          Иванов
2    1    2     01/01/05          Иван
3    1    3     01/01/05          Иванович
4    2    1     01/01/05          Смирнов
5    2    2     01/01/05          Семен
6    2    3     01/01/05          Семенович
7    3    1     01/01/05          Петров
8    3    2     01/01/05          Петр
9    3    3     01/01/05          Петрович
10   4    4     01/01/04 31/12/04 лопата
10   4    4     01/01/05          совок

Лопата была «лопатой» в 2004 году и стала совком с 2005-го года.
Чтобы не производить каждый раз фильтрацию по дате, вынесем 
текущие (достоверные на сегодняшний день) данные в отдельную таблицу.
Будем хранить ВСЕ данные в архиве (одной большой таблице
DATAS_A) и текущие данные в отдельной таблице (DATAS).
Другими словами: таблица DATAS будет видом (view)
таблицы DATAS_A.
Или по-другому: таблица DATAS – это данные из DATAS_A
отфильтрованные по дате.

Получаем:
архив:
DATAS_A
ID   ID_S ID_P  DATEON   DATEOFF  DATA
---- ---- ----  -------- -------  ---------
1    1    1     01/01/05          Иванов
2    1    2     01/01/05          Иван
3    1    3     01/01/05          Иванович
4    2    1     01/01/05          Смирнов
5    2    2     01/01/05          Семен
6    2    3     01/01/05          Семенович
7    3    1     01/01/05          Петров
8    3    2     01/01/05          Петр
9    3    3     01/01/05          Петрович
10   4    4     01/01/04 31/12/04 лопата
10   4    4     01/01/05          совок

актуальные данные:
DATAS
ID   ID_S ID_P  DATEON   DATEOFF  DATA
---- ---- ----  -------- -------  ---------
1    1    1     01/01/05          Иванов
2    1    2     01/01/05          Иван
3    1    3     01/01/05          Иванович
4    2    1     01/01/05          Смирнов
5    2    2     01/01/05          Семен
6    2    3     01/01/05          Семенович
7    3    1     01/01/05          Петров
8    3    2     01/01/05          Петр
9    3    3     01/01/05          Петрович
10   4    4     01/01/05          совок

связи:
LINKS
ID_1  ID_2  DATEON   DATEOFF  
----  ----  -------  -------  
1     4     01/01/05 

Запись в LINKS показывает, что «Иванов» владеет «лопатой» 
с 01/01/05.
Также можно сделать историю для свойств и получить историю БАЗЫ!
...
Рейтинг: 0 / 0
05.01.2005, 15:41
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854528
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
В данная структуре можно хранить «перечисления»!
DATAS
ID   ID_S ID_P DATA
---- ---- ---- ---------
1    1    1    Иванов
12   1    1    Ивановский

Две фамилии у одного человека одновременно!
С фамилиями, конечно, казус, но пример показывает возможность
хранения «перечислений».


Как узнать, кому принадлежит лопата?
В реляционной базе понадобится добавить поле – код родителя.
Что если лопата принадлежит двум людям?
(связь многие ко многим)
Добавляем таблицу с двумя полями: код родителя и 
код предмета. (более универсальный способ)
В нашей базе для описания связей между данными добавим таблицу 
(LINKS). В LINKS два поля: код родителя и код предмета.
Логически связь можно описать как: Иванов владеет лопатой,
или, если прочитать наоборот: лопата принадлежит Иванову.
Получаем:
LINKS
ID_1  ID_2
----  ----
1     4


История.
Легко реализуется добавлением двух дат:
дата начала и дата окончания.
Получаем период достоверности информации

Получаем:
DATAS
ID   ID_S ID_P  DATEON   DATEOFF  DATA
---- ---- ----  -------- -------  ---------
1    1    1     01/01/05          Иванов
2    1    2     01/01/05          Иван
3    1    3     01/01/05          Иванович
4    2    1     01/01/05          Смирнов
5    2    2     01/01/05          Семен
6    2    3     01/01/05          Семенович
7    3    1     01/01/05          Петров
8    3    2     01/01/05          Петр
9    3    3     01/01/05          Петрович
10   4    4     01/01/04 31/12/04 лопата
10   4    4     01/01/05          совок

Лопата была «лопатой» в 2004 году и стала совком с 2005-го года.
Чтобы не производить каждый раз фильтрацию по дате, вынесем 
текущие (достоверные на сегодняшний день) данные в отдельную таблицу.
Будем хранить ВСЕ данные в архиве (одной большой таблице
DATAS_A) и текущие данные в отдельной таблице (DATAS).
Другими словами: таблица DATAS будет видом (view)
таблицы DATAS_A.
Или по-другому: таблица DATAS – это данные из DATAS_A
отфильтрованные по дате.

Получаем:
архив:
DATAS_A
ID   ID_S ID_P  DATEON   DATEOFF  DATA
---- ---- ----  -------- -------  ---------
1    1    1     01/01/05          Иванов
2    1    2     01/01/05          Иван
3    1    3     01/01/05          Иванович
4    2    1     01/01/05          Смирнов
5    2    2     01/01/05          Семен
6    2    3     01/01/05          Семенович
7    3    1     01/01/05          Петров
8    3    2     01/01/05          Петр
9    3    3     01/01/05          Петрович
10   4    4     01/01/04 31/12/04 лопата
10   4    4     01/01/05          совок

актуальные данные:
DATAS
ID   ID_S ID_P  DATEON   DATEOFF  DATA
---- ---- ----  -------- -------  ---------
1    1    1     01/01/05          Иванов
2    1    2     01/01/05          Иван
3    1    3     01/01/05          Иванович
4    2    1     01/01/05          Смирнов
5    2    2     01/01/05          Семен
6    2    3     01/01/05          Семенович
7    3    1     01/01/05          Петров
8    3    2     01/01/05          Петр
9    3    3     01/01/05          Петрович
10   4    4     01/01/05          совок

связи:
LINKS
ID_1  ID_2  DATEON   DATEOFF  
----  ----  -------  -------  
1     4     01/01/05 

Запись в LINKS показывает, что «Иванов» владеет «лопатой» 
с 01/01/05.
Также можно сделать историю для свойств и получить историю БАЗЫ!
...
Рейтинг: 0 / 0
05.01.2005, 15:42
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854534
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
Как получить список людей? 

Или другими словами: 
Как выбрать все объекты со свойствами: фамилия, имя, отчество?
При этом нужно учитывать, что фамилия, имя или отчество может отсутствовать.

Сначала выберем записи с интересующими данными (фамилиями, именами, отчествами):
SELECT id_s
 FROM datas
 WHERE id_p = 1 OR id_p = 2 OR id_p = 3
 GROUP BY id_s
 INTO TABLE tmp

затем сами данные:
SELECT
 datas.id_s,
 datas.id_p,
 datas.data
 FROM datas, tmp
 WHERE 
  datas.id_s = tmp.id_s AND
  (datas.id_p = 1 OR
  datas.id_p = 2 OR
  datas.id_p = 3)
 ORDER BY id_s, id_p
 INTO TABLE people

что откуда:
1 – для фамилии
2 – для имени
3 – для отчества
напомню:
id_s – код экземпляра (код строки)
id_p – код свойства (код поля)

Результат:
people
ID_S ID_P DATA
---- ---- ---------
1    1    Иванов
1    2    Иван
1    3    Иванович
2    1    Смирнов
2    2    Семен
2    3    Семенович
3    1    Петров
3    2    Петр
3    3    Петрович

Нужные данные получены.
...
Рейтинг: 0 / 0
05.01.2005, 15:45
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854588
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
Группировки.
Подсчет суммы с группировкой.
Будем считать сумму с группировкой по фамилии.

DATAS
ID_S ID_P DATA
---- ---- ---------
1    1    Иванов
2    1    Смирнов
3    1    Петров
1    5    100
1    5    1000
2    5    100
3    5    100

То есть аналогичная таблица будет выглядеть так:

  | 1(фамилия) 5(сумма)
--|----------- --------
1 | Иванов     100
1 |            1000
2 | Смирнов    100
3 | Петров     100

После группировки должны получить:

  | 1(фамилия) 5(сумма)
--|----------- --------
1 | Иванов     1100
2 | Смирнов    100
3 | Петров     100

или по-новому:
NEW
ID_S ID_P DATA
---- ---- ---------
1    1    Иванов
2    1    Смирнов
3    1    Петров
1    5    1100
2    5    100
3    5    100

То есть задача сводится к группировке данных по...
коду экземпляра!

SELECT
 id_s ,;
 SUM(data) as sum
FROM datas
GROUP BY id_s
WHERE id_p = 5
INTO TABLE grouped

grouped 
ID_S SUM
---- ---------
1    1100
2    100
3    100
...
Рейтинг: 0 / 0
05.01.2005, 16:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854615
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
О хранении файлов в БД:
Можно хранить. Бесспорно.
Только как быть с большими файлами, с музыкой, с фильмами?
Возьмем для примера фильм.
Получается надо выкачать из базы файл размеров 650 М, куда-то его сохранить...

Или же делать из базы файловую систему с возможностью передвижения по данным (fseek()). База в свою очередь будет работать с файловой системой, где будет выполнять опять же fseek()...
...
Рейтинг: 0 / 0
05.01.2005, 16:32
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854701
Vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vybegallo
Гость
To adisk :

Это ваше "универсальное хранилище" придумывается каждым программистом баз даных на определенном этапе профессионального роста. Позже приходит понимание, что выигрыщ в простоте проектирования не стоит сооруженного на свою голову геморроя с запросами. А потом приходит заказчик и закатывает истерику, что все работает недопустимо медленно...
...
Рейтинг: 0 / 0
05.01.2005, 17:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854717
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
VybegalloTo adisk :

Это ваше "универсальное хранилище" придумывается каждым программистом баз даных на определенном этапе профессионального роста. Позже приходит понимание, что выигрыщ в простоте проектирования не стоит сооруженного на свою голову геморроя с запросами. А потом приходит заказчик и закатывает истерику, что все работает недопустимо медленно...

Что ж.
Возможно еще не дорос.
Прекрасно осознаю, что будет падение производительности.
Будет ли оно столь ощутимым? Думаю нет.
...
Рейтинг: 0 / 0
05.01.2005, 18:06
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854845
Vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vybegallo
Гость
adisk VybegalloTo adisk :

Это ваше "универсальное хранилище" придумывается каждым программистом баз даных на определенном этапе профессионального роста. Позже приходит понимание, что выигрыщ в простоте проектирования не стоит сооруженного на свою голову геморроя с запросами. А потом приходит заказчик и закатывает истерику, что все работает недопустимо медленно...

Что ж.
Возможно еще не дорос.
Прекрасно осознаю, что будет падение производительности.
Будет ли оно столь ощутимым? Думаю нет.

Ну давайте я помогу дорасти.
Дано :
таблица customers, 100 000 записей
customer_id int
customer_desc char(50)

Таблица orders, 1 000 000 записей
order_id int
customer_id int
order_desc char(50)
order_cost decimal (9,2)
order_date date
order_flag char(1)

Требуется :
найти сумму отгруженных договоров (order_flag="Y") с 1.1.2004 по 31.12.04 по каждому покупателю и описание покупателя.

select customer_id, customer_desc , sum(order_cost) from customers, orders
where customers.customer_id = orders.customer_id
and order_flag = "Y"
and order_date between "01/01/2004" and "12/31/2004"
group by 1, 2


Давайте вашу модернизированную схему и запрос, время выполнения я сейчас померяю для своей задачи и потом на том же железе - для вашего варианта.
...
Рейтинг: 0 / 0
05.01.2005, 22:18
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854847
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
У меня есть четкое убеждение, что вышеописанная идея "универсального хранилища" подходит только для создания справочников номенклатурных позиций, так как там довольно мало реальных записей (под этой цифрой я подразумеваю 50000-60000).
Если при этом учесть, что в "универсальном хранилище" записей, описывающих каждую позицию, будет порядка в 5 раз больше, то с производительностью системы, в которой все так реализовано, будет все понятно.

Городить бизнес-логику в такой системе я думаю, не есть удобно, а довольно тяжело. Надо ведь реализовать такие вещи, как ссылочную целостность, уникальность и др. Говорю я, что тяжело, так как сам создавал такую систему.Она поддерживала и целостность и уникальность (как по простым поля, так и по составным) и прочее, но именно из-за своей производительности "база данных в базе данных" смысл имеет очень малый. Опять таки, можно же добавлять данные непосредственно в таблицы словаря БД (чур меня) и будет та же "универсальность" ... -:)

Кстати, в инете полно таких "универсальных хранилищ". Если надо, то когда выйду на работу, моги кинуть ссылки.
...
Рейтинг: 0 / 0
05.01.2005, 22:19
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854864
Vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vybegallo
Гость
Results :

1. No indexes, order_date between 1/1/04 and 12/31/04
optimized uses dynamic hash join
real 0m36.64s
user 0m1.31s
sys 0m0.16s

2. second run with the same parameters:

real 0m38.53s
user 0m2.02s
sys 0m0.21s

---- 3 : indexes on c.customer_id, o.customer_id, o.order_date ,
real 1m13.51s
user 0m1.72s
sys 0m0.14s

----- 4 indexes on c.customer_id, o.(order_date+cutomer_id) ----
real 0m50.93s
user 0m1.64s
sys 0m0.22s

------ 5 (no indexes, order_date between 1.11.04 and 12.31.04)
real 0m9.77s
user 0m0.35s
sys 0m0.06s

------ 6 (all indexes, 1 month)
real 0m9.99s
user 0m0.32s
sys 0m0.08s
--------------------


Что интересно, на данной задаче мне не удалось подобрать индекс(ы), улучшающие результат полученный dynamic hash join (Informix 9.21, Sun).
...
Рейтинг: 0 / 0
05.01.2005, 23:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854892
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
Vybegallo, Вы все пишете абсолютно правильно, я бы даже сказал канонически правильно. ;) Позволю себе тем не менее обратить Ваше внимание на некоторые детали:

> А потом приходит заказчик и закатывает истерику, что все работает недопустимо медленно...

Заработная плата одного девелопера за год больше стоимости кластера из четырех двухпроцессорных серверов. Может, в этом контексте производительность - не самое узкое место?

> найти сумму отгруженных договоров (order_flag="Y") с 1.1.2004 по 31.12.04 по
> каждому покупателю и описание покупателя.

Не думаю, что такие отчеты - самая типичная задача. Т. е. сравнить-то оно конечно можно, только результат понятен и без сравнения. ;)

Imho проблемы описанных здесь т. н. универсальных хранилищ заключаются отнюдь не в производительности (это следствие), а в абсолютно неправильной интерпретации возможностей реляционных СУБД для таких задач.
...
Рейтинг: 0 / 0
06.01.2005, 00:35
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854896
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> но именно из-за своей производительности "база данных в базе данных" смысл
> имеет очень малый.

Хм... imho проблема производительности преувеличена. А вот смысл очень даже имеет. Естественно, не в описанных в этом треде вариантах реализации.

> Опять таки, можно же добавлять данные непосредственно в таблицы словаря БД
> (чур меня) и будет та же "универсальность" ... -:)

К сожалению, не будет. Приложение будет намертво привязано к СУБД.
...
Рейтинг: 0 / 0
06.01.2005, 00:43
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854904
Vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vybegallo
Гость
guest_20040621Vybegallo, Вы все пишете абсолютно правильно, я бы даже сказал канонически правильно. ;) Позволю себе тем не менее обратить Ваше внимание на некоторые детали:

> А потом приходит заказчик и закатывает истерику, что все работает недопустимо медленно...

Заработная плата одного девелопера за год больше стоимости кластера из четырех двухпроцессорных серверов. Может, в этом контексте производительность - не самое узкое место?

> найти сумму отгруженных договоров (order_flag="Y") с 1.1.2004 по 31.12.04 по
> каждому покупателю и описание покупателя.

Не думаю, что такие отчеты - самая типичная задача. Т. е. сравнить-то оно конечно можно, только результат понятен и без сравнения. ;)

Imho проблемы описанных здесь т. н. универсальных хранилищ заключаются отнюдь не в производительности (это следствие), а в абсолютно неправильной интерпретации возможностей реляционных СУБД для таких задач.

1. Горбатого может исправить только могила, а неправильно продуманную базу - только ее полный редизайн. Не нужно надеяться, что железо вытянет все огрехи проектирования - на практике чаще случается выжимать из него все соки.
2. При таком дизайне, придется не только кластер прикупить, но и нанять второго девелопера, поскольку элементарный запрос приходится конструировать несколько дней. А потом пригласить консультанта, который сможет его оптимизировать до приемлимой скорости выполнения.
3. Согласен, это нетипичный отчет. Мои типичные отчеты занимают минимум полстраницы. Предложите "типичный" отчет -проверим на нем
...
Рейтинг: 0 / 0
06.01.2005, 01:04
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854908
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> 1. Горбатого может исправить только могила, а неправильно продуманную базу -
> только ее полный редизайн. [...]

Нечего возразить.

ОК, попробую с другой стороны. Скажите, лично Вас все устраивает в реляционной модели с точки зрения возможностей описания структур данных?
...
Рейтинг: 0 / 0
06.01.2005, 01:17
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854912
Vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vybegallo
Гость
Это вы на что намекаете ? :-)

Рекурсивность и древовидность сильно гадят, а так - не жалуюсь.
...
Рейтинг: 0 / 0
06.01.2005, 01:32
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32854927
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Это вы на что намекаете ? :-)

Это я пока практически еще и не начал намекать. ;)

> Рекурсивность и древовидность сильно гадят, а так - не жалуюсь.

Практически счастливый человек. ;)

ОК, давайте попробуем решить традиционным образом такую задачу: путь в базе данных есть некоторая сущность, которая может быть связана с любой из других сущностей этой же базы данных отношением n:m. Какую бы схему Вы реализовали? (hint: база данных среднего размера, единицы сотен таблиц; hint2: таких сущностей в общем случае большей одной).
...
Рейтинг: 0 / 0
06.01.2005, 02:19
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855033
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
Хочу обратить ваше внимание на хранение информации в компьютере.
Информация располагается в памяти.
Память линейна.
---------------------------------------
1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|...
---------------------------------------
Что бы мы не сохраняли, данные лягут в память. 
(виртуальную, но все же линейную. даже на винчестере данные
представлены в виде последовательности битов)

Используется объектная модель, реляционная, древовидная или 
еще какая, любые данные будут отображены в память.
Отображены, как банальная примитивная последовательность байтов.
Информация в памяти однозначно определяется адресом. (адресом
ячейки) 
Адрес – это первичный ключ.

Задача: 
Оптимально отобразить данные в линейную память, чтобы быстро 
получать данные.
Любые данные! Любого типа, любого размера.
Предлагаемое решение:

ID   ID_S ID_P DATA
---- ---- ---- ---------
1    1    1    Иванов
2    1    2    Иван
3    1    3    Иванович
4    2    1    Смирнов
5    2    2    Семен
6    2    3    Семенович

В память данные отобразятся в виде:
1    1    1    Иванов 2    1    2    Иван ...

Имеет ли смысл говорить об объектности или реляционности модели?
Все располагается линейно!

В DBF-файле данные об одном объекте собраны в строки.
Это всем знакомо...
Самая частая задача для СУБД:
вывести одно свойство, зная другое 
(например, имя человека, зная его фамилию)
Как это происходит?
Создаются индексы.
По индексам «делением пополам» происходит поиск.
Определяются строки. Считываются строки. Выводятся 
требуемые поля.

В предлагаемой выше структуре все данные содержатся в одном
поле (в одном месте). Казалось бы, и индекс по полю будет 
огромный. Но! 
Что мешает создать отфильтрованные индексы?
(например, как в FoxPro: 
INDEX ON data TO idx_name_1 FOR id_p = 1
индексируются только записи с id_p = 1)

Да, индексов будет много.
А сколько их в простой реляционной базе?
Ровно столько же!
По индексу на искомое поле. Длина индекса такая же, 
(размер индексного фала тот же). Скорость поиска – такая же!

Знаю, что создать такие индексы можно.
Буду очень признателен, если подскажете, есть ли такая
возможность в MS SQL? в других серверах?
...
Рейтинг: 0 / 0
06.01.2005, 09:52
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855127
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
По моему скромному мнению данные надо хранить так как удобно для
компьютера, а представлять их так как удобно человеку.
То есть планировать, проектировать базу и работать с объектами.
Но хранить в виде удобном для обработки компьютером.

Золотая середина мне представляется в "ОО модели над РБД".
В чем и хочу посоветоваться с Вами, уважаемые...
...
Рейтинг: 0 / 0
06.01.2005, 11:32
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855227
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Как всегда началось: "Приложение будет намертво привязано к СУБД." Ну и черт ты с ним. Ну это просто мысли вслух. Просьба флейм не начинать.Кстати, где же результат запроса от adisk, а то дальше лозунгов "я думаю с производительностью будет хорошо" дело не идет.
...
Рейтинг: 0 / 0
06.01.2005, 12:35
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855300
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
ShtockКак всегда началось: "Приложение будет намертво привязано к СУБД." Ну и черт ты с ним. Ну это просто мысли вслух. Просьба флейм не начинать.Кстати, где же результат запроса от adisk, а то дальше лозунгов "я думаю с производительностью будет хорошо" дело не идет.

Присылай заархивированную базу на "adisk собака mail.ru".
...
Рейтинг: 0 / 0
06.01.2005, 13:16
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855380
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Как всегда началось: "Приложение будет намертво привязано к СУБД." Ну и черт
> ты с ним.

Я бы не был так категоричен. Hint3: решение нужно в общем виде, безотносительно СУБД.

> Ну это просто мысли вслух. Просьба флейм не начинать.

Никакого флейма. Вы предложили возможное решение, я обосновал, почему такое решение неприемлемо.
...
Рейтинг: 0 / 0
06.01.2005, 14:25
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855502
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Сам же говорил, флейма не начинать, НО: решение неприемлемо в случае, если в постановке задачи указано "система должна не зависеть от СУБД". В общем виде - так оно и есть в общем виде: использовать словарь БД. Понятно, что в каждой БД он разный, но БД без словаря не бывает -:)
...
Рейтинг: 0 / 0
06.01.2005, 16:01
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855526
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> решение неприемлемо в случае, если в постановке задачи указано "система
> должна не зависеть от СУБД".

На самом деле такой постановки задачи практически не бывает (по крайней мере, не должно быть). Я бы лучше сформулировал так: программное обеспечение должно функционировать с СУБД x, y, z.

> В общем виде - так оно и есть в общем виде: использовать словарь БД. Понятно,
> что в каждой БД он разный, но БД без словаря не бывает -:)

Это понятно. Нет смысла создавать системные объекты для каждой из возможных СУБД, - думаю, Вы представляете, почему. Хотелось бы решение чуть более высокого уровня абстракции. Есть еще варианты?
...
Рейтинг: 0 / 0
06.01.2005, 16:17
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855594
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
guest_20040621> Это вы на что намекаете ? :-)

Это я пока практически еще и не начал намекать. ;)

> Рекурсивность и древовидность сильно гадят, а так - не жалуюсь.

Практически счастливый человек. ;)

ОК, давайте попробуем решить традиционным образом такую задачу: путь в базе данных есть некоторая сущность, которая может быть связана с любой из других сущностей этой же базы данных отношением n:m. Какую бы схему Вы реализовали? (hint: база данных среднего размера, единицы сотен таблиц; hint2: таких сущностей в общем случае большей одной).

Ок, давайте вы мне расскажите реальную постановку, а я вам расскажу, почему некая "сущность, связанная отношением м:н к любой другой сущности" вам нахер не нужна.
...
Рейтинг: 0 / 0
06.01.2005, 17:22
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855609
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
других способов, не зависимых от субд, я не вижу. Что до хранения "постоянно добавляющихся атрибутов", то если это не, как уже говорилось ранее, справочник номенклатурных позиций, надо думать, что проблемы у заказчика. Если есть все-таки желание их хранить, то я в своих задачах выявляю стопроцентные атрибуты и выношу их как поля в таблицах, а если должны появиться вспомогательные новые, то делаю поле типа XML, там все и храню.
...
Рейтинг: 0 / 0
06.01.2005, 17:32
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855623
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
adiskПо моему скромному мнению данные надо хранить так как удобно для
компьютера, а представлять их так как удобно человеку.
То есть планировать, проектировать базу и работать с объектами.
Но хранить в виде удобном для обработки компьютером.

Золотая середина мне представляется в "ОО модели над РБД".
В чем и хочу посоветоваться с Вами, уважаемые...

Что-то вас мотает из стороны в сторону. То бросаетесь революцию в индексном деле устраивать, то изобретаете очередной "универсальный справочник всего", теперь вот в ООБД ударились... Про них уже насоветовали в соседнем разделе аж на 36 страниц.
Пока что ваши идеи и произведения принадлежат k разряду "компьютерной графомании". Мой вам добрый совет - поработайте с одной из серьезных баз (Оракл, MS SQL, Informix, DB2, Sybase), почитаете документацию, особенно главы про внутреннее устройство - и тогда приходите с идеями. А сейчас лучше не надо. Чтобы не было мучительно стыдно потом, поскольку форум-то нестираемый, и глупости, высказанные публично, имеют свойство всплывать в самый неподходящий момент.
Ну и запрос - я таки жду запрос. Мне очень интересно, как вы сделаете
- join между таблицами
- sum по текстовому полю
- "транспонирование" результата, чтобы две отдельных строки (сумма и описание покупателя) превратились в две колонки в результирующей таблице.
...
Рейтинг: 0 / 0
06.01.2005, 17:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855628
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
ShtockСам же говорил, флейма не начинать, НО: решение неприемлемо в случае, если в постановке задачи указано "система должна не зависеть от СУБД". В общем виде - так оно и есть в общем виде: использовать словарь БД. Понятно, что в каждой БД он разный, но БД без словаря не бывает -:)

Магические слова : SQL 92.
Чтобы решение было независимо от субд, используйте только средства, входящие в стандарт - и будет вам щасте.
...
Рейтинг: 0 / 0
06.01.2005, 17:45
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855664
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
автор
Мой вам добрый совет - поработайте с одной из серьезных баз (Оракл, MS SQL, Informix, DB2, Sybase), почитаете документацию, особенно главы про внутреннее устройство - и тогда приходите с идеями. А сейчас лучше не надо. Чтобы не было мучительно стыдно потом, поскольку форум-то нестираемый, и глупости, высказанные публично, имеют свойство всплывать в самый неподходящий момент.

Чего мне стыдится?
Того, что я не дошел до Вашего уровня, уважаемый?
Излагая свое мнения, я ищу единомышленников. Или обоснованную критику.
Если Вы такой граммотный умный человек объясните мне простой способ хранения данных с произвольными свойствами.
Метаясь из стороны в сторону, я использую страрые проверенные реляционные БД, но ищу лучшие варианты. Лучшие способы хранения и обработки данных.
Жизнь не стоит на месте и с этим Вы не можете не согласиться.
автор
Ну и запрос - я таки жду запрос. Мне очень интересно, как вы сделаете
- join между таблицами

Так же как и раньше. Операция пересечения множеств изменилась, что ли?
автор
- sum по текстовому полю

Думаю, Вы ошибочно полагаете, что я собираюсь хранить все данные в одном ТЕКСТОВОМ поле? Сказывается многолетняя работа с таблицами вроде DBF, где поля строго типизированы.
А вы думали как таблицы хранятся на диске или в памяти? там есть тип?

Замечу, что ОО поверх СУЩЕСТВУЮЩИХ РБД сделать сложно. (как раз из-за таких ограничений)
автор
- "транспонирование" результата, чтобы две отдельных строки (сумма и описание покупателя) превратились в две колонки в результирующей таблице.
Как прикладная программа Вам показывает на экране таблицу (Grid, browse или еще что...)
Какие чудеса происходят с данными полученными от SQL-сервера или считанными с диска?
Никаких. Отображение информации нужном месте в нужное время.
что в этом сложного?
Вы справшиваете как сделать это средствами MS SQL или Oracl?
...
Рейтинг: 0 / 0
06.01.2005, 18:35
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855678
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
adisk автор
Мой вам добрый совет - поработайте с одной из серьезных баз (Оракл, MS SQL, Informix, DB2, Sybase), почитаете документацию, особенно главы про внутреннее устройство - и тогда приходите с идеями. А сейчас лучше не надо. Чтобы не было мучительно стыдно потом, поскольку форум-то нестираемый, и глупости, высказанные публично, имеют свойство всплывать в самый неподходящий момент.

Чего мне стыдится?
Того, что я не дошел до Вашего уровня, уважаемый?
Излагая свое мнения, я ищу единомышленников. Или обоснованную критику.
Если Вы такой граммотный умный человек объясните мне простой способ хранения данных с произвольными свойствами.
Метаясь из стороны в сторону, я использую страрые проверенные реляционные БД, но ищу лучшие варианты. Лучшие способы хранения и обработки данных.
Жизнь не стоит на месте и с этим Вы не можете не согласиться.


Стыдиться надо неряшливости мышления. Вы систему придумали, а протестировать ее даже на самом простом случае не удосужились - прибежали на форум "советоваться".
Не говоря уж о том, что вы почему-то считаете ваш подход чем-то новым, типа "жизнь не стоит на месте". Поиск в Инете вы тоже не соизволили выполнить. Ну и получите критику, как заказывали.

adisk автор
Ну и запрос - я таки жду запрос. Мне очень интересно, как вы сделаете
- join между таблицами

Так же как и раньше. Операция пересечения множеств изменилась, что ли?


Для вас -да. Вы же все таблицы слили в одну - вот и изобразите нам операцию пересечения множеств в вашей "постреляционной" алгебре.

adisk автор
- sum по текстовому полю

Думаю, Вы ошибочно полагаете, что я собираюсь хранить все данные в одном ТЕКСТОВОМ поле? Сказывается многолетняя работа с таблицами вроде DBF, где поля строго типизированы.
А вы думали как таблицы хранятся на диске или в памяти? там есть тип?


Как данные хранятся на диске - я не думаю, я знаю. Мне интересно, как ВЫ их собираетесь хранить, а главное - обрабатывать. Поскольку чтобы обработать, субд должна знать, что именно там хранится. Традиционно это организовано как таблица syscolumns, где есть поле "тип колонки". Выши предложения ?
Или ваша система в принципе не реализуема на существующих СУБД, а представляет собой некий маниловский проджект ?

adisk
Замечу, что ОО поверх СУЩЕСТВУЮЩИХ РБД сделать сложно. (как раз из-за таких ограничений)


То, что вы предлагаете ("универсальный справочник") никоим боком не касается ООБД.

adisk автор
- "транспонирование" результата, чтобы две отдельных строки (сумма и описание покупателя) превратились в две колонки в результирующей таблице.
Как прикладная программа Вам показывает на экране таблицу (Grid, browse или еще что...)
Какие чудеса происходят с данными полученными от SQL-сервера или считанными с диска?
Никаких. Отображение информации нужном месте в нужное время.
что в этом сложного?
Вы справшиваете как сделать это средствами MS SQL или Oracl?

Именно. Я именно это и спрашиваю. Нарисуйте мне запрос, чтобы я мог его запустить из excel и получить вместо вашей длинной и узкой таблицы - широкую и короткую, как этого хотят все нормальные пользователи.
...
Рейтинг: 0 / 0
06.01.2005, 18:56
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855682
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Ок, давайте вы мне расскажите реальную постановку, а я вам расскажу, почему
> некая "сущность, связанная отношением м:н к любой другой сущности" вам нахер
> не нужна.

Да нет проблем. Например, есть словари. Толковый, технический, иностранный, - неважно, может, их несколько или они все вместе. Например, есть стандарты, согласно которым проектируются структуры данных. Две сущности - достаточно? Буквосочетание "семантик веб" ни о чем не говорит?

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

На самом деле задача абсолютно реальна. И "нахер нужна". Приводить ТЗ я не буду, - незачем, и денег оно стоило, придется верить на слово. Замечу однако, что решение у этой задачи есть.

> Что до хранения "постоянно добавляющихся атрибутов", то если это не, как
> уже говорилось ранее, справочник номенклатурных позиций, надо думать, что
> проблемы у заказчика.

Вы представляете себе разницу между детерминированными системами и адаптивными? Это не проблемы заказчика, это абсолютно нормально.

> Если есть все-таки желание их хранить, то я в своих задачах выявляю
> стопроцентные атрибуты и выношу их как поля в таблицах, а если должны
> появиться вспомогательные новые, то делаю поле типа XML, там все и храню.

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

> Магические слова : SQL 92.
> Чтобы решение было независимо от субд, используйте только средства,
> входящие в стандарт - и будет вам щасте.

Крайне важное замечание. ;)
...
Рейтинг: 0 / 0
06.01.2005, 19:06
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855688
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
guest_20040621> Ок, давайте вы мне расскажите реальную постановку, а я вам расскажу, почему
> некая "сущность, связанная отношением м:н к любой другой сущности" вам нахер
> не нужна.

Да нет проблем. Например, есть словари. Толковый, технический, иностранный, - неважно, может, их несколько или они все вместе. Например, есть стандарты, согласно которым проектируются структуры данных. Две сущности - достаточно? Буквосочетание "семантик веб" ни о чем не говорит?

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

На самом деле задача абсолютно реальна. И "нахер нужна". Приводить ТЗ я не буду, - незачем, и денег оно стоило, придется верить на слово. Замечу однако, что решение у этой задачи есть.

> Что до хранения "постоянно добавляющихся атрибутов", то если это не, как
> уже говорилось ранее, справочник номенклатурных позиций, надо думать, что
> проблемы у заказчика.

Вы представляете себе разницу между детерминированными системами и адаптивными? Это не проблемы заказчика, это абсолютно нормально.

> Если есть все-таки желание их хранить, то я в своих задачах выявляю
> стопроцентные атрибуты и выношу их как поля в таблицах, а если должны
> появиться вспомогательные новые, то делаю поле типа XML, там все и храню.

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

> Магические слова : SQL 92.
> Чтобы решение было независимо от субд, используйте только средства,
> входящие в стандарт - и будет вам щасте.

Крайне важное замечание. ;)

1. Попытайтесь не приписывать мне чужих цитат.
2. Сочетание "семантик веб" мне ни о чем не говорит
3. "Техзадание стоит денег" - это пять ! "У нас есть такие системы, но мы вам о них не расскажем" :-) Ну хоть суть-то проблемы изложить можете ? Что там со словарями не втискивается в релятивистскую модель ? Отношение "слово - значение", что ли ? Типа слово может иметь много значений, и значение может описываться синонимами ? Так это стандартное отношение м:н, разрешается вводом промежуточной таблицы.
...
Рейтинг: 0 / 0
06.01.2005, 19:19
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855707
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> 1. Попытайтесь не приписывать мне чужих цитат.

И не думал. Ответил на два сообщения сразу одним, - подумал, что каждый из авторов разберется, что кому предназначено. Если это не удобно, буду отвечать постатейно.

> 2. Сочетание "семантик веб" мне ни о чем не говорит

Хм... некоторые считают, что это будет самое употребимое буквосочетание в 2005 году. ;) Собственно, это к тому, что таких "суперсущностей" может быть не одна. В общем, неважно, забыли. Просто отметили факт: такие сущности есть. А почему, откуда они взялись, кто и как будет их использовать - как бы и не важно.

> 3. "Техзадание стоит денег" - это пять ! "У нас есть такие системы, но мы вам о
> них не расскажем" :-)

При чем здесь это? Никаких систем реально еще нет. За техническое задание действительно были заплачены imho достаточно серьезные деньги, а меня никто не уполномочил его тиражировать. Основную проблему, которая связана с этим проектом, я сформулировал.

> Ну хоть суть-то проблемы изложить можете?

Ну так я и изложил: "в базе данных есть некоторая сущность, которая может быть связана с любой из других сущностей этой же базы данных отношением n:m".

> Что там со словарями не втискивается в релятивистскую модель ? Отношение
> "слово - значение", что ли ? Типа слово может иметь много значений, и
> значение может описываться синонимами ? Так это стандартное отношение
> м:н, разрешается вводом промежуточной таблицы.

Все правильно. Теперь считаем. Как я и говорил, база данных среднего размера (единицы сотен таблиц; для определенности примем 500). Пусть это отношение имеет смысл для половины сущностей (опустили служебные таблицы и связи). Получаем 250 (двести пятьдесят) промежуточных таблиц. Создали таблицы, заполнили их. Теперь выбираем сущности, связанные с определенным словом. Как по-Вашему, какие проблемы меня здесь ждут?

И еще: по-Вашему, каково максимальное количество сущностей, к которым я могу построить такие связи (напомню, СУБД не конкретизирована)?
...
Рейтинг: 0 / 0
06.01.2005, 20:04
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855729
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
Хм... прошу прощения, уточнение. Увидел требуемое n:m, а сообщение прочел по диагонали. :( Как организован справочник (справочники) - дело десятое. Факт в том, что с ним (с ними) может быть связана любая сущность. Отсюда и количество таблиц.
...
Рейтинг: 0 / 0
06.01.2005, 20:59
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855737
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
1. Зачем вам пятьсот однотипных таблиц словарей?
2. Вас что, двести пятьдесят промежуточных таблиц пугает ? Тогда вы внутрь SAPов/Peoplesoftов/JDEdvardсов лучше не смотрите, чтоб кондратий не хватил - там счет таблицам идет на тысячи. Причем, что характерно, работают на любой промышленной БД - Oracle, MS SQL, Informix, DB2, Sybase...
...
Рейтинг: 0 / 0
06.01.2005, 21:08
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855751
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> 1. Зачем вам пятьсот однотипных таблиц словарей?

Какие пятьсот однотипных таблиц словарей? Вы о чем? Пятьсот таблиц - это собственно и есть содержимое среднего размера базы данных, про организацию словарей я ни слова не сказал. А таблиц связей со словарем, соответственно, двести пятьдесят.

> 2. Вас что, двести пятьдесят промежуточных таблиц пугает ?

Нет, меня не пугает двести пятьдесят таблиц. Я не буду использовать решение, которое предполагает двести пятьдесят запросов к базе данных для достаточно простой операции. Вы что-то, помнится, говорили про производительность? Эта операция будет использоваться гораздо чаще, чем пример с Вашим отчетом о годовых продажах. Дело в том, что сущностей, которые требуют таких промежуточных таблиц, - даже не десяток. И пользователей такой системы - далеко не десяток.

> Тогда вы внутрь SAPов/Peoplesoftов/JDEdvardсов лучше не смотрите, чтоб
> кондратий не хватил - там счет таблицам идет на тысячи.

Хм... а чего, собственно, критерий - количество таблиц? Кто сказал, что эти лавки с громкими имена используют оптимальную структуру данных? Ну, сидят там индусы-кодеры за относительно небольшие деньги и описывают себе детерминированные системы. И?

> Причем, что характерно, работают на любой промышленной БД - Oracle, MS
> SQL, Informix, DB2, Sybase...

Я за них сильно рад. Вот только лично мне этот факт мои задачи решать как бы совсем никак не помогает. Т. е. абсолютно.

Возвращаясь к теме обсуждения (напомню, речь шла об объектных надстройках): по моему мнению, есть ряд задач, которые не рационально решать традиционными для реляционных СУБД способами и структурами данных. Вот именно для решения таких задач реляционным СУБД необходима некая надстройка (объектная, квазиобъектная, постреляционная - это все не отражает ни ее назначения, ни функциональных особенностей). Не универсальное хранилище, универсальный классификатор, идеальная система и пр., - а механизм, позволяющий оптимизировать описание данных. Возражения?
...
Рейтинг: 0 / 0
06.01.2005, 21:47
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855758
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
Я все еще не вижу примера таких задач. Вы мне изложили не постановку, а свое понимание реализации - через какое-то поле связи всего со всеми. Вы попытайтесь _внятно_ рассказать, что надо сделать, а как это сделать без двухсотпятидесяти таблиц в одном запросе мы уж придумаем. Попробуйте обойтись без слов "сущность", "объект" и "связь" - замените их на что-то типа "Вася", "яблоко" и "принадлежит".

А как только мы услышим пример задачи, которую нерационально решать реляционными методами - так сразу и перейдем к обсуждению альтернативных методов.
...
Рейтинг: 0 / 0
06.01.2005, 22:01
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855761
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
guest_20040621
Все правильно. Теперь считаем. Как я и говорил, база данных среднего размера (единицы сотен таблиц; для определенности примем 500). Пусть это отношение имеет смысл для половины сущностей (опустили служебные таблицы и связи). Получаем 250 (двести пятьдесят) промежуточных таблиц. Создали таблицы, заполнили их. Теперь выбираем сущности, связанные с определенным словом. Как по-Вашему, какие проблемы меня здесь ждут?


Зачем вы разнесли сущности по пятистам таблицам ? У вас что, 500 разных словарей, и вы ищете слово по всем словарям ? Почему не поместить сущности в одну таблицу ?
...
Рейтинг: 0 / 0
06.01.2005, 22:07
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855781
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Я все еще не вижу примера таких задач.

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

> Вы мне изложили не постановку, а свое понимание реализации - через какое-то
> поле связи всего со всеми.

Ни о каких полях связи "всего со всеми" речи не было, откуда Вы это взяли?

> Вы попытайтесь _внятно_ рассказать, что надо сделать, а как это сделать без
> двухсотпятидесяти таблиц в одном запросе мы уж придумаем.

А чем пример со словарем не годится?

> Попробуйте обойтись без слов "сущность", "объект" и "связь" - замените их на
> что-то типа "Вася", "яблоко" и "принадлежит".

"Объект" я стараюсь не употреблять, поскольку для использования этого термина применительно к реляционным СУБД необходимо уточнять, о чем речь, - очень уж неоднозначно его можно интерпретировать. А "сущность" и "связь" - это как бы устоявшиеся термины; всегда думал, что они понимаются однозначно.

ОК, еще раз про словарь. Есть база данных (тематика, структура - не важны). В этой базе данных есть некий словарь (иностранных слов, толковый, - неважно), который состоит из одной таблицы (его структура роли не играет). Необходимо связать этот словарь (т. е. таблицу словаря) со всеми другими таблицами этой базы данных (предположим, что такая связь имеет смысл для всех таблиц) отношением n:m в предположении, что любому слову в любой таблице может быть сопоставлено некоторое слово (в общем случае несколько) из словаря.

Так нормально?

> Зачем вы разнесли сущности по пятистам таблицам ? У вас что, 500 разных
> словарей, и вы ищете слово по всем словарям ? Почему не поместить сущности
> в одну таблицу ?

Нет, словарь у меня один. ;) А вот других таблиц с остальными данными - пятьсот.
...
Рейтинг: 0 / 0
06.01.2005, 22:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855790
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
1. Вы опять излагаете свою реализацию, а не постановку.
2. Если лень заводить 250 промежуточных таблиц - заведите одну, где будет дополнительно указываться "имя связанной таблицы".
3. Если вам надо выбрать записи из 500 таблиц, то вы явно не продумали структуру базы. Но если вам прям позарез хочется это сделать, то вы можете либо выполнить 500 запросов, либо один Union запрос с 500 подзапросами. Второй вариант - для тех любителей острых ощущений, которые считают, что у оптимизатора их субд отменное здоровье и крепкие нервы.
...
Рейтинг: 0 / 0
06.01.2005, 22:58
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855796
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> 2. Если лень заводить 250 промежуточных таблиц - заведите одну, где будет
> дополнительно указываться "имя связанной таблицы".

Нет, не лень. Просто смысла нет заводить 250 лишних таблиц. А вот одна таблица - это хорошо, только тогда как быть с ссылочной целостностью? А удаление/добавление/хранение истории? А версионность структуры данных?

> 3. Если вам надо выбрать записи из 500 таблиц, то вы явно не продумали
> структуру базы.

Уверяю Вас, это не так. 3 н. ф. - как норма проектирования.

> Но если вам прям позарез хочется это сделать, то вы можете либо выполнить 500
> запросов, либо один Union запрос с 500 подзапросами.

Не хочу. Эффект разреженной матрицы: запрос вернет очень немного записей. Из пушки по воробьям.
...
Рейтинг: 0 / 0
06.01.2005, 23:23
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855809
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
guest_20040621> 2. Если лень заводить 250 промежуточных таблиц - заведите одну, где будет
> дополнительно указываться "имя связанной таблицы".

Нет, не лень. Просто смысла нет заводить 250 лишних таблиц. А вот одна таблица - это хорошо, только тогда как быть с ссылочной целостностью? А удаление/добавление/хранение истории? А версионность структуры данных?

> 3. Если вам надо выбрать записи из 500 таблиц, то вы явно не продумали
> структуру базы.

Уверяю Вас, это не так. 3 н. ф. - как норма проектирования.

> Но если вам прям позарез хочется это сделать, то вы можете либо выполнить 500
> запросов, либо один Union запрос с 500 подзапросами.

Не хочу. Эффект разреженной матрицы: запрос вернет очень немного записей. Из пушки по воробьям.

3 нф - не панацея от неправильного проектирования.
Если у вас однотипная информация разбросана по 500 таблицам - то со структурой явно что-то не так.
Не вижу никаких проблем с удалением, добавлением и изменением записей - все как обычно, транзакцию открыли, добавили в одну, вторую, промежуточную - транзакцию закрыли. Если так хочется ссылочной целостности - в каждой из пятисот таблиц заведите FK на промежуточную таблицу, PK сделайте глобально уникальными - назначайте со сдвигом в 1000 для каждой таблицы (в первой - 1, 1001, 2001..., во второй - 2, 2002, 2003...). С внезапно возникшей версионностью делайте что хотите, обычно она нахрен не нужна, но если сильно хочется - заводите архивы.
Если так сильно ломает опрашивать все пятьсот таблиц - заведите одну и в ней храните, в какой таблице слово встречается. Потом динамически генерируйте селекты и вперед.
Я одно не пойму - куда вы клоните ? Сначала вы рассовали однородную информацию в пятьсот мест, а теперь жалуетесь, что ее трудно собирать. Ну дык ! А когда вам говорят, что не надо ее рассовывать - вы меня уверяете, что все сделано правильно.
...
Рейтинг: 0 / 0
07.01.2005, 00:13
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855826
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> 3 нф - не панацея от неправильного проектирования.
> Если у вас однотипная информация разбросана по 500 таблицам - то со
> структурой явно что-то не так.

С чего Вы взяли, что я разбросал однотипные данные по 500 таблицам? - нет, все хорошо и с нормализацией, и с описанием.

> Не вижу никаких проблем с удалением, добавлением и изменением записей -
> все как обычно, транзакцию открыли, добавили в одну, вторую,
> промежуточную - транзакцию закрыли.

Да я тоже проблем не вижу. Хотелось, чтобы Вы это сформулировали. ;)

> Если так хочется ссылочной целостности

;)

> - в каждой из пятисот таблиц заведите FK на промежуточную таблицу, PK
> сделайте глобально уникальными - назначайте со сдвигом в 1000 для каждой
> таблицы (в первой - 1, 1001, 2001..., во второй - 2, 2002, 2003...).

Не пойдет. Никто не гарантирует, что 1000 записей для одной таблицы хватит.

> С внезапно возникшей версионностью делайте что хотите, обычно она нахрен
> не нужна, но если сильно хочется - заводите архивы.

;)) Хм... у меня версионность внезапно не возникает. На самом деле еще много подзадач есть; мы ж не конкретный проект обсуждаем, а все-таки надстройку, правда? - чего ж я буду несущественными деталями грузить? О чем это я? Ага, версионность. Мне казалось, что обычно она как раз нужна. Ладно, забудем версионность.

> Если так сильно ломает опрашивать все пятьсот таблиц - заведите одну и в
> ней храните, в какой таблице слово встречается. Потом динамически
> генерируйте селекты и вперед.

;) Н-да, про версионность я рановато забыл. В общем, Вы так или иначе сказали то, чего я от Вас добивался: используем одну таблицу. В общем неважно, что и как там хранить, имена таблиц со словами и идентификаторами или просто идентификаторы; отметим факт: имеем некоторую таблицу, которая по некоторым правилам позволяет нам связывать таблицы базы данных.

> Я одно не пойму - куда вы клоните?

Все, уже закончил клонить. ;) Берем предложенное Вами возможное решение: используем одну таблицу для связей между "супертаблицей" и остальными таблицами базы данных. Весь требуемый функционал (ссылочную целостность, апдейты, динамические запросы и пр.) реализуем за пределами базы данных. Собственно, получили часть той надстройки, о которой я говорил. ;)) Я всего лишь чуть видоизменил _предложенное Вами_ решение. ;)) Возражения?

> Сначала вы рассовали однородную информацию в пятьсот мест, а теперь
> жалуетесь, что ее трудно собирать.

Да не рассовывал я ее никуда. Если мой пример не нравится, возьмите любую Вашу базу данных и попробуйте подключить к ней словарь. Ко всем таблицам, где это имеет смысл. Не то же самое получилось? ;)
...
Рейтинг: 0 / 0
07.01.2005, 01:36
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855829
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
guest_20040621> 3 нф - не панацея от неправильного проектирования.
> Если у вас однотипная информация разбросана по 500 таблицам - то со
> структурой явно что-то не так.

С чего Вы взяли, что я разбросал однотипные данные по 500 таблицам? - нет, все хорошо и с нормализацией, и с описанием.

> Не вижу никаких проблем с удалением, добавлением и изменением записей -
> все как обычно, транзакцию открыли, добавили в одну, вторую,
> промежуточную - транзакцию закрыли.

Да я тоже проблем не вижу. Хотелось, чтобы Вы это сформулировали. ;)

> Если так хочется ссылочной целостности

;)

> - в каждой из пятисот таблиц заведите FK на промежуточную таблицу, PK
> сделайте глобально уникальными - назначайте со сдвигом в 1000 для каждой
> таблицы (в первой - 1, 1001, 2001..., во второй - 2, 2002, 2003...).

Не пойдет. Никто не гарантирует, что 1000 записей для одной таблицы хватит.

> С внезапно возникшей версионностью делайте что хотите, обычно она нахрен
> не нужна, но если сильно хочется - заводите архивы.

;)) Хм... у меня версионность внезапно не возникает. На самом деле еще много подзадач есть; мы ж не конкретный проект обсуждаем, а все-таки надстройку, правда? - чего ж я буду несущественными деталями грузить? О чем это я? Ага, версионность. Мне казалось, что обычно она как раз нужна. Ладно, забудем версионность.

> Если так сильно ломает опрашивать все пятьсот таблиц - заведите одну и в
> ней храните, в какой таблице слово встречается. Потом динамически
> генерируйте селекты и вперед.

;) Н-да, про версионность я рановато забыл. В общем, Вы так или иначе сказали то, чего я от Вас добивался: используем одну таблицу. В общем неважно, что и как там хранить, имена таблиц со словами и идентификаторами или просто идентификаторы; отметим факт: имеем некоторую таблицу, которая по некоторым правилам позволяет нам связывать таблицы базы данных.

> Я одно не пойму - куда вы клоните?

Все, уже закончил клонить. ;) Берем предложенное Вами возможное решение: используем одну таблицу для связей между "супертаблицей" и остальными таблицами базы данных. Весь требуемый функционал (ссылочную целостность, апдейты, динамические запросы и пр.) реализуем за пределами базы данных. Собственно, получили часть той надстройки, о которой я говорил. ;)) Я всего лишь чуть видоизменил _предложенное Вами_ решение. ;)) Возражения?

> Сначала вы рассовали однородную информацию в пятьсот мест, а теперь
> жалуетесь, что ее трудно собирать.

Да не рассовывал я ее никуда. Если мой пример не нравится, возьмите любую Вашу базу данных и попробуйте подключить к ней словарь. Ко всем таблицам, где это имеет смысл. Не то же самое получилось? ;)

С генерированием уникального ключа вы не поняли - я предлагаю не диапазон ключей выделать (1-1000 для первой таблицы, 1001-2000 для второй) а сдвиг и номер : для первой таблицы последние три разряда всегда 001, для второй - 002 и т.д. Так что для тысячи таблиц такой схемы вам должно хватить, а нет - увеличьте сдвиг.
Я последний раз повторяю : в нормально спроектированной системе не бывает запросов к пятистам таблицам одновременно. Можете принять это за аксиому. Или лучше поступим как с адиском - вы рассказываете условие, я придумываю схему без пятисот таблиц , мы сверяем производительность.

И какой такой словарь вы все время пытаетесь подключить "ко всем таблицам" ? Словарь чего ? Чем вас не устраивают systables / syscolumns ?
...
Рейтинг: 0 / 0
07.01.2005, 01:56
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855834
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> С генерированием уникального ключа вы не поняли - я предлагаю не диапазон
> ключей выделать (1-1000 для первой таблицы, 1001-2000 для второй) а сдвиг и
> номер:

Да, действительно не понял. ОК, снимается.

> Я последний раз повторяю : в нормально спроектированной системе не бывает
> запросов к пятистам таблицам одновременно. Можете принять это за аксиому.

Вот здесь я с Вами абсолютно согласен. Действительно не бывает. Но связать эти пятьсот таблиц между собой - просто необходимо. ;))

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

У Вас содержимое баз данных на русском языке? Подключите к любой из Ваших баз данных словарь Ожегова. Любым образом. Ничего сверять не нужно, нужна только схема.

> И какой такой словарь вы все время пытаетесь подключить "ко всем таблицам"?
> Словарь чего ? Чем вас не устраивают systables / syscolumns ?

;) Да при чем здесь системные таблицы? Я ж говорю, просто обычный языковой словарь. Как пример. Не хотите словарь, - давайте представим, что есть куча картинок, документов или еще чего. Что больше нравится?
...
Рейтинг: 0 / 0
07.01.2005, 02:16
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855856
Фотография mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mv
Участник
Предлагаю опустить голову в пустую бочку и закричать: "Оу-а-а! Пятьсот табли-и-иц!", а оппоненту в это же время колотить по бочке палкой, стараясь его перешуметь.
...
Рейтинг: 0 / 0
07.01.2005, 04:43
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855862
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
guest_20040621
> Я последний раз повторяю : в нормально спроектированной системе не бывает
> запросов к пятистам таблицам одновременно. Можете принять это за аксиому.

Вот здесь я с Вами абсолютно согласен. Действительно не бывает. Но связать эти пятьсот таблиц между собой - просто необходимо. ;))

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

У Вас содержимое баз данных на русском языке? Подключите к любой из Ваших баз данных словарь Ожегова. Любым образом. Ничего сверять не нужно, нужна только схема.

> И какой такой словарь вы все время пытаетесь подключить "ко всем таблицам"?
> Словарь чего ? Чем вас не устраивают systables / syscolumns ?

;) Да при чем здесь системные таблицы? Я ж говорю, просто обычный языковой словарь. Как пример. Не хотите словарь, - давайте представим, что есть куча картинок, документов или еще чего. Что больше нравится?

Я как-то слабо понимаю что такое "подключите" в вашей трактовке.
Если вы собираетесь каждое текстовое поле проверять на наличие в словаре, то (забыв про различные формы одного слова) достаточно навесить триггер на вставку. Поскольку словарь - вещь статичная, то никаких каскадных удалений и RI не надо. А если вас интересует, в каких таблицах встречается данное слово - то заведите себе козу, пардон, таблицу формата слово/таблица, и вставляйте туда записи при insert в любую из ваших таблиц. В чем проблема-то ?
...
Рейтинг: 0 / 0
07.01.2005, 05:08
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855965
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Я как-то слабо понимаю что такое "подключите" в вашей трактовке.

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

> Если вы собираетесь каждое текстовое поле проверять на наличие в словаре,

Yes! Получилось. ;))

> то (забыв про различные формы одного слова) достаточно навесить триггер на
> вставку.

Не, забывать про различные формы слова мы не будем. Будем корректны. Триггеры - триггерами, а связи нужны для того, чтобы иметь возможность сделать обратную выборку. Т. е. знать, в каких таблицах выбранное из словаря слово встречается.

> Поскольку словарь - вещь статичная, то никаких каскадных удалений и RI не
> надо.

Ну, положим, словарь действительно относительно статичный. Но данным в остальных таблицах ничто меняться не мешает. ;)

> А если вас интересует, в каких таблицах встречается данное слово - то
> заведите себе козу, пардон, таблицу формата слово/таблица, и вставляйте
> туда записи при insert в любую из ваших таблиц. В чем проблема-то ?

Да нет проблем. ;) Вы снова предложили решение с одной таблицей. Так я ж об этом Вам и пытался рассказать с самого начала. ;)) Т. е. в результате _Ваших умозаключений_ мы пришли к решению, которое 1. не является типовым для реляционной базы данных, 2. тем не менее хорошо формализуется и может быть реализовано в виде внешнего (к базе данных) модуля. Теперь, надеюсь, нет возражений? ;)) Вы же все сами сформулировали, - я только немного _Ваше решение_ причесал.
...
Рейтинг: 0 / 0
07.01.2005, 12:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32855974
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Статья относящаяся как раз к теме топика.

http://www.ibase.ru/devinfo/oop_rdbms.htm
...
Рейтинг: 0 / 0
07.01.2005, 12:44
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856025
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Думаю не только мне интересна тема данного форума.
И поэтому вот еще ссылка про ОО над РБД:
http://www.stikriz.narod.ru/art/oobd.htm
...
Рейтинг: 0 / 0
07.01.2005, 15:09
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856042
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Реализвал вариант БД с одной таблицей. (где все данные зранятся в одной таблице)
эксперимент проводил на FoxPro

Для разных типов данных были созданы поля и
витоге таблица с данными выглядела так:
id_s - Numeric(20) код экземпляра
id_p - Character (20) код свойства экземпляра (символьный)
для чисел data_N - numeric(20,5)
для строк data_С - character (50)
для дат data_D - date

Все как и описывал в предыдущих постах.
Заполнил таблицу как кто-то предлагал выше:
customers (id, name)- 100 000 записей
orders (id, id_cust, sum, date, state)- 1 000 000 записей

Получилось 6 200 000 строк! По 2 строки на 100 000 customers'ов и
по 6 записей на 1 000 000 строк orders)
Базу проиндексировал по всем полям. Чертовкси долго это проиходило.
База заняла 450 Мегабайт. (без индеков) Конечно, из-за лишних полей.

Требовалось получить сумму свойства sum
с условиями
state="Y"
date between {^2004/01/01} and {^2004/12/31}
с группировкой по customer'ам

Работало около 10 секунд.
(Cel-4 2200M / ОЗУ 512М )

Работаю над оптимизацией.
Как снова буду на работе вышлю код программы с запросами.
...
Рейтинг: 0 / 0
07.01.2005, 15:36
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856098
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
2 adisk :
Я знал, что вам понравятся 6 миллионов записей :-)
Как насчет select ? фокс фоксом, но хотелось бы увидеть текст запроса на SQL.
И, кстати, поля разных типов неплохо бы разнести по разным таблицам.
...
Рейтинг: 0 / 0
07.01.2005, 17:34
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856101
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
guest_20040621> Я как-то слабо понимаю что такое "подключите" в вашей трактовке.

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

> Если вы собираетесь каждое текстовое поле проверять на наличие в словаре,

Yes! Получилось. ;))

> то (забыв про различные формы одного слова) достаточно навесить триггер на
> вставку.

Не, забывать про различные формы слова мы не будем. Будем корректны. Триггеры - триггерами, а связи нужны для того, чтобы иметь возможность сделать обратную выборку. Т. е. знать, в каких таблицах выбранное из словаря слово встречается.

> Поскольку словарь - вещь статичная, то никаких каскадных удалений и RI не
> надо.

Ну, положим, словарь действительно относительно статичный. Но данным в остальных таблицах ничто меняться не мешает. ;)

> А если вас интересует, в каких таблицах встречается данное слово - то
> заведите себе козу, пардон, таблицу формата слово/таблица, и вставляйте
> туда записи при insert в любую из ваших таблиц. В чем проблема-то ?

Да нет проблем. ;) Вы снова предложили решение с одной таблицей. Так я ж об этом Вам и пытался рассказать с самого начала. ;)) Т. е. в результате _Ваших умозаключений_ мы пришли к решению, которое 1. не является типовым для реляционной базы данных, 2. тем не менее хорошо формализуется и может быть реализовано в виде внешнего (к базе данных) модуля. Теперь, надеюсь, нет возражений? ;)) Вы же все сами сформулировали, - я только немного _Ваше решение_ причесал.

Проверка на наличие в глобальном словаре - это не совсем связь. Так что 250 промежуточных таблиц вам изначально были не нужны. Как и RI, целостность изменений, версионность и прочие страсти, которые вы рассказывали. Не вижу ничего, что делает эту задачу неудобной для реляционной бд. И решение совершенно типовое, первое, что приходит в голову. Над такими решениями проектировщик вобще не должен задумываться. Так что пардон, но ваш пример лично мне ничего не доказал.
...
Рейтинг: 0 / 0
07.01.2005, 17:45
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856119
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Проверка на наличие в глобальном словаре - это не совсем связь.

А где я связь считал тождественной проверке?

> Так что 250 промежуточных таблиц вам изначально были не нужны.

Мне - действительно не нужны. Я уже говорил, что не буду пользоваться таким решением.

> Как и RI, целостность изменений, версионность и прочие страсти, которые вы
> рассказывали.

Напрасно Вы решили, что ссылочная целостность мне не нужна. Я бы сказал, что в контексте обсуждения - это краеугольная штука. Версионность (а также разделение доступа, локализация, хранение истории изменений и пр. "страсти") на самом деле реально используется в этой задаче. Так что Ваш вывод - мимо кассы. ;) Но к обсуждению они действительно не имеют отношения, так что их можно было не упоминать. Ну, сказал и сказал, большой проблемы я в этом не вижу.

> Не вижу ничего, что делает эту задачу неудобной для реляционной бд. И решение
> совершенно типовое, первое, что приходит в голову. Над такими решениями
> проектировщик вобще не должен задумываться. Так что пардон, но ваш пример
> лично мне ничего не доказал.

Хм... а и не было желания ничего никому доказать. ;) Было желание заставить Вас предложить такое решение, которое невозможно было бы описать в терминах "сущность" - "связь" без системных таблиц. Чего Вы очень не хотели, настаивая на традиционном связывании сущностей. Но что, собственно, практически без труда и получилось. ;) А нашли Вы в этом какие-то доказательства чего-то или не нашли, - мне лично совершенно наплевать. ;) Ы?
...
Рейтинг: 0 / 0
07.01.2005, 18:20
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856140
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
guest_20040621> Проверка на наличие в глобальном словаре - это не совсем связь.

А где я связь считал тождественной проверке?


> Не вижу ничего, что делает эту задачу неудобной для реляционной бд. И решение
> совершенно типовое, первое, что приходит в голову. Над такими решениями
> проектировщик вобще не должен задумываться. Так что пардон, но ваш пример
> лично мне ничего не доказал.

Хм... а и не было желания ничего никому доказать. ;) Было желание заставить Вас предложить такое решение, которое невозможно было бы описать в терминах "сущность" - "связь" без системных таблиц. Чего Вы очень не хотели, настаивая на традиционном связывании сущностей. Но что, собственно, практически без труда и получилось. ;) А нашли Вы в этом какие-то доказательства чего-то или не нашли, - мне лично совершенно наплевать. ;) Ы?

Ну если вы согласны, что проверка наличия не есть связь, то в вашей задаче, увы, нет проблемы "сущность-связь".
...
Рейтинг: 0 / 0
07.01.2005, 20:01
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856146
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Ну если вы согласны, что проверка наличия не есть связь,

Кто с этим спорил?

> то в вашей задаче, увы, нет проблемы "сущность-связь".

Хех, да и проблемы-то такой нет. Т. е. вообще. Как класса. Н-да... жаль, что мы говорим на разных языках. Извините, но у меня нет ни желания, ни возможности пересказывать курс проектирования баз данных. Спасибо за обсуждение.
...
Рейтинг: 0 / 0
07.01.2005, 20:21
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856371
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621> 2. Если лень заводить 250 промежуточных таблиц - заведите одну, где будет
> дополнительно указываться "имя связанной таблицы".

Нет, не лень. Просто смысла нет заводить 250 лишних таблиц. А вот одна таблица - это хорошо, только тогда как быть с ссылочной целостностью? А удаление/добавление/хранение истории? А версионность структуры данных?

> 3. Если вам надо выбрать записи из 500 таблиц, то вы явно не продумали
> структуру базы.

Уверяю Вас, это не так. 3 н. ф. - как норма проектирования.

> Но если вам прям позарез хочется это сделать, то вы можете либо выполнить 500
> запросов, либо один Union запрос с 500 подзапросами.

Не хочу. Эффект разреженной матрицы: запрос вернет очень немного записей. Из пушки по воробьям.

Возможно я смогу решить ваши проблемы, если они примут форму коммерческого проекта. Иногда проще просто сделать чем теоретизировать, кто то же бывает первым
...
Рейтинг: 0 / 0
08.01.2005, 13:35
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856381
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Возможно я смогу решить ваши проблемы, если они примут форму коммерческого
> проекта.

Ваша квалификация вызывает сомнения в том, что Вы хотя бы поняли, о чем речь.

> Иногда проще просто сделать чем теоретизировать, кто то же бывает первым

Для начала Вам неплохо было бы поиметь хотя бы небольшое представление о проектировании. А уж потом браться за коммерческие проекты. А со своими проблемами я как-нибудь сам разберусь.
...
Рейтинг: 0 / 0
08.01.2005, 13:56
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856464
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Честно говоря теперь вы произвели на меня впечатление просто канцеляриста, которых во все времена было великое множество! Но вот создали они хоть что-нибудь?
Во первых со скрытым забралом, а это явный признак не дискутировать и не замечать. Стремление скрыться тоже о чем то говорит. Ну и как водится ...мимикрия, т.е. человек усваивает определенное количество фраз и ...
...
Рейтинг: 0 / 0
08.01.2005, 17:07
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856503
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
Модератору: сообщение не флейма ради, но исключительно сохранения статус кво для.

> Честно говоря теперь вы произвели на меня впечатление просто канцеляриста,

Дружище, мне абсолютно наплевать, какое впечатление я на Вас произвел и почему.

Не нужно прятать за словоблудием недостаток знаний. Не нужно браться за работу, которую Вы представления не имеете как делать. Не нужно использовать обсуждение для получения работы. Хотите кушать - есть форум "работа", там и развлекайтесь.

Пожалуйста, не утруждайте себя комментариями, - потратьте это время с пользой, например, прочтите что-нибудь полезное.
...
Рейтинг: 0 / 0
08.01.2005, 18:49
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856512
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
guest_20040621Модератору: сообщение не флейма ради, но исключительно сохранения статус кво для.

> Честно говоря теперь вы произвели на меня впечатление просто канцеляриста,

Дружище, мне абсолютно наплевать, какое впечатление я на Вас произвел и почему.

Не нужно прятать за словоблудием недостаток знаний. Не нужно браться за работу, которую Вы представления не имеете как делать. Не нужно использовать обсуждение для получения работы. Хотите кушать - есть форум "работа", там и развлекайтесь.

Пожалуйста, не утруждайте себя комментариями, - потратьте это время с пользой, например, прочтите что-нибудь полезное.
Народ, а вот не флейма ради, а ради истины, прошу высказаться по поводу этого выпада. Думаю, польза будет для всех! Мы еще наверное не до конца осознали прелести века интернет. Лично я в своей работе много раз сталкивался с тем, что первая догадка не приводит к решению задачи и когда задача все-таки решена, то от первой догадки это достаточно далеко, такой вот получается итеративный процесс. Тут сошлись мнения разных людей и вобщемто не по одному вопросу. Почему бы думающему человеку не высказаться, даже если вопрос выйдет за чисто технические рамки. Почему бы не устроить такой вот эксперимент, быть может каждый в нем что-то сумеет открыть.
...
Рейтинг: 0 / 0
08.01.2005, 19:20
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856524
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
А пока коллеги флеймят продолжаю реализацию ОО над РБД. ;)

Закидываю данные в MySQL.
Для хранения данных исользую тип BLOB.
Судя по пробным тестам работает очень быстро!
Тормоза проявляются при большом когичестве строк в результируюющей таблице.
Т.е. когда запрос выдает более 50000 строк время ощутимо (4 сек) (Cel-400 / ОЗУ 256M)

Кстати все данные хранятся в одной таблице, как и предполагал сделать.
...
Рейтинг: 0 / 0
08.01.2005, 19:57
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856529
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Когда оптимизировал запросы, задумался над структурой БД...
А ведь есть таблицы сруктура которых не меняются!
Справочник городов, улиц, классификаторы...
То есть гибкость сруктуры им не нужна. Следовательно их следует вынести в отдельные таблицы.
...для скорости выборки.

Что касается ОО-модели - по моему мнению - это ЛОГИЧЕСКАЯ модель и она может быть реализована в реляционной базе.
Мне представляется процесс так:
рисуем модель (или описываем каким-либо языком) - логическая модель
и по схеме (или описаниям) генерируем структуру БД, процедуры и интерфейс - физическая реализация.

Для объектов с нежестко заданными свойствами (как товары в магазинах или услуги)
используем универсальное хранилище.
...
Рейтинг: 0 / 0
08.01.2005, 20:16
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856530
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
adiskА пока коллеги флеймят продолжаю реализацию ОО над РБД. ;)

Закидываю данные в MySQL.
Для хранения данных исользую тип BLOB.
Судя по пробным тестам работает очень быстро!
Тормоза проявляются при большом когичестве строк в результируюющей таблице.
Т.е. когда запрос выдает более 50000 строк время ощутимо (4 сек) (Cel-400 / ОЗУ 256M)

Кстати все данные хранятся в одной таблице, как и предполагал сделать.

Выскажу свое субъективное мнение: Вы, коллега избрали не самый оптимальный способ хранения значений разных типов(BLOB). Это ведь проблемы вашего программирования, стоит ли уклоняться от решения проблемы на более серьезном уровне, т.е. Integer - в одной таблице, Float - в другой и т.д. Дальше просто уметь переходить по ссылке к нужному значению в соответствующей таблице...и тут просто нужен опыт программирования и он получается от конкретных проектов "а не от сырости"! Хочу пожелать вам не уклоняться от наилучших способов (по-вашему) решения, а не тех, которые из=за лени и это окупится.
...
Рейтинг: 0 / 0
08.01.2005, 20:18
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856538
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Programmer_OrtodoxВыскажу свое субъективное мнение: Вы, коллега избрали не самый оптимальный способ хранения значений разных типов(BLOB). Это ведь проблемы вашего программирования, стоит ли уклоняться от решения проблемы на более серьезном уровне, т.е. Integer - в одной таблице, Float - в другой и т.д. Дальше просто уметь переходить по ссылке к нужному значению в соответствующей таблице...и тут просто нужен опыт программирования и он получается от конкретных проектов "а не от сырости"! Хочу пожелать вам не уклоняться от наилучших способов (по-вашему) решения, а не тех, которые из=за лени и это окупится.
Коллега, а как у Вас это реализовано?
...
Рейтинг: 0 / 0
08.01.2005, 20:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32856669
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Еще одна ссылка по теме ОО и РБД:
http://www.osp.ru/os/2002/09/057_print.htm
...
Рейтинг: 0 / 0
09.01.2005, 09:14
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32857055
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
adiskА пока коллеги флеймят продолжаю реализацию ОО над РБД. ;)

Закидываю данные в MySQL.
Для хранения данных исользую тип BLOB.
Судя по пробным тестам работает очень быстро!
Тормоза проявляются при большом когичестве строк в результируюющей таблице.
Т.е. когда запрос выдает более 50000 строк время ощутимо (4 сек) (Cel-400 / ОЗУ 256M)

Кстати все данные хранятся в одной таблице, как и предполагал сделать.

Ну так мы увидим уогда-нибудь select для обьединения таблиц, коллега ?
И, кстати, подскажите, какой процент дискового пространства вы теряете в среднем, храня все атрибуты в одной таблице.
...
Рейтинг: 0 / 0
10.01.2005, 01:58
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32858223
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Вот и схема родилась. (см. вложение)

На расунке нет истории (версионности) и доступов.

Пояснения в статье: http://www.osp.ru/os/2002/09/057_print.htm

Таблицы реляционной базы формируются из метаданных,
созданных по ОО-модели.
...
Рейтинг: 0 / 0
11.01.2005, 05:43
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32858364
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
adisk, Вы поразительно внимательно читаете то, что Вам пишут!! Я сам изначально писал, что универсальное хранилище нужно для часто изменяющихся значений. Вы теперь гордо пишите:
"То есть гибкость сруктуры им не нужна. Следовательно их следует вынести в отдельные таблицы.
...для скорости выборки.
Для объектов с нежестко заданными свойствами (как товары в магазинах или услуги)
используем универсальное хранилище."


Вам про это изначально и говорили!Поздравляю с прозрением!!!
...
Рейтинг: 0 / 0
11.01.2005, 09:34
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32858930
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
Всех с наступившим новым годом!
(сегодня первый день на работе и только добрался до и-нета)
Желаю всем всяческих (и особенно - творческих) успехов в этом году!
:)

Тема, на мой взгляд, явно подразделяется на несколько вопросов и обсуждение хаотично мечется между ними :)
Вопросы получаются следующие:
1) Возможно-ли сделать ЭТО - "универсальное" "объектное" хранилище "метаданных" и данных в одной "структуре" - "систему" на основе существующих реляционных СУБД?
2) Зачем нужна (или может понадобится) такая система?)
3) Кому нужна (или может понадобится) такая система?
4) Есть-ли на рынке коммерческие или свободные прогр. продукты подобной функциональности, и если есть то почему они вам/нам не подходят?
5) Как можно практически реализовать отдельные элементы такой системы (или всю ее целиком)?
6) ... правильно-ли я делаю вот так в своем ХХХ-варианте (или "а я пробую вот так делать...")?
7) Есть-ли смысл дальнейшего обсуждения темы в прежнем виде здесь или стоит желающим организовать нечто большее в какой-либо другой форме?

Ниже попробую сформулировать свои ответы хотя-бы на некоторые из этих вопросов. :)
...
Рейтинг: 0 / 0
11.01.2005, 13:20
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32859003
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
о хранении мета-данных:

вы будете смеяться, но в мс скл, к примеру, есть таблица sysobjects в которой хранится описание всех объектов БД, syscolumns в которой хранится описание колонок всех таблиц, есть другие сис.таблицы, большинство (многие) компонентов доступа предоставляют функции для получения данных о структуре.

Для 1ц хранение мета-данных в своём формате оправдано возможностью использования разных хранилищ данных (версии для мс скл и дбф работают внешне совершенно одинаково). Тяга к созданию объектных БД в большинстве других случаев вероятно объясняется нежеланием учить скл. А ведь придётся.
...
Рейтинг: 0 / 0
11.01.2005, 13:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32859145
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
to 1024: смеяться не будем. Про это уже писали чуть ниже.Эти супер-таблицы называются Словарь БД.
...
Рейтинг: 0 / 0
11.01.2005, 14:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32859295
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> 1) Возможно-ли сделать ЭТО - "универсальное" "объектное" хранилище
> "метаданных" и данных в одной "структуре" - "систему" на основе существующих
> реляционных СУБД?

Возможно. Но - не нужно.

> 2) Зачем нужна (или может понадобится) такая система?)
> 3) Кому нужна (или может понадобится) такая система?
> 4) Есть-ли на рынке коммерческие или свободные прогр. продукты подобной
> функциональности, и если есть то почему они вам/нам не подходят?

После ответа на первый вопрос ответ на эти смысла не имеет.

> 5) Как можно практически реализовать отдельные элементы такой системы (или
> всю ее целиком)?

Зависит от задачи и способа реализации.

> 6) ... правильно-ли я делаю вот так в своем ХХХ-варианте (или "а я пробую вот
> так делать...")?

Хотелось бы видеть не такую постановку вопроса, а такую: "нужно получить то-то и то-то, сделав так, как советуют [список источников], не смог решить такую задачу [описание проблемы]. Обсуждать поделки с измышлениями - не интересно.

> 7) Есть-ли смысл дальнейшего обсуждения темы в прежнем виде здесь или
> стоит желающим организовать нечто большее в какой-либо другой форме?

Хех, какая разница, где обсуждать? - было бы что обсуждать.
...
Рейтинг: 0 / 0
11.01.2005, 15:00
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32859474
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
"Тяга к созданию объектных БД в большинстве других случаев вероятно объясняется нежеланием учить скл. А ведь придётся"
to 1024:
... а тяга к использованию RAD объясняется нежеланием учить Assembler?! Интересно, многим ли пользователям этого форума "пришлось" освоить и использовать его (Assembler) для создания своих систем??? :)

to guest_20040621:
> Возможно. Но - не нужно.
Если Вам это не нужно - зачем здесь флудить? А то складывается впечатление, что Вам все-равно что обсуждать, лишь-бы что-то написать. :)

> Хотелось бы видеть не такую постановку вопроса, а такую: "нужно получить то-то и то-то, сделав так, как советуют [список источников], не смог решить такую задачу [описание проблемы].
- ... а еще хотелось-бы кругленький счет в швейцарском банке, виллу на канарах, личный самолет... :)


>Обсуждать поделки с измышлениями - не интересно.
- Не интересно - не обсуждайте! Разве кто-то заставляет? Нравится другая форма постановки вопроса/проблемы - ставьте! Только не надо таких поучений и ответов "не нужно, бессмысленно"- здесь все-таки не школьники общаются. До сих пор я был о Вас более высокого мнения (хотя наверняка мое мнение Вас и не интересует :)
В дальнейшем на подобные провокационные :) посты отвечать не буду. Давайте лучше по делу говорить.
...
Рейтинг: 0 / 0
11.01.2005, 15:47
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32859549
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Если Вам это не нужно - зачем здесь флудить? А то складывается впечатление,
> что Вам все-равно что обсуждать, лишь-бы что-то написать. :)

Хм... да не было желания флудить. Вроде кто-то в этом топике говорил о Самой Главное Универсальной Базе Данных, - новых аргументов я привести не смогу.

> а еще хотелось-бы кругленький счет в швейцарском банке, виллу на канарах,
> личный самолет... :)

Ну так Вы же сами пишите о том, что здесь не школьники? Если трезво посмотреть на местные форумы, станет очевидно, что 90% вопросов вызваны 1. нежеланием читать документацию, 2. нежеланием изучать предметную область, 3. недостатком профессиональных знаний. Imho предметов для дискуссий в этих 90% обсуждений нет. Вопрос - ответ. А не словесный поток сознания. О чем, собственно, и хотелось сказать.

> Не интересно - не обсуждайте! Разве кто-то заставляет?

Нет, конечно, никто не заставляет. Конкретно этот тред потенциально интересен, - собственно, хотелось бы, чтобы обсуждение было предметным. Кроме того, ничего более.

> Нравится другая форма постановки вопроса/проблемы - ставьте!

Попробовал. В результате получил предложение о практической реализации задачи.
...
Рейтинг: 0 / 0
11.01.2005, 16:08
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32859672
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
автор... а тяга к использованию RAD объясняется нежеланием учить Assembler?! Интересно, многим ли пользователям этого форума "пришлось" освоить и использовать его (Assembler) для создания своих систем??? :)

rad средства имеют преимущества перед ассемблером по скорости создания приложений, в некоторых случаях ассемблер приходится использовать (драйвера к примеру какие-нить илил для встроеных устройств)

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

взгляните на 1ц. Это настоящая объектная БД (на ихом языке нет таблиц а есть, к примеру, объект "справочник" и т.п.), вполне доступна для изучения. Но какую цену приходится платить.
...
Рейтинг: 0 / 0
11.01.2005, 16:39
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32859757
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
Shtockadisk, Вы поразительно внимательно читаете то, что Вам пишут!! Я сам изначально писал, что универсальное хранилище нужно для часто изменяющихся значений. Вы теперь гордо пишите:
"То есть гибкость сруктуры им не нужна. Следовательно их следует вынести в отдельные таблицы.
...для скорости выборки.
Для объектов с нежестко заданными свойствами (как товары в магазинах или услуги)
используем универсальное хранилище."


Вам про это изначально и говорили!Поздравляю с прозрением!!!

Это еще не прозрение. Прозрение будет, когда он хоть один JOIN напишет, да попытается его выполнить. Но adisk из тех, кто предпочитает отттягивать конец :-)
...
Рейтинг: 0 / 0
11.01.2005, 17:04
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32859820
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Rovdo
Гость
guest_20040621> С генерированием уникального ключа вы не поняли - я предлагаю не диапазон
> ключей выделать (1-1000 для первой таблицы, 1001-2000 для второй) а сдвиг и
> номер:

Да, действительно не понял. ОК, снимается.

> Я последний раз повторяю : в нормально спроектированной системе не бывает
> запросов к пятистам таблицам одновременно. Можете принять это за аксиому.

Вот здесь я с Вами абсолютно согласен. Действительно не бывает. Но связать эти пятьсот таблиц между собой - просто необходимо. ;))



Я вот все читаю и никак не могу понять одного.
Выше я уже упоминал, что вполне функциональные объектные надстройки над реляционными БД существуют: FastObjects .NET (SQL Object Factory), Bold, Реализации JDO ... Так вот все приводимые примеры прекрасно реализуются в рамках объектной модели, предлагаемой такими продуктами. Более того я не зря привел выдержку из обсуждения. Именно с похожей ситуацией мне недавно пришлось столкнуться. Уверяю вас, что некоторое время подумав все проблемы действительно можно разрешить в рамках реляционной системы. И ответ на ряд вопросов в обсуждении уже приведен. От себя могу добавить, что нет необходимости писать всякий раз 500 запросов когда нужно выбрать объекты из всех таблиц - можно ограничиться одним, адресуемым в одну таблицу которая содержит глобальные PM всех объектов (быстродействие такого запросо зависит от деталей реализации, но в целом будет намного ниже чем типовой SELECT из одной таблицы). И реализовав на практике такое решение (де факто организовав реляционную модель таким образом, что впору говорить о возникновении нового объектного уровня абстракции и моделирования структуры данных) конечно понимаешь, что глупо изобретать велосипед - нужно просто брать готовые продукты и ими пользоваться.
...
Рейтинг: 0 / 0
11.01.2005, 17:29
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32859852
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Так вот все приводимые примеры прекрасно реализуются в рамках объектной
> модели, предлагаемой такими продуктами.

Нет. Прочтите, пожалуйста, условия задачи еще раз.

> можно ограничиться одним, адресуемым в одну таблицу которая содержит
> глобальные PM всех объектов

Вы говорите про частный случай. Системные таблицы (их состав и структура) у каждой СУБД уникальны.

> (де факто организовав реляционную модель таким образом, что впору говорить о
> возникновении нового объектного уровня абстракции и моделирования структуры
> данных)

Никто реляционную модель перелопачивать или реорганизовывать не собирается. Речь идет о некоторой дополнительной функциональности и, возможно, о расширенных требованиях к описанию данных. Не уверен, что это правильно интерпретировать как новый уровень абстракции.

> конечно понимаешь, что глупо изобретать велосипед - нужно просто брать
> готовые продукты и ими пользоваться.

Для обсуждаемой задачи я не знаю готовых продуктов, к сожалению.
...
Рейтинг: 0 / 0
11.01.2005, 17:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32859899
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Rovdo
Гость
guest_20040621> ... Речь идет о некоторой дополнительной функциональности и, возможно, о расширенных требованиях к описанию данных. Не уверен, что это правильно интерпретировать как новый уровень абстракции.


Возможно, я действительно что-то не до конца понимаю. Поясните, пожалуйста, о каких именно расширенных требованиях и дополнительной функциональности идет речь. И почему на ваш взгляд существующие продукты их не реализуют.
...
Рейтинг: 0 / 0
11.01.2005, 17:57
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32859918
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Поясните, пожалуйста, о каких именно расширенных требованиях и
> дополнительной функциональности идет речь.

См. начиная со страницы 7 обсуждения:

...такую задачу: путь в базе данных есть некоторая сущность, которая может быть связана с любой из других сущностей этой же базы данных отношением n:m.

Hint1: база данных среднего размера, единицы сотен таблиц,
Hint2: таких сущностей в общем случае большей одной,
Hint3: решение нужно в общем виде, безотносительно СУБД,
Hint4: решение должно предоставлять возможность управления отношениями без написания дополнительного кода.

Imho такая задача может быть решена использованием несколько отличных от традиционных способов описания объектов реляционной базы данных.

Собственно, задача и [возможный] способ решения - перед Вами. Если Вы приведете список продуктов, которые позвояют ее решить, буду Вам сильно признателен.
...
Рейтинг: 0 / 0
11.01.2005, 18:08
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32859962
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
Пробую отвечать на выше обозначенные вопросы (на которые - повторяю - фактически разбилось обсуждение в этом топике):

1) Возможно-ли сделать ЭТО - "универсальное" "объектное" хранилище "метаданных" и данных в одной "структуре" - "систему" на основе существующих реляционных СУБД?
Возможно я не совсем точно сформулировал что значит "ЭТО" - то, что обсуждается в этом топике, но старался писать как можно короче и наверно поэтому несколько расплывчать получилось.
"ЭТО" сделать возможно. Хотя-бы потому, что такие системы уже есть. Одну из них я в этом топике уже упоминал. Если кому известны другие - приводите ссылки. Кстати эти ссылки и просил автор топика в самом первом сообщении.

2) Зачем нужна (или может понадобится) такая система?)
Прошу читателей учесть, что на любой вопрос в обсуждении есть как минимум две точки зрения. В нашем вопросе - могут быть различные точки зрения и со стороны заказчика системы и со стороны разработчика.
Пробую изложить вполне реальную ситуацию с точки зрения лица, ответственного за поддержку и развитие систем автоматизации БП организации, и имеющего за плечами определенный собственный опыт разработки коммерческих систем.
Итак - что есть:
Есть довольно распределенная географически организация со стабильным нестандартным бизнесом. Есть "своя" небольшая отдельная компания для разработки и поддержки бизнес-софта. Есть наработанная силами этой компании "кусочная" автоматизация на основе стандартной методологии разработки 3-уровневых систем с РСУБД, слабо связанная в общую систему различными "мостиками" БД и очень слабо документированая - исторический факт. Раздельное развитие отдельных кусков-подсистем фактически зашло в тупик. Быстрое расширение бизнес-функциональности ПО необходимо, но развитие существующей системы стало уже просто нерентабельно. Т.е. имеется стабильный но очень консервативный софт, фактически тормозящий развитие бизнеса.
Отказаться от услуг своей компании-разработчика - нельзя.
Стороннее готовое коммерческое ПО - не подходит по некоторым причинам, и привлекать сторонних консультантов или разработчиков для его адаптации / доработки - нельзя.
Критиковать сложившуюся ситуацию - можно, но бессмысленно :)
Что нужно:
Активное развитие информационной системы "до уровня КИС"
- своими силами;
- с переносом в новую систему ранее наработанной функциональности и данных;
- с заранее не определенными пределами функциональности (как можно больший потенциал развития) - возм. универсальное ядро системы (БД);
- простота и высокая скорость разработки и внесения изменений и доработок в систему;
- использование знакомых средств разработки, или новых, но стабильных и простых в освоении;
В сложившейся ситуации считаю развитие существующей системы ошибкой а разработку новой системы по старой методике - просто преступлением.

Думаю, что в этой ситуации правильным выходом была-бы как раз разработка "объектной" системы на реляционной БД. Почему именно такой - позже напишу.

(продолжение следует... завтра :)
...
Рейтинг: 0 / 0
11.01.2005, 18:37
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32859979
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> (продолжение следует... завтра :)

Не возражаете против пары дополнительных вопросов сегодня?

> Активное развитие информационной системы "до уровня КИС"

Пожалуйста, очертите круг задач этой информационной системы.

> Думаю, что в этой ситуации правильным выходом была-бы как раз разработка
> "объектной" системы на реляционной БД.

Если Вас не затруднит, пожалуйста, сформулируйте требования к "объектности" такой системы.
...
Рейтинг: 0 / 0
11.01.2005, 18:47
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32860202
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
skorohod
to guest_20040621:
> Возможно. Но - не нужно.
Если Вам это не нужно - зачем здесь флудить? А то складывается впечатление, что Вам все-равно что обсуждать, лишь-бы что-то написать. :)
Полностью согласен с skorohod.

Поделитесь ссылками.
Дайте названия проектов, в которых можно посмотреть как реализована подобная надстройка.
Кто имел опыт работы с такими системами, расскажите свои впечатления.
(Вон как Кашисты хвалят свою СУБД!)
...
Рейтинг: 0 / 0
12.01.2005, 04:28
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863138
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
2 adisk

Почитайте еще раз топик с начала - ссылки есть, люди делились. И ресурсы по теме в нете есть. Можно "теорию" почитать в "СУБД" и "Открытые системы".
Я сейчас как раз "перерыванием" доступных ресурсов занимаюсь. Сам ок. 6 лет "размышлял" над необходимостью подобной ОО-надстройки над РСУБД. Просто не было возможности (у меня) её реального применения. Теперь вроде-бы появилась - по работе. То, что сам раньше "надумал" сильно перекликается с тем, о чем в этом (и других) топике писали. Пока есть время надо по максимуму ознакомится с тем что уже есть, чтобы потом не наступать на грабли, которые кто-то уже нашел как обходить :)
Может получится использовать у нас чью-то готовую разработку - неважно свободную или коммерческую?! Пока ищу, знакомлюсь с тем, что есть.

P.S. Кроме "Каше" была еще такая "Жасмин" от СА, а "всяк сверчок хвалит свой шесток" (пока ему там тесно не станет :)


2 guest_20040621

>Пожалуйста, очертите круг задач этой информационной системы.
Эта информационная система должна будет как минимум реализовать единое информационное пространство для всех подразделений и компаний а в идеале обеспечить в организации все требования и управленческого учета и финансового и остальных... :)
Можно много писать о конкретике и "воде", но чтобы мне здесь круг задач очерчивать конкретно, то ни места ни времени не хватит. Могу только несколько примеров привести:
Надо чтобы и у коммерсантов и у финансистов данные в ИХ отчетах о (напр.)реализации продукции были одинаковые;
Надо чтобы справочник оргструктуры у кадровиков был такой-же как и у тех-же коммерсантов и у финансистов;
Надо чтобы менеджер (не важно какого уровня), пожелавший ежедневно с утра получать отчетность нового вида, смог начать ее получать не через месяц-два, а уже через день;
Надо чтобы внедрение в систему новой функциональности занимало не 3-6 месяцев а 1-2 недели;

>Если Вас не затруднит, пожалуйста, сформулируйте требования к "объектности" такой системы
"объектность" такой системы плавно вытекла из логичной необходимости иметь не в Visio или Rose, а в БД модель всей организации и ее БП. Сделать это можно и "традиционным реляционным" подходом, забив все необходимые данные в кучу справочников и обеспечив их "динамичность", но поддерживать и развивать такую систему и на уровне БД и на уровне прикладного софта будет очень проблематично даже для небольшой компании.
Выходом здесь на мой взгляд(и не только на мой) может послужить внесение в БД дополнительного "низкоуровневого", "объектного" слоя (или "объектной надстройки" - наверно не важно как это называть) в которой можно будет описать модель предметной области, в нашем случае - организации и её БП, в виде набора логических объектов, их связей, атрибутов и методов.
Обычно подобные вещи называется "метаданными", "словарем БД" но в нашем случае этот объектный слой или надстройка имеет более широкий смысл.
Практически это будет небольшой, сторго ограниченный (или автоматически дополняемый) набор таблиц и ХП (если использовать напр. MS SQL-Server). В конкретной реализации такого набора таблиц возможны варианты - это предмет обсуждения по вопросу, который я выше в теме обозначил номером 6.
Логично было-бы в объектном слое описать для необходимых бизнес-объектов и их пользовательский интерфейс - тоже в виде логических объектов. Тогда можно было-бы все возможные клиентские модули системы ограничить единым универсальным модулем - генератором user-интерфейса (очень тонкий клиент).
При наличии в системе такого объектного слоя разработка и коррекция её функционала сведется к описанию/редактированию в БД модели - заполнению/редактированию "модельных" таблиц объектного слоя данными и, возможно, написанию/генерации некоторых специфических ХП.
"Традиционную реляционную"структуру БД, при необходимости, можно будет получить из объектного слоя автоматически в виде представлений, временных или постоянных таблиц и др. и хранить данные системы в них. НО! Т.к. при внесении изменений в модель системы потребуется корекция или перегенерация всех или части таблиц традиционной реляционной структуры, то мы получим серьезные трудности с хранением данных живой, изменяемой системы в таких таблицах. Поэтому на мой взгляд, имея объектный слой в БД, эффективнее было-бы и для хранения данных системы пользоваться только объектным слоем, а постоянные/временные таблицы или представления использовать только в "крайних" случаях - автоматически генерировать для сложных отчетов, пересчетов данных, и т.п.
В этом случае данные будут хранится в объектном слое так-же в строго органиченном наборе таблиц, аналогичном набору таблиц для модели системы. Тогда, при внесении изменений в модель системы, не придется изменять/перегенерировать ни одну таблицу объектного слоя.
Фактически такая объектная надстройка/слой БД не противоречит традиционному реляционному подходу - в ней тоже есть таблицы с полями, индексы, связи, ХП, запросы, представления... Просто в этом случае в ходе проектирования системы мы уходим несколько дальше, чем традиционная 3 форма нормализации модели данных :)
Минусами при этом будут - нетрадиционный подход к проектированию и структуре БД, возможно меньшая производительность (что спорно и сильно зависит от реализации), и больший объем БД.
Плюсов и выгод на мой взгляд гораздо больше чем минусов и о них тоже можно будет поговорить.
Возможно Вам не нравится сам термин "объектная" (надстройка или слой в БД) но этот термин на мой взгляд наиболее точно отражает суть предлагаемых изменений в подходе к проектированию в СУБД :)
...
Рейтинг: 0 / 0
13.01.2005, 13:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863658
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Эта информационная система должна будет как минимум реализовать единое информационное пространство для всех
> подразделений и компаний а в идеале обеспечить в организации все требования и управленческого учета и финансового
> и остальных... :)

Хорошая задача. ;) С учетом и управлением - понятно, а вот с единым информационным пространством - есть варианты и темы для обсуждения.

> Надо чтобы внедрение в систему новой функциональности занимало не 3-6 месяцев а 1-2 недели;

Еще одна хорошая задача.

> Выходом здесь [...] может послужить внесение в БД дополнительного "объектного" слоя [...] в которой можно будет
> описать модель предметной области, в нашем случае - организации и её БП, в виде набора логических объектов, их
> связей, атрибутов и методов.

Хм... у меня похожие посылки и аналогичные выводы. ;)

> Обычно подобные вещи называется "метаданными", "словарем БД" но в нашем случае этот объектный слой или надстройка
> имеет более широкий смысл.

Почему, собственно, и хотелось уточнить трактовку "объектности". Если речь - об описании, то, видимо, правильнее все-таки использование термин "метаданные". В общем, неважно, смысл понятен. Пусть это будет "объектная надстройка".

> Практически это будет небольшой, сторго ограниченный (или автоматически дополняемый) набор таблиц и ХП (если
> использовать напр. MS SQL-Server). В конкретной реализации такого набора таблиц возможны варианты - это предмет
> обсуждения по вопросу, который я выше в теме обозначил номером 6.

Какой набор элементарных логических объектов Вы намерены использовать? В задачу входит регистрация состояний объектов? Если входит, то какие состояния Вы намерены регистрировать?

> Логично было-бы в объектном слое описать для необходимых бизнес-объектов и их пользовательский интерфейс - тоже в
> виде логических объектов. Тогда можно было-бы все возможные клиентские модули системы ограничить единым
> универсальным модулем - генератором user-интерфейса (очень тонкий клиент).

Это относительно несложно. Причем, абсолютно логично в описание интерфейса вписываются права и уровень доступа.

> При наличии в системе такого объектного слоя разработка и коррекция её функционала сведется к
> описанию/редактированию в БД модели - заполнению/редактированию "модельных" таблиц объектного слоя данными и,
> возможно, написанию/генерации некоторых специфических ХП.

Imho два варианта: хорошее, полное описание бизнес-правил в обмен на ужесточение детерминированности (второй вариант - соответственно, наоборот). По моему мнению, код писать придется в обоих случаях. У меня не получилось найти удобного решения.

> Т.к. при внесении изменений в модель системы потребуется корекция или перегенерация всех или части таблиц
> традиционной реляционной структуры, то мы получим серьезные трудности с хранением данных живой, изменяемой
> системы в таких таблицах.

Почему? А версионность?

> Поэтому на мой взгляд, имея объектный слой в БД, эффективнее было-бы и для хранения данных системы пользоваться
> только объектным слоем, а постоянные/временные таблицы или представления использовать только в "крайних" случаях -
> автоматически генерировать для сложных отчетов, пересчетов данных, и т.п.

Понятно. Т. е. получилась такая база данных в базе данных.

> В этом случае данные будут хранится в объектном слое так-же в строго органиченном наборе таблиц, аналогичном набору
> таблиц для модели системы. Тогда, при внесении изменений в модель системы, не придется изменять/перегенерировать
> ни одну таблицу объектного слоя.

А для какой цели ограничивать этот набор таблиц? Imho это требование ниоткуда не вытекает, а ограничений накладывает кучу.

> Фактически такая объектная надстройка/слой БД не противоречит традиционному реляционному подходу

Не уверен.

> Просто в этом случае в ходе проектирования системы мы уходим несколько дальше, чем традиционная 3 форма
> нормализации модели данных :)

Хм... зависит от того, как на это посмотреть. Если положить метаописание эквивалентным системным таблицам, - что, в общем, imho вполне оправданно, - тогда упоминаемая Вами жесткая структура таблиц может быть рассмотрена как обычная стуктура данных. Тогда, как обычно, есть варианты и стоит посмотреть на реализацию этой жесткой структуры таблиц.

> Минусами при этом будут [...] и больший объем БД.

Imho здесь накладные расходы будут действительно большими, но меня это не пугает. Стоимость хранения данных падает на глазах. А вот с производительностью сложнее.
...
Рейтинг: 0 / 0
13.01.2005, 16:33
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863663
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Rovdo
Гость
guest_20040621>
...такую задачу: путь в базе данных есть некоторая сущность, которая может быть связана с любой из других сущностей этой же базы данных отношением n:m.

Hint1: база данных среднего размера, единицы сотен таблиц,
Hint2: таких сущностей в общем случае большей одной,
Hint3: решение нужно в общем виде, безотносительно СУБД,
Hint4: решение должно предоставлять возможность управления отношениями без написания дополнительного кода.



Направление моей мысли (вариант решения в рамках ОО-подхода, возможны некоторые вариации):

Сущность 1 = объект класса 1

Класс 1
{
тип атрибут1;
тип атрибут2;
тип=(ссылка на Класс2) атрибут3;
...
}

Класс3, ... КлассN - наследуют от Класса2

Сущность 2 = объект класса 2
...

Если нужно назначить какие-то параметры самой ссылке, то атрибут3 можно определить как объект класса "Отношение", включив в него все необходимые атрибуты.

Это объектная модель дальше берем O/R-инструментарий (например, VOA JDO) и получаем решение, позволяющее хранить все это в любой реляционной СУБД, поддерживаемой данным инструментарием. Причем все изменения объектной модели (добавление/изменение классов и атрибутов) таким инструментарием (с некоторыми оговорками) могут отрабатываться автоматически.

Правда не совсем понятно, что означает требование 4.

С уважением, Алексей Ровдо.
...
Рейтинг: 0 / 0
13.01.2005, 16:34
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863793
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
skorohod"объектность" такой системы плавно вытекла из логичной необходимости иметь не в Visio или Rose, а в БД модель всей организации и ее БП. Сделать это можно и "традиционным реляционным" подходом, забив все необходимые данные в кучу справочников и обеспечив их "динамичность", но поддерживать и развивать такую систему и на уровне БД и на уровне прикладного софта будет очень проблематично даже для небольшой компании.
Выходом здесь на мой взгляд(и не только на мой) может послужить внесение в БД дополнительного "низкоуровневого", "объектного" слоя (или "объектной надстройки" - наверно не важно как это называть) в которой можно будет описать модель предметной области, в нашем случае - организации и её БП, в виде набора логических объектов, их связей, атрибутов и методов.
Обычно подобные вещи называется "метаданными", "словарем БД" но в нашем случае этот объектный слой или надстройка имеет более широкий смысл.
Практически это будет небольшой, сторго ограниченный (или автоматически дополняемый) набор таблиц и ХП (если использовать напр. MS SQL-Server).
...
Минусами при этом будут - нетрадиционный подход к проектированию и структуре БД, возможно меньшая производительность (что спорно и сильно зависит от реализации), и больший объем БД.


А я вот для себя сформулировал "закон сохранения сложности", который гласит : "сложность задачи состоит из сложности алгоритмов и сложности структур данных. Уменьшение одной компоненты ведет к увеличению другой".

Поэтому если вы 50-100-200 таблиц собираете в 5, то сложность данных вы уменьшаете, но вот алгоритмы...
Ну ладно, adisk не хочет попробовать написать JOIN для "объектного слоя". Ему не хочется хвататься грязными руками за хрустальную мечту его программистского детства :-). В конце концов, знатоки Фокса не обязаны знать SQL !
Но вы-то собираетесь все это реально внедрять ? Ну так попробуйте, прикиньте, как будет выглядеть запрос с соединением 2 таблиц в вашем хранилище.
Или вы тоже на Фоксе пишите ?
...
Рейтинг: 0 / 0
13.01.2005, 17:28
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863807
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
adiskРеализвал вариант БД с одной таблицей. (где все данные зранятся в одной таблице)
эксперимент проводил на FoxPro

Работаю над оптимизацией.
Как снова буду на работе вышлю код программы с запросами.


Ждем-с....
...
Рейтинг: 0 / 0
13.01.2005, 17:33
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863813
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> тип=(ссылка на Класс2) атрибут3;

напомню: отношение n:m

> Это объектная модель дальше берем O/R-инструментарий (например, VOA JDO) и получаем решение, позволяющее
> хранить все это в любой реляционной СУБД, поддерживаемой данным инструментарием.

Правильно. С 500 связанными таблицами. Оно хм... просто не нужно. Еще варианты?

> Причем все изменения объектной модели (добавление/изменение классов и атрибутов) таким инструментарием (с
> некоторыми оговорками) могут отрабатываться автоматически.

Для типовых структур - возможно. Но, если Вы заметили, о них речь не идет. Вообще. Так что в данном случае такие генераторы бесполезны. Т. е. абсолютно.

> Правда не совсем понятно, что означает требование 4.

Прочтите сообщение Member skorohod [1242024] (последнеее на 9 странице). Он описал примерно то, что мы с Вами пробуем обсуждать. Вопросов осталась масса, но в общем и целом идея должна быть понятна.
...
Рейтинг: 0 / 0
13.01.2005, 17:36
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863921
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
2 guest_20040621
> Хорошая задача. ;) С учетом и управлением - понятно, а вот с единым информационным пространством - есть варианты и темы для обсуждения.

Согласен, есть. Только наверно надо отдельно обсуждать структуру базы и цели автоматизации - а то сами не разберемся что и где написали :)

>> Практически это будет небольшой, сторго ограниченный (или автоматически дополняемый) набор таблиц и ХП (если
>> использовать напр. MS SQL-Server). В конкретной реализации такого набора таблиц возможны варианты - это предмет
>> обсуждения по вопросу, который я выше в теме обозначил номером 6.
> Какой набор элементарных логических объектов Вы намерены использовать?
> В задачу входит регистрация состояний объектов? Если входит, то какие
> состояния Вы намерены регистрировать?

Набор логических объектов будет зависеть от задачи. Согласитесь, что для "библиотеки" или "химического справочника" или "КИС" эти наборы будут ОЧЕНЬ разные! Хотя 100% для всех задач должен быть определенный небольшой (наверно) набор, определяющий структуру, функционал объектов самого ядра системы.
Я нигде не упоминал термина "атрибут", имея ввиду, что любой атрибут логического объекта модели является таким-же логическим обектом той-же модели но уже следующего уровня иерархии. И конечно д.б. атрибуты конечные (или первичные - с какого конца смотреть), которые ни на что уже не подразделяются и имеют только значение определенного типа.
Логично в виде объектов модели ввести доступ пользователей, версионность самих объектов, их состояния, ссылки, отношения, типы данных, различные типы объектов, события, сообщения...
Состояния обязательно. Я бы хотел фиксировать:
а) системные состояния объектов модели (шаблонов / классов)- зависит от реализации ядра системы - ну напр. "в разработке" (не введен в строй), "активный" (понятно), "архив" (выведен из текущей эксплуатации), ...
б) бизнес-состояния объектов собственно системы (ну тут может быть что угодно)

> Это относительно несложно. Причем, абсолютно логично в описание
> интерфейса вписываются права и уровень доступа.

На мой взгляд права доступа должны определяться на объектах модели а на юзер-интерфейс они должны отображаться опосредованно.

>> При наличии в системе такого объектного слоя разработка и коррекция её функционала сведется к
>> описанию/редактированию в БД модели - заполнению/редактированию "модельных" таблиц объектного слоя данными и,
>> возможно, написанию/генерации некоторых специфических ХП.
> Imho два варианта: хорошее, полное описание бизнес-правил в обмен на
> ужесточение детерминированности (второй вариант - соответственно,
> наоборот). По моему мнению, код писать придется в обоих случаях. У меня
> не получилось найти удобного решения.

Код конечно будет - (не считая ХП в БД) на языке сервера приложения д.б. модули обработки определенных событий и методов объектов, но храниться они будут тоже в БД.

>> Т.к. при внесении изменений в модель системы потребуется корекция или перегенерация всех или части таблиц
>> традиционной реляционной структуры, то мы получим серьезные трудности с хранением данных живой, изменяемой
>> системы в таких таблицах.
> Почему? А версионность?

Версионнность в традиционной системе - это по-моему слишком громоздко и накладно будет.

> Понятно. Т. е. получилась такая база данных в базе данных.
:) Ну в SQL-S 2000 тоже в пустой новорожденной базе присутствует куча системных табличек, так что мы не первые!

>> В этом случае данные будут хранится в объектном слое так-же в строго органиченном наборе таблиц, аналогичном набору
>> таблиц для модели системы. Тогда, при внесении изменений в модель системы, не придется изменять/перегенерировать
>> ни одну таблицу объектного слоя.
> А для какой цели ограничивать этот набор таблиц? Imho это требование
> ниоткуда не вытекает, а ограничений накладывает кучу.

Я просто считаю что это вариант проще в реализации и "универсален". Кроме того получаемые при этом преимущества перевесят накладываемые ограничения. А вообще изначально я начал свои измышления на эту тему "из чисто спортивного интереса" с целью придумать именно универсальную структуру, годную для описания любой инфосистемы на уровне данных, без изменения реляционной структуры.

>> Фактически такая объектная надстройка/слой БД не противоречит традиционному реляционному подходу
> Не уверен.
Хорошо! "Традиционному" именно сегодня может и противоречит, но согласитесь, что "традиционный" подход 5 или 10 лет назад был несколько другим, чем сегодня! Традиции приходят и уходят...
Разве стандарт SQL ставит ограничения на степень нормализации данных, или на структуру логической модели данных приложения???

>> Просто в этом случае в ходе проектирования системы мы уходим несколько дальше, чем традиционная 3 форма
>> нормализации модели данных :)
> Хм... зависит от того, как на это посмотреть. Если положить метаописание
> эквивалентным системным таблицам, - что, в общем, imho вполне
> оправданно, - тогда упоминаемая Вами жесткая структура таблиц может
> быть рассмотрена как обычная стуктура данных. Тогда, как обычно, есть
> варианты и стоит посмотреть на реализацию этой жесткой структуры таблиц.

Сегодня варианты не приведу, но их на самом деле можно по пальцам перечесть и потом обсуждать - какой лучше/хуже и почему. В этом топике они вроде были, и в паре смежных топиков - я где-то раньше здесь на них ссылки приводил (в конце декабря).

>> Минусами при этом будут [...] и больший объем БД.
> Imho здесь накладные расходы будут действительно большими, но меня это
> не пугает. Стоимость хранения данных падает на глазах. А вот с
> производительностью сложнее.

На счет производительности тоже можно будет говорить конкретно, только имея что-то, что можно протестировать на серьезном объеме данных. Т.е. сейчас наверно еще рановато. Хотя можно привлечь к обсуждению авторов / владельцев подобных систем. Есть такие в реале.
...
Рейтинг: 0 / 0
13.01.2005, 18:16
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863934
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Rovdo
Гость
guest_20040621> тип=(ссылка на Класс2) атрибут3;

напомню: отношение n:m

> Это объектная модель дальше берем O/R-инструментарий (например, VOA JDO) и получаем решение, позволяющее
> хранить все это в любой реляционной СУБД, поддерживаемой данным инструментарием.

Правильно. С 500 связанными таблицами. Оно хм... просто не нужно. Еще варианты?



Для любого отношения можно построить адекватную струтуру класса (классов).

Но если решение с 500 таблицами вас принципиально не устраивает (в общем-то могу понять) и вы хотите разместить данные в меньшем количестве таблиц, навернув на это некую оболочку, то чем это отличается от попытки создания объектной СУБД, где в качестве хранилища данных выступает некая структура, размещаемая внутри РСУБД? Не проще ли в таком случае просто переориентироваться на использование чистой ООСУБД, в которой можно отследить и достаточно сложные случаи модификации структуры данных и их взаимосвязей? Ведь любое моделирование рассматриваемой ситуации (в т.ч. и в приводимых выше в дискуссии статьях) приводит нас к модели в виде какого-то графа. Но хранение и обрабтка структурированной таким образом информации - прерогатива объектных систем (они для этого в первую очередь и создавались).
...
Рейтинг: 0 / 0
13.01.2005, 18:20
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863956
Фотография 4d_monster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4d_monster
Участник
2 vybegallo
Зачем ему такие джойны ?

Ваша задача не на выборку данных, а на отображение их на клиенте.
Ваши юзеры наверно не на прямую в SQL работают, а через интерфейс.

IMHO, Mon$te®
...
Рейтинг: 0 / 0
13.01.2005, 18:30
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863958
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
skorohod2 guest_20040621
> Хорошая задача. ;) С учетом и управлением - понятно, а вот с единым информационным пространством - есть варианты и темы для обсуждения.

Согласен, есть. Только наверно надо отдельно обсуждать структуру базы и цели автоматизации - а то сами не разберемся что и где написали :)

>> Практически это будет небольшой, сторго ограниченный (или автоматически дополняемый) набор таблиц и ХП (если
>> использовать напр. MS SQL-Server). В конкретной реализации такого набора таблиц возможны варианты - это предмет
>> обсуждения по вопросу, который я выше в теме обозначил номером 6.
> Какой набор элементарных логических объектов Вы намерены использовать?
> В задачу входит регистрация состояний объектов? Если входит, то какие
> состояния Вы намерены регистрировать?

Набор логических объектов будет зависеть от задачи. Согласитесь, что для "библиотеки" или "химического справочника" или "КИС" эти наборы будут ОЧЕНЬ разные! Хотя 100% для всех задач должен быть определенный небольшой (наверно) набор, определяющий структуру, функционал объектов самого ядра системы.
Я нигде не упоминал термина "атрибут", имея ввиду, что любой атрибут логического объекта модели является таким-же логическим обектом той-же модели но уже следующего уровня иерархии. И конечно д.б. атрибуты конечные (или первичные - с какого конца смотреть), которые ни на что уже не подразделяются и имеют только значение определенного типа.
Логично в виде объектов модели ввести доступ пользователей, версионность самих объектов, их состояния, ссылки, отношения, типы данных, различные типы объектов, события, сообщения...
Состояния обязательно. Я бы хотел фиксировать:
а) системные состояния объектов модели (шаблонов / классов)- зависит от реализации ядра системы - ну напр. "в разработке" (не введен в строй), "активный" (понятно), "архив" (выведен из текущей эксплуатации), ...
б) бизнес-состояния объектов собственно системы (ну тут может быть что угодно)

> Это относительно несложно. Причем, абсолютно логично в описание
> интерфейса вписываются права и уровень доступа.

На мой взгляд права доступа должны определяться на объектах модели а на юзер-интерфейс они должны отображаться опосредованно.

>> При наличии в системе такого объектного слоя разработка и коррекция её функционала сведется к
>> описанию/редактированию в БД модели - заполнению/редактированию "модельных" таблиц объектного слоя данными и,
>> возможно, написанию/генерации некоторых специфических ХП.
> Imho два варианта: хорошее, полное описание бизнес-правил в обмен на
> ужесточение детерминированности (второй вариант - соответственно,
> наоборот). По моему мнению, код писать придется в обоих случаях. У меня
> не получилось найти удобного решения.

Код конечно будет - (не считая ХП в БД) на языке сервера приложения д.б. модули обработки определенных событий и методов объектов, но храниться они будут тоже в БД.

>> Т.к. при внесении изменений в модель системы потребуется корекция или перегенерация всех или части таблиц
>> традиционной реляционной структуры, то мы получим серьезные трудности с хранением данных живой, изменяемой
>> системы в таких таблицах.
> Почему? А версионность?

Версионнность в традиционной системе - это по-моему слишком громоздко и накладно будет.

> Понятно. Т. е. получилась такая база данных в базе данных.
:) Ну в SQL-S 2000 тоже в пустой новорожденной базе присутствует куча системных табличек, так что мы не первые!

>> В этом случае данные будут хранится в объектном слое так-же в строго органиченном наборе таблиц, аналогичном набору
>> таблиц для модели системы. Тогда, при внесении изменений в модель системы, не придется изменять/перегенерировать
>> ни одну таблицу объектного слоя.
> А для какой цели ограничивать этот набор таблиц? Imho это требование
> ниоткуда не вытекает, а ограничений накладывает кучу.

Я просто считаю что это вариант проще в реализации и "универсален". Кроме того получаемые при этом преимущества перевесят накладываемые ограничения. А вообще изначально я начал свои измышления на эту тему "из чисто спортивного интереса" с целью придумать именно универсальную структуру, годную для описания любой инфосистемы на уровне данных, без изменения реляционной структуры.

>> Фактически такая объектная надстройка/слой БД не противоречит традиционному реляционному подходу
> Не уверен.
Хорошо! "Традиционному" именно сегодня может и противоречит, но согласитесь, что "традиционный" подход 5 или 10 лет назад был несколько другим, чем сегодня! Традиции приходят и уходят...
Разве стандарт SQL ставит ограничения на степень нормализации данных, или на структуру логической модели данных приложения???

>> Просто в этом случае в ходе проектирования системы мы уходим несколько дальше, чем традиционная 3 форма
>> нормализации модели данных :)
> Хм... зависит от того, как на это посмотреть. Если положить метаописание
> эквивалентным системным таблицам, - что, в общем, imho вполне
> оправданно, - тогда упоминаемая Вами жесткая структура таблиц может
> быть рассмотрена как обычная стуктура данных. Тогда, как обычно, есть
> варианты и стоит посмотреть на реализацию этой жесткой структуры таблиц.

Сегодня варианты не приведу, но их на самом деле можно по пальцам перечесть и потом обсуждать - какой лучше/хуже и почему. В этом топике они вроде были, и в паре смежных топиков - я где-то раньше здесь на них ссылки приводил (в конце декабря).

>> Минусами при этом будут [...] и больший объем БД.
> Imho здесь накладные расходы будут действительно большими, но меня это
> не пугает. Стоимость хранения данных падает на глазах. А вот с
> производительностью сложнее.

На счет производительности тоже можно будет говорить конкретно, только имея что-то, что можно протестировать на серьезном объеме данных. Т.е. сейчас наверно еще рановато. Хотя можно привлечь к обсуждению авторов / владельцев подобных систем. Есть такие в реале.
Есть они. А сложность-это всего лишь миф! Мало таблиц-проще алгоритм,так по крайней мере получилось у меня. Мало ли что может показаться вначале....
...
Рейтинг: 0 / 0
13.01.2005, 18:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863959
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
2 quot vybegallo

> А я вот для себя сформулировал "закон сохранения сложности", который
> гласит : "сложность задачи состоит из сложности алгоритмов и сложности
> структур данных. Уменьшение одной компоненты ведет к увеличению другой".
>
> Поэтому если вы 50-100-200 таблиц собираете в 5, то сложность данных вы
> уменьшаете, но вот алгоритмы...
> Ну ладно, adisk не хочет попробовать написать JOIN для "объектного слоя".
> Ему не хочется хвататься грязными руками за хрустальную мечту его
> программистского детства :-). В конце концов, знатоки Фокса не обязаны
> знать SQL !
> Но вы-то собираетесь все это реально внедрять ? Ну так попробуйте,
> прикиньте, как будет выглядеть запрос с соединением 2 таблиц в вашем
> хранилище.
> Или вы тоже на Фоксе пишите ?

Уважаемый!
А можно мне поинтересоваться целью Вашего присутствия в этом топике?
Задавить всех интересующихся Вашим богатым опытом? Или доказать, что этого в природе не существует и сделать такое в принципе невозможно? Или, что это не нужно Вам в Вашей тяжелой работе? Или может Вы беспокоитесь за ухудшение состояния нашей психики в ходе обсуждений? :)
Объяснитесь, плиз! Очень хочется узнать!
...
Рейтинг: 0 / 0
13.01.2005, 18:32
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864032
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
4d_monster2 vybegallo
Зачем ему такие джойны ?

Ваша задача не на выборку данных, а на отображение их на клиенте.


IMHO, Mon$te®

Ну так для того, чтобы отобразить, сначала нужно выбрать ?
...
Рейтинг: 0 / 0
13.01.2005, 19:28
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864034
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
skorohod2 quot vybegallo

> А я вот для себя сформулировал "закон сохранения сложности", который
> гласит : "сложность задачи состоит из сложности алгоритмов и сложности
> структур данных. Уменьшение одной компоненты ведет к увеличению другой".
>
> Поэтому если вы 50-100-200 таблиц собираете в 5, то сложность данных вы
> уменьшаете, но вот алгоритмы...
> Ну ладно, adisk не хочет попробовать написать JOIN для "объектного слоя".
> Ему не хочется хвататься грязными руками за хрустальную мечту его
> программистского детства :-). В конце концов, знатоки Фокса не обязаны
> знать SQL !
> Но вы-то собираетесь все это реально внедрять ? Ну так попробуйте,
> прикиньте, как будет выглядеть запрос с соединением 2 таблиц в вашем
> хранилище.
> Или вы тоже на Фоксе пишите ?

Уважаемый!
А можно мне поинтересоваться целью Вашего присутствия в этом топике?
Задавить всех интересующихся Вашим богатым опытом? Или доказать, что этого в природе не существует и сделать такое в принципе невозможно? Или, что это не нужно Вам в Вашей тяжелой работе? Или может Вы беспокоитесь за ухудшение состояния нашей психики в ходе обсуждений? :)
Объяснитесь, плиз! Очень хочется узнать!

Есть такой старый анекдот
Сидит чукча на дереве и пилит под собой ветку. Прохожий ему
- что ты делаешь, ты же упадешь !
чукча продолжает пилить, падает, встает - "Колдун, однако !"

Я понятно намекаю ?
...
Рейтинг: 0 / 0
13.01.2005, 19:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864082
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
2 skorohod

> Только наверно надо отдельно обсуждать структуру базы и цели автоматизации - а то сами не разберемся что и где
> написали :)

Вы правы.

> Набор логических объектов будет зависеть от задачи.

Хм... нет, не соглашусь. _Элементарные_ логические объекты будут одинаковы для любой задачи.

> Логично в виде объектов модели ввести доступ пользователей, версионность самих объектов, их состояния, ссылки,
> отношения, типы данных, различные типы объектов, события, сообщения...

Я бы предложил другой подход. Если в общем и целом придерживаться уже описанной структуры (пока забыли о деталях; важно, что есть метаинформация и есть данные), то _в ее рамках_ легко выделить два уровня представления: физический и логический. На физическом уровне удобно оперировать понятиями, сходными с теми, которые употребляются для описания метаданных СУБД (т. е. используются для системных объектов СУБД), на логическом (термин не очень точно отражает суть представления, но лучше ничего не придумалось) - близким к объектному или традиционному проектированию.

> а) системные состояния объектов модели [...] б) бизнес-состояния объектов собственно системы

Возражений нет.

> а на юзер-интерфейс они должны отображаться опосредованно.

Это всего лишь один из уровней проверки (всего их - классический паттерн - три). Возражений нет.

> Код конечно будет - (не считая ХП в БД) на языке сервера приложения д.б. модули обработки определенных событий и
> методов объектов, но храниться они будут тоже в БД.

Понятно. Хозяин - барин, конечно, но мне такая реализация не нравится. Я предпочитаю хранить в базе данных только правила обработки.

> Версионнность в традиционной системе - это по-моему слишком громоздко и накладно будет.

Нет необходимости поддерживать ее в объеме cvs. ;)

> Я просто считаю что это вариант проще в реализации и "универсален".

Это кажущаяся простота. В данном случае схема данных получается настолько навороченной, что бороться нужно не за компактность хранения данных, а за скорость манипуляции данными.

> А вообще изначально я начал свои измышления на эту тему "из чисто спортивного интереса" с целью придумать именно
> универсальную структуру, годную для описания любой инфосистемы на уровне данных, без изменения реляционной
> структуры.

Ну, по этому поводу здесь уже были замечания, повторяться не буду.

> Традиции приходят и уходят...

Не думаю. Динамика традиций проектирования реляционных баз данных imho заключается в увеличении роли адаптивной составляющей по сравнению с детерминированной. И только. Я бы не стал называть это новыми традициями.

> Разве стандарт SQL ставит ограничения на степень нормализации данных, или на структуру логической модели данных
> приложения???

Не помню, не могу сказать.

> Хотя можно привлечь к обсуждению авторов / владельцев подобных систем. Есть такие в реале.

Вы знаете о практических реализациях этой задачи? Поделитесь ссылками, pls, очень интересно.



2 Alexey Rovdo

> Для любого отношения можно построить адекватную струтуру класса (классов).

Кто бы с этим спорил. ;)

> то чем это отличается от попытки создания объектной СУБД, где в качестве хранилища данных выступает некая структура,
> размещаемая внутри РСУБД?

Хороший вопрос. Дело в том, что мне не нужна объектная реализация как таковая: с удовольствием предоставлю возможность решать эту задачу промежуточному уровню (благо вариантов масса) ПО. Но при этом хотел бы иметь дополнительную функциональность, отличную как от объектных СУБД, так и от реляционных. Один из примеров я Вам привел. Их (примеров) еще есть. ;)

> Не проще ли в таком случае просто переориентироваться на использование чистой ООСУБД,

Не проще.

> в которой можно отследить и достаточно сложные случаи модификации структуры данных и их взаимосвязей?

Хм... это не есть главная задача.

> Ведь любое моделирование [...] приводит нас к модели в виде какого-то графа.

В данном случае Вы ошибаетесь.
...
Рейтинг: 0 / 0
13.01.2005, 20:19
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864098
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
Дополнение: если обсуждаемое решение дополнить семантической составляющей (в предположении, что хронология, права доступа, мультиязычность и пр. реализованы), получившася база данных будет imho иметь основания таковой называться.

Остался без обсуждения вопрос о единственности информационного пространства. Какие будут соображения на этот счет?
...
Рейтинг: 0 / 0
13.01.2005, 20:45
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864255
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Поскольку запросов на выборку данных будет гораздо больше, чем модификаций структуры базы,
рациональнее хранить данные в отдельнах таблицах. (то есть в РБД)
Но при этом обращаться к данным только через объектную надстройку.
Другими словами, генерировать SQL-запрос к реляционной базе на основе метаданных.
Такой подход даст производительность сравнимую с РБД и одновременно придаст БД гибкость.

Исключить прямые обращения к таблицам и полям из клиентского приложения.
Т.е. работать с данными только через ОО-надстройку.
...
Рейтинг: 0 / 0
14.01.2005, 07:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864261
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
2 vybegallo:
Считаю, некорректным выяснение отношений в рамках данного топика.
Также считаю пустой тратой времени общение с человеком препятствующим развитию идеи в то время как подавляющее большинство занимается ее развитием и верят в ее состоятельность.
Ваши дальнейшие посты будуть игнорироваться.
...
Рейтинг: 0 / 0
14.01.2005, 07:34
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864270
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
adisk2 vybegallo:
Считаю, некорректным выяснение отношений в рамках данного топика.
Также считаю пустой тратой времени общение с человеком препятствующим развитию идеи в то время как подавляющее большинство занимается ее развитием и верят в ее состоятельность.
Ваши дальнейшие посты будуть игнорироваться.

Одно из двух : или JOIN не удалось написать, или время выполнения зашкалило за все пределы разумного.

Да развивайте на здоровье вашу идею, уважаемые ! У меня подобная система в продакшн сидит - своими руками бы автора задушил, жаль, он уволился лет пять назад... А в теории да, система замечательная, позволяет все что угодно описать пятью таблицами. Между прочим, говорят, любую мысль в русском языке можно передать словоформами пяти матерных корней :-)
...
Рейтинг: 0 / 0
14.01.2005, 07:52
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864271
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
БД можно представить в виде направленного графа.
Направленные дуги - это связи м/у объектами.

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


Такая программа уже реализована в качестве эксперимента, и уже тестировалась на рабочей РБД. (Не ОО)
Хоть и с глюками, но работает!
...
Рейтинг: 0 / 0
14.01.2005, 07:59
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864365
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
2 vybegallo

> Есть такой старый анекдот
> Сидит чукча на дереве и пилит под собой ветку. Прохожий ему
> - что ты делаешь, ты же упадешь !
> чукча продолжает пилить, падает, встает - "Колдун, однако !"
> Я понятно намекаю ?

Амвросий Амбруазович!
Я тут посмотрел по форуму...
Вы оказывается не только в нашем топике проверяете, чтобы народ на нужных ветках сидел и в руки ничего лишнего не брал.
Как, не тяжело за всеми сразу следить??? На пенсию не пора еще?
Я понятно намекаю ?
...
Рейтинг: 0 / 0
14.01.2005, 09:32
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864385
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Я собственными глазами видел систему и даже чуть чуть работал с ней, в которой есть именно "Поскольку запросов на выборку данных будет гораздо больше, чем модификаций структуры базы,
рациональнее хранить данные в отдельнах таблицах. (то есть в РБД)
Но при этом обращаться к данным только через объектную надстройку.
Другими словами, генерировать SQL-запрос к реляционной базе на основе метаданных.
Такой подход даст производительность сравнимую с РБД и одновременно придаст БД гибкость. "
Исключить прямые обращения к таблицам и полям из клиентского приложения.
Т.е. работать с данными только через ОО-надстройку."

Подозреваю, что для Вас объем базы 580 Гб великоват, но я бы сказал, что система очень тормозит. Кстати, для такой системы очень важно, чтобы она была привязана к конкретной субд, так как она будет вся построена на динамическом sql, а при больших объемах всплывают тонкости, на которые обычно забиваешь в малых БД (для меня это 14-20Gb). Это я к тому, что независимость от СУБД вряд ли удастся, потому как у многих это самоцель...

Кстати, г-н Adisk, Вы умнеете на глазах. Теперь уже не хотите, по крайней мере, все (изменяющиеся данные и бизнес-логику) хранить в "единой универсальной структуре".
...
Рейтинг: 0 / 0
14.01.2005, 09:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864498
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
guest_20040621Дополнение: если обсуждаемое решение дополнить семантической составляющей (в предположении, что хронология, права доступа, мультиязычность и пр. реализованы), получившася база данных будет imho иметь основания таковой называться.

Остался без обсуждения вопрос о единственности информационного пространства. Какие будут соображения на этот счет?

Вопрос конечно интересный!
Что называть единым инфо-пространством?!
Применительно к коммерческим структурам (что наверное большинству здешних посетителей ближе) это значит, что должны быть максимально автоматизированы бизнес-процессы всех подразделений организации, которые имеет смысл автоматизировать, с целью повышения эффективности деятельности и снижения затрат на обеспечение работы организации вцелом.
При этом, конечно, есть процессы, которые необходимо автоматизировать с помощью СУБД, но есть и такие, для которых достаточно будет M$ Office. (всех мух из котлет надо сразу повыковыривать!)
Возможные варианты на мой взгляд:
1) Все пользователи работают с различными интерфейсами функциональных частей (модулей/задач/... - как это реализовано практически - сейчас не важно) инфосистемы, базирующейся на единственной, общей многофункциональной БД;
2) Разные пользователи работают с различными интерфейсами функциональных частей нескольких многофункциональных подсистем (каждая на своей БД), реализованных с поддержкой общей (единой) БД метаданных.
3) Разные пользователи работают с интерфейсами нескольких узкоспециализированных подсистем (каждая на своей БД), реализованных с поддержкой общей (единой) БД метаданных.
п.3 есть разновидность п.2. Оба они гораздо сложнее в разработке и поддержке, чем 1, но должны дать большую производительность. Хотя у каждого варианта есть свои плюсы и минусы. Например от 1 к 3 возрастает сложность аналитики данных, что иногда может перевесить плюс производительности.
Если говорить о функциональности, то в идеале наверно для всех (крупных организаций) обязательно д.б. реализован полный замкнутый документооборот, возможно реализация интранет на основе СУБД... Остальные функциональные части будут зависеть от специфики организации.

Кстати, guest_20040621, интересно узнать ваш взгляд на необходимость и форму реализации мультиязычности!
...
Рейтинг: 0 / 0
14.01.2005, 10:25
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864535
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Посмотрите систему интеграции TMU Decarte, мне кажется она довольно интересна и соответствует обсуждаемым в этом топике идеям.А то, не сомневаюсь, велосипедов наизобретаете много да и клавиатуры постираете -:(
...
Рейтинг: 0 / 0
14.01.2005, 10:42
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864576
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
ShtockЯ собственными глазами видел систему и даже чуть чуть работал с ней

Расскажите как она устроена. Как хранятся данные?
Как создаются формы ввода?
Как реализована версионность (исторя)?

Shtock
Подозреваю, что для Вас объем базы 580 Гб великоват, но я бы сказал, что система очень тормозит. Кстати, для такой системы очень важно, чтобы она была привязана к конкретной субд, так как она будет вся построена на динамическом sql, а при больших объемах всплывают тонкости, на которые обычно забиваешь в малых БД (для меня это 14-20Gb).

Верно, такими объемами "живых" данных манипулировать не приходилось.
Сечас пробую сделать так:
1. заполняю описание базы (то есть Объектную надстройку)
2. из описания генерирую таблицы (create) или изменяю их структуру (alter table)
3. далее для обращения к данным динамически формирую SQL-запросы,
но предполагаю кеширование SQL-запросов (кеширование не данных, а SQL-выражений)
4. динамически формирую формы ввода (т.е. есть шаблон формы, на котором в левой части в столбик располагаются поля , в правой части связанный с текущим полем справочник)
такой вид:
Код: plaintext
1.
2.
3.
4.
5.
 --==== |+-----+
 --==== ||     |
 --==== ||     |
 --==== ||     |
 --==== |+-----+

Проблемы:
1. сложно генерировать запросы с GROUP BY и UNION - пока не могу придумать единый механизм;
2. для формы содержащих вычислемые значения, надо писать процедуры - то есть не все генерится; (халява не проходит ;))
3. как ни крути надо как-то поддерживать версионность кода. Для обработки старых данных, прошлых перидов и т.д. использовать старый код, для текущих - новый.

А в целом, имея метаописание базы, предоставляя пользователю, понятные русские названия объектов, даем ему возможность самостоятельно манипулировать данными! (может даже так просто как в Excel!)

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

Shtock
Теперь уже не хотите, по крайней мере, все (изменяющиеся данные и бизнес-логику) хранить в "единой универсальной структуре".
Твердо убежден, что комбинация "универсального хранилища" и РБД - лучшее решение.
Именно их комбинация - данные с неизменяемой (статичной) структурой в РБД, с дополняемой (изменяемой) структурой в некотором общем хранилище.
Лучше чем описано в ссылке, приведенной выше, описать не смогу.
...
Рейтинг: 0 / 0
14.01.2005, 11:02
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864670
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Поздравляю с прозрением. На самом деле, это стандартная архитектура большинства современных коробочных ИС.
Вся история ведется в РБД. Схема движка-коммерческая тайна, но суть Вы и сами объяснили (метаданные по реляционным (не добавляемым автоматом, я не считаю это правильным) таблицам. Синхроницация метаданных идет автоматом по словарю БД., описание методов (с учетом того, что есть полиморфизм) как имя хранимой процедуры + список параметров).
Я работал с серверной частью,но знаю, что формы генерятся полностью автоматом, далее из них убирается то, что не нужно системой контроля доступа.Истории бизнес-логики там не было.
Например, в системе BusinessObjects это называется "метаслой", правда это business intelegence система и в ней нет методов.
Кстати, по поводу велосипедов, метаданные максимально просто хранить в XML, что автоматом решает проблему разработки пользовательского интерфейса настроек ИС, ведь редакторов xml до черта.
...
Рейтинг: 0 / 0
14.01.2005, 11:37
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864768
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
2 Shtock

> Кстати, для такой системы очень важно, чтобы она была привязана к конкретной субд, так как она будет вся построена на
> динамическом sql,

По поводу динамического SQL - совсем не обязательно.

> а при больших объемах всплывают тонкости, на которые обычно забиваешь в малых БД (для меня это
> 14-20Gb). Это я к тому, что независимость от СУБД вряд ли удастся, потому как у многих это самоцель...

Хм... смотря по тому, на каком уровне говорить о независимости.



2 skorohod

> Что называть единым инфо-пространством?!

Хороший вопрос. ;)

> 1) Все пользователи работают с различными интерфейсами функциональных частей (модулей/задач/... - как это
> реализовано практически - сейчас не важно) инфосистемы, базирующейся на единственной, общей многофункциональной
> БД;
> 2) Разные пользователи работают с различными интерфейсами функциональных частей нескольких многофункциональных
> подсистем (каждая на своей БД), реализованных с поддержкой общей (единой) БД метаданных.
> 3) Разные пользователи работают с интерфейсами нескольких узкоспециализированных подсистем (каждая на своей БД),
> реализованных с поддержкой общей (единой) БД метаданных.

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

> Кстати, guest_20040621, интересно узнать ваш взгляд на необходимость и форму реализации мультиязычности!

В общем случае imho обязательно. Немного задач, которые реально позволяют без нее обойтись. Форма - традиционная (любой из трех возможных способов на выбор). Наличие/отсутствие локализованных значений регистрируется в метаописании как один из признаков.
...
Рейтинг: 0 / 0
14.01.2005, 12:12
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864795
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Кстати, по поводу велосипедов,

;)

> метаданные максимально просто хранить в XML, что автоматом решает проблему

Нет смысла их выносить во внешний файл. Вот сгенерировать конфиг или интерфейс - действительно удобно.
...
Рейтинг: 0 / 0
14.01.2005, 12:22
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864864
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Хранить в БД, почему обязательно файл
...
Рейтинг: 0 / 0
14.01.2005, 12:46
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864899
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Хранить в БД, почему обязательно файл

Т. е. xml и храним в базе данных? А пользуемся так: сначала выбираем его из базы данных, потом разбираем? Фишка-то в чем? Если файл, то по крайней мере из базы ничего выбирать не надо, это уже быстрее.
...
Рейтинг: 0 / 0
14.01.2005, 13:02
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32865186
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Моя СУБД прекрасно работает с xml.
...
Рейтинг: 0 / 0
14.01.2005, 14:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32865248
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Моя СУБД прекрасно работает с xml.

Вы считаете, что это достаточный аргумент? Т. е. на здравый смысл наплевать, важно, что _Моя СУБД_ поддерживает фичу N? Ну-ну.
...
Рейтинг: 0 / 0
14.01.2005, 14:51
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32865358
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Это норма, а не фича (из культовых субд imho этого нет в ib/fb/yfl и mysql). Я не собираюсь горбатиться ради самоцели "независимость от СУБД". Мы с Вами людим по этому поводу уже говорили.
...
Рейтинг: 0 / 0
14.01.2005, 15:23
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32865417
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Это норма, а не фича

Ссылочку на нормативный документ - в студию.

> (из культовых субд imho этого нет в ib/fb/yfl и mysql).

Не бывает культовых СУБД. Есть тупые религиозные фанатики.

> Я не собираюсь горбатиться ради самоцели "независимость от СУБД".

Ну-ну еще раз.
...
Рейтинг: 0 / 0
14.01.2005, 15:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32865429
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
guest_20040621
2 skorohod
> Что называть единым инфо-пространством?!
Хороший вопрос. ;)
.............
Под единым информационным пространством мне бы хотелось понимать еще и возможность идентификации любой сущности (файл, документ или запись любой внешней базы данных). Соответственно, и потенциальная возможность оперировать (по крайней мере, корректно на нее ссылаться) такой сущностью.


Согласен - это просто вопрос полноты объектного описания окружающей реальности и вполне реализуемо - хватило-бы ума и здоровья.
А вот на счет записей внешних БД! Хорошо, если это справочные (напр. на CD)базы "readonly" - нет проблем, и вполне логично использовать и такой ресурс. А если это "живая" база, да без грамотного словаря, в которой сегодня есть запись, а завтра уже нету, или таблицы появляются-исчезают. Как быть? Как отслеживать корректность ссылок? Использовать уже упоминавшиеся в этом топике средства вроде BuisnesObjects? Или вносить их функциональность в "нашу" систему усложняя метаданные?

guest_20040621
> Кстати, guest_20040621, интересно узнать ваш взгляд на необходимость и форму реализации мультиязычности!

В общем случае imho обязательно. Немного задач, которые реально позволяют без нее обойтись. Форма - традиционная (любой из трех возможных способов на выбор). Наличие/отсутствие локализованных значений регистрируется в метаописании как один из признаков.


А можно здесь описать три возможных способа применительно к объектной-модели БД? Дабы сравнить с ними мое представление.
...
Рейтинг: 0 / 0
14.01.2005, 15:42
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32865480
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
1. Для Вас пунк меню Правка, где можно копировать, вставлять и др норма или фича?!А нормативного документа на это нет.XML существует довольно много лет и если в субд не реализовали его использования, то это их проблемы.Им за это деньги платят.Нет-пошли додальше...
2. Под какой СУБД работаете Вы?
3. НЕ походите на mv с его "калеками"
4. если любите работать - работайте для абстрактных самоцелей (похоже, опять уходим в рекурсию)
...
Рейтинг: 0 / 0
14.01.2005, 16:01
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32865536
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Согласен - это просто вопрос полноты объектного описания окружающей реальности и вполне реализуемо - хватило-бы
> ума и здоровья.

Я немного не то имел в виду. Нужна не готовая структура для описания внешних объектов, а алгоритм, правила, которые позволяли бы это делать. Структура данных для этого - не самое сложное.

> А если это "живая" база, да без грамотного словаря, в которой сегодня есть запись, а завтра уже нету, или таблицы
> появляются-исчезают. Как быть? Как отслеживать корректность ссылок?

В общем случае - никак. Я не знаю такого способа. Но можно решить более узкую задачу (например, для баз данных без физического удаления записей; изменения состава/имен таблиц трактовать как версионность).

> Или вносить их функциональность в "нашу" систему усложняя метаданные?

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

> А можно здесь описать три возможных способа применительно к объектной-модели БД?

А почему применительно к объектной модели? Мультиязычность сама по себе, объектная модель - сама по себе (т. е. это не связанные вещи; одна без другой вполне себе существует). Важно описать локализованные значения в метаданных.
...
Рейтинг: 0 / 0
14.01.2005, 16:22
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32865547
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> XML существует довольно много лет и если в субд не реализовали его
> использования, то это их проблемы.

Если такого типа данных нет в стандарте, то его реализация - отсебятина. А кому какая моча в голову ударила и по какому поводу - у меня нет ни желания, ни времени разбираться.
...
Рейтинг: 0 / 0
14.01.2005, 16:27
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32865585
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Никто и не собирается его реализовывать вручную: я выбираю СУБД под задачу (чтобы при этом меньше напрягаться как в материальном, так и во временном смысле), а не задачу под СУБД. Вы не ответили на вопрос о СУБД, на которой работаете Вы.В стандарте w3c есть xml.

Заранее сорри, НО топик называется по-другому, а Вы довольно успешно сбиваете всех на какие-то левые разговоры. Поздравляю. Вам с таким талантом в психотерапевты идти.

Удачных выходных, господа. Берегите мозги.
...
Рейтинг: 0 / 0
14.01.2005, 16:41
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32865634
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Вы не ответили на вопрос о СУБД, на которой работаете Вы.

К обсуждению это отношения не имеет.

> В стандарте w3c есть xml.

Вот когда в sql стандартах появится тип данных xml, появится и предмет для обсуждения.
...
Рейтинг: 0 / 0
14.01.2005, 17:00
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32865706
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
skorohod2 vybegallo

> Есть такой старый анекдот
> Сидит чукча на дереве и пилит под собой ветку. Прохожий ему
> - что ты делаешь, ты же упадешь !
> чукча продолжает пилить, падает, встает - "Колдун, однако !"
> Я понятно намекаю ?

Амвросий Амбруазович!
Я тут посмотрел по форуму...
Вы оказывается не только в нашем топике проверяете, чтобы народ на нужных ветках сидел и в руки ничего лишнего не брал.
Как, не тяжело за всеми сразу следить??? На пенсию не пора еще?
Я понятно намекаю ?

-- Ничего, ничего, -- сказал Выбегалло. -- Это вам не Португалия.
Критики не любите. Лет триста назад я бы с тобой тоже не особенно
церемонился, кафолик недорезанный.
...
Рейтинг: 0 / 0
14.01.2005, 17:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32865732
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
2 guest_20040621
> Я немного не то имел в виду. Нужна не готовая структура для описания
> внешних объектов, а алгоритм, правила, которые позволяли бы это
> делать. Структура данных для этого - не самое сложное.

Я о подобных правилах не слышал. УМЛ наверно сюда очень слабо вписывается! Вы предлагаете их здесь выработать? Результат наверное "потянул-бы" на всеобщий стандарт. Только боюсь, что ничего не получится из этого. Т.е. придется каждому обходиться "встроенной" в голову логикой, знанием предметной области, и умнием проводить декомпозицию.
Возможно спасла бы положение единая общедоступная библиотека примитивов / субмоделей / моделей, (не алгоритмы и правила а "правильные" образцы) но сейчас это даже более несбыточно, чем голубая/розовая мечта :)

>> А если это "живая" база, да без грамотного словаря, в которой сегодня
>> есть запись, а завтра уже нету, или таблицы
>> появляются-исчезают. Как быть? Как отслеживать корректность ссылок?

> В общем случае - никак. Я не знаю такого способа. Но можно решить более
> узкую задачу (например, для баз данных без физического удаления записей;
> изменения состава/имен таблиц трактовать как версионность).

Можно динамику структуры и данных трактовать как версионность, но все равно останется задача КОНТРОЛЯ всего описанного в модели внешнего окружения. Если позволяют аппаратные ресурсы и не смущает разбухание объектной модели - то я особых проблем не вижу (возм. за исключением совместимости) - пусть машина работает, и перелопачивает все хоть каждые 5 минут.

>> Или вносить их функциональность в "нашу" систему усложняя метаданные?

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

Я с этим уже выше согласился, можно, просто не нравится что придется в модели описывать чужие базы, приложения, хотя если очень нужно и денежку заплатят ... :)

>> А можно здесь описать три возможных способа применительно к объектной-модели БД?

> А почему применительно к объектной модели? Мультиязычность сама по
> себе, объектная модель - сама по себе (т. е. это не связанные вещи; одна
> без другой вполне себе существует). Важно описать локализованные
> значения в метаданных.

Да, не связанные, но мне интересна Ваша позиция именно в частном случае реализации мультиязычности в системе с объектной моделью. Как бы вы описали эти локализованные значения?
...
Рейтинг: 0 / 0
14.01.2005, 17:57
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32865905
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Т.е. придется каждому обходиться "встроенной" в голову логикой, знанием предметной области, и умнием проводить
> декомпозицию.

Н-да, действительно сложновато получается. :(

> Возможно спасла бы положение единая общедоступная библиотека примитивов / субмоделей / моделей, (не алгоритмы и
> правила а "правильные" образцы) но сейчас это даже более несбыточно, чем голубая/розовая мечта :)

Хорошая мысль про библиотеку примитивов.

> Как бы вы описали эти локализованные значения?

Так "в лоб" и описал бы. Структура метаинформации к сожалению будет зависеть от способа локализации. Т. е. если выбрать вариант с одной таблицей и множеством полей для разных языков, получится что-то вроде:

system_language;
model_object;
model_object_attribute;
...
rel_object;
...
model_object_attribute_internationalisation;
...
rel_system_language;
rel_object_attribute;
...

Если локализация со связанной таблицей, то будут, соответственно, источник, локализуемое поле, приемник, локализующее поле.

Если честно, я не дошел еще до описания локализации, так что набросал на скорую руку.
...
Рейтинг: 0 / 0
14.01.2005, 20:58
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32866033
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
adisk VybegalloTo adisk :

Это ваше "универсальное хранилище" придумывается каждым программистом баз даных на определенном этапе профессионального роста. Позже приходит понимание, что выигрыщ в простоте проектирования не стоит сооруженного на свою голову геморроя с запросами. А потом приходит заказчик и закатывает истерику, что все работает недопустимо медленно...

Что ж.
Возможно еще не дорос.
Прекрасно осознаю, что будет падение производительности.
Будет ли оно столь ощутимым? Думаю нет.

Ну что ж, раз никто из авторов не рискнул хлебнуть супца собственного приготовления - пришлось протестировать собственноручно.
Напомню задачу :
Дано :
таблица customers, 100 000 записей
customer_id int
customer_desc char(50)

Таблица orders, 1 000 000 записей
order_id int
customer_id int
order_desc char(50)
order_cost decimal (9,2)
order_date date
order_flag char(1)

Требуется :
найти сумму отгруженных договоров (order_flag="Y") с 1.1.2004 по 31.12.04 по каждому покупателю и описание покупателя.

select customer_id, customer_desc , sum(order_cost) from customers, orders
where customers.customer_id = orders.customer_id
and order_flag = "Y"
and order_date between "01/01/2004" and "12/31/2004"
group by 1, 2

-----
Результат решения "в лоб" -
от
No indexes, order_date between 1/1/04 and 12/31/04
optimized uses dynamic hash join
real 0m36.64s
user 0m1.31s
sys 0m0.16s
до
---- 3 : indexes on c.customer_id, o.customer_id, o.order_date ,
real 1m13.51s
user 0m1.72s
sys 0m0.14s

т.е от 36 до 74 секунд.

Нарисовал я рекомендуемую схему, загнал тестовые данные, построил индексы, статистику обновил. Нарисовал запрос (естественно, с использованием view), запустил...

real 37m26.49s
user 0m0.04s
sys 0m0.06s

:-)))))))

Наблюдается небольшое падение производительности - всего лишь в 30-60 раз !

--------- скрипт для желающих проверить лично -----

create table data_s
(id serial,
id_s int,
id_p int,
data varchar(50)) extent size 1000000 next size 200000;

create table data_i
(id serial,
id_s int,
id_p int,
data int) extent size 100000 next size 20000;

create table data_dc
(id serial,
id_s int,
id_p int,
data decimal(12,2)) extent size 100000 next size 20000;

create table data_dt
(id serial,
id_s int,
id_p int,
data date) extent size 100000 next size 20000;

create table data_c
(id serial,
id_s int,
id_p int,
data char(1)) extent size 100000 next size 20000;

create table attr
(id int,
value char(50));

insert into attr values (1, "customer_id");
insert into attr values (2, "customer_desc");
insert into attr values (3, "order_id");
insert into attr values (4, "customer_id2");
insert into attr values (5, "order_desc");
insert into attr values (6, "order_cost");
insert into attr values (7, "order_date");
insert into attr values (8, "order_flag");


create view vcustomers as
select a.data as customer_id, b.data as customer_desc
from data_i a, data_s b
where a.id_p = b.id_p
and a.id_s in (select id from attr where value = "customer_id")
and b.id_s in (select id from attr where value = "customer_desc");

create view vorders as
select a.data as order_id, b.data as customer_id, d.data as order_cost,
e.data as order_date, f.data as order_flag
from data_i a, data_i b, data_dc d, data_dt e, data_c f
where
a.id_p = b.id_p
and a.id_p = d.id_p
and a.id_p = e.id_p
and a.id_p = f.id_p
and a.id_s = 3
and b.id_s = 4
and d.id_s = 6
and e.id_s = 7
and f.id_s = 8;

--drop procedure ins_cust;
create procedure ins_cust (nm int)
define i int;
define c char(30);

for i = 1 to nm
insert into data_i values (0, 1, i, i);
let c = "Customer desc" || i;
insert into data_s values (0, 2, i, c);
end for
end procedure;

create procedure ins_orders (nprev int, nm int)
define i, j int;
define c char(30);
define cost decimal (12,2);
define dt date;

for i = 1 to nm
for j = 1 to 10
insert into data_i values (0, 3, (nprev + i), i); -- order_id
insert into data_i values (0, 4, i, i); -- customer_id
let c = "Order desc" || i || "_" || j; -- order_desc
insert into data_s values (0, 5, i, c);
let cost = i * 1.0;
insert into data_dc values (0, 6, i, cost); -- order_cost
let dt = today - (i / 100);
insert into data_dt values (0, 7, i, dt); -- order_date
if (mod (i,2) = 0) then
insert into data_c values (0, 8, i, "Y");
else
insert into data_c values (0, 8, i, "N");
end if
end for
end for
end procedure;

execute procedure ins_cust (100000);

execute procedure ins_orders(1000000, 100000);


create index is1 on data_s (id_p);
create index is2 on data_s (id_s);

create index ii1 on data_i (id_p);
create index ii2 on data_i (id_s);

create index idc1 on data_dc (id_p);
create index idc2 on data_dc (id_s);

create index idt1 on data_dt (id_p);
create index idt2 on data_dt (id_s);

update statistics;

select customer_id, customer_desc , sum(order_cost) from vcustomers, vorders
where vcustomers.customer_id = vorders.customer_id
and order_flag = "Y"
and order_date between "01/01/2004" and "12/31/2004"
group by 1, 2
...
Рейтинг: 0 / 0
14.01.2005, 23:56
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32866137
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
vybegalloА если
Код: plaintext
1.
2.
3.
4.
5.
create view vcustomers as
select a.data as customer_id, b.data as customer_desc
from data_i a, data_s b
where a.id_p = b.id_p
and a.id_s =  1 
and b.id_s =  2
И построить вместо
Код: plaintext
1.
create index is1 on data_s (id_p);
create index is2 on data_s (id_s)
как один индекс для IOT(правильно ? бишь кластерный) по (id_p, id_s) для всех таблиц свойств ?
А также для таблицы data_dt не забыть проиндексировать еще и по полю Data, если конечно не выбирается практически весь диапазон.
Кстати, а какой смысл поля serial в данном контексте ?
Проверил бы сам, но под рукой только MSSQL, а переводить лениво :)
...
Рейтинг: 0 / 0
15.01.2005, 08:08
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32866149
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
ChA vybegalloА если
Код: plaintext
1.
2.
3.
4.
5.
create view vcustomers as
select a.data as customer_id, b.data as customer_desc
from data_i a, data_s b
where a.id_p = b.id_p
and a.id_s =  1 
and b.id_s =  2
И построить вместо
Код: plaintext
1.
create index is1 on data_s (id_p);
create index is2 on data_s (id_s)
как один индекс для IOT(правильно ? бишь кластерный) по (id_p, id_s) для всех таблиц свойств ?
А также для таблицы data_dt не забыть проиндексировать еще и по полю Data, если конечно не выбирается практически весь диапазон.
Кстати, а какой смысл поля serial в данном контексте ?
Проверил бы сам, но под рукой только MSSQL, а переводить лениво :)

Да я еще поиграюсь в понедельник с индексами. Запустил update statistics high, так он мне новый план построил - на 1 час 4 минуты :-)
Проиндексировать по дате есть смысл, но если прикинуть всю систему в целом, скажем, 100 таблиц, и все сливают свои даты в одну таблицу...
view так же переделал, но тестировать уже не было времени - уж больно я задачу упростил этими id_s = 3 :-) вместо where id_s in (select ... from attr ...).
Короче, нашим юным пионерам есть о чем задуматься в плане производительности.

Я, кстати, не хочу сказать, что такая схема всегда и обязательно зло. Скажем, кто-то на форуме постил задачу - требуется учесть атрибуты товаров, причем товаров много, и атрибуты у них разнообразные. Ну не заводить же 1000 таблиц для каждого товара отдельно ? Имеет смысл атрибуты слить в одну таблицу. Но при этом надо ясно понимать и отдавать себе отчет в том, какой геморрой в плане запросов и производительности тебе предстоит - а не эти вот заявления "думаю, падение производительности будет неощутимым". Ты, блин, не думай - ты попробуй !
...
Рейтинг: 0 / 0
15.01.2005, 09:04
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32866452
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
Кстати, продолжая тему, кластерным, пожалуй, лучше делать не (id_p, id_s), а (id_s, id_p), тогда свойства с одним номером будут рядом.
vybegalloview так же переделал, но тестировать уже не было времени - уж больно я задачу упростил этими id_s = 3 :-) вместо where id_s in (select ... from attr ...)Не совсем, дело в том, что в подобных схемах используется автогенерация запросов или view, когда в них сразу подставляется номера свойств. Их описание никого из пользователей не интересует. Что-то вроде упомянутого выше
Код: plaintext
1.
2.
3.
4.
5.
create view vcustomers
as select
a.data as customer_id,
b.data as customer_desc
from data_i a, data_s b
where a.id_p = b.id_p and a.id_s =  1  and b.id_s =  2
То что производительность падает, никаких сомнений, хотя при определенном тьюнинге не так разительно. В общем, надо очень дружить с оптимизатором :)Разумеется, если заменить таблицу с сотней полей на слияние сотни таблиц, то тут и к бабке не ходить :) Но в реальности объектов с сотнями полей бывает не так уж много, обычно подобно Вашему примеру. В таких случаях применяется еще один способ оптимизации, когда свойства из одной и той же таблицы можно получать одним проходом путем группировки. Что-то типа
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
create view vorders as
SELECT order_id, customer_id
FROM (
  SELECT id_p
  , MAX(CASE id_s WHEN  3  THEN a.data END) as order_id
  , MAX(CASE id_s WHEN  4  THEN a.data END) as customer_id
  FROM data_i
  GROUP BY id_p
)  a, data_dc d, data_dt e, data_c f
where d.id_p = a.id_p
and e.id_p = a.id_p
and f.id_p = a.id_p
and d.id_s =  6 
and e.id_s =  7 
and f.id_s =  8 ;
Самая большая проблема при реализации подобных схем, это то, что в лоб там делать ничего нельзя, хоронить будут на бис... :) И сложность запросов чаще всего превышает условно стандартную, подчас сильно, а это минус, особенно для неопытных разработчиков, которым видится революция. Она же их и похоронит как героев :) Хотя, есть конечно и определенные плюсы, но это лучше под пиво... :)
...
Рейтинг: 0 / 0
15.01.2005, 18:45
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32869604
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
guest_20040621
> Т.е. придется каждому обходиться "встроенной" в голову логикой, знанием предметной области, и умнием проводить
> декомпозицию.

Н-да, действительно сложновато получается. :(

> Возможно спасла бы положение единая общедоступная библиотека примитивов / субмоделей / моделей, (не алгоритмы и
> правила а "правильные" образцы) но сейчас это даже более несбыточно, чем голубая/розовая мечта :)

Хорошая мысль про библиотеку примитивов.

> Как бы вы описали эти локализованные значения?

Так "в лоб" и описал бы. Структура метаинформации к сожалению будет зависеть от способа локализации. Т. е. если выбрать вариант с одной таблицей и множеством полей для разных языков, получится что-то вроде:

system_language;
model_object;
model_object_attribute;
...
rel_object;
...
model_object_attribute_internationalisation;
...
rel_system_language;
rel_object_attribute;
...

Если локализация со связанной таблицей, то будут, соответственно, источник, локализуемое поле, приемник, локализующее поле.

Если честно, я не дошел еще до описания локализации, так что набросал на скорую руку.

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

По поводу многоязычности я спросил потому, что (по моему опыту) есть на самом деле немного задач, где она нужна в полном объеме.
Опять-же, как пример, могу привести единую коммерческую систему (БД), имеющую он-лайн клиентов в России, СНГ, Ю.Азии, З.Азии, З.Европе, В.Европе с головным офисом в Москве. Здесь "многоязычность" реализована русско-(для СНГ) и англо-язычными интерфейсами и двуязычными справочниками. В ходе разработки и поддержки системы никто не смог придумать веских агрументов для перевода данных и GUI на итальянский, венгерский, польский, турецкий, вьетнамский, казахский... языки. Всех вполне устроили русский и английский!
Навскидку могу "придумать", что полная многоязычность может понадобиться в международных образовательных проектах вроде библиотек, справочных БД, "баз знаний" и т.д. Там разработчикам придется делать абсолютно равноценную реализацию всех языков и тогда возникнет проблема алфавитной сортировки по множеству языков, которую корректно можно будет решить только на распределенных БД - на каждом сервере БД свой национальный collation и своя часть данных системы на национальном языке.
...
Рейтинг: 0 / 0
18.01.2005, 11:35
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32870016
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Не поделитесь хотя-бы в общих словах

Что-то типа маленькой информационной системки "на каждый день". ;)

> По поводу многоязычности я спросил потому, что (по моему опыту) есть на самом
> деле немного задач, где она нужна в полном объеме.

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

> Здесь "многоязычность" реализована русско-(для СНГ) и англо-язычными
> интерфейсами и двуязычными справочниками.

Я сталкивался с таким подходом.

> Всех вполне устроили русский и английский!

Пример из жизни: [национальные] информационные агентства. Основная лента новостей - естественно, на родном языке. _Часть_ дублируется на английском. А нужны все сообщения. Вариант реализации: регистрируем все сообщения, переводим на нужный язык - частично. Дешевле потому как. Но - ничего из потенциально значимого не теряем.

> полная многоязычность может понадобиться в международных образовательных
> проектах вроде библиотек, справочных БД, "баз знаний" и т.д.

Здесь будет важен интерфейс. Базу знаний принципиально не сделать полноценно многоязычной.

> возникнет проблема алфавитной сортировки по множеству языков,

Не думаю.

> которую корректно можно будет решить только на распределенных БД - на
> каждом сервере БД свой национальный collation и своя часть данных системы
> на национальном языке.

Хм... в общем случае - не согласен. Как один из возможных вариантов - возражений нет.
...
Рейтинг: 0 / 0
18.01.2005, 13:33
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32870429
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
> Что-то типа маленькой информационной системки "на каждый день". ;)
А, это Вы, Штирлиц! :)

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

На счет громоздкости и нетривиальности - позвольте не согласиться!
С О-надстройкой могут быть довольно простые варианты решения и с несинхронным переводом тоже.
...
Рейтинг: 0 / 0
18.01.2005, 15:39
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32870887
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> На счет громоздкости и нетривиальности - позвольте не согласиться!
> С О-надстройкой могут быть довольно простые варианты решения и с
> несинхронным переводом тоже.

Теоретически. А реально структура данных и без того получилась достаточно сложной. К тому же полноценная локализация - не главная задача в данном случае. Т. е. что-то будет переводиться, но без лингвистических изысков.
...
Рейтинг: 0 / 0
18.01.2005, 18:06
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32871137
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
Очередные результаты тестирования.
Ничего утешительного для любителей простых схем и сложных запросов :
real 50m53.88s
user 0m0.05s
sys 0m0.07s

Самое пикантное, что SELECT остался прежним, только вместо реальных таблиц приходится использовать вьюхи. Поскольку сложность написания запросов "влоб", без view, зашкаливает за пределы разумного. Стоило ли огород городить ?


Изменения, внесенные в схему :
1. create view vcustomers as
select a.data as customer_id, b.data as customer_desc
from data_i a, data_s b
where a.id_p = b.id_p
and a.id_s = 1 --in (select id from attr where value = "customer_id")
and b.id_s = 2; --in (select id from attr where value = "customer_desc");

create view vorders_ip (id_p, order_id, customer_id) as
SELECT id_p
,MAX(CASE id_s WHEN 3 THEN data END)
,MAX(CASE id_s WHEN 4 THEN data END)
FROM data_i
GROUP BY id_p;

create view vorders as
select
v.order_id,
v.customer_id,
d.data as order_cost,
e.data as order_date,
f.data as order_flag
from vorders_ip v, data_dc d, data_dt e, data_c f
where d.id_p = v.id_p
and e.id_p = v.id_p
and f.id_p = v.id_p
and d.id_s = 6
and e.id_s = 7
and f.id_s = 8;

3.
create index is1 on data_s (id_p, id_s);
create index is2 on data_s (id_s, id_p);

create index ii1 on data_i (id_p, id_s);
create index ii2 on data_i (id_s, id_p);

create index idc1 on data_dc (id_p, id_s);
create index idc2 on data_dc (id_s, id_p);

create index idt1 on data_dt (id_p, id_s);
create index idt2 on data_dt (id_s, id_p);
...
Рейтинг: 0 / 0
18.01.2005, 21:36
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32871190
Фотография andrushok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrushok
Участник
Приветик Всем,
я наверно уже поздно встрял, тут такого наворотили... Извиняйте, коли что не то. Прочитал первые 2, 3 части внимательно, остальное между строк - несколько утомительно однако.

Ну вот, что есть сказать.
1) Идея, достойная внимания
2) Надстройками проблему не решить - нужна ПЛАТФОРМА (см маркисзм-ленинизм).
3) Кой-каки платформы уже имеются (Berkeley DB например). Пока все сыро и неэффективно.

Тольки в конце про XML стали упоминать - идея здравая, опять таки струмент еще не доведен до ума.

Так, что для любителей можно взять хоть туже Berkeley DB (библиотеки) и свою собственную DB забацать (я уже имел некий опыт по собственному базоконструированию - нужна была шустрая база в которая в основное время используется как read-only, а данные ежедневно грузятся скрипитами на back-end).

К слову, всяки решения "на коленке" типа метаданных (на мой взгляд, не бейте) становятся нееффективны, если число записей велико (10^6-10^7). Для интернет магазина потянет, для более сложных задач может помереть.
...
Рейтинг: 0 / 0
18.01.2005, 23:19
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32871275
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Ставлю вопрос ребром!
Торговая интернет-компания.
Разные виды товаров. Услуги.
До сегодняшнего дня торговала только оргтехнику. Мониторы, факсы...
Как представляеете базу для нее?

Теперь эта компания стала продавать еще и ковры, микросхемы, мебель...
Как теперь представляеете базу для нее?

Сколько времени портебуется на разработку базы без описания?
Сколько клиентов потеряет фирма пока не готово ПО?
...
Рейтинг: 0 / 0
19.01.2005, 04:36
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32871276
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Вижу решение в следующей связке:
метаописания + надстройка над РБД + генераторы интерфейса.

Можно это называть Плаформой - суть не меняется.
...
Рейтинг: 0 / 0
19.01.2005, 04:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32871291
Фотография andrushok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrushok
Участник
Уважаемый дисковый Вы наш,
Интернет магазин, даже самый навороченый, задачка плевая (по отживанию ресурсов). С етим и простые базы справляются неплохо. Ну, от методанных, конечно никуды не уйдешь - но это лишь просто метод решения данной задачи. Прототип интернет магазина я и на XML DB видал.
А мне хромосому надоть в базу запихнуть - она сама на 2GB баз тянет. Да и описание сегментов (features - для понимающих) не много не мало 300 тышь. Ну и иде с метаданными развернуться? Все умре не родившись. Так что платформа нужна хорошая позарез. А всяки трюки мы уж придумать смогем.
...
Рейтинг: 0 / 0
19.01.2005, 06:26
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32871485
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
2 andrushok.
Есть идеи по раелизации?
Или это болтовня на тему "у кого задача круче"?

При постоянной структуре данных расположение данных жестко фиксируется. Как поля в обычных таблицах.
Но чтобы понять, что где лежит, нужно иметь информацию о сруктуре.
Заголовок в dbf таблице - тоже метаданные.
Иначе как понять какие данные где?

Можете хранить все в XML.
Да хоть в текстовом файле...
Самое производительное решение - 300 полей в одной таблице и каждое, проиндексировано.
...
Рейтинг: 0 / 0
19.01.2005, 09:35
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32871909
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Как один из разработчиков крупнейшего интернет-магазина в России могу только посмеяться над последними двумя высказываниями.

Тока дальше не продолжайте - помру со смеху, а за это иск вам вчиню

-- Tygra's --
...
Рейтинг: 0 / 0
19.01.2005, 12:01
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32871988
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Точнее, предпоследними двумя.

-- Tygra's --
...
Рейтинг: 0 / 0
19.01.2005, 12:16
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32872171
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Что-то перечитал посты - не смешно стало. Звиняйте, если что.

Но есть вопросы:
авторСтавлю вопрос ребром!
Торговая интернет-компания.
Разные виды товаров. Услуги.
До сегодняшнего дня торговала только оргтехнику. Мониторы, факсы...
Как представляеете базу для нее?

Теперь эта компания стала продавать еще и ковры, микросхемы, мебель...
Как теперь представляеете базу для нее?

Сколько времени портебуется на разработку базы без описания?
Сколько клиентов потеряет фирма пока не готово ПО?
Это вопрос к кому или чему собственно? К ОО или Р? И почему интернет-компания?
Ну и ответ некоторый (для РСУБД): если софт для компании разрабатывался не тупыми уродами, то база останется та же - добавятся типы товаров и структура их описания. Все. На доработку уйдет время в днях.

andrushokИнтернет магазин, даже самый навороченый, задачка плевая
Вы видели действительно "навороченные" интернет-магазины? Что-то не верится.
авторС етим и простые базы справляются неплохо
Мне кажется, именно они и должны с этим справляться, это точно ИХ место.


-- Tygra's --
...
Рейтинг: 0 / 0
19.01.2005, 12:55
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32872988
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
2 -- Tygra's --

Покажите Вашу БД.
Хотя бы только мне.
...
Рейтинг: 0 / 0
19.01.2005, 17:04
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32873125
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
Вот мне интересно - зачем в этом топике люди пишут посты вроде "все, что тут обсуждается - это неправильно!" ???
Раз уж кто-то задал вопрос, раз на него есть куча ответов по делу (были приведены ссылки на готовые работающие продукты) - значит, как минимум, это кому-то интересно, и кому-то нужно по-делу!
Если Вы считаете, что сама тема неправильная - перейдите в другие топики, а зачем тут флудить-то?!
Ну предоставьте нам, "извращенцам от SQL", свободу общаться и заблуждаться так, как нам этого хочется :) а глубину вашего опыта и познаний демонстрируйте в других топиках.
Рассказывайте страждущим как организовать учет бракованного товара, или сделать правильный индекс...
Возможно время придет - и мы у вас тоже про индексы спросим - с почтением и глубоким уважением выслушаем! Только в других топиках!

Естественно, такие системы, которые тут обсуждаются, в общем случае ХУЖЕ по производительности, чем традиционные реляционные, и наверняка у них есть и другие минусы...
Только нам интересно обсудить не их минусы, а их плюсы! Какие можно получить преимущества с таким подходом к проектированию и разработке инфосистемы!

P.S. (сорри за эмоции)
P.P.S. "не приумножай сущности сверх необходимости"
...
Рейтинг: 0 / 0
19.01.2005, 17:57
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32873139
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
vybegallo"А какой системы у Вас машинка ?" "Кин-дза-дза" :)
Как уже говорилось, облом переводить приведенный Вами пример. Похожий пример из рабочей системы на MSSQL 2000 с попыткой адаптации
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
CREATE TABLE AAP ([ID] int PRIMARY KEY, [Code] varchar( 255 ) UNIQUE, [Description] varchar( 7500 ))
INSERT INTO AAP ([ID], [Code], [Description])
SELECT [ID], [Code], [Description] FROM MMK2004.dbo.[AAP.Collection]

SELECT [ID], [Code], [Description] FROM AAP 
-- Table 'AAP'. Scan count 1, logical reads 47, physical reads 0, read-ahead reads 0.
-- 
-- SQL Server Execution Times:
--    CPU time = 15 ms,  elapsed time = 86 ms.
SELECT [ID], [Code], [Description] FROM MMK2004.dbo.[AAP.Collection]
-- Table 'NoteA'. Scan count 1, logical reads 46, physical reads 0, read-ahead reads 0.
-- Table 'Object'. Scan count 1, logical reads 24, physical reads 0, read-ahead reads 0.
-- Table 'StringA'. Scan count 1, logical reads 35, physical reads 0, read-ahead reads 0.
-- 
-- SQL Server Execution Times:
--    CPU time = 32 ms,  elapsed time = 81 ms.


CREATE TABLE Prov ([ID] int PRIMARY KEY, [DebetID] int, [SumDef] decimal( 28 ,  10 ), [Description] varchar( 7500 ))
INSERT INTO Prov
SELECT [ID], [DebetID], [SumDef], [Description] FROM MMK2004.dbo.[JHProv.Collection]

SELECT * FROM Prov
-- Table 'Prov'. Scan count 1, logical reads 149, physical reads 0, read-ahead reads 0.
-- 
-- SQL Server Execution Times:
--    CPU time = 62 ms,  elapsed time = 465 ms.
SELECT a.ObjectID AS [ID], a.[Data] AS [DebetID], s.[Data] AS [SumDef], d.Data AS [Description]
FROM MMK2004.dbo.[JHProv.DebetID] a
INNER MERGE JOIN MMK2004.dbo.[JHProv.SumDef] s ON (s.[ObjectID] = a.[ObjectID])
LEFT MERGE JOIN MMK2004.dbo.[JHProv.Description] d ON (d.[ObjectID] = a.[ObjectID])
-- Table 'NoteA'. Scan count 1, logical reads 58, physical reads 0, read-ahead reads 0.
-- Table 'Numbers'. Scan count 1, logical reads 148, physical reads 0, read-ahead reads 0.
-- Table 'Reference'. Scan count 1, logical reads 106, physical reads 0, read-ahead reads 0.
-- 
-- SQL Server Execution Times:
--    CPU time = 188 ms,  elapsed time = 465 ms.

CREATE VIEW [AAP.Sums1] AS
SELECT
DebetID
, SUM([SumDef]) AS [Sum]
, (SELECT [Description] FROM [AAP] a WHERE a.[ID] = DebetID) AS [Description]
FROM [Prov]
GROUP BY DebetID
GO

CREATE VIEW [AAP.Sums2] AS
SELECT
a.[Data] AS DebetID
, SUM(s.Data) AS [Sum]
, (SELECT [Data] FROM MMK2004.dbo.[AAP.Description] d WHERE d.[ObjectID] = a.[Data]) AS [Description]
FROM MMK2004.dbo.[JHProv.DebetID] a
INNER MERGE JOIN MMK2004.dbo.[JHProv.SumDef] s ON (s.[ObjectID] = a.[ObjectID])
GROUP BY a.[Data]
GO


SELECT * FROM [AAP.Sums1]
-- Table 'AAP'. Scan count 1, logical reads 47, physical reads 0, read-ahead reads 0.
-- Table 'Prov'. Scan count 1, logical reads 149, physical reads 0, read-ahead reads 0.
-- 
-- SQL Server Execution Times:
--    CPU time = 109 ms,  elapsed time = 145 ms.
SELECT * FROM [AAP.Sums2]
-- Table 'NoteA'. Scan count 1, logical reads 46, physical reads 0, read-ahead reads 0.
-- Table 'Numbers'. Scan count 1, logical reads 148, physical reads 0, read-ahead reads 0.
-- Table 'Reference'. Scan count 1, logical reads 106, physical reads 0, read-ahead reads 0.
-- 
-- SQL Server Execution Times:
--    CPU time = 235 ms,  elapsed time = 266 ms.
GO

DROP TABLE AAP
DROP TABLE Prov
Надеюсь, что в этой "каше" некоторые темы узнаваемы. Собственно к вопросу, что не все так страшно :)
AAP - 6989 строк
Prov - 33646 строк
Естественно, самый упрощенный вариант, порядка предложенного примера. Цифры статистики, естественно, могут гулять, где-то в пределах 1%, данные, понятно, в кэше.
...
Рейтинг: 0 / 0
19.01.2005, 18:01
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32873189
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
авторЕстественно, такие системы, которые тут обсуждаются, в общем случае ХУЖЕ по производительности, чем традиционные реляционные, и наверняка у них есть и другие минусы...
Только нам интересно обсудить не их минусы, а их плюсы! Какие можно получить преимущества с таким подходом к проектированию и разработке инфосистемы!
Ну тогда уж нужно наверное сначала сложить все минусы :) и посмотреть: а не слишком ли их много и найдется ли столько плюсов, чтобы перевесить минусы?

ЗЫ Никого не хотел обидеть, не пытался наехть, ничего такого, просто эмоции в связи с тем, что всевозможные ОО "над" и "в" БД в последний месяц обсуждаются чуть ли не в каждом топике. Однако многовато, кажется, особенно в разрезе того, что популярность и возможности не слишком высоки.
Прям какое-то наступление ОО на БД :))

-- Tygra's --
...
Рейтинг: 0 / 0
19.01.2005, 18:20
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32873238
Фотография andrushok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrushok
Участник
Уважаемый дисковый, можно уточнить пожалуйста.
Идеи реализации чего? Интернет-магазина? Нет идей, не занимаюсь сим. Молекулярной лабуды? Куча идей, но пока мало что работает. Через метаданные и Oracle, и MsSQL пока тормозят, а XML DB не тянет вовсе. Работает пока тольки собраная на коленке собственная база по принципу - всем пользователем доступ read-only, а данные грузятся с back-end. На cron скрипт висит, который качает данные, парсит и грузит в базу, при этом базы реально 2 - рабочая и вспомогательная. Соответсвенно скрипт грузит данные во впомогательную, а пользователи видят только рабочую. Когда загрузка закончена - вспомогательная становится активной (пользователи начинают работать с ней) и в это же время данные из нее начинают копироваться в рабочую. Когда копирование закончено, все возращается назад, можно опять начинать грузить данные. Вот таки танцы с бубнами.
У кого задача круче - спор дурацкий, поддерживать его я не хотел, если что не так понятно было - извиняйте. Кажный имеет то, что имеет, однако.

Уважаемый полосатый, самый крутой интернет-магазинщик по совместительству Вы наш. Не хотел Вас обидеть. Ето мое мнение. Вы с ним не согласны - нет проблем. Можете считать, что интернет-магазин - самая крутая задачка да базаразработчиков. Я переубеждать Вас не буду. Крутые интернет магазины я видел и даже ими пользовался (amazon, например, или fingehut). Что там в потрахах - не знаю, не мой профиль. Программисты, они ребята такие - с любой простой задачкой такого понаворотят, век расхлебывать бушь...
Ну а насчет посмеятся - давайте вместе. Так даже веселее. Объясние, только, что тут такого смешного - повеселимся от души...
...
Рейтинг: 0 / 0
19.01.2005, 18:36
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32873254
Фотография andrushok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrushok
Участник
2 тигра
По поводу OOБД - я согласен, у них щас больше минусов чем плюсов. Время их еще не пришло. Скоро ли придет? - не знаю. Потребность в них есть? - разумеется. Для интернет магазина приемлемо? - не мне решать, наверно Вам...
...
Рейтинг: 0 / 0
19.01.2005, 18:44
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32873355
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
ChA vybegallo"А какой системы у Вас машинка ?" "Кин-дза-дза" :)
Как уже говорилось, облом переводить приведенный Вами пример. Похожий пример из рабочей системы на MSSQL 2000 с попыткой адаптации
Надеюсь, что в этой "каше" некоторые темы узнаваемы. Собственно к вопросу, что не все так страшно :)
AAP - 6989 строк
Prov - 33646 строк
Естественно, самый упрощенный вариант, порядка предложенного примера. Цифры статистики, естественно, могут гулять, где-то в пределах 1%, данные, понятно, в кэше.

Вы что сказать-то хотели, уважаемый ChA ? Что при 7000 записях в одной таблице и 34000 в другой, с минимумом JOIN и когда все данные уже в памяти - работать будет быстро? Не возражаю.
...
Рейтинг: 0 / 0
19.01.2005, 19:55
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32873392
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
vybegalloВы что сказать-то хотелиСтало интересно, что это за СУБД, по таким индексам и так медленно сливать :) Видно все-таки придется Ваш пример эмулировать на MS SQL :(
vybegalloпри 7000 записях в одной таблице и 34000 в другой, с минимумом JOIN и когда все данные уже в памяти - работать будет быстро?
Это в результирующих, классических, можно сказать, таблицах плана счетов и проводок. В самой БД реально так (упоминаемые в скрипте)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Таблица    Строк

Object       598 053
Reference   876 646
StringA      301 483
NoteA        298 425
Numbers     1 111 414

Вытащил данные по классу "Счет Плана Счетов" и "Проводка Журнала операций" по весьма солидной фирме за год. Для каждого класса и свойства есть свои автогенерированные view, по скрипту видно их использование. Сливаются только те данные, которые нужны для отчета, не имеет смысла сливать полные множества атрибутов. Например, итоги по корреспонденции счетов всего в 3-4 раза медленнее(запросы не приведены), чем это делалось бы классическим путем. В большинстве случаев на практике большая часть БД и так находится в памяти. Хотя у одного из клиентов таких баз на одном сервере больше 10 одновременно используемых и, в основном, при обычной работе никто не ощущает торможений. Резюм: схема вполне работоспособная, но для определенного вида задач. Собственно все... :)
...
Рейтинг: 0 / 0
19.01.2005, 20:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32873449
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
ChA vybegalloВы что сказать-то хотелиСтало интересно, что это за СУБД, по таким индексам и так медленно сливать :) Видно все-таки придется Ваш пример эмулировать на MS SQL :(
Просим, просим !
Приведенные результаты были получены на Informix 9.21 на Сан боксе Solaris 8, 2 CPU 336MHz
Я даже ради такого дела у себя на лаптопе вдобавок к DB2 и MS SQL еще и Informix поставлю, устроим сравнение яблок с яблоками.

ChA Резюм: схема вполне работоспособная, но для определенного вида задач. Собственно все... :)
Согласен.
...
Рейтинг: 0 / 0
19.01.2005, 22:10
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32873460
PArth
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PArth
Гость
andrushok2 тигра
По поводу OOБД - я согласен, у них щас больше минусов чем плюсов. Время их еще не пришло. Скоро ли придет? - не знаю. Потребность в них есть? - разумеется. Для интернет магазина приемлемо? - не мне решать, наверно Вам...

Дежавю какое-то... Не поленился, раскопал в архиве свой дипломный проект: "Преимущества применения реляционных баз данных для решения задач ..." 1986 год. Цитаты из одной из рецензий - "... реляционные базы данных имеют исключительно академический интерес ... подобные алгоритмы обработки ... использовать проверенные временем системы баз данных, например ADABAS" (выделение мое...)
Кто нибудь еще помнит, что такое ADABAS? Ну и не надо Вам этого...
...
Рейтинг: 0 / 0
19.01.2005, 22:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32873568
Фотография andrushok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrushok
Участник
Пенсильванский Вы наш rth ( PA rth),
Я вот в школе вот алгол проходил, кто нить можа помнит, а? Какой года - да так, конец 70-х. С еще толклом небыло, не то что С++. Перфокарты долбили. Ну и что - а ничего, судьба такой.
...
Рейтинг: 0 / 0
20.01.2005, 05:57
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32874143
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
andrushokУважаемый полосатый, самый крутой интернет-магазинщик по совместительству Вы наш. Не хотел Вас обидеть. Ето мое мнение. Вы с ним не согласны - нет проблем. Можете считать, что интернет-магазин - самая крутая задачка да базаразработчиков. Я переубеждать Вас не буду
То, что самый крутой интернет-магазинщик - спасиба
Ну, не самый, но опыта дофига имеется.
Да не самая крутая задачка - я так не говорил. Но хороший магазин сделать - это нужно очень попотеть. Магазин в полном объеме - и веб и бэк.
авторКрутые интернет магазины я видел и даже ими пользовался (amazon, например, или fingehut). Что там в потрахах - не знаю, не мой профиль.
Воит я и говорю - пользоваться это одно, мне тоже нравится :)
А вот внутри.... Я вот знаю, чего там. Эхххх, много чего.
авторПрограммисты, они ребята такие - с любой простой задачкой такого понаворотят, век расхлебывать бушь...
Вот если бы еще наоборот: со сложной просто было бы :))
авторНу а насчет посмеятся - давайте вместе. Так даже веселее. Объясние, только, что тут такого смешного - повеселимся от души...
Да не, ничего, я уж извинился, видать магнитные бури на голову повлияли вчера. :)

авторПо поводу OOБД - я согласен, у них щас больше минусов чем плюсов. Время их еще не пришло. Скоро ли придет? - не знаю. Потребность в них есть? - разумеется. Для интернет магазина приемлемо? - не мне решать, наверно Вам...
Ну в силу очень большой разницы между ОО и Р и специфики, пока что не вижу замены РСУБД конкретно в интернет-магазинах.

-- Tygra's --
...
Рейтинг: 0 / 0
20.01.2005, 11:36
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32874829
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Rovdo
Гость
andrushok... А мне хромосому надоть в базу запихнуть - она сама на 2GB баз тянет. Да и описание сегментов (features - для понимающих) не много не мало 300 тышь. Ну и иде с метаданными развернуться? Все умре не родившись. Так что платформа нужна хорошая позарез. А всяки трюки мы уж придумать смогем.

А я вот, наблюдая за течением дискуссии, все тверже увериваюсь в том, что реляционные СУБД не являются подходящим выбором для платформы, на базе которой предлагается строить решение. Т.е. объектная надстройка над реляционной СУБД в данном случае мне видится излишним (и значительным) усложнением задачи. Меня уже несколько убедили в том, что сами по себе объектные СУБД или типовые средства объектно-реляционного отображения не могут рассматриваться как готовое решение, но судя по всему именно их следовало брать за основу, поскольку решение рассматриваемой задачи в этом случае найти гораздо легче (ИМХО).

А касаемо биологических проблем, то здесь еще более осмыслено применение именно ООСУБД, которые как раз и создавались для подобных целей. К примеру, СУБД Versant находят широкое применение в биоинформатике и позволяют нормально работать с таки объектами, как хромосомы и т.п.
...
Рейтинг: 0 / 0
20.01.2005, 14:28
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32874851
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> наблюдая за течением дискуссии, все тверже увериваюсь в том, что
> реляционные СУБД не являются подходящим выбором для платформы, на базе
> которой предлагается строить решение.

Поясните, пожалуйста, что Вы имели в виду под этим набором букв?

Hint: флеймить или продавать кривые поделки - есть другие разделы форума.
...
Рейтинг: 0 / 0
20.01.2005, 14:34
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32874951
Alexey Sh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Sh
Участник
2 PArth : Ну я помню ADABAS образца 1986 года. Нарушал он первую НФ нещадно периодическими группами и множественными полями.
...
Рейтинг: 0 / 0
20.01.2005, 14:57
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32875804
Фотография andrushok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrushok
Участник
2 Самый крутой интергет-магазиншик
Ну магнитные бури усех иногда задевают, нет проблем. Я думаю, что для интернет-магазинов как раз OOБД и не нужно. Свойств у товара не так много (я имею ввиду свойств, по которым необходим поиск и они дожны быть индксированны) ну не больше сотни (и то наверно перегнул). Так что даже решения "в лоб", типа KEY -> VALUE пары (VALUE может быть значение, а может и объект, реально в таблице храняться различные VALUE: VALUE_INT, VALUE_DOUBLE, VALUE_STR, VALUE_DATE, VALUE_ID - в случае объекта) вполне решают проблему. Это не оптимально, но приемлемо. Но при сложной и ветвистой (а главное развесистой) струтуре релеационная база мрет.

2 Alexey Rovdo
А что за штука така Versant? Я погуглю, конечна - но так Ваши впечатления.

Уважаемый гость 20 MB +/- 5%
Если вы считаете, что надстройки достаточно (неуважение к марксизму-ленинизму, однако - радуйтесь, що щас 2005 а не 1937, хотя усе равно добраться до Вас сложно - под странными кликухами спряталися!) - то милости просим. Пожалте, объясните круг задач, где это быть может реализовано. Ну не совсем точно - где это будет _выгодно_ реализовать. Судя по моему скромному опыту - эта такая сфера, где объекты оч. сложные - но их немного. Единсвенное, что мне пришло в голову - генеалогическое древо. Оно может уйти на много поколений, но самих их много не надо - максимум на себя и близких друзей (родственники само собой в древо "на себя, любимого" лягуть). Так что вперед - найдите таких любителей и впаривайте им таку разработку.
...
Рейтинг: 0 / 0
20.01.2005, 19:37
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32875824
PArth
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PArth
Гость
Alexey Sh2 PArth : Ну я помню ADABAS образца 1986 года. Нарушал он первую НФ нещадно периодическими группами и множественными полями.

Помните - и слава Богу! Я ж не про ADABAS... А про то, что рецензия на мой диплом была жутко отрицательная, можно сказать разгромная в пользу этих самых "периодических групп и множественных полей" ... Похожая ситуация сейчас у многих в головах и по поводу OODB. (К сожалению...)
...
Рейтинг: 0 / 0
20.01.2005, 20:07
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32875842
Alexey Sh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Sh
Участник
Я не просто так вспомнил про ADABAS. Спросил в своё время у научного руководителя, какая у ADABAS модель данных (иерархическая, сетевая, реляционная (копья ломали тогда по этому поводу) )? Получил короткий ответ: своя модель. Никто и ничто не обязано к чему-либо относиться.

Этот ответ подходит и к данной дискуссии.
...
Рейтинг: 0 / 0
20.01.2005, 20:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32875893
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Пожалте, объясните круг задач, где это быть может реализовано.

Уже. См. выше.

> Ну не совсем точно - где это будет _выгодно_ реализовать.

Ваш критерий выгоды?

> Судя по моему скромному опыту - эта такая сфера, где объекты оч. сложные - но
> их немного.

Выберите 15 минут, прочтите обсуждение хотя бы с середины, - там все очень доступно.
...
Рейтинг: 0 / 0
20.01.2005, 22:00
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32875899
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Никто и ничто не обязано к чему-либо относиться.

Да ну? Очень интересно. А стандарты, значит, пишут идиоты для идиотов же?

> Этот ответ подходит и к данной дискуссии.

Вы не слишком внимательно читаете. Речь-то как раз о том, чтобы _стандартным образом_ описывать структуру данных.
...
Рейтинг: 0 / 0
20.01.2005, 22:06
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32875910
Фотография andrushok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrushok
Участник
Уважаемый 20 мульенов + 40 тыщь с гаком
За 15 минут сие не прочтещь, дай Бог просто пролистать. Полчасика я на это убил вчера - но что-то толком про область применения не въехал. Все кажетси вокруг магазинов - складов - товаров - проводок крутиться. На сей счет я сказал - обычных баз достаточно, не чо огород городить (мое скромное мнение, да и не только мое, и не совсем скромное уже). Может Вы ракеты пускать собралися, али ядреный реактор моделировать - наверно подойдеть (ракет и реакторов по пальцам пересчитать, и все дюже сложные). Вот тольки за ракеты и реакторы плотють либо мало, либо ... сами знаете что.

А обижаться, типа - вот она уже ГОТОВА, бери пользуй, а вы тут усе рылом воротите - не умно. Я много знавал программ, которые уже были готовы, и были никому не нужны. Сам такие писал тоже. Опыт, батенька, опыт. Только дураки учаться на своих ошибках - Бисмарк (с).
...
Рейтинг: 0 / 0
20.01.2005, 22:23
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32875912
Фотография andrushok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrushok
Участник
В догонку
Критерий выгод прост. Разница между "скольки потрачено" и "скольки получено".
Если потрачена 1 копейка, а ничего не получено - это _не_выгодно_.
...
Рейтинг: 0 / 0
20.01.2005, 22:28
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32875929
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Все кажетси вокруг магазинов - складов - товаров - проводок крутиться.

Ничего похожего. Пересказывать лень, если интересно - читайте.

> Я много знавал программ, которые уже были готовы, и были никому не нужны.

Какие программы? Кому не нужны? Речь идет о способе описания структуры данных, _дополнительном_ по отношению к системному. Не хотите - не пользуйтесь, проблем - ни одной.

> Критерий выгод прост. Разница между "скольки потрачено" и "скольки получено".
> Если потрачена 1 копейка, а ничего не получено - это _не_выгодно_.

Понятно. Так вот, я предпочитаю один раз потратить десять рублей и получить эффект в полтора рубля, чтобы потом тратить ноль рублей, а получать те же полтора рубля. Мне моя бухгалтерия больше нравится.
...
Рейтинг: 0 / 0
20.01.2005, 23:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32876379
Alexey Sh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Sh
Участник
2 guest_20040621 :
>да ну? Очень интересно. А стандарты, значит, пишут идиоты для идиотов же?

В каждой шутке есть доля шутки :)
...
Рейтинг: 0 / 0
21.01.2005, 10:29
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32876531
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
2 andrushok
andrushok
2 Alexey Rovdo
А что за штука така Versant? Я погуглю, конечна - но так Ваши впечатления.


Alexey Rovdo этот самый Versant продает, а здесь на форуме его "продвигает".
(- информация к размышлению)
Не могу сказать что это хорошо или плохо. просто наверно кому-то пригодится... :)
...
Рейтинг: 0 / 0
21.01.2005, 11:16
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32877742
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Rovdo
Гость
guest_20040621> наблюдая за течением дискуссии, все тверже увериваюсь в том, что
> реляционные СУБД не являются подходящим выбором для платформы, на базе
> которой предлагается строить решение.

Поясните, пожалуйста, что Вы имели в виду под этим набором букв?

Hint: флеймить или продавать кривые поделки - есть другие разделы форума.

Обсуждаемая задача несомненно может быть решена в том ключе, который вы избрали - в виде некой объектной надстройки над реляционной СУБД (рациональность и быстродействие я не обсуждаю здесь). Выше вы убедили меня в том, что такая надстройка не является всего-лишь средством обеспечения объектно-реляционного отображения (коих существует тьма), а предполагает гораздо большее. Однако наблюдая предложенные решения я считаю, что получить необходимую функциональность было бы легче и быстрее делая надстройку над объектной СУБД или, как вариант, (простите за тавтологию) надстройку над средством объектно-реляционного отображения, работающим с реляционной СУБД. Здесь есть, конечно, и одна важная проблема - это будет легче только тому, кто знаком с ОО-программированием и может выйти за рамки SQL-мышления (не воспринимайте это в свой адрес).

Что же касается Versant, то о чем знаю - то и советую (заметьте, что это было замечание по поводу хранения сложноструктурированных данных в биоинформатике). Да и не нравится - не ешь, чего попусту камни катить, тем более что полно соответствующих топиков, в которых этим заняты все кому не лень!
...
Рейтинг: 0 / 0
21.01.2005, 16:28
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32877781
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Обсуждаемая задача несомненно может быть решена в том ключе, который вы
> избрали - в виде некой объектной надстройки над реляционной СУБД

Объектной - это исключительно условное название. Эта задача может быть решена абсолютно разными способами для разных условий.

> Однако наблюдая предложенные решения я считаю, что получить необходимую
> функциональность было бы легче и быстрее делая надстройку над объектной СУБД

Нет. Не легче и не быстрее. Реляционные базы данных предполагают адекватный математический аппарат, которого нет в объектных СУБД. Это раз. Реляционные базы данных соответствуют (пытаются, декларируют - с разным успехом) стандарту SQL92/99/2003. Объектные СУБД вообще ничему не соответствуют. Нет такого понятия "стандарт" применительно к объектной СУБД. Т. е. решение принципиально нельзя получить в общем виде. Это два.
...
Рейтинг: 0 / 0
21.01.2005, 16:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32877842
PArth
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PArth
Гость
guest_20040621> ... Объектные СУБД вообще ничему не соответствуют. Нет такого понятия "стандарт" применительно к объектной СУБД. Т. е. решение принципиально нельзя получить в общем виде. Это два.

А про ODMG Вы что-нибудь слышали? http://www.odmg.org/
...
Рейтинг: 0 / 0
21.01.2005, 17:02
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32877908
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> А про ODMG Вы что-нибудь слышали? http://www.odmg.org/

Естественно. Если это - стандарт, то я - трамвай.
...
Рейтинг: 0 / 0
21.01.2005, 17:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32877912
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
guest_20040621
Нет. Не легче и не быстрее. Реляционные базы данных предполагают адекватный математический аппарат, которого нет в объектных СУБД. Это раз. Реляционные базы данных соответствуют (пытаются, декларируют - с разным успехом) стандарту SQL92/99/2003. Объектные СУБД вообще ничему не соответствуют. Нет такого понятия "стандарт" применительно к объектной СУБД. Т. е. решение принципиально нельзя получить в общем виде. Это два.

Похоже что (как это ни прискорбно) имеющиеся на рынке реляционные базы, за исключением Оракла-9 (SQL99), соответствуют только стандарту SQL92.
(пример - см. вопросы от @любопытный в ветви форума "Сравнение СУБД")
Возможно в какой-то степени Юкон улучшит эту картину, сответствуя хотя-бы частично стандарту 2003... ?
Но факт остается фактом: РСУБД действительно опираются на семейство общепризнанных стандартов SQL-ХХХ, подкрепленных математической базой. Т.е. нам, конечно, приходится считать стандартом то, что АНСИ официально принимает как "стандарт" для "них", да и не только АНСИ.

Для ООСУБД подобных стандартов, насколько я знаю, нет. То, что упомянул PArth -
"А про ODMG Вы что-нибудь слышали? http://www.odmg.org/"
- как я смог пока разобраться, существует в виде манифеста, набора деклараций, принципов, публикуемых в виде журнальных статей и монографий самих членов ODMG, и нигде (кроме ODMG) не закрепленных так-же официально, как это сделано с SQL-ХХХ (в том-же АНСИ например). Во всяком случае не оформленных ПОКА. Если это не так - прошу (PArth) привести ссылки на опубликованные стандарты.
Из-за этого мы и имеем такую неразбериху и в терминологии, и в понимании принципов ОО (в меньшей степени ОО-программирования и в гораздо болшей - ООСУБД). Кстати ODMG изначально назывались Object Database Management Group а потом, в ходе своей эволюции превратились в Object Data Management Group. Вроде бы мелочь, но показательная!
...
Рейтинг: 0 / 0
21.01.2005, 17:33
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32877929
PArth
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PArth
Гость
Насколько я понимаю, стандарты в области ИС не всегда исходят из АНСИ либо ИСО, не всегда издаются книжками, имеют твердую копию с синей печатью... :-)))
RFC к примеру. И никто TCP/IP, SMTP, ... etc не считает НЕСТАНДАРТНЫМИ протоколами. Более того, ИСО-шные стандарты в данной области потерпели полное фиаско...
...
Рейтинг: 0 / 0
21.01.2005, 17:42
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32877952
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Насколько я понимаю, стандарты в области ИС не всегда исходят из АНСИ либо
> ИСО, не всегда издаются книжками, имеют твердую копию с синей печатью...

Логично.

> RFC к примеру. И никто TCP/IP, SMTP, ... etc не считает НЕСТАНДАРТНЫМИ
> протоколами.

Справедливо. На Ваш взгляд, в чем именно заключается разница между ODMG и W3C?
...
Рейтинг: 0 / 0
21.01.2005, 17:56
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32877962
Фотография andrushok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrushok
Участник
По поводу стандартов - увы. Это так, руководство к действию. Даже С++ не все поддерживают (мелкомягкие тому пример). Судьба такой...
По поводу бухгалтерии - полностью согласен. Я тоже готов потратить 10 руб. и поручать по 1.5 руб. в течении долгого времени. Но предпочитаю хорошо подумать, прежде чем потратить 1 коп и не получить ничего взамен.
По поводу сферы применения. Странное дело получается, гость тьмуший все машет флагом, вот де ЭТО совсем другое - а на конкретный вопрос - ЧТО ЭТО? - послылает и молчит как партизан. Я не поленился, еще посмотрел. Конкретно что ЭТО - не нашел. Может он расколется все-таки, или кто-нить другой подскажеть... Помогите, люди, а?
И кстати - где Versant посмотреть можно. Кто его толкает, мне абсолютно фиолетово. Я тут (а может и рядом) про свои проблемы вещал, так что готов взглянуть, попробовать, если что предложите. Ко всем относится, кстати (включая тьмущих).
...
Рейтинг: 0 / 0
21.01.2005, 17:59
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32877969
PArth
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PArth
Гость
Честно - не знаю, не занимался историей вопроса. Но моя мысль состояла в том, что и "стандарт" SQL-XX родиля тоже не в недрах ANSI, а стандатром де-факто стал намного позднее своего появления на свет. И только благодаря поддержке крупнейших производителей...
...
Рейтинг: 0 / 0
21.01.2005, 18:02
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32878151
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Но моя мысль состояла в том, что и "стандарт" SQL-XX родиля тоже не в недрах
> ANSI,

Не могу сказать, что было раньше 1992 г., но SQL92 - ISO/IEC 9075:1992, Database Language SQL. Последующие - тоже под шапкой ISO/IEC.

> а стандатром де-факто стал намного позднее своего появления на свет. И только
> благодаря поддержке крупнейших производителей...

Хм... некогда рыться в Сети, не могу ничего возразить по существу. Однако, сильно сомневаюсь, что это так.
...
Рейтинг: 0 / 0
21.01.2005, 20:22
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32878157
PArth
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PArth
Гость
andrushok ... И кстати - где Versant посмотреть можно. ...

www.versant.com
...
Рейтинг: 0 / 0
21.01.2005, 20:26
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32878165
PArth
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PArth
Гость
guest_20040621

Не могу сказать, что было раньше 1992 г., но SQL92 - ISO/IEC 9075:1992, Database Language SQL. Последующие - тоже под шапкой ISO/IEC.

> а стандатром де-факто стал намного позднее своего появления на свет. И только
> благодаря поддержке крупнейших производителей...

Хм... некогда рыться в Сети, не могу ничего возразить по существу. Однако, сильно сомневаюсь, что это так.

Извиняюсь, ссылка не на Сеть, а на статью: Astrahan M.M., Chamberlin D.D. [1975] Implementation of a Structured English Query Language.

А ANSI он принят в качестве стандарта в 1986 г. (Если верить Martin Gruber...)
...
Рейтинг: 0 / 0
21.01.2005, 20:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32878211
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Astrahan M.M., Chamberlin D.D. [1975] Implementation of a Structured English Query Language.

Спасибо за информацию.

> А ANSI он принят в качестве стандарта в 1986 г.

Воспользуемся Вашим изложением эволюции стандарта SQL: [первая?] публикация - 1975 год, принятие стандарта - через десять лет, последняя редакция (мне известная) - 2003 год (это к тому, что стандарт развивается). Если ODMG будет двигаться аналогичным образом, то _стандарт_ (не сборник примеров, отдельные статьи или историю успеха) мы увидим в следующем десятилетии. Тогда - если будет повод - можно будет говорить о преимуществах/недостатках концепции, модели, реализации и пр.

Консенсус?
...
Рейтинг: 0 / 0
21.01.2005, 21:39
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32878230
PArth
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PArth
Гость
OK!
...
Рейтинг: 0 / 0
21.01.2005, 22:03
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32878235
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Rovdo
Гость
guest_20040621> Если ODMG будет двигаться аналогичным образом, то _стандарт_ (не сборник примеров, отдельные статьи или историю успеха) мы увидим в следующем десятилетии. Тогда - если будет повод - можно будет говорить о преимуществах/недостатках концепции, модели, реализации и пр.


Привожу ссылочку на небольшой обзор по состоянию стандартизации в области объектных баз данных в 1995г. С тех пор ничего особенно не изменилось.

Кратко излагая суть этой статьи.
Американская государственная организация ANSI в свое время не нашла общего языка с ассоциацией производителей OMG. Поэтому появилось два стандарта - ODMG-93 и SQL3. SQL3 от ANSI как-то не прижился, а вот ODMG-93 поддерживается целым рядом продуктов и называть его "сборником статей" я бы не стал. Да и по поводу стандартов ANSI как нельзя в тему звучит выдержка из этой статьи:
We may see the recurrent phenomenon of vendors running ahead of ANSI committees, which was evident with the Internet protocol -- for example, TCP/IP against ANSI X.25. Eventually, however, it is likely (and desirable) that the two streams of standards, ODMG and SQL3, will influence each other or even merge.

Но, как я понимаю, весь этот разговор о стандартах возник из-за того, что вы предположили, что использование в качестве основы для решения обсуждаемой задачи именно ООСУБД будет означать ориентацию только на какую-то одну систему и использование проприетарных решений. Но это не так. Более того, технологии, имеющиеся на сегодняшний день в ООСУБД и сопутствующих им средствах разработки позволяют создавать действительно независимые от платформы решения, которые могут использовать в качестве оконечных хранилищ данных практически любые СУБД (объектные, реляционные). Вообще ваше мнение о современных объектных системах неправильное по многим пунктам. Я ограничиваюсь здесь только таким комментарием, поскольку считаю, что подробнее писать в этом топике о собственно объектных системах будет не вполне корректным (впрочем, как пожелаете).
...
Рейтинг: 0 / 0
21.01.2005, 22:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32878264
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
vybegalloПросим, просим !
Приведенные результаты были получены на Informix 9.21 на Сан боксе Solaris 8, 2 CPU 336MHz
Ловите :) Ничего лишнего, вроде более-менее адекватный перевод
Итак MSSQL 2000 SP3 на FS PRIMERGY C200, 2*1.26Гц, no parallelism
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
CREATE TABLE customer (
	id int PRIMARY KEY,
	descr varchar( 50 )
)

DECLARE @i int
SET @i =  0 
WHILE @i <  100000  BEGIN
	INSERT INTO customer SELECT @i , 'customer' + STR(@i)
	SET @i = @i +  1 
END

CREATE TABLE [order] (
	id int identity( 1000000 ,  1 ) PRIMARY KEY,
	customer_id int REFERENCES customer (id),
	descr varchar( 50 ),
	cost decimal ( 9 , 2 ),
	[date] datetime,
	flag char( 1 ),
)

SET @i =  0 
WHILE @i <  10  BEGIN
	INSERT INTO [Order] (customer_id, descr, cost, [date], flag)
	SELECT id, 'Order_' + str(id) + '_' + str(@i), id, GETDATE() - (id/ 100 ), (CASE id% 2  WHEN  0  THEN 'Y' ELSE 'N' END)
	FROM [Customer]
	SET @i = @i +  1 
END

select c.id
, c.descr
, sum(cost)
from customer c, [order] o
where c.id = o.customer_id
and flag = 'Y'
and [date] between '20040101' and '20041231'
group by c.id, c.descr
-- Table 'customer'. Scan count 1, logical reads 434, physical reads 0, read-ahead reads 0.
-- Table 'order'. Scan count 1, logical reads 7718, physical reads 0, read-ahead reads 0.
-- 
-- SQL Server Execution Times:
--    CPU time = 1640 ms,  elapsed time = 1768 ms.

CREATE TABLE data_s
(id_p int,
id_s int,
data varchar( 50 ),
PRIMARY KEY(id_p, id_s))

INSERT INTO data_s(id_p, id_s, Data)
SELECT  5 , id, descr
FROM [Order]
INSERT INTO data_s(id_p, id_s, Data)
SELECT  2 , id, descr
FROM [customer]

CREATE TABLE data_i
(id_p int,
id_s int,
data int,
PRIMARY KEY(id_p, id_s))

INSERT INTO data_i(id_p, id_s, Data)
SELECT  3 , id, id
FROM [Order]
INSERT INTO data_i(id_p, id_s, Data)
SELECT  1 , id, id
FROM [customer]
INSERT INTO data_i(id_p, id_s, Data)
SELECT  4 , id, customer_id
FROM [Order]

CREATE TABLE data_dc
(id_p int,
id_s int,
data decimal( 12 , 2 ),
PRIMARY KEY(id_p, id_s))

INSERT INTO data_dc(id_p, id_s, Data)
SELECT  6 , id, cost
FROM [Order]

CREATE TABLE data_dt
(id_p int,
id_s int,
data datetime,
PRIMARY KEY(id_p, id_s))

INSERT INTO data_dt(id_p, id_s, Data)
SELECT  7 , id, [Date]
FROM [Order]

CREATE TABLE data_c
(id_p int,
id_s int,
data char( 1 ),
PRIMARY KEY(id_p, id_s))

INSERT INTO data_c(id_p, id_s, Data)
SELECT  8 , id, flag
FROM [Order]
GO

create view vcustomers as
select a.data as customer_id, b.data as customer_desc
from data_i a, data_s b
where a.id_s = b.id_s
and a.id_p =  1 
and b.id_p =  2 
GO

create view vorders as
select a.data as order_id, b.data as customer_id, d.data as order_cost,
e.data as order_date, f.data as order_flag
from data_i a, data_i b, data_dc d, data_dt e, data_c f
where
a.id_s = b.id_s
and a.id_s = d.id_s
and a.id_s = e.id_s
and a.id_s = f.id_s
and a.id_p =  3 
and b.id_p =  4 
and d.id_p =  6 
and e.id_p =  7 
and f.id_p =  8 
GO

select vcustomers.customer_id, customer_desc , sum(order_cost) from vcustomers, vorders
where vcustomers.customer_id = vorders.customer_id
and order_flag = 'Y'
and order_date between '20040101' and '20041231'
group by vcustomers.customer_id, customer_desc

-- Table 'data_i'. Scan count 3, logical reads 5147, physical reads 0, read-ahead reads 0.
-- Table 'data_dc'. Scan count 1, logical reads 3021, physical reads 0, read-ahead reads 0.
-- Table 'data_c'. Scan count 1, logical reads 2093, physical reads 0, read-ahead reads 0.
-- Table 'data_dt'. Scan count 1, logical reads 3098, physical reads 0, read-ahead reads 0.
-- Table 'data_s'. Scan count 1, logical reads 487, physical reads 0, read-ahead reads 0.
-- 
-- SQL Server Execution Times:
--    CPU time = 6407 ms,  elapsed time = 6538 ms.
Маленькая путаница произошла при переводе, там где id_p - читать id_s, махнул не глядя :) Собственно, важно соотношение
CPU time = 1640 ms, elapsed time = 1768 ms
к
CPU time = 6407 ms, elapsed time = 6538 ms.
Как видим, далеко от 30-60 раз, при этом практически не озабочивались оптимизацией.
Резюм: MS SQL 2000 лучше подходит при построении объектной настройки над реляционной СУБД, чем Informix 9.21 :)
...
Рейтинг: 0 / 0
21.01.2005, 23:23
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32878266
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Привожу ссылочку на небольшой обзор по состоянию стандартизации в
> области объектных баз данных в 1995г. С тех пор ничего особенно не изменилось.

Безотносительно темы обсуждения: Вы привели ссылку на документ десятилетней давности и утверждаете, что ничего особенно не изменилось. Хм... плохо.

> Кратко излагая суть этой статьи.

Спасибо. ;)

"...In October 1993, ODMG published its first version of standard, ODMG-93, which defines the data model, query language, and language bindings...". Где оно? Я могу посмотреть его (лучше, конечно, последнюю версию) иначе, чем купив книгу?

> ODMG-93 поддерживается целым рядом продуктов и называть его "сборником
> статей" я бы не стал.

Комментарии к стандарту создали у меня именно такое впечатление.

> использование в качестве основы для решения обсуждаемой задачи именно
> ООСУБД будет означать ориентацию только на какую-то одну систему

Да, что-то вроде того.

> Но это не так.

Приведите, pls, ссылки на стандарты и материалы (лучше независимые), из которых была бы понятна степень соответствия программных продуктов этим стандартам.

> Более того, технологии, имеющиеся на сегодняшний день в ООСУБД и
> сопутствующих им средствах разработки позволяют создавать действительно
> независимые от платформы решения,

_Не бывает_ не зависимых от платформы решений.

> которые могут использовать в качестве
> оконечных хранилищ данных практически любые СУБД (объектные,
> реляционные).

А почему, собственно, Вы решили, что у меня это хранилище получится хуже? ;)

> Вообще ваше мнение о современных объектных системах неправильное по
> многим пунктам.

Очень хорошо. Давайте начнем с азов. Где стандарты "современных объектных систем"? Ссылку, pls. Будем читать.

> подробнее писать в этом топике о собственно объектных системах будет не
> вполне корректным

Я бы предпочел первоисточники. Т. е., сначала стандарты, потом - если до этого дойдет - мануалы.
...
Рейтинг: 0 / 0
21.01.2005, 23:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32878274
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
ChA vybegalloПросим, просим !
Приведенные результаты были получены на Informix 9.21 на Сан боксе Solaris 8, 2 CPU 336MHz
Ловите :) Ничего лишнего, вроде более-менее адекватный перевод
Итак MSSQL 2000 SP3 на FS PRIMERGY C200, 2*1.26Гц, no parallelism

...
-- Table 'data_i'. Scan count 3, logical reads 5147, physical reads 0, read-ahead reads 0.
-- Table 'data_dc'. Scan count 1, logical reads 3021, physical reads 0, read-ahead reads 0.
-- Table 'data_c'. Scan count 1, logical reads 2093, physical reads 0, read-ahead reads 0.
-- Table 'data_dt'. Scan count 1, logical reads 3098, physical reads 0, read-ahead reads 0.
-- Table 'data_s'. Scan count 1, logical reads 487, physical reads 0, read-ahead reads 0.
--
-- SQL Server Execution Times:
-- CPU time = 6407 ms, elapsed time = 6538 ms.
[/src]Маленькая путаница произошла при переводе, там где id_p - читать id_s, махнул не глядя :) Собственно, важно соотношение
CPU time = 1640 ms, elapsed time = 1768 ms
к
CPU time = 6407 ms, elapsed time = 6538 ms.
Как видим, далеко от 30-60 раз, при этом практически не озабочивались оптимизацией.
Резюм: MS SQL 2000 лучше подходит при построении объектной настройки над реляционной СУБД, чем Informix 9.21 :)

Хотелось бы увидеть результаты при числе physical reads отличных от нуля.
...
Рейтинг: 0 / 0
22.01.2005, 00:13
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32878294
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Вообще ваше мнение о современных объектных системах неправильное по многим пунктам.

http://synthesis.ipi.ac.ru/synthesis/publications/odmg93/html

Если это соответствует действительности, то я рад, что у меня с Вашей точки зрения неправильное мнение о современных объектных системах.
...
Рейтинг: 0 / 0
22.01.2005, 01:03
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32878323
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
vybegalloХотелось бы увидеть результаты при числе physical reads отличных от нуля.
Только для Вас, с "нуля", после запуска сервера
Исходные запросы
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
select c.id
, c.descr
, sum(cost)
from customer c, [order] o
where c.id = o.customer_id
and flag = 'Y'
and [date] between '20040101' and '20041231'
group by c.id, c.descr


select vcustomers.customer_id, customer_desc , sum(order_cost) from vcustomers, vorders
where vcustomers.customer_id = vorders.customer_id
and order_flag = 'Y'
and order_date between '20040101' and '20041231'
group by vcustomers.customer_id, customer_desc

Самый первый запуск после заполнение данными и создания view
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
SQL Server parse and compile time: 
   CPU time =  12078  ms, elapsed time =  14385  ms.

Table 'customer'. Scan count  1 , logical reads  434 , physical reads  1 , read-ahead reads  433 .
Table 'order'. Scan count  1 , logical reads  7695 , physical reads  261 , read-ahead reads  6620 .

SQL Server Execution Times:
   CPU time =  1563  ms,  elapsed time =  3091  ms.

Table 'data_i'. Scan count  3 , logical reads  5147 , physical reads  257 , read-ahead reads  4215 .
Table 'data_dc'. Scan count  1 , logical reads  3021 , physical reads  202 , read-ahead reads  1808 .
Table 'data_c'. Scan count  1 , logical reads  2093 , physical reads  112 , read-ahead reads  888 .
Table 'data_dt'. Scan count  1 , logical reads  3098 , physical reads  197 , read-ahead reads  1791 .
Table 'data_s'. Scan count  1 , logical reads  487 , physical reads  16 , read-ahead reads  409 .

SQL Server Execution Times:
   CPU time =  6609  ms,  elapsed time =  8677  ms.
Затем сразу второй запуск
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
SQL Server parse and compile time: 
   CPU time =  0  ms, elapsed time =  0  ms.

Table 'customer'. Scan count  1 , logical reads  434 , physical reads  0 , read-ahead reads  0 .
Table 'order'. Scan count  1 , logical reads  7695 , physical reads  0 , read-ahead reads  0 .

SQL Server Execution Times:
   CPU time =  1531  ms,  elapsed time =  1699  ms.

Table 'data_i'. Scan count  3 , logical reads  5147 , physical reads  0 , read-ahead reads  8 .
Table 'data_dc'. Scan count  1 , logical reads  3021 , physical reads  0 , read-ahead reads  0 .
Table 'data_c'. Scan count  1 , logical reads  2093 , physical reads  0 , read-ahead reads  8 .
Table 'data_dt'. Scan count  1 , logical reads  3098 , physical reads  0 , read-ahead reads  0 .
Table 'data_s'. Scan count  1 , logical reads  487 , physical reads  0 , read-ahead reads  0 .

SQL Server Execution Times:
   CPU time =  6438  ms,  elapsed time =  6555  ms.
Ну не виноват SQL Server, что оперативки много :) После первого запроса он сожрал 254 МБ и успокоился. Диски SCSI, как полагается, 10000 об, U160. Никакого параллелизма, 1 процессор на запрос.
После полного перезапуска компьютера
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
SQL Server parse and compile time: 
   CPU time =  1312  ms, elapsed time =  1448  ms.

Table 'customer'. Scan count  1 , logical reads  434 , physical reads  1 , read-ahead reads  433 .
Table 'order'. Scan count  1 , logical reads  7695 , physical reads  2 , read-ahead reads  7716 .

SQL Server Execution Times:
   CPU time =  1610  ms,  elapsed time =  2528  ms.

Table 'data_i'. Scan count  3 , logical reads  5147 , physical reads  4 , read-ahead reads  5408 .
Table 'data_dc'. Scan count  1 , logical reads  3021 , physical reads  2 , read-ahead reads  3150 .
Table 'data_c'. Scan count  1 , logical reads  2093 , physical reads  2 , read-ahead reads  2222 .
Table 'data_dt'. Scan count  1 , logical reads  3098 , physical reads  2 , read-ahead reads  3108 .
Table 'data_s'. Scan count  1 , logical reads  487 , physical reads  4 , read-ahead reads  485 .

SQL Server Execution Times:
   CPU time =  6546  ms,  elapsed time =  7401  ms.
SQL Server parse and compile time: 
   CPU time =  0  ms, elapsed time =  0  ms.
Далее, как упоминалось. Не верите ? Вот и я не поверил, когда было озвучено 30-60 раз и время больше часа... :)

P.S. Можете просмотреть скрипт, вдруг наврал где, хотя вряд ли ?
...
Рейтинг: 0 / 0
22.01.2005, 03:07
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32878324
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
vybegalloПредупреждение: проверять на Pentium133 - 32MB не буду и не просите :)
...
Рейтинг: 0 / 0
22.01.2005, 03:19
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32878421
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
vybegalloОграничил память MSSQL до 32МБ
Холодный запуск
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
-- SQL Server parse and compile time: 
--    CPU time = 1328 ms, elapsed time = 1362 ms.
-- 
-- Table 'customer'. Scan count 1, logical reads 434, physical reads 1, read-ahead reads 433.
-- Table 'order'. Scan count 1, logical reads 7695, physical reads 2, read-ahead reads 7716.
-- 
-- SQL Server Execution Times:
--    CPU time = 1390 ms,  elapsed time = 3613 ms.
-- 
-- Table 'data_i'. Scan count 3, logical reads 5147, physical reads 4, read-ahead reads 5409.
-- Table 'data_dc'. Scan count 1, logical reads 3021, physical reads 2, read-ahead reads 3150.
-- Table 'data_c'. Scan count 1, logical reads 2093, physical reads 2, read-ahead reads 2222.
-- Table 'data_dt'. Scan count 1, logical reads 3098, physical reads 2, read-ahead reads 3108.
-- Table 'data_s'. Scan count 1, logical reads 487, physical reads 4, read-ahead reads 485.
-- 
-- SQL Server Execution Times:
--    CPU time = 6391 ms,  elapsed time = 10173 ms.
Следующий запуск
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
-- SQL Server parse and compile time: 
--    CPU time = 1313 ms, elapsed time = 1324 ms.
-- 
-- Table 'customer'. Scan count 1, logical reads 434, physical reads 1, read-ahead reads 433.
-- Table 'order'. Scan count 1, logical reads 7695, physical reads 2, read-ahead reads 7716.
-- 
-- SQL Server Execution Times:
--    CPU time = 1515 ms,  elapsed time = 2448 ms.
-- 
-- Table 'data_i'. Scan count 3, logical reads 5147, physical reads 3, read-ahead reads 5409.
-- Table 'data_dc'. Scan count 1, logical reads 3021, physical reads 2, read-ahead reads 3150.
-- Table 'data_c'. Scan count 1, logical reads 2093, physical reads 2, read-ahead reads 2222.
-- Table 'data_dt'. Scan count 1, logical reads 3098, physical reads 2, read-ahead reads 3108.
-- Table 'data_s'. Scan count 1, logical reads 487, physical reads 4, read-ahead reads 485.
-- 
-- SQL Server Execution Times:
--    CPU time = 6453 ms,  elapsed time = 10060 ms.
Третий запуск
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
SQL Server parse and compile time: 
   CPU time =  1313  ms, elapsed time =  1351  ms.

Table 'customer'. Scan count  1 , logical reads  434 , physical reads  1 , read-ahead reads  433 .
Table 'order'. Scan count  1 , logical reads  7695 , physical reads  2 , read-ahead reads  7716 .

SQL Server Execution Times:
   CPU time =  1609  ms,  elapsed time =  2518  ms.

Table 'data_i'. Scan count  3 , logical reads  5147 , physical reads  3 , read-ahead reads  5409 .
Table 'data_dc'. Scan count  1 , logical reads  3021 , physical reads  2 , read-ahead reads  3150 .
Table 'data_c'. Scan count  1 , logical reads  2093 , physical reads  2 , read-ahead reads  2222 .
Table 'data_dt'. Scan count  1 , logical reads  3098 , physical reads  2 , read-ahead reads  3108 .
Table 'data_s'. Scan count  1 , logical reads  487 , physical reads  4 , read-ahead reads  485 .

SQL Server Execution Times:
   CPU time =  6469  ms,  elapsed time =  9945  ms.
Хватит проверок ?
...
Рейтинг: 0 / 0
22.01.2005, 12:06
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32880284
Astron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Astron
Гость
Здравствуйте, недавно заглянул, возможно ответ заинтересует автора топика.
Есть такие системы, и стоят они примерно под лимон баксов. Пример - пожалуйста, www.ftc.ru , это автоматизированная банковская система. На этом принципе сделано еще кое-что. Работает замечательно. Сколько в системе кода, таблиц и вьюшек никто давно уже не считал, очень и очень дофига. Реально, если для нормальной оракловой базы хватает разумного соотношения "память/диск/процессора", то для этой, для отработки объектной надстройки, процессоров надо раз в 5 больше. Кроме того, стоимость разработки всевозможных расширений к системе достаточно велика, из-за ее сложности. Разумеется, это окупается гибкостью, даже "бесхребетностью" системы, но оправданным это становится начиная с небольших размеров банка, документов (платежек) на ~3000 в день. И перестает быть оправданным на большом банке, документов на 30000 в день. При этом SUN с 10 процессорами начинает неимоверно тормозить из-за их перегрузки, а Оракл (а это крайне дубовая весчь) становится неплохо периодически перезагрузить, во избежание. Короче, разрабатывать подобные системы ИМХО неправильно для небольших баз и серверов, овчинка выделки не стоит...
...
Рейтинг: 0 / 0
24.01.2005, 15:07
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32880645
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Есть такие системы, и стоят они примерно под лимон баксов.

;)) Это формирование ценовой категории разработок? А чего не десять миллионов или сто?

> то для этой, для отработки объектной надстройки, процессоров надо раз в 5 больше.

Значит, она плохо спроектирована или плохо реализована.

> Кроме того, стоимость разработки всевозможных расширений к системе
> достаточно велика, из-за ее сложности.

Скорее, все-таки плохо спроектирована.

> Короче, разрабатывать подобные системы ИМХО неправильно для небольших баз и
> серверов, овчинка выделки не стоит...

Imho ошибочная точка зрения.
...
Рейтинг: 0 / 0
24.01.2005, 16:51
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32883133
Astron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Astron
Гость
;)) Это формирование ценовой категории разработок? А чего не десять миллионов или сто?

Нет, это цена лицензии на 1 сервер. Продажи идут успешно. Почему не 10 и не 100 - не знаю, наверное это вопрос к маркетологам :-)


Значит, она плохо спроектирована или плохо реализована.
Скорее, все-таки плохо спроектирована.

Ну.... Один транслятор собственного объектно-ориентированного языка чего стоит. Транслирует свой язык в оракловый PL/SQL. А поскольку все нормализовано до упора, то каждая выборка объекта преобразуется в жуткого вида запрос, состоящий из кучи таблиц да еще и соединения все внешние. Я знакомому в свое время писал
-------------------------------------------
Astron, 28.05.2004 12:03 :
это надо видеть..... Голый оракл как в инверсии (правильно?) рядом с этим монстром просто как полено выглядит. например в нашем коде - поиск банка для вставки в плательщика
код на ее языке -
----------------
cl:=' р/с '||d_send.ACC_PL||' с '||::[CL_BANK_N]([BIC]=d_send.BIC_PL and rownum <>2).[NAME];
-----------------
транслируется в
--# 773,4
begin
select a1.id
into plp$ID_7
from Z#CL_BANK_N a1
where a1.C_BIC = D_SEND.BIC_PL and ROWNUM <> 2;
exception
when NO_DATA_FOUND then raise rtl.NO_DATA_FOUND;
when TOO_MANY_ROWS then raise rtl.TOO_MANY_ROWS;
end;
CL := ' р/с '||D_SEND.ACC_PL||' в '||Z#CL_BANK_N#INTERFACE.get_str(plp$ID_7,'NAME');
--# 774,7
-------------------------------------------
Да, можно работать напрямую, и производительность будет значительно выше, но про объекты придется забыть. А насчет реализации и проектирования - насколько хорошо можно все сделать если систему писали десятки человек много лет? Насколько уж можно.....


> Короче, разрабатывать подобные системы ИМХО неправильно для небольших баз и
> серверов, овчинка выделки не стоит...

Imho ошибочная точка зрения.
Ну, практика-критерий истины. Если это поможет Вам заработать больше $$ чем в отсутствии подобных наворотов, то я согласен :-)
...
Рейтинг: 0 / 0
25.01.2005, 18:02
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32883189
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Нет, это цена лицензии на 1 сервер. Продажи идут успешно. Почему не 10 и не
> 100 - не знаю, наверное это вопрос к маркетологам :-)

Понятно. Не думаю, что в данном случае цена обусловлена структурой данных.

> Ну.... Один транслятор собственного объектно-ориентированного языка чего стоит.

Хм... мсье безусловно понимает толк в извращениях. ;)

> А насчет реализации и проектирования - насколько хорошо можно все сделать
> если систему писали десятки человек много лет?

Десятки человек много лет писали нечто, что в результате жутко тормозит и "...стоимость разработки расширений к системе достаточно велика...". Может, в консерватории что-то подправить?
...
Рейтинг: 0 / 0
25.01.2005, 18:24
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32887305
Витал
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Витал
Участник
skorohod2 quot vybegallo

> А я вот для себя сформулировал "закон сохранения сложности", который
> гласит : "сложность задачи состоит из сложности алгоритмов и сложности
> структур данных. Уменьшение одной компоненты ведет к увеличению другой".
>
> Поэтому если вы 50-100-200 таблиц собираете в 5, то сложность данных вы
> уменьшаете, но вот алгоритмы...
> Ну ладно, adisk не хочет попробовать написать JOIN для "объектного слоя".
> Ему не хочется хвататься грязными руками за хрустальную мечту его
> программистского детства :-). В конце концов, знатоки Фокса не обязаны
> знать SQL !
> Но вы-то собираетесь все это реально внедрять ? Ну так попробуйте,
> прикиньте, как будет выглядеть запрос с соединением 2 таблиц в вашем
> хранилище.
> Или вы тоже на Фоксе пишите ?

Уважаемый!
А можно мне поинтересоваться целью Вашего присутствия в этом топике?
Задавить всех интересующихся Вашим богатым опытом? Или доказать, что этого в природе не существует и сделать такое в принципе невозможно? Или, что это не нужно Вам в Вашей тяжелой работе? Или может Вы беспокоитесь за ухудшение состояния нашей психики в ходе обсуждений? :)
Объяснитесь, плиз! Очень хочется узнать!

Не дочитал топик до конца (не утерпел).
Что ли здесь Вашу конкрентную проблему обсуждают, уважаемый? Изначально вопрос не стоял, как Вам практически пройти по уже явно выбранному Вами пути. Это - заводите свой топик и болтайте сколько влезет. Тогда мнения, с Вами не согласные (т.е., конечно же, неправильные), Вы можете оттуда гнать поганой метлой.

А пока мне лично хотелось бы узнать все ЗА и ПРОТИВ.
...
Рейтинг: 0 / 0
27.01.2005, 15:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32887941
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
Витал skorohod2 quot vybegallo

> А я вот для себя сформулировал "закон сохранения сложности", который
> гласит : "сложность задачи состоит из сложности алгоритмов и сложности
> структур данных. Уменьшение одной компоненты ведет к увеличению другой".
>
> Поэтому если вы 50-100-200 таблиц собираете в 5, то сложность данных вы
> уменьшаете, но вот алгоритмы...
> Ну ладно, adisk не хочет попробовать написать JOIN для "объектного слоя".
> Ему не хочется хвататься грязными руками за хрустальную мечту его
> программистского детства :-). В конце концов, знатоки Фокса не обязаны
> знать SQL !
> Но вы-то собираетесь все это реально внедрять ? Ну так попробуйте,
> прикиньте, как будет выглядеть запрос с соединением 2 таблиц в вашем
> хранилище.
> Или вы тоже на Фоксе пишите ?

Уважаемый!
А можно мне поинтересоваться целью Вашего присутствия в этом топике?
Задавить всех интересующихся Вашим богатым опытом? Или доказать, что этого в природе не существует и сделать такое в принципе невозможно? Или, что это не нужно Вам в Вашей тяжелой работе? Или может Вы беспокоитесь за ухудшение состояния нашей психики в ходе обсуждений? :)
Объяснитесь, плиз! Очень хочется узнать!

Не дочитал топик до конца (не утерпел).
Что ли здесь Вашу конкрентную проблему обсуждают, уважаемый? Изначально вопрос не стоял, как Вам практически пройти по уже явно выбранному Вами пути. Это - заводите свой топик и болтайте сколько влезет. Тогда мнения, с Вами не согласные (т.е., конечно же, неправильные), Вы можете оттуда гнать поганой метлой.

А пока мне лично хотелось бы узнать все ЗА и ПРОТИВ.

:) Сорри! Не понял - в чей огород камень?
Если в мой - так дочитайте топик до конца! Если есть претензии или вопросы - пишите, только не сюда (не надо тему засорять постами "сам дурак"). "Разбираться" со мной можно и по почте, чего не скажешь об уважаемом vybegallo.
...
Рейтинг: 0 / 0
27.01.2005, 18:47
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32887977
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
Некий промежуточный (надеюсь) ответ по самому первому вопросу этой темы. Фактически - собрал ссылки в этом топике и других местах, и на то, что успел посмотреть (нумерация продуктов случайная), даю краткое резюме:

ИС на ОРБД:

1. NEXUS
NEXUS (независимая группа разработчиков)
Россия, СПб, 2000 - 2005
http://nexus.arbinada.com/
«Open-Source», доступны инструменты разработчика, исходники, документация.
Архитектура: (2) клиент-сервер; Универсальный «тонкий» клиент - генератор интерфейса (С++); Сервер - СУБД MS SQL 2000; Предметная область, бизнес-правила, GUI и т.д. описаны в модели в виде объектов и хранятся в РБД; Методы объектов – T-SQL; Реляционная реализация объектной модели в РБД «полустатичная» (при расширении модели в БД могут добавляться таблицы);
Есть несколько успешных внедрений в коммерческих структурах (СПб) разного профиля (названы 3 компании).

2. SQ конструктор
Extracode (Экстракод), Институт Проблем Управления РАН
Россия, Москва, 2002 - 2005
http://www.s-q.ru/, http://www.extracode.ru
Коммерческая, доступны ограниченные демо-версии системы, документация.
Архитектура: (3?) стандартный вэб-клиент – вэб-сервер (IIS, Apache) – БД-сервер (MS SQL, планируется Oracle); Предметная область, бизнес-правила, GUI и т.д. описаны в модели в виде объектов и хранятся в РБД; Методы объектов – T-SQL + «картриджи» на языке программирования;
Реляционная реализация объектной модели в РБД «статичная» (при расширении модели табличный состав БД не меняется);
Есть большой набор "конфигураций" по различным бизнес-задачам, но на сайте отсутствуют упоминания о конкретных внедрениях системы.

3. UBD (УБД) – разработчиком декларируется «ООСУБД»
stikriz (компания?) (Николай Банников)
Россия, город?, 2003 - 2004
http://www.stikriz.net
Коммерческая, доступна ограниченная демо-версия системы.
Архитектура: (3) клиент – сервер приложений – сервер БД; Клиент (Delphi), сервер приложений (Delphi), сервер БД (MS SQL 2000, а также InterBase SQL Server и клоны Yaffil и FireBird); Предметная область, бизнес-правила, GUI и т.д. описаны в модели в виде объектов и хранятся в РБД; "Независимость данных пользователя от конечного хранилища данных; Доступ к данным на OSQL и на стандартном SQL92";
Методы объектов – ? (возм. Delphi?);
Реляционная реализация объектной модели в РБД - ???.
Декларируется – сделали уже очень много, и сделаем все, что вам нужно!

4. VisualDoc 4.1
«ЦентрИнвест Софт»,
Россия, Москва, 1998 – 2005
http://www.visualdoc.ru
Коммерческая, доступна полнофункциональная демо-версия (3.35) с ограничением по времени использования, документация;
Архитектура (3?); «…объектноориентированная СУБД, работающая на базе MS SQL или ORACLE, имеющая в своем составе специальные средства для работы с документами, процессами и данными, включая язык запросов VD SQL.», «…динамическое отражение изменений в (предметной области) структуре (системы) без дополнительного перепрограммирования…»;
Есть большое количество успешных внедрений в коммерческих и гос. структурах разного профиля.

5. Hibernate (Java)
Internet community (+ русскоязычные энтузиасты)
http://www.hibernate.org, http://www.hibernate.ru - неофициальный сайт.
Free / Open-Source - Hibernate is licensed under the LGPL (Lesser GNU Public License)
Доступны релизы, исходники, документация на английском, частично на русском;
Hibernate - инструмент объектно-реляционного отображения данных (ORM tool) в реляционную модель со схемой данных основанной на SQL, для Java-окружения.

6. ERP5
Internet community
http://erp5.org
Open-Source (+ free СУБД: MySQL, PostgreSQL, …)
Доступны релизы, исходники, документация на нескольких европейских языках;
«ERP5: A Next-Generation, Open-Source ERP Architecture …»

7. TechInsite
Австралия, Мельбурн 1999-2005
http://www.techinsite.com.au/tiOPF/Default.htm
Open-Source; Доступны релизы, исходники, документация на английском;
«The TechInsite Object Persistence Framework (tiOPF) is an Open Source framework of Delphi code that simplifies the mapping of an object oriented business model into a relational database...»
Архитектура 3-звенная, возможны варианты 2-звенной и много-звенной архитектуры;

Другие альтернативные коммерческие продукты:
InstantObjects
BOLD
KODO
…….
...
Рейтинг: 0 / 0
27.01.2005, 19:04
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32888526
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
R2D2
Открытый (OpenSource)
Написан на CLIP (http://www.itk.ru/)
Кросплатформенный
ОО модель поверх РБД.

http://www.itk.ru/r2d2/index.shtml
...
Рейтинг: 0 / 0
28.01.2005, 10:07
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32888675
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Rovdo
Гость
FastObjects .NET, FastObjects t7
Versant Corporation (+Poet Holdings)

платформа .NET (C#, VB .NET и др. IL-совместимые языки)
платформы Win, Lin, Unix (C++, Java)
ОО модель с хранением данных в ООСУБД
ОО модель поверх MS SQL, Oracle, DB2 (FastObjects SQL Object Factory)

http://www.versant.ru
...
Рейтинг: 0 / 0
28.01.2005, 11:14
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32889490
MMS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MMS
Гость
Здравствуйте!
На обсуждение набрел через ключевые слова "Иерархическая классификация". Как не программист, мало чего понял из сказанного; по ощущениям же - "очень тепло".
Вчера встречался с академиком (философия, математика, теория систем), по его утверждению "более-менее стройной теории классификации не существует и толком не разрабатывается". При этом я вижу, что движение к иерархическому классификатору (ИК) идет повсеместно - но пока не стало всеобщей идеей. Обсуждаемая здесь возможность сделать ИК надстройкой над СУБД мне кажется крайне продуктивной

1. Правильно ли я понял, что применение ИК-надстройки резко повышает требования к ресурсам? Ведь достаточно один раз привязать ID записи СУБД к ID конечной ветви визуализатора
2. Не являются ли упомянутые участниками сложности следствием абстрактности обсуждаемого вопроса? Введение границ применения могло бы сильно все упростить.
3. Означают ли попытки участников написать собственный инструмент ИК то, что готовых многофункциональных древопостроителей нет на рынке? Я встречал самоделки, местами довольно остроумные; видел готовые управленческие продукты с применением классификатора в их составе - но не как отдельного продукта

Темой ИК заинтересовался приличный инвестор, предполагается создание лаборатории разработки прототипов. Я - идеолог и постановщик, руководитель проекта.
Предлагаю обменяться материалами, по которым можно судить, насколько Вы продвинулись в плане ИК. Поскольку я не программер - лучше короткие описания в любом виде и скриншоты. Авось из этого что-то да и выйдет - ведь при прототипировании необязательно всем сидеть в одной комнате.

С уважением,
Шустер Михаил Михайлович
Директор по качеству
Институт поддержки эксплуатации АЭС
Киев

shuster@npp-osi.kiev.ua

PS. Материалы, раскрывающие идеи до такой степени, что их можно украсть, лучше оставить при себе.
...
Рейтинг: 0 / 0
28.01.2005, 14:54
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32889544
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
А этот топик не про иерархические классификаторы.
Он про объектные СУБД.
Давайте заведем парочку топиков про классификаторы (можно и про графы вообще ), и поконкретнее сформулируем вопросы.

"пока вы смотрите свой телевизор, инопланетяне через него трахают вам мозги"
...
Рейтинг: 0 / 0
28.01.2005, 15:10
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32889653
MMS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MMS
Гость
Dogen (Доген), как дзенский учитель, никогда не отделял вопрос от спрашивающего :-)
У меня не столь вопрос, сколь предложение. Два из трех вопросов довольно конкретны.
Насчет офтопика-наберите в любом поисковике "ИК" - 80% ссылок будет на этот топик.
...
Рейтинг: 0 / 0
28.01.2005, 15:36
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32889761
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Вчера встречался с академиком (философия, математика, теория систем), по его
> утверждению "более-менее стройной теории классификации не существует и
> толком не разрабатывается".

Напрасно так думает Ваш академик. Поищите в google "тезаурус" и лингвистические разработки на его основе.

> При этом я вижу, что движение к иерархическому классификатору (ИК) идет
> повсеместно - но пока не стало всеобщей идеей.

Иерархическая классификация сама по себе не представляет интереса. Это всего лишь способ хранения данных.
...
Рейтинг: 0 / 0
28.01.2005, 16:00
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32889847
MMS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MMS
Гость
Тезаурус, семантика, онтология, семиотика, таксономия, фракталы - все это лишь частные применения ИК
...
Рейтинг: 0 / 0
28.01.2005, 16:26
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890004
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
Dogen
А этот топик не про иерархические классификаторы.
Он про объектные СУБД.
..............


Поправочка небольшая:
Этот топик про ОБЪЕКТНЫЕ надстройки над РЕЛЯЦИОННЫМИ СУБД.
А Объектные СУБД - это немножко совсем-совсем другое!
И, как пример, то, что писал о продуктах Versant Corporation
Alexey Rovdo
...............
ОО модель с хранением данных в ООСУБД
ОО модель поверх MS SQL, Oracle, DB2 (FastObjects SQL Object Factory)
...............

укладывается в тему топика только в части последней приведенной строки!

Очень "долгое" сравнение РСУБД, ООСУБД и ОРСУБД есть в форуме "Сравнение СУБД" - почитайте!
...
Рейтинг: 0 / 0
28.01.2005, 17:18
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890014
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
skorohod Dogen
А этот топик не про иерархические классификаторы.
Он про объектные СУБД.
..............


Поправочка небольшая:
Этот топик про ОБЪЕКТНЫЕ надстройки над РЕЛЯЦИОННЫМИ СУБД.
А Объектные СУБД - это немножко совсем-совсем другое!


Не суть важно для прикладного программирования.

Как пример можно взять Zope - у него есть объектная ZODB, но можно адаптировать его и к mySQL или Oracle, будет он в RDBMS свои объекты хранить.
...
Рейтинг: 0 / 0
28.01.2005, 17:23
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890061
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Тезаурус, семантика, онтология, семиотика, таксономия, фракталы - все это
> лишь частные применения ИК

Хм... и что из этого следует?

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

Так что Ваше замечание мне не очень понятно.
...
Рейтинг: 0 / 0
28.01.2005, 17:45
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890066
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
2 Dogen
> Не суть важно для прикладного программирования.
> Как пример можно взять Zope - у него есть объектная ZODB, но можно
> адаптировать его и к mySQL или Oracle, будет он в RDBMS свои объекты
> хранить.

Ну не знаю...
Изначально вопрос стоял довольно конкретный "какие вы знаете...?". На него были конкретные ответы, и кроме них попутно выяснялось много сопутствующих моментов.
Просто у меня сложилось свое личное мнение на один из сопутствующих вопросов - кому нужны эти "Объектные надстройки над реляционными СУБД".
Я думаю, что он интересуют тех людей, которые в силу разных обстоятельств своей профессиональной деятельности пришли к выводу, что стандартная методика проектирования и разработки ИС на основе РСУБД их уже не удовлетворяет, а про ООСУБД они или:
1) не знают совсем;
2) знают (в разной степени хорошо) и хотят их использовать но НЕ МОГУТ - по финансовым, корпоративным или каким-либо другим причинам;
3) знают очень хорошо и поняли, что это тоже "не то" и сознательно не хотят их использовать;
Так вот я считаю, что поднимаемые в обсуждении этого топика вопросы интересны в основном именно людям "3)" и наверно "2)". Т.е. тем, кто не хочет/может переходить на новый инструмент разработки, а хочет по максимуму использовать годами наработанный опыт работы с РСУБД на несколько более высоком (логическом) уровне.

P.S. Как я уже сказал - это мое личное мнение, так что если на Ваш взгляд я ошибаюсь - плз. не кидайте камни и тухлые помидоры :)
...
Рейтинг: 0 / 0
28.01.2005, 17:47
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890090
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
skorohod2 Dogen
> Не суть важно для прикладного программирования.
> Как пример можно взять Zope - у него есть объектная ZODB, но можно
> адаптировать его и к mySQL или Oracle, будет он в RDBMS свои объекты
> хранить.

Ну не знаю...
Изначально вопрос стоял довольно конкретный "какие вы знаете...?". На него были конкретные ответы, и кроме них попутно выяснялось много сопутствующих моментов.
Просто у меня сложилось свое личное мнение на один из сопутствующих вопросов - кому нужны эти "Объектные надстройки над реляционными СУБД".
Я думаю, что он интересуют тех людей, которые в силу разных обстоятельств своей профессиональной деятельности пришли к выводу, что стандартная методика проектирования и разработки ИС на основе РСУБД их уже не удовлетворяет, а про ООСУБД они или:
1) не знают совсем;
2) знают (в разной степени хорошо) и хотят их использовать но НЕ МОГУТ - по финансовым, корпоративным или каким-либо другим причинам;
3) знают очень хорошо и поняли, что это тоже "не то" и сознательно не хотят их использовать;
Так вот я считаю, что поднимаемые в обсуждении этого топика вопросы интересны в основном именно людям "3)" и наверно "2)". Т.е. тем, кто не хочет/может переходить на новый инструмент разработки, а хочет по максимуму использовать годами наработанный опыт работы с РСУБД на несколько более высоком (логическом) уровне.

P.S. Как я уже сказал - это мое личное мнение, так что если на Ваш взгляд я ошибаюсь - плз. не кидайте камни и тухлые помидоры :)

С моей дремучей точки зрения не суть важно, разработаете Вы объектную надстройку над РСУБД или же объекты у Вас будут существовать в клиентском приложении, и на низком уровне реализации, в методах объектов, там будет код, помещающий/считывающий данные в РСУБД.

Получается вопрос - никакой. В философском смысле, конечно. Ясно что на практике надо выбирать, _как_ именно лучше сделать.

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

А кто занимается, они идут имхо по одному из мной указанных путей. И есть еще и такие, которые делают объектные СУБД.

Надо бы с уровнем абстракции определиться, где будем про объекты говорить - на уровне приложения, промежуточной софтины о которой топик, или на уровне СУБД.
...
Рейтинг: 0 / 0
28.01.2005, 17:56
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890104
MMS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MMS
Гость
Объектная надстройка может выглядеть в виде ИК, причем это не способ хранения данных, а метод визуализации их местонахождения.
Посмотрел несколько тезаурусов. Душераздирающее зрелище, как говорил ослик Иа
...
Рейтинг: 0 / 0
28.01.2005, 18:02
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890133
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
skorohod
нтересуют тех людей, которые в силу разных обстоятельств своей профессиональной деятельности пришли к выводу, что стандартная методика проектирования и разработки ИС на основе РСУБД их уже не удовлетворяет

Опять соглашусь с коллегой.
skorohod
2) знают (в разной степени хорошо) и хотят их использовать но НЕ МОГУТ - по финансовым, корпоративным или каким-либо другим причинам;

В точку.

MMS
Объектная надстройка может выглядеть в виде ИК, причем это не способ хранения данных, а метод визуализации их местонахождения.

Точно!

2 MMS
Есть огромное желание объединиться, но, если вы не программер нам с Вами не сладить.
...
Рейтинг: 0 / 0
28.01.2005, 18:24
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890140
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Объектная надстройка может выглядеть в виде ИК,

Может. А может и не выглядеть. Вообще дело десятое, какая структура данных использована для описания объектов.

> причем это не способ хранения данных, а метод визуализации их
> местонахождения.

Вы заблуждаетесь. Способ хранения не обязан быть связан с методом визуализации.

> Посмотрел несколько тезаурусов. Душераздирающее зрелище

Что вызвало у Вас столь отрицательные эмоции?
...
Рейтинг: 0 / 0
28.01.2005, 18:29
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890158
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
Dogen
С моей дремучей точки зрения не суть важно, разработаете Вы объектную надстройку над РСУБД или же объекты у Вас будут существовать в клиентском приложении, и на низком уровне реализации, в методах объектов, там будет код, помещающий/считывающий данные в РСУБД.
..............
Надо бы с уровнем абстракции определиться, где будем про объекты говорить - на уровне приложения, промежуточной софтины о которой топик, или на уровне СУБД.

Вот если мы затронем вопрос сопровождения готовой ИС и её вполне возможного в перспективе "модельного апгрейда" (речь не идет о "кривом" проектировании - просто со временем требования к отлично спроектированной и реализованной системе могут измениться), это даст нам какую-то точку опоры для определения "уровня абстракции"!
Т.е. от вопроса "кому надо" переходим к вопросу "зачем надо". (немного повторю то, что уже писал здесь раньше)
На мой взгляд - логическая объектная модель ИС д.б. реализована в виде отдельного слоя в РСУБД таким образом, что любое изменение этой логической объектной модели ИС (т.е. требований к функциональности ИС) не влечет, при реализации этих новых требований, никаких изменений ни в структуре РБД ИС, ни в сервере приложений (если он есть), ни в клиентском приложении! Все изменения функциональности ИС будут выполняться путем "манипулирования записями в РБД" (отдельный разговор о методах объектов - есть несколько вариантов, не противоречащих вышесказанному) через, раз и навсегда сделанный, универсальный клиентский интерфейс (или стандартный вэб-клиент).
Если же, как Вы писали, "объекты у Вас будут существовать в клиентском приложении, и на низком уровне реализации, в методах объектов, там будет код, помещающий/считывающий данные в РСУБД", то Вам придется (в общем случае) каждый раз, при изменении требований к Вашей ИС и реализации этих требований в объектной модели приложения, и заниматься дальнейшей частью цикла разработки-сопровождения - перекомпилляцией, отладкой, тестированием, переинсталляцией приложения у всех пользователей...
Всего этого можно избежать в первом случае, перенеся процесс изменения ИС только на работу с ОРБД.
Можно это назвать ленью, а можно - сокращением издержек на разработку-сопровождение ИС.
Убедил на счет уровня абстракции?
...
Рейтинг: 0 / 0
28.01.2005, 18:41
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890159
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Dogen
Надо бы с уровнем абстракции определиться, где будем про объекты говорить - на уровне приложения, промежуточной софтины о которой топик, или на уровне СУБД.

На уровне промежуточной софтины.
И, конечно, на уровне приложения.
...
Рейтинг: 0 / 0
28.01.2005, 18:41
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890163
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
adisk Dogen
Надо бы с уровнем абстракции определиться, где будем про объекты говорить - на уровне приложения, промежуточной софтины о которой топик, или на уровне СУБД.

На уровне промежуточной софтины.
И, конечно, на уровне приложения.


Сколько людей, столько и мнений!
Кто стырил консенсус!!!
:)
...
Рейтинг: 0 / 0
28.01.2005, 18:44
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890172
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
2 MMS
Поищите где-то ближе к началу топика пост от ASU (по-моему, сейчас уже поздно мне искать). Там он довольно хорошо объяснил разницу между иерархией, классификацией (и наследованием). Из-за различного понимания этих терминов тут тоже много непонимания между людьми и лишнего копьеломания.
...
Рейтинг: 0 / 0
28.01.2005, 18:50
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890173
MMS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MMS
Гость
Гостю
Поисковые семантические надстройки над Сетью просто лучше ищут нужное в мусорной куче информации. ИК может работать с "обратной стороны", складывая информацию так, чтобы она не образовывала мусорных куч-тогда качество и процессы поиска будут другими.
Мне нужен не "разгребальщик", а "укладчик". В начале топика были высказывания типа "Вот сделал такую фигню (по моему разумению-пробу создания инструментов ИК) , не знаю зачем" - мне показалось в этом можно найти полезное взаиморазумение или хотя бы получить наводку. Очень, знаете ли, не хочется велосипедов изобретать. Тем более, что отношусь к группе 1 :-)
У меня быстро и успешно внедрены две системы управления на АЭС, ИК составляет их основу. Поскольку использовались местные программеры, возможно, они не использовали современных средств (опирающихся на ИК) и я пытаюсь выяснить, существуют ли таковые.
Высказывание академика под сомнение не ставлю. Однако оно может означать лишь отсутствие прогресса в официальной науке, программерские же разработки могут находиться вне ее, либо засекречиваться.

Я не спец в средствах автоматизации и бОльшей части слов в этом топике не понимаю. Но хорошо знаю предмет приложения этих средств и всегда стараюсь упрощать программирование за счет упрощения задач. Поэтому, пожалуйста, давайте попытаемся говорить на языке, позволяющем общаться не тыча в морду интеллектом :-)
Задам свои вопросы иначе:

1. Существует ли ПО, которое не будучи неотъемлемой принадлежностью СУБД могло бы выстраивать ИК так, чтобы связать (пусть вручную) концы ветвей деревьев ИК с объектами, описанными в произвольной СУБД?
2. Вызывает ли ИК-надстройка над СУБД резкий рост требований к ресурсам?
3. Если стандартных решений нет, но есть собственные наработки-давайте свяжемся по мылу, поскольку на таковые имеется заказчик, хотя и не стопроцентный
...
Рейтинг: 0 / 0
28.01.2005, 18:50
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890197
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
skorohod Dogen
С моей дремучей точки зрения не суть важно, разработаете Вы объектную надстройку над РСУБД или же объекты у Вас будут существовать в клиентском приложении, и на низком уровне реализации, в методах объектов, там будет код, помещающий/считывающий данные в РСУБД.
..............
Надо бы с уровнем абстракции определиться, где будем про объекты говорить - на уровне приложения, промежуточной софтины о которой топик, или на уровне СУБД.

Вот если мы затронем вопрос сопровождения готовой ИС и её вполне возможного в перспективе "модельного апгрейда" (речь не идет о "кривом" проектировании - просто со временем требования к отлично спроектированной и реализованной системе могут измениться), это даст нам какую-то точку опоры для определения "уровня абстракции"!
Т.е. от вопроса "кому надо" переходим к вопросу "зачем надо". (немного повторю то, что уже писал здесь раньше)
На мой взгляд - логическая объектная модель ИС д.б. реализована в виде отдельного слоя в РСУБД таким образом, что любое изменение этой логической объектной модели ИС (т.е. требований к функциональности ИС) не влечет, при реализации этих новых требований, никаких изменений ни в структуре РБД ИС, ни в сервере приложений (если он есть), ни в клиентском приложении! Все изменения функциональности ИС будут выполняться путем "манипулирования записями в РБД" (отдельный разговор о методах объектов - есть несколько вариантов, не противоречащих вышесказанному) через, раз и навсегда сделанный, универсальный клиентский интерфейс (или стандартный вэб-клиент).
Если же, как Вы писали, "объекты у Вас будут существовать в клиентском приложении, и на низком уровне реализации, в методах объектов, там будет код, помещающий/считывающий данные в РСУБД", то Вам придется (в общем случае) каждый раз, при изменении требований к Вашей ИС и реализации этих требований в объектной модели приложения, и заниматься дальнейшей частью цикла разработки-сопровождения - перекомпилляцией, отладкой, тестированием, переинсталляцией приложения у всех пользователей...
Всего этого можно избежать в первом случае, перенеся процесс изменения ИС только на работу с ОРБД.
Можно это назвать ленью, а можно - сокращением издержек на разработку-сопровождение ИС.
Убедил на счет уровня абстракции?
Не-а, не убедил.
По-моему, Вы сразу потеряете так ВСЕ возможности, предоставляемые РСУБД, кроме возможности тупо хранить данные объекта и искать его по первичному ключу.
...
Рейтинг: 0 / 0
28.01.2005, 19:11
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890218
MMS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MMS
Гость
Гостю
\\\Вы заблуждаетесь. Способ хранения не обязан быть связан с методом визуализации

В чем заблуждаюсь? Я же написал "это НЕ способ хранения данных, а метод визуализации их местонахождения". Именно такой подход позволит непрограммеру получать новые функциональности (через визуализацию), не трогая структуры записей в СУБД. Надстройка и СУБД могут быть полностью развязаны, стыкуясь только по ID.
Скажем так: СУБД хранит сам ОЛАП, а ИК представляет собой стандартизованный сборник разрезов этого ОЛАПа. Только не в виде плоских шаблонов отчетов

adisk
C программерами намного легче ладить, чем с манагерами :-)
Формализованные мозги в коммуникациях дают совсем иное качество понимания, даже без знаний в предметной области. Бросайте опасения :-)

Скороходу
Пост АСУ заметил, в этой проблематике давно. Не люблю рассуждать про инкапсуляции и прочие суперпозиции. Если не стремиться к идеальному качеству классификации (которое невозможно), то вполне реально создавать ИК с качеством "достаточным для инженерных расчетов"; их может быть несколько (на любителя) - каждый со своими проколами. Дальше-вопрос привычки.
С наследованием никогда проблем не было, ограничивался набором конкретных признаков объекта и не залазил в дебри.
...
Рейтинг: 0 / 0
28.01.2005, 19:28
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890261
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
MMSГостю
Поисковые семантические надстройки над Сетью просто лучше ищут нужное в мусорной куче информации. ИК может работать с "обратной стороны", складывая информацию так, чтобы она не образовывала мусорных куч-тогда качество и процессы поиска будут другими.
Мне нужен не "разгребальщик", а "укладчик". В начале топика были высказывания типа "Вот сделал такую фигню (по моему разумению-пробу создания инструментов ИК) , не знаю зачем" - мне показалось в этом можно найти полезное взаиморазумение или хотя бы получить наводку. Очень, знаете ли, не хочется велосипедов изобретать. Тем более, что отношусь к группе 1 :-)
У меня быстро и успешно внедрены две системы управления на АЭС, ИК составляет их основу. Поскольку использовались местные программеры, возможно, они не использовали современных средств (опирающихся на ИК) и я пытаюсь выяснить, существуют ли таковые.
Высказывание академика под сомнение не ставлю. Однако оно может означать лишь отсутствие прогресса в официальной науке, программерские же разработки могут находиться вне ее, либо засекречиваться.

Я не спец в средствах автоматизации и бОльшей части слов в этом топике не понимаю. Но хорошо знаю предмет приложения этих средств и всегда стараюсь упрощать программирование за счет упрощения задач. Поэтому, пожалуйста, давайте попытаемся говорить на языке, позволяющем общаться не тыча в морду интеллектом :-)
Задам свои вопросы иначе:

1. Существует ли ПО, которое не будучи неотъемлемой принадлежностью СУБД могло бы выстраивать ИК так, чтобы связать (пусть вручную) концы ветвей деревьев ИК с объектами, описанными в произвольной СУБД?
2. Вызывает ли ИК-надстройка над СУБД резкий рост требований к ресурсам?
3. Если стандартных решений нет, но есть собственные наработки-давайте свяжемся по мылу, поскольку на таковые имеется заказчик, хотя и не стопроцентный

Пункт '3' меня заинтересовал, если это взаимно, то пишите на мыло, здесь тусоваться считаю для себя малопродуктивным.
По пункту '1' - ответ положительный,
по пункту '2'-отрицательный. Разумеется эти данные экспериментальные, а не голая теория.
...
Рейтинг: 0 / 0
28.01.2005, 20:11
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32891235
Рус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рус
Участник
EJB или JDO - вот вам и объектная надстройка над СУБД. Не изобретайте велосипед, господа!
...
Рейтинг: 0 / 0
30.01.2005, 17:46
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32891916
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Rovdo
Гость
РусEJB или JDO - вот вам и объектная надстройка над СУБД. Не изобретайте велосипед, господа!

Все не так просто в этом топике. Господа хотят больше, чем дает типовой O/R-мэппинг. И при этом хотят во что бы то ни стало работать только с тем инструментарием, который доступен в составе существующих РСУБД (т.е. использовать JDO в качестве отправной точки в своих разработках они не считают возможным).
И если первое я могу понять, то причины второго я так и не осознал (впрочем, возможно я и не очень старался, а с другой стороны - каждый имеет право распоряжаться своим временем как пожелает).
...
Рейтинг: 0 / 0
31.01.2005, 11:42
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32891959
Фотография 4d_monster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4d_monster
Участник
IMHO, ООСУБД - не подходят, потому-что для всей системы будет только один класс, у которого из атрибутов - коллекция значений аттрибутов...

IMHO, Mon$te®
...
Рейтинг: 0 / 0
31.01.2005, 11:57
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32891996
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
4d_monster IMHO, ООСУБД - не подходят, потому-что для всей системы будет только один класс, у которого из атрибутов - коллекция значений аттрибутов...

IMHO, Mon$te®
Ну тогда весь этот странный топик - про серверы бизнес-логики. Кому нужен универсальный сервер, в котором можно прописывать возможные алгоритмы обработки атрибутов объектов и коллекций объектов, да еще так чтобы это все осмысленно хранилось и эффективно обрабатывалось в РСУБД?
Маниловщина это всё.
...
Рейтинг: 0 / 0
31.01.2005, 12:08
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32892026
Фотография 4d_monster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4d_monster
Участник
Мне на пример :-)

а вот "осмысленно хранилось" мне не требуется :), достаточно чего-то типа варианта adisk`a

IMHO, Mon$te®
...
Рейтинг: 0 / 0
31.01.2005, 12:19
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32892062
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
4d_monsterМне на пример :-)

а вот "осмысленно хранилось" мне не требуется :), достаточно чего-то типа варианта adisk`a

IMHO, Mon$te®

А тогда при чем тут РСУБД - хоть вы в файлах объекты храните и нумеруйте их файл0001.ххх, хоть в РСУБД, так и так "не осмысленно".
...
Рейтинг: 0 / 0
31.01.2005, 12:29
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32892137
Фотография 4d_monster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4d_monster
Участник
не то, нодопоняли, хранить естественнов РСУБД,
но "осмысленное хранение" подразуменвает хранение в таблицах с осмысленными названиями, с осмысленно названными полями. а это мне не нужно

IMHO, Mon$te®
...
Рейтинг: 0 / 0
31.01.2005, 12:50
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32892159
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
4d_monsterне то, нодопоняли, хранить естественнов РСУБД,
но "осмысленное хранение" подразуменвает хранение в таблицах с осмысленными названиями, с осмысленно названными полями. а это мне не нужно

IMHO, Mon$te®
Я имел в виду хранение в осмысленной структуре данных, учитывающей алгоритмы обработки - с построением полезных индексов, с нормализацией в разумных пределах.
Иначе для чего Вам РСУБД? Ни для чего. А как именовать поля - дело десятое, если Вы до такого уровня опускаться не собираетесь.
...
Рейтинг: 0 / 0
31.01.2005, 12:57
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32899756
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Кто-то спрашивал про базу данных ген.
Загляните.
http://gmod.sourceforge.net/
Возможно поможет.
...
Рейтинг: 0 / 0
03.02.2005, 16:39
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32899916
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
В недрах sf.net обнаружена интересная СУБД.
MonetDB http://monetdb.sourceforge.net/

Представьте себе базу в которой проведена полная декомпозиция.
Все поля таблиц разделены.
Другими словами: модель Тенцера (attribs+objects) разделенная на много таблиц.
Для каждого атрибута своя таблица.
...
Рейтинг: 0 / 0
03.02.2005, 17:36
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32900104
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Описания ядра системы
http://monetdb.cwi.nl/TechDocs/Core/monet/index.html
и плагаю схемку с сайта.
...
Рейтинг: 0 / 0
03.02.2005, 18:35
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32901320
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
Для каждого атрибута своя таблица.

Наверное для каждого типа атрибута своя таблица?
Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
04.02.2005, 13:49
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32901429
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
Своя таблица для каждого атрибута, а не типа!!!
Полная противоположность вариантам организации О. ядра системы на РСУБД, которые ранее упоминались в этом топике. ("горизонтальный" и "вертикальный" O-R маппинг)
imho на первый взгляд скорость доступа к атрибутам в отдельных таблицах съедается увеличением сложности методов O-R ядра. Или я не прав?
...
Рейтинг: 0 / 0
04.02.2005, 14:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32917315
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
ASUВ раннем творчестве А. Макаревича была песня "Битва с дураками", она заканчивается словами:
Код: plaintext
1.
2.
3.
Когда последний дурак упал,
Труба победу проиграла.
И лишь тогда я осознал,
Насколько нас осталось мало.
Экзюпери говорил, что стоит только начать бороться с горбунами, как станет заметно, что действительно прямоходящих людей очень мало...
Александр Сергеевич, уж не ожидал вас встретить на этом форуме, но тем приятнее :)
Бог с ним, с маппингом, я почитал - слишком много нестыковок уже на понятйном уровне. А нет ли у вас желания продолжить статью о СУПе ?
http://www.arbinada.com/modules.php?name=Content&pa=showpage&pid=22
...
Рейтинг: 0 / 0
15.02.2005, 21:05
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32917317
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
skorohodСвоя таблица для каждого атрибута, а не типа!!!
Полная противоположность вариантам организации О. ядра системы на РСУБД, которые ранее упоминались в этом топике. ("горизонтальный" и "вертикальный" O-R маппинг)
imho на первый взгляд скорость доступа к атрибутам в отдельных таблицах съедается увеличением сложности методов O-R ядра. Или я не прав?
"Вертикального" OR-маппинга не бывает.
...
Рейтинг: 0 / 0
15.02.2005, 21:06
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32917325
baza
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baza
Участник
Templar skorohodСвоя таблица для каждого атрибута, а не типа!!!
Полная противоположность вариантам организации О. ядра системы на РСУБД, которые ранее упоминались в этом топике. ("горизонтальный" и "вертикальный" O-R маппинг)
imho на первый взгляд скорость доступа к атрибутам в отдельных таблицах съедается увеличением сложности методов O-R ядра. Или я не прав?
"Вертикального" OR-маппинга не бывает.

Забавно слышать такие заявления, когда я каждый день работаю с продуктом, в настройках которого есть маппинг: "горизонтальный/вертикальный/смешанный"
...
Рейтинг: 0 / 0
15.02.2005, 21:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32917326
baza
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baza
Участник
Поле --> Strategy :)
...
Рейтинг: 0 / 0
15.02.2005, 21:16
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32917362
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
BaZaЗабавно слышать такие заявления, когда я каждый день работаю с продуктом, в настройках которого есть маппинг: "горизонтальный/вертикальный/смешанный"
Тут я ничего нового не скажу :) Вертикальный иаппинг, конечно, бывает, только он не реляционный в силу определения реляционной модели :)
...
Рейтинг: 0 / 0
15.02.2005, 22:10
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32918595
baza
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baza
Участник
Так тут, по-моему речь и идет об ОБЪЕКТНОЙ надстройке на РСУБД. а маппинг он всегда объектно-реляционный...
...
Рейтинг: 0 / 0
16.02.2005, 14:26
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32918986
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
BaZaТак тут, по-моему речь и идет об ОБЪЕКТНОЙ надстройке на РСУБД. а маппинг он всегда объектно-реляционный...
Маппинг, он объектно-"чегототам". Вертикальное хранение атрибутов - это не реляционная модель, а "чегототам"-модель, реализованная средствами РСУБД, то есть тройной маппинг получается:
объектно-чегототам-реляционный :)
...
Рейтинг: 0 / 0
16.02.2005, 16:26
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919131
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Согласен, Templar.

Только не "чегототам", а вполне конкретон - в "вертикальном" (как его тут называют) маппинге в РБД отображаются данные в терминах используемой в ОО-программе системе базовых (например - int, char, float и т.д.)типов - то есть фактически в системе типов поддерживаемой даже не ОО-программой, а машиной , на которой выполняется эта ОО-программа. Соответсвенно от возможностей РСУБД, обуславливаемых очень во многом тем, что она реализует типы-отношений,остаются рожки и ножки.
...
Рейтинг: 0 / 0
16.02.2005, 17:04
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919250
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
U-geneТолько не "чегототам", а вполне конкретон
Да я просто не в курсе, как такая модель на академическом языке называется. Видимо, никак.
А схему вертикального хранения атрибутов тоже обсуждали несколько лет назад горячие парни :) Некоторые даже успешно реализовали в своих проектах, благо, например, задачка версионности (темпоральная БД) решается "на раз". Зато с запросами беда, у оптимизатора крышу сносит :)
...
Рейтинг: 0 / 0
16.02.2005, 17:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919269
baza
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baza
Участник
я согласен со всем, что здесь говориться, однако мне кажется, что когда говорят "объектно-реляционный" маппинг, имеют ввиду преобразование сопоставляющее объектам вашего приложения реляционную схему их хранения.

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

а что там происходит между "объектно-.................... и .................. -реляционный" это уже дело каждого из нас, кому как больше нравится, и как это называется по науке я тоже не знаю :)
...
Рейтинг: 0 / 0
16.02.2005, 17:44
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919334
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
авторпричем
вертикальный маппинг — это когда для классов потомков создается новая таблица,

... в моем воспаленном воображении термин "вертикальный маппинг" как-то по другому представился....просто некоторые пытаютя по-атрибутно объекты в разные таблицы запихивать... типа одна таблица на все атрибуты типа int всех объкетов, другая на все char....пятью таблицами обходятся.... но раз уж есть такой общепризнанный термин, то сорри, ежели кого обидел.
...
Рейтинг: 0 / 0
16.02.2005, 18:05
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919345
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
BaZa вертикальный маппинг — это когда для классов потомков создается новая таблица,
горизонтальный — это когда для класса потомка не создается новая таблица, а все поля появляются в той же таблице, где хранится родитель.

По моему, это таки называется не "вертикальным/горизонтальным", а complete/incomplete subtyping с возможностями roll-up (атрибуты подкласса в новой таблице) и roll-down (атрибуты добавляются к таблице суперкласса).

Обычно термин "вертикальный/горизонтальный" относится к хранению атрибутов (построчно/постолбцово).
...
Рейтинг: 0 / 0
16.02.2005, 18:09
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919394
baza
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baza
Участник
Мда, что-то недопонимание какое-то:

With flat mapping fields from the subclasses are mapped to the superclass table. Flat mapping is the simplest and usually fastest option so it is the default.

Flat - это по-нашему Горизонтальный

With vertical mapping each class has its own table containing only its fields.

С vertical, думаю, все понятно :)

ЗЫ ЧесСлово, не я это придумал, так в книгах пишут ГуРу (и иногда в инете)
...
Рейтинг: 0 / 0
16.02.2005, 18:30
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919459
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
BaZaWith flat mapping fields from the subclasses are mapped to the superclass table. Flat mapping is the simplest and usually fastest option so it is the default.
Flat - это по-нашему Горизонтальный

Flat вроде всегда "плоским" был :)
Flat file - это когда вся БД в одном файле (в эпоху DBF). Для реляционки - вся база в одной таблице.
Это одна из трех схем маппинга:
1. Соединение всех атрибутов в единой сущности
2. Группировка общих атрибутов в одном отношении и разнесение уникальных атрибутов по различным вспомогательным отношениям;
3. Представление каждой сущности в виде отдельного отношения

текст статьи 1994 года :)
...
Рейтинг: 0 / 0
16.02.2005, 19:04
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919469
baza
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baza
Участник
Это мы говорим горизонтальный, а ОНИ (забугорные) говорят FLAT.
Я просто хочу узнать совпадает ли приведенное мной определение с Вашими...
:)
...
Рейтинг: 0 / 0
16.02.2005, 19:11
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919496
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
BaZaЭто мы говорим горизонтальный, а ОНИ (забугорные) говорят FLAT.
Я просто хочу узнать совпадает ли приведенное мной определение с Вашими...
:)
Определение совпадает, а термин "горизонтальный" - нет :) Ну, я вообще вряд ли перевел бы flat как "горизонтальный" в таком контексте.
...
Рейтинг: 0 / 0
16.02.2005, 19:23
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919514
baza
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baza
Участник
Главное что суть одна и та же, а кто как это называет, это уже их дело :)

Суть в том, что мы купили продукт в котором ГМ назван FLAT Mapping'ом

вот, еще раз:
...
Рейтинг: 0 / 0
16.02.2005, 19:30
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919529
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
BaZaГлавное что суть одна и та же, а кто как это называет, это уже их дело :)
Суть в том, что мы купили продукт в котором ГМ назван FLAT Mapping'ом
вот, еще раз:
Ага, это оно "Соединение всех атрибутов в единой сущности".
Предлагаю так и называть его "плоской проекцией".
А можно аналогичную картинку для других типов посмотреть ?
Можно даже прямо на мыло serge@arbinada.com
...
Рейтинг: 0 / 0
16.02.2005, 19:39
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919549
baza
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baza
Участник
Templar BaZaГлавное что суть одна и та же, а кто как это называет, это уже их дело :)
Суть в том, что мы купили продукт в котором ГМ назван FLAT Mapping'ом
вот, еще раз:
Ага, это оно "Соединение всех атрибутов в единой сущности".
Предлагаю так и называть его "плоской проекцией".
А можно аналогичную картинку для других типов посмотреть ?
Можно даже прямо на мыло serge@arbinada.com

Вот они: (продублирую на мыло)

Вертикальный:
...
Рейтинг: 0 / 0
16.02.2005, 19:47
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919550
baza
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baza
Участник
и Смешанный:
...
Рейтинг: 0 / 0
16.02.2005, 19:48
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32919593
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
BaZaи Смешанный:
Ага, спасибо.
Термин "вертикальный", конечно неудачный, но что же поделать, если авторы продукта так решили. Это обычный incomplete subtyping. Ну, у них и mixed тут не вписывается в классификацию. Видимо, это некоторое настраиваемое промежуточное положение между incomplete и complete subtyping-ом.
...
Рейтинг: 0 / 0
16.02.2005, 20:29
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935269
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Как ни крути модель Тенцера очень хороша.

К примеру:
Простой домохозяин(ка) не смыслящий в БД и нормализации занялся
учетом средств.

10.00 03/01/2005 Черный хлеб Хлеб Хлебобулочные
10.00 03/01/2005 Батон Хлеб Хлебобулочные
15.00 03/01/2005 Фанта Газ.вода Напитки
25.00 03/01/2005 Пиво Пиво Алкоголь
75.00 03/01/2005 Водка "Минал" Водка Алкоголь

Специально умалчиваю про нормализацию, ведь можно добиться корректного ввода
данных, просмотрев вышестоящие строчки и предложив выбрать из них. Или занести
новые данные.

Можно ли в Excel сделать такую базу данных? Конечно.
Плюсы за Excel:
1. наглядно
2. автофильтры (для простых запросов)
3. есть мастер сводной таблицы (для запросов с группировками)
4. подсказка из занесенных ранее значений
5. реализована печать
6. есть поиск/замена
7. автосохранение
8. легко переносится на любую машину
9. легко делается резервная копия
10. цвета, шрифты, графики...
11. можно "на ходу" заносить дополнительные атрибуты (поля)


Теперь сохраняю это "чудо-творение" в формате SYLK (*.slk).
Полученный файл открываю текстовым редактором:
...
C;X1;Y14;K10
C;X2;Y14;K38355
C;X3;Y14;K"Батон"
C;X4;Y14;K"Хлеб"
C;X5;Y14;K"Хлебобулочные"
C;X1;Y15;K15
C;X2;Y15;K38355
C;X3;Y15;K"Фанта"
C;X4;Y15;K"Газ.вода"
C;X5;Y15;K"Напитки"
C;X1;Y16;K25
C;X2;Y16;K38355
C;X3;Y16;K"Пиво"
C;X4;Y16;K"Пиво"
C;X5;Y16;K"Алкоголь"
C;X1;Y17;K75
C;X2;Y17;K38355
C;X3;Y17;K"Водка ""Минал"""
C;X4;Y17;K"Водка"
C;X5;Y17;K"Алкоголь"

Плоская таблица хранящаяся в 4-х столбцах.
Что-то напоминает, не так ли?

Данные хранятся в ОДНОМ (последнем) столбце - это значения атрибутов.
Второе поле (X1,X2,X3,...) - это код атрибута.
Третье поле (Y14,Y15,...) - это код объекта.
Все данные хранятся в ОДНОМ файле.

Дальнейшее увеличение полей или строк исходной таблицы не повлияет
на количество полей в slk-файле!
Такой вот формат ;)

Осталось нормализовать (???) и добавить связи (LINKS) ;)

Если нужно хранить doc, mp3, exe-файлы - используем последний столбец.
Excel такой файл уже не прочитает, но это проблемы MicroSoft.

В итоге опять же:
...
Рейтинг: 0 / 0
27.02.2005, 06:45
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935351
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
adiskКак ни крути модель Тенцера очень хороша.

К примеру:
Простой домохозяин(ка) не смыслящий в БД и нормализации занялся
учетом средств.
Оставив в стороне вопрос авторства, следует дождаться момента, когда домохозяин, наконец, начнет думать: "А зачем мне все эти данные ?" С последующими попытками получить по ним хоть какую-то аналитику.
...
Рейтинг: 0 / 0
27.02.2005, 13:03
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935415
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
templarОставив в стороне вопрос авторства, следует дождаться момента, когда домохозяин, наконец, начнет думать: "А зачем мне все эти данные ?" С последующими попытками получить по ним хоть какую-то аналитику.

?

Не понял к чему это ты.
...
Рейтинг: 0 / 0
27.02.2005, 15:28
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935433
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
adisk?
Не понял к чему это ты.
К вопросу "А зачем вести данные". Очевидно, чтобы потом в них что-то искать.
...
Рейтинг: 0 / 0
27.02.2005, 16:08
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935441
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
Обсуждение вертикального хранения в фидо 4 года назад

Даже скопирую сосбтвенный мессадж для ленивых
1. Общие мысли, не в плане критики Вас лично или статьи, просто наболело.
Думаю, что не открою ни для кого секрета в эхе, что в структуру типа:

Сущности(ID_сущности, Название_в_предметной_области)
Атрибуты(ID_сущности, ID_атрибута, Название_в_предметной_области)
Экземпляры(ID_сущности, ID_Экземпляра)
Значения(ID_сущности, ID_Экземпляра, ID_атрибута,
Дата_установки/изменения_значения, Значение_с_указанной_даты)

можно впихнуть все (или почти все) объекты реального мира с историей их
изменений.
Для получения информации из такой структуры будет достаточно даже начального
уровня стандарта SQL.

Вопрос. Какая модель данных и ее физическая реализация это потянет?

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

Вопрос не менее интересный: почему при таком очевидно простом решении (4
педали и пара рычагов) никто за 30 лет не добился промышленных результатов?
Иными словами, почему мы до сих пор сидим на реляционке, если все задачи
решаются четырьмя сущностями?

2. По статье, очень бегло.
2.1. Модели и так отделены от средств реализации. Но это не значит, что
данная модель будет одинаково хорошо реализована разными средствами.
2.2. "Блочный" подход в стиле hardware-компонентов тоже не стал панацеей,
хотя и занял свое место. Тому есть несколько причин:
(1) в hardware имеем прохождение сигнала со скоростью тактовой частоты
(цифра) или света (аналог), в то время как в software время отклика на
выходе практически всегда зависит от поданной на вход информации.
(2) число возможных состояний конечного автомата в не самом сложном
бизнес-software-компоненте на порядки выше, чем в hardware-микросхеме.
Протестировать все состояния не представляется возможным за разумное время.
А если возможно, то это относительно простые компоненты вроде вычисления
математических функций или STL, для которых, опять таки, верен п(1).
Таким образом, собрав из кучи микросхем устройство мы уверены, что оно будет
работать с единой тактовой частотой. Собрав из кучи компонентов программу мы
не можем даже приблизительно оценивать время отклика на выходе.
2.3. "Прошло время программ - "черных ящиков с большой красной кнопкой" -
это противоречит принципу инкапсуляции. Она - как беременность, либо есть,
либо ее нет.


--
Открытая SmallERP / Архитекторы программных систем
...
Рейтинг: 0 / 0
27.02.2005, 16:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935472
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> что в структуру типа

Процентов десять реальных объектов такой структурой можно описать. И?

> почему при таком очевидно простом решении

А потому что это неправильное решение некорректной задачи. Не имеет оно ничего общего с реальным положением вещей. Чего для его тиражировать?
...
Рейтинг: 0 / 0
27.02.2005, 18:32
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935500
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
guest_20040621
Процентов десять реальных объектов такой структурой можно описать. И?
Описать-то можно процентов 100.

А потому что это неправильное решение некорректной задачи. Не имеет оно ничего общего с реальным положением вещей. Чего для его тиражировать?
Это решение эффективно по некоторым критериям. Не более. Собсно, в этом и был мессадж для adisk.
...
Рейтинг: 0 / 0
27.02.2005, 19:30
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935524
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Описать-то можно процентов 100.

Поправочка: адекватно описать. Независимых сущностей - для которых эта схема будет приемлема - и будет десять процентов. Очень оптимистично. А для остальных девяноста процентов - ну совсем не покатит такая схема. Т. е. абсолютно.

> Это решение эффективно по некоторым критериям. Не более.

Начнем с того, что оно ошибочно по сути. Как минимум потому, что ни сущность, ни атрибуты не зависят от предметной области.
...
Рейтинг: 0 / 0
27.02.2005, 20:20
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935538
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
guest_20040621Поправочка: адекватно описать. Независимых сущностей - для которых эта схема будет приемлема - и будет десять процентов. Очень оптимистично. А для остальных девяноста процентов - ну совсем не покатит такая схема. Т. е. абсолютно.
Эта схема адекватно описывает 100% сущностей, их атрибуты, классификацию и связи между ними. Проблема в приемлемой реализации использования этих описаний. Возможно, для 10% она существует, хотя, согласен, это оптимистичная оценка.

Начнем с того, что оно ошибочно по сути. Как минимум потому, что ни сущность, ни атрибуты не зависят от предметной области.
Схема не привязана к предметной области. Атрибуты, точнее их подмножество, зависят от моделируемой предметной области.
...
Рейтинг: 0 / 0
27.02.2005, 20:46
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935550
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Эта схема адекватно описывает 100% сущностей, их атрибуты, классификацию и
> связи между ними.

Пальцем ткните, чего темнить: как именно с помощью четырех (я правильно посчитал?) перечисленных таблиц описаны связи и классифицированы сущности. Очень интересно, чесслово. Особенно в контексте предметных областей.

> Схема не привязана к предметной области.

А "Название_в_предметной_области" тогда зачем? Чтобы врагов запутать?

> Атрибуты, точнее их подмножество, зависят от моделируемой предметной области.

Опаньки, это что-то новое. Можно подробнее, каким образом?
...
Рейтинг: 0 / 0
27.02.2005, 21:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935562
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
guest_20040621Пальцем ткните, чего темнить: как именно с помощью четырех (я правильно посчитал?) перечисленных таблиц описаны связи и классифицированы сущности. Очень интересно, чесслово. Особенно в контексте предметных областей.
Так вы обсуждаете мое давнее тезисное сообщение с целью непосредственного использования ? Разочарую вас - оно имело собой другую цель.
Возьмите картинку со схемой на предыдущей странице, в которой эта же схема уже детализована для использования.
Тыкаю в эту картинку: берете ваши сущности и заносите в таблицы "Классы", "Атрибуты" и "Типы связей".


А "Название_в_предметной_области" тогда зачем? Чтобы врагов запутать?
Чтобы моделировать предметную область или несколько смежных в контексте.

Опаньки, это что-то новое. Можно подробнее, каким образом?
У сущности есть множество атрибутов. Для моделирования предметной области нам в общем случае не нужны все атрибуты множества.
...
Рейтинг: 0 / 0
27.02.2005, 22:28
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935584
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Так вы обсуждаете мое давнее тезисное сообщение с целью непосредственного
> использования ?

Ну нет конечно же.

> Тыкаю в эту картинку: берете ваши сущности и заносите в таблицы "Классы",
> "Атрибуты" и "Типы связей".

Понятно. Это уже было. В треде про сервер объектного представления. Из реляционной СУБД сделали... полное непотребство. Для какой цели, позвольте поинтересоваться? Что, это сильно удобно? Или сильно производительно? Или, может, переносимость идеальная?

> Чтобы моделировать предметную область или несколько смежных в контексте.

А что, у Вас _сущности_ от контекста зависят? Сильно.

> У сущности есть множество атрибутов. Для моделирования предметной области
> нам в общем случае не нужны все атрибуты множества.

Правильно, не нужны. Но сами-то атрибуты не начали зависеть от предметной области, правда?
...
Рейтинг: 0 / 0
28.02.2005, 00:18
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935591
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
guest_20040621Понятно. Это уже было. В треде про сервер объектного представления. Из реляционной СУБД сделали... полное непотребство. Для какой цели, позвольте поинтересоваться? Что, это сильно удобно? Или сильно производительно? Или, может, переносимость идеальная?
Ссылка приведена, читайте обсуждение. Вкратце: это она их схем маппинга объектов. Расширяемая без изменения структуры БД. Унификация связей. Метаданные.

А что, у Вас _сущности_ от контекста зависят? Сильно.
Похоже у вас "название сущности в предметной области" и "сущность" каким-то образом тождественны. Вот это, действительно, сильно :)

Правильно, не нужны. Но сами-то атрибуты не начали зависеть от предметной области, правда?
См. выше про "множество атрибутов".
...
Рейтинг: 0 / 0
28.02.2005, 00:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32935605
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Ссылка приведена, читайте обсуждение.

Уже. Что я, по-Вашему, должен вынести из этого обсуждения?

Ну, наваял себе А. Тенцер что-то монстроподобное. Я уже говорил, что для работодателей г-на Тенцера - это мина замедленного действия. Которая бабахнет, когда г-ну Тенцеру вздумается уволиться. Видимо, их это устраивает. Очень хорошо, это исключительно их проблемы (в смысле, работодателей).

Повторяю вопрос: Вы-то свою схему реализовали для какой цели? Это сильно удобно? Или сильно производительно? Или, может, переносимость идеальная? В чем фишка-то, поделитесь?

> Похоже у вас "название сущности в предметной области" и "сущность" каким-то
> образом тождественны.

Хм... как имя может быть тождественно сущности? Для Вашего примера "название сущности в предметной области" - бессмысленное буквосочетание.

> См. выше про "множество атрибутов".

Спасибо, я это уже читал. Вопрос в силе.
...
Рейтинг: 0 / 0
28.02.2005, 01:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32936172
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
guest_20040621Повторяю вопрос: Вы-то свою схему реализовали для какой цели? Это сильно удобно? Или сильно производительно? Или, может, переносимость идеальная? В чем фишка-то, поделитесь?
Мы делали подобное в 1996 как расширение для бизнес-админа.
В системе обычный маппинг на таблицы, реализуемый прикладным программстом. Для добавления новых классов/атрибутов использовалась вертикальная схема. Админ, без программирования, за 5 минут добавлял классу новый атрибут, который тут же появлялся во всех динамических формах, металанных и построителях запросов/отчетов. Да, это для него "сильно удобно". Это "сильно удобно" для прототипирования. В этом и "фишка".

Хм... как имя может быть тождественно сущности? Для Вашего примера "название сущности в предметной области" - бессмысленное буквосочетание.
О тождественности говорили вы, лихо перейдя с "названия в предметной области" на "зависимость сущности от предметной области". Вам и разбираться в своих логических построениях.


> См. выше про "множество атрибутов".
Спасибо, я это уже читал. Вопрос в силе.
Ответ тоже в силе. См.выше. Или см. в словаре про "тезаурус" и "синонимичные ключевые слова".
...
Рейтинг: 0 / 0
28.02.2005, 12:30
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32936340
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Да, это для него "сильно удобно". Это "сильно
> удобно" для прототипирования. В этом и "фишка".

В обмен на imho весьма сомнительную гибкость Вы намертво привязали приложение к СУБД, получили абсолютно неудобную архитектуру и максимально геморройный для сопровождения код. Великолепный результат.

> О тождественности говорили вы, лихо перейдя с "названия в предметной области"
> на "зависимость сущности от предметной области". Вам и разбираться в своих
> логических построениях.

Все предельно просто. Я вижу имя "название_в_предметной_области", из чего делаю вывод, что сущность может иметь разные имена для разных предметных областей. Я бы не стал это реализовывать, но теоретических проблем не вижу. Вместе с тем я вижу такую структуру данных, которая при таком подходе не позволит однозначно идентифицировать сущность без предметной области, что на мой взгляд является ошибкой.

> Ответ тоже в силе. См.выше. Или см. в словаре про "тезаурус" и "синонимичные
> ключевые слова".

Какой тезаурус и какие синонимичые ключевые слова? Как они связаны с атрибутами, позвольте поинтересоваться?
...
Рейтинг: 0 / 0
28.02.2005, 13:25
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32936472
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
guest_20040621В обмен на imho весьма сомнительную гибкость Вы намертво привязали приложение к СУБД, получили абсолютно неудобную архитектуру и максимально геморройный для сопровождения код. Великолепный результат.
Позвольте сначала поинтересоваться, где вам удалось увидеть в такой схеме привязку к СУБД ?
...
Рейтинг: 0 / 0
28.02.2005, 14:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32936671
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Позвольте сначала поинтересоваться, где вам удалось увидеть в такой схеме
> привязку к СУБД ?

Нигде. Я сопоставил Ваше описание, тред "реализация сервера объектного представления", время выхода статьи и время обсуждения.
...
Рейтинг: 0 / 0
28.02.2005, 15:18
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32936733
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
guest_20040621Нигде. Я сопоставил Ваше описание, тред "реализация сервера объектного представления", время выхода статьи и время обсуждения.
Раз нет привязки, то нет и вопросов.
Если хотите обсудить статью или архитектуру NEXUS - ссылки были даны.
...
Рейтинг: 0 / 0
28.02.2005, 15:38
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937007
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Не могу смотреть как спорят два умных человека.
Вмешаюсь и получу тумаков от обоих...
И вмешиваюсь:

Для наглядности прилагаю схемку. (по описанию templar)
Очень хочу разобраться.
Как тут описать связь рабочего и цеха.

Рабочий работает в цехе.
В реляционной БД: добавим к данным рабочего код цеха.
В модели Тенцера: добавим строку в таблицу связей (LINKS).
А тут как?
...
Рейтинг: 0 / 0
28.02.2005, 17:13
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937024
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Раз нет привязки, то нет и вопросов.

Хех, ну это Вам кажется, что вопросов нет. ОК, забыли о реализации. Остановились на схеме.

Так какой, говорите, тезаурус используется в схеме? Как описаны предметные области? Как реализована локализация? Как локализация связана с тезаурусом? Как реализовано разделение доступа?

> Если хотите обсудить статью или архитектуру NEXUS - ссылки были даны.

Нет, не хочу. Во-первых, не хочу никуда ходить. Если Вам интересно - обсуждайте это в треде, к которому присоединились или который создали самостоятельно. Как минимум невежливо куда-то отсылать оппонента. Во-вторых, предмет обсуждения хм... ну не вызывает желания его обсуждать. Единственный вопрос, на который хотелось бы получить ответ, это "зачем?". Я не могу придумать ни одной рациональной причины (иррациональные, думаю, Вам неинтересны).
...
Рейтинг: 0 / 0
28.02.2005, 17:18
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937038
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Про ту же "новую" схему.
Я бы сделал две даты "дата_начала_действия" (создания/изменения) и "дата_окончания_действия" (удаления).
А то узнать, что данные удалены?
...
Рейтинг: 0 / 0
28.02.2005, 17:22
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937180
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
guest_20040621Хех, ну это Вам кажется, что вопросов нет. ОК, забыли о реализации. Остановились на схеме.
Это хорошо что вы забыли о реализации.

Так какой, говорите, тезаурус используется в схеме? Как описаны предметные области? Как реализована локализация? Как локализация связана с тезаурусом? Как реализовано разделение доступа?
Напоминаю, мы о ней забыли.
Для вышеназванного в ядро добавится десяток таблиц.
...
Рейтинг: 0 / 0
28.02.2005, 18:21
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937200
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
adiskДля наглядности прилагаю схемку. (по описанию templar)
Очень хочу разобраться.
Не нужно тезисно приведенную схемку использовать как рабочую даже в первом приближении. Если хотите использовать, то нужно проектировать ее под ваши системные требования.
Смысл дискуссии по ссылке состоит совсем в другом: универсальность схемы оборачивается проблемами с выборкой данных даже по простым условиям как по скорости, так и по сложности запросов.
Получается неряляционная (вертикальная) модель хранения, реализованная реляционными средствами.
...
Рейтинг: 0 / 0
28.02.2005, 18:26
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937233
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
А, Сергей, ты здесь ? Брось ты этот топик, что тебе-то здесь ловить ?
Пусть молодые вон упражняются в словоблудии.
Я как увидал эту бодягу на 10*N страниц - сразу все понял.
...
Рейтинг: 0 / 0
28.02.2005, 18:41
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937238
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
MasterZivА, Сергей, ты здесь ? Брось ты этот топик, что тебе-то здесь ловить ?
Пусть молодые вон упражняются в словоблудии.
Я как увидал эту бодягу на 10*N страниц - сразу все понял.
Да я вспомнил нашу давнюю дискуссию в фидо , кстати, и с твоим участием :) и запостил ссылку, в надежде, что людям полегчает :)
...
Рейтинг: 0 / 0
28.02.2005, 18:44
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937242
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Напоминаю, мы о ней забыли.

Про реализацию. А про схему никто не забывал. Перечисленные задачи по крайней мере частично в схему вписываются очень даже.

> Для вышеназванного в ядро добавится десяток таблиц.

У Вас же уже есть четыре таблицы, зачем еще? Н-да... и здесь не получилось дискуссии.
...
Рейтинг: 0 / 0
28.02.2005, 18:48
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937253
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
guest_20040621Про реализацию. А про схему никто не забывал. Перечисленные задачи по крайней мере частично в схему вписываются очень даже.
и

У Вас же уже есть четыре таблицы, зачем еще? Н-да... и здесь не получилось дискуссии.
Если забыть про реализацию, то можно впихнуть и в 4.
Ну, потратить еще десяток страниц на тему "что первично", решая, как же внести класс "класс" если класса "класс" еще не существует (не описан). Потом на оптимальность. У всех будут свои критерии оптимальности. Что вам стоит. Думаю, и без меня управитесь.
...
Рейтинг: 0 / 0
28.02.2005, 18:56
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937325
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Если забыть про реализацию, то можно впихнуть и в 4.

Винегрет получится знатный. Покруче, чем у Тенцера.

> Ну, потратить еще десяток страниц на тему "что первично", решая, как же внести
> класс "класс" если класса "класс" еще не существует (не описан). Потом на
> оптимальность. У всех будут свои критерии оптимальности. Что вам стоит.
> Думаю, и без меня управитесь.

Хех, да дело не в том, управлюсь я или нет. На мой взгляд, предложенная Вами схема (о реализации молчим, как и договаривались) содержит принципиальные ошибки. Два варианта: либо Вы намеренно опустили некоторые объекты этой схемы (о чем, вообще говоря, нужно предупреждать), либо честно привели ошибочную схему (в чем я лично сомневаюсь).

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

А Вы - про первичность, оптимальность...
...
Рейтинг: 0 / 0
28.02.2005, 19:53
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937332
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
guest_20040621Кроме того, абсолютно неясны критерии (я уже задавал Вам этот вопрос) выбора собственно элементов метаописания. Почему они выбраны такими и в таком количестве? Какие объекты Вы получили в результате? С какими свойствами? Какие операции и для какой цели вы реализовали для Вашей схемы?
Опять про реализацию ?
Придется повторить еще раз и последний: схема была написана мной "на коленке" и приведена в сообщении в фидо несколько лет назад для дискуссии на тему "как хреново с такой схемой жить, если нужно делать сложные выборки" и "почему за 30 лет никто из производителей СУБД не удосужился реализовать такой подход".
Если хотите обсуждать реализацию и проектирование такой схемы - вопросы к Тенцеру.
Мы не делали полной реализации, мы добавили похожую усеченную схему для создания расширений непрограммистом. Это совершенно конкретная и ограниченная задача. Все.
Почему выбрано такие метаописания, а не другие - потому что у нас были такие требования к системе, а не другие. Не нужна нам была ни многоязычность, ни "многоименность" сущностей в разных предметных областях. Система безопасности тут вообще боком стояла. Кому нужно, думаю, сами догадаются, как все это поддержать в рамках схемы.
...
Рейтинг: 0 / 0
28.02.2005, 20:07
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937442
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Опять про реализацию ?

Старательно избегаю.

> Это совершенно конкретная и ограниченная задача. Все.

Семён Семёныч... Чего ж я тогда к Вам пристал? Вопросы снимаются. Я-то по наивности подумал (и беглый взгляд на Nexus это вроде как бы и подтвердил), что Вы говорите о законченном решении, а оно, оказывается, и не так вовсе...

> Кому нужно, думаю, сами догадаются, как все это поддержать в рамках схемы.

Это понятно. Жаль, тема по-настоящему интересная.
...
Рейтинг: 0 / 0
28.02.2005, 22:19
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937488
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
guest_20040621Я-то по наивности подумал (и беглый взгляд на Nexus это вроде как бы и подтвердил), что Вы говорите о законченном решении, а оно, оказывается, и не так вовсе...
Теперь впору мне удивляться и спрашивать, а что за зверь такой "законченное решение" и почему, например, Nexus туда не относится ?
...
Рейтинг: 0 / 0
28.02.2005, 23:34
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937514
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Теперь впору мне удивляться и спрашивать, а что за зверь такой "законченное
> решение" и почему, например, Nexus туда не относится ?

Действительно, о законченности можно говорить исключительно в контексте задачи. Несколько страниц назад примерный набор абстрактных требований (включающий в себя локализацию, разделение доступа, тезаурус и пр.) к объектной надстройке вроде как был сформулирован. Абсолютно безосновательно я взял его за основу, говоря о законченном решении. Это было сделано некорректно, признаю.
...
Рейтинг: 0 / 0
01.03.2005, 00:44
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937522
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
guest_20040621Действительно, о законченности можно говорить исключительно в контексте задачи. Несколько страниц назад примерный набор абстрактных требований (включающий в себя локализацию, разделение доступа, тезаурус и пр.) к объектной надстройке вроде как был сформулирован. Абсолютно безосновательно я взял его за основу, говоря о законченном решении. Это было сделано некорректно, признаю.
Скажем так, это некоторые из требований к уровням ядра/системных сервисов платформы для построения информационных систем, которые желательно закладывать с самого начала. Если с претензией на относительную универсальность.
Сегодня многие вещи реализовать легче, чем 5 и тем более 10 лет назад. Но одновременно и спрос на "движки" упал. Выбирают готовые решения пусть бы они были даже и на несовершенных платформах. Поэтому и дискуссии на эту тему практически сошли "на нет".
...
Рейтинг: 0 / 0
01.03.2005, 01:03
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937542
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Если с претензией на относительную универсальность.

На мой взгляд, основные из перечисленных задач могут быть решены сразу несколькими способами, большинство из которых имеют право на существование; использование их (способов) может определяться дополнительными требованиями к программному продукту (например, можно выбрать схему локализации, минимизирующую итоговое количество таблиц или реализовать ограничение доступа с быстрой проверкой, но без возможности расширения). А предусмотреть несколько альтернативных вариантов реализации при проектировании структуры базы данных - накладно. К чему это: к сожалению, даже просто формулирование требований - не слишком простая задача; imho сделать это можно только в общих чертах.

> Но одновременно и спрос на "движки" упал.

Не соглашусь. Просто предложений стало больше, спрос естественным образом сегментировался.

> Выбирают готовые решения пусть бы они были даже и на несовершенных
> платформах. Поэтому и дискуссии на эту тему практически сошли "на нет".

Да их и пять лет назад было не много. ;) Что было десять лет назад - не знаю, врать не буду.
...
Рейтинг: 0 / 0
01.03.2005, 02:05
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937547
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
guest_20040621Не соглашусь. Просто предложений стало больше, спрос естественным образом сегментировался.
Тут и я не соглашусь, хотя специально спрос не изучал :) Гипотеза такая. "Движок" нужен для систем класса ИС предприятия (обощенно, КИС). Подрядчику делать платформу ради одного закачика невыгодно. Видимо, рентабельность приходит где-то к пятому-десятому проекту, а это уровень малотиражного продукта.
Все больше проектов делается с использованием готовых систем. Спрос на малотиражные системы падает. На "движки" для них, соответственно, тоже.
...
Рейтинг: 0 / 0
01.03.2005, 02:18
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32937923
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Гипотеза такая. "Движок" нужен для систем класса ИС предприятия (обощенно,
> КИС).

Чем функциональность приложения для маленькой лавчонки с 10 сотрудниками должна глобально отличаться от функциональности приложения для крупного холдинга? Ну да, задач у холдинга будет побольше, требования к производительности серьезнее, а базовая функциональность (т. е. тот самый набор абстрактных требований, который я упоминал) приложения останется неизменной. В простейшем случае эта функциональность определяется системным набором сущностей базы данных и метаописанием объектов базы данных.

> Подрядчику делать платформу ради одного закачика невыгодно. Видимо,
> рентабельность приходит где-то к пятому-десятому проекту, а это уровень
> малотиражного продукта.

Ну почему ради одного заказчика? Если ядро схемы остается неизменным для любой реализации, то новизна проекта сводится к решению дополнительных задач.

> Все больше проектов делается с использованием готовых систем.

Каких, например, если не секрет?

> Спрос на малотиражные системы падает. На "движки" для них, соответственно, тоже.

Возникает закономерный вопрос: а вновь появляющиеся продукты пишутся исключительно благодаря альтруизму разработчиков? Или все-таки они оплачены (пусть частично)?
...
Рейтинг: 0 / 0
01.03.2005, 10:21
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32938017
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
guest_20040621
> Гипотеза такая. "Движок" нужен для систем класса ИС предприятия
> (обощенно, КИС).

Чем функциональность приложения для маленькой лавчонки с 10 сотрудниками должна глобально отличаться от функциональности приложения для крупного холдинга? Ну да, задач у холдинга будет побольше, требования к производительности серьезнее, а базовая функциональность (т. е. тот самый набор абстрактных требований, который я упоминал) приложения останется неизменной. В простейшем случае эта функциональность определяется системным набором сущностей базы данных и метаописанием объектов базы данных.


Я тоже хочу вмешаться!
guest_20040621, а можете Вы здесь изложить свою точку зрения на конкретный (необходимый/достаточный) состав "системного набора сущностей базы данных и метаописания объектов базы данных" в контексте неизменной базовой функциональности приложения - как Вы его себе представляете.
Как я понимаю это д.б. универсальная структура (ядро системы) в БД и базовый функционал на уровне данных БД, позволяющий реализовать с его помощью большую часть функциональности стандартных задач учета (и возм. доругих - кому что надо), + расширяемый и дополняемый.
...
Рейтинг: 0 / 0
01.03.2005, 10:48
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32939968
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> точку зрения на конкретный (необходимый/достаточный) состав "системного
> набора сущностей базы данных и метаописания объектов базы данных"

К сожалению, пока такой структуры нет.

> в контексте неизменной базовой функциональности приложения - как Вы его
> себе представляете.

Ну вот если взять, например, схемку в Power Designer, то из его внутреннего формата можно (с разной степенью достоверности) сгеренировать базу данных для довольно большого количества СУБД. Базовые системные объекты должны предоставлять не меньшие возможности в плане описания объектов базы данных (т. е. собственно генератор и словарь конкретной базы данных - не самое главное; важно не потерять существенные детали).

> Как я понимаю это д.б. универсальная структура (ядро системы) в БД и базовый
> функционал на уровне данных БД, позволяющий реализовать с его помощью
> большую часть функциональности стандартных задач учета (и возм. доругих -
> кому что надо), + расширяемый и дополняемый.

Под базовым функционалом мне хотелось бы подразумевать не расчетные задачи, а организационные (т. е. разделение доступа, локализация, конфиги и пр.); причем, хотелось бы иметь такую структуру данных, чтобы она была бы работоспособна и без метаописания.
...
Рейтинг: 0 / 0
01.03.2005, 23:57
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32942682
jip
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jip
Гость
adiskПро ту же "новую" схему.
Я бы сделал две даты "дата_начала_действия" (создания/изменения) и "дата_окончания_действия" (удаления).
А то узнать, что данные удалены? IMHO, поле "дата_окончания_действия" породит проблемы, связанные со стыковкой дат в хронологии того же объекта (если в БД хранится хронология) или у связанных событий/объектов. К тому же выборка актуального значения потребует выполнением подзапроса, что зело накладно.

Гораздо проще хранить флаг "актуально_ли_значение", который устанавливать только у актуальной (последней в хронологии) записи, и одну дату "дата_начала_действия". Для маркировки удаленности записи можно завести еще один флаг, "удалена_ли_запись". И пару байт в записи сэкономим, и запросы ускорим.
...
Рейтинг: 0 / 0
03.03.2005, 07:29
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32949062
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Почему Две даты ( дата начала + дата окончания ):
1. Запрос выполняется быстрее ($date between dateon and dateoff)
2. К свежим данным запросы происходят чаще, поэтому предлагаю такую схему: таблица архивов + таблица текущих данных. Нужны свежие данные - обращаемся к актуальной таблице. Нужна история - к архивной. Таблица текущих данных (актуальных) может получится select'ом самых свежих записей из архива. Другими словами можно просто всегда работать с архивом.
Естественно в актуальной таблице можно обходиться бед фильтрации по датам, как это происходит сейчас в большинстве информационных систем.
3. С 1-го числа по 2-е были данные, с 2-го по 3-е они удалены, с 3-го по 4-е опять продолжают существование. (один период выпадает) С двумя датами это легко и наглядно реализуется.
...
Рейтинг: 0 / 0
06.03.2005, 07:43
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32954030
Фотография 4d_monster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4d_monster
Участник
Лучше Две даты, потому-что,
тогда для получения состояния на какую-то любую дату, запросы будут одинаковыми.
...
Рейтинг: 0 / 0
10.03.2005, 17:04
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32954064
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
4d_monsterЛучше Две даты, потому-что,
тогда для получения состояния на какую-то любую дату, запросы будут одинаковыми.
Для вас, спорщики :)
...
Рейтинг: 0 / 0
10.03.2005, 17:14
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32954606
Andr2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andr2
Гость
TemplarДля вас, спорщики :) Интересно бы было там же увидеть сравнительные результаты по скорости на простых и усложненных выборках. Сам когда-то делал сравнение для Oracle - на простых выборках вариант с одной датой проигрывал по скорости ~ в 1.3-1.5 раза (но с приемлемым временем).
...
Рейтинг: 0 / 0
11.03.2005, 05:42
| Ответить | Цитировать | Написать  
438 сообщений из 438, показаны все 18 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Объектная надстройка над релационной СУБД
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]