Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Самоучитель PHP 5 / 6 (3 издание). Авторы: Кузнецов М.В., Симдянов И.В. Социальная инженерия и социальные хакеры. Авторы: Кузнецов М.В., Симдянов И.В. MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. C++. Мастер-класс в задачах и примерах. Авторы: Кузнецов М.В., Симдянов И.В. Программирование. Ступени успешной карьеры. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум MySQL

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Объектно-ориентированные технологии в базах данных
 
 автор: Progr@mmer   (22.03.2009 в 19:09)   письмо автору
 
 

Добрый вечер!

Уважаемые участники форума, хотелось бы обсудить такую тему, как объектно-ориентированные базы данных. Понимаю, что немногие думают, что это действительно тема для обсуждения, но я не хочу вступать в спор, хороши ли данные системы или плохи. Потому что, исходя из моих поисков в интернете, особенно интересных ООСУБД я не нашёл, к сожалению, может быть, я и плохо искал, по крайней мере, нашёл такую, как Cache, но она не особо понравилась из-за её привязанности к конкретному языку, похоже её сложно даже использовать как ООСУБД именно с таким замечательным средством разработки как PHP.
Неужели нет таких средств, гибких, чтобы можно было использовать их интерфейс именно в разработке на других языках, а не только C++???

Я думаю, что нынешние реляционные СУБД, хотя они и самые распространённые, всё-таки сложны при разработке приложений, которые имеют разветвлённую структуру данных, а в ООСУБД, думаю, было бы приятно и удобно разрабатывать такие системы!

Приведу пример-аналогию, почему именно ООСУБД является наилучшим средством по сравнению с РСУБД. Я думаю, что аналогии позволют разработчикам абстрагироваться от конкретной работы и посмотреть шире. Как разрабатывают, вкратце, к примеру, строительные комплексы, здания или даже автомобили? Сначала разрабатывается модель системы. Она обсуждается со всеми интересующимися сторонами. Когда принята модель, она постепенно разбивается на более мелкие детали, а именно, конкретные здания, конструкции здания, при этом используются стандартные конструкции или разрабатываются новые. Когда, наконец, система спроектирована, она разрабатывается, тестируется, внедряется, эксплуатируется, поддерживается. Но вот самое интересное - в момент эксплуатации и поддержки наша система находится в СОБРАННОМ ВИДЕ! Взять автомобиль или здание, или комплекс любой. Даже в момент модернизации, эта система всего лишь частично реконструируется, иногда, конечно, полностью разбирается, если идёт полная реконстукция, и собирается ВНОВЬ! Бывают такие моменты, когда используемая система сдаётся на хранение, например, когда её эксплуатация невозможна в данный момент, к примеру, на катере не покатаешься зимой, его поэтому надо хранить в специальном месте, возможно, даже его при хранении нужно разбирать на основные составные части для удобства хранения.

Так к чему же я! А к тому, что ведь в реляционных базах данных производится хранение данных в неудобном и не совсем естественном виде, причём в момент использования. С одной стороны в некоторых случаях это удобно. Это удобно, когда нужно просмотреть сходные детали, как, например, в магазине запчастей, а когда нам нужен закоченный продукт, мы всё-таки не идём в магазин запчастей и не говорим "быстренько собирайте мне машину", а идём туда, где находятся собранные машины. А РСУБД находится именно в состояни, если не магазина запчастей, то лабиринта незаконченных изделий по причине того, что когда-то давно негде было хранить большие машины, их хранили по смыслу - рули в одном месте, бензобаки в другом, моторы в третьем, и т.д. Это удобно, когда мы имеем склад запчастей или, когда негде ставить большие машины, попросту, когда нет ни производственного отдела, ни магазина. Всё делается вместе, как появился покупатель, так мы ему и собрали машину.

Но дорогие программисты-разработчики! Мы ведь научились работать с такими вещами как ООП, инкапсуляуия, полиморфизм, наследование..., научились разрабатывать сложные продукты раздельно, по стадиям, и в то же время, комплексно, так как эти стадии разработки в итоге работают на одно общее дело! Почему же мы тогда так инертны и не можем понять, что когда данные часто используются, не надо их хранить в разобранном виде, нужно их как-то уметь хранить в готовом для продажи и эксплуатации виде. Возможно даже нужно хранить данные в двух видах - табличном и объектном.

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

Существующие объектно-реляционные СУБД, лишь замедляют работу СУБД, так как они используют ООП-интерфейс как надстройку, а хранят данные как и РСУБД - в таблицах.

А мой главный вопрос, существуют ли на данный момент хотя бы на этапе разработки такие ООСУБД, использование которых возможно в системах, НЕЗАВИСИМО от языка?

  Ответить  
 
 автор: Progr@mmer   (22.03.2009 в 21:50)   письмо автору
 
   для: Progr@mmer   (22.03.2009 в 19:09)
 

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

  Ответить  
 
 автор: cheops   (27.03.2009 в 02:48)   письмо автору
 
   для: Progr@mmer   (22.03.2009 в 19:09)
 

Вроде PostgreSQL поддерживала объектно-ориентированный подход... однако пока переходить слишком рано - слишком неэффективный объектно-ориентрированные базы, а база данных это пока создает 90% нагрузки сервера.

А так все верно и правильно и как только будет что-то подходящее тут же будем использовать.

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования