Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
В принципе, более или менее признанная классификация СУБД существует. Вот только возникают проблемы с отнесением конкретных продуктов к тому или иному виду. Ведь не секрет, что реляционная модель Кодда реализуется в современных "реляционных" СУБД не вполне адекватно (желающие понять в чем - читайте книги Дейта), тем не менее мы упрямо называем Oracle, MS SQL, DB2 и т.д. "реляционными СУБД". Ситуация с объектными системами еще сложнее - единой и внятной модели нет, но есть общепризнанные идеи, такие как поддержка полиморфизма, наследования и инкапсуляции. Посему и возникает путаница с терминологией, когда одни и те же продукты с одной стороны реляционные, а с другой - объектно-ориентированные. С чем же мы имеем дело на практике? Правильнее всего заглянуть в историю, почитать статьи Кузнецова на www.citforum.ru и понимание прийдет. Что же касается моего личного мнения - предпочитаю придерживаться следующей классификации: Oracle, MS SQL, DB2 ... - реляционные СУБД (в некоторых случаях - с очень неудобными, навернутыми поверх реляционного ядра, объектными функциями). Cache, Postgress, Informix ... - объектно-реляционные СУБД (попытка совместить две технологии, результатом чего явился некоторый отход от реляционного ядра, но полностью объектными такие системы не стали - предлагаются некие компромиссные механизмы, оказывающиеся, впрочем, весьма удачными при решении ряда специфических задач). Versant VDS, Versant FastObjets, GemStone, O2, Objectivity ... - истинно объектные СУБД, вся структура ядра, формат хранения и обработки данных целиком ориентированы на работу с объектами. В целом, действительно объектные СУБД всегда имеют тесную интеграцию с самими ОО языками программирования. Т.е. для настоящих объектных СУБД разработки структуры базы данных как таковой не производится - есть некий API и/или расширения языка которые позволяют полностью оттранслировать объектную структуру приложения в структуру базы данных. К примеру, я просто объявляю Java-класс сохраняемым и все объекты этого класса автоматически получают возможность быть сохраненными в БД (т.е. мне не надо вообще заботиться о том, в какой таблице эти объекты будут храниться и т.п.). Именно поэтому любой профессионал ОО-программирования может научиться работать с ООСУБД за очень незначительное время. Разумеется серьезные системы имеют массу прибамбасов, которые уже навешиваются поверх объектного ядра с различными целями (например, обеспечить обработку запросов в SQL-стиле, организовать ODBC-доступ и т.п.). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 11:18 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
А если не секрет, зачем Вы этот вопрос задали? Пытаетесь что-то понять, или чему-то нас научить? С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 13:00 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo Т.е. для настоящих объектных СУБД разработки структуры базы данных как таковой не производится - есть некий API и/или расширения языка которые позволяют полностью оттранслировать объектную структуру приложения в структуру базы данных. Т.е. получается что ADO - это ОО СУБД(с некоторой натяжкой)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 13:08 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo Давай те уж для начала определимся с терминами "Обьектно-Ориентированное-Программирование", "Обьект", "Класс" и их роли и перспективности в роли описания и обработки "множеств" информации. А уж потом будем пытаться понять, что же из себя должна представлять ОО-СУБД и зачем она нужна :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 13:12 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Константин ЛисянскийА если не секрет, зачем Вы этот вопрос задали? Пытаетесь что-то понять, или чему-то нас научить? С уважением, Константин Лисянский http://lissianski.narod.ru Предыстория вопроса /topic/146255&pg=2#1187983 Просто вынес свой ответ в отдельный топик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 17:06 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
ASCRUS Alexey Rovdo Давай те уж для начала определимся с терминами "Обьектно-Ориентированное-Программирование", "Обьект", "Класс" и их роли и перспективности в роли описания и обработки "множеств" информации. А уж потом будем пытаться понять, что же из себя должна представлять ОО-СУБД и зачем она нужна :) Честно говоря, не готов , да и не хочу обсуждать правомерность самого ОО подхода к решению задач обработки информации. Лично я убежден в том, что все зависит от специфики этой задачи и рамок, в которые поставлен разработчик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 17:20 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Я просто пытаюсь понять, что именно должна уметь СУБД X, чтобы можно было говорить о её "объектной ориентированности". Скажем, рассмотрим такой пример. Пусть есть реляционная база X. Пусть в неё добавлена поддержка пользовательских типов, которые представляют собой классы, т.е. имеют свойства, методы, события. Иными словами, я могу создать в коде, родном для данной СУБД (пусть это очередное расширение SQL - X-SQL), экземпляр класса: Код: plaintext и далее вызывать методы: Код: plaintext Будет такая СУБД объекно-ориентированнной? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 19:06 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
jimmersЯ просто пытаюсь понять, что именно должна уметь СУБД X, чтобы можно было говорить о её "объектной ориентированности". Скажем, рассмотрим такой пример. Пусть есть реляционная база X. Пусть в неё добавлена поддержка пользовательских типов, которые представляют собой классы, т.е. имеют свойства, методы, события. Иными словами, я могу создать в коде, родном для данной СУБД (пусть это очередное расширение SQL - X-SQL), экземпляр класса: Код: plaintext и далее вызывать методы: Код: plaintext Будет такая СУБД объекно-ориентированнной? Нет. Вы сами сказали "Пусть есть реляционная база". Т.е. определили ее как реляционную и надстроили над ней механизм поддержки объектности. В современных объектных базах все наоборот. Важно понять, что разделение СУБД на объектные и реляционные не лежит в плоскости их функционала (умений). Объектные данные можно разместить в реляционной СУБД без потерь (на этом факте и построены современные средства O/R-мэппинга). И наоборот - реляционные данные прекрасно преобразуются в объектные. Способ хранения данных - вопрос удобства разработчика и требований проекта. Вообще существует постоянная путаница, вызванная тем, что объектные СУБД всегда сопровождаются объектным инструментарием разработки, который можно было бы рассматривать и как нечто отдельное. Например, есть ООСУБД FastObjects .NET, которая представляет собой объектный сервер базы данных и набор инструментов, интегрирующихся с Visual Studio и позволяющих использовать ООСУБД в программах на C#,VB .NET и т.п. Но сам этот набор инструментов может использоваться и без объектного сервера данных. В этом случае данные храняться в реляционной СУБД (MS SQL, Oracle или DB2), а обращения к ним осуществляются через встроенное в инструментарий FastObjects средство объектно-реляционного отображения. И нет никакой разницы (кроме быстродействия), где хранятся данные - в объектном хранилище FastObjects или в базе данных Oracle (их вообще можно распределить между гетерогенными системами хранения). Таким образом сам инструментарий становится самостоятельным продуктом (Versant Open Access .NET), основная ценность которого состоит в ускорении и упрощении разработки сложных систем и говорить при его рассмотрении следует о преимуществах ООП вообще, а не об объектных СУБД в частности. Рекомендую почитать здесь: http://www.softkey.ru/catalog/program.php?ID=7275&CID=950&progdesc=long возможно вы лучше поймете то, о чем я говорю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 19:26 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo Ведь не секрет, что реляционная модель Кодда реализуется в современных "реляционных" СУБД не вполне адекватно (желающие понять в чем - читайте книги Дейта), тем не менее мы упрямо называем Oracle, MS SQL, DB2 и т.д. "реляционными СУБД". Почему мы должны читать непременно только книги Дейта. Он даже не автор этой модели. Термин "реляционные" есть и в других моделях данных: бинарные реляционные, семантические реляционные. Теперь уже имеет значение общепризнанность, а не мнение одного человка - даже автора. Джин выпущен из бутылки. РМД - Кодда вышеупомянутые СУБД способны реализовать. Есть базовая реляционная, есть расширенная, которая не так строго стандартизована - т.е. это вообще семейство. Расширения включающие поддержку объектных типов называют ОРМД. Есть 12 правил Кодда, которым должна отвечать РСУБД. Но это уже ничего не меняет. Ну назовите их по другому, если приживется будут пользоваться новым названием. Все равно они доминируют в настоящее время. Но главное в Рел модели - структурирование, ограничения целостности и манипулирование данными они поддерживают. Alexey Rovdo Правильнее всего заглянуть в историю, почитать статьи Кузнецова на www.citforum.ru и понимание прийдет. Но я другое читаю - толстые книги по БД. Чем они хуже Кузнецова на www.citforum.ru? Это Вы нас сбиваете с толку, подбрасывая конкретных авторов? Alexey Rovdo Oracle, MS SQL, DB2 ... - реляционные СУБД (в некоторых случаях - с очень неудобными, навернутыми поверх реляционного ядра, объектными функциями). Это Вы так между делом в один ход объявили ОРСУБД потерпевшей крах? Возможно Вы торопитесь. Именно с ней по мненю некоторых авторов и приходится бороться ООСУБД, а не только с РСУБД. А Вы как бы между делом, под шумок заранее приписали им не успех, чтобы бороться только с РСУБД? В надежде что многие, кто не долюбливают ОО откажутся от ОРМД? Но есть и сторонники РМД, которые не собираются отказываться от использования ООП. Нас не так просто одурачить. Не пойдет. Нужна конкретика. Alexey Rovdo Cache, Postgress, Informix ... - объектно-реляционные СУБД (попытка совместить две технологии, результатом чего явился некоторый отход от реляционного ядра, но полностью объектными такие системы не стали - предлагаются некие компромиссные механизмы, оказывающиеся, впрочем, весьма удачными при решении ряда специфических задач). А Oracle, MS SQL, DB2 не ОРСУБД? Тогда что означает текст предыдущей цитаты Вашего текста? Оракл претендует на то, что он ОРСУБД. А Cache на то что поддерживает ООСУБД. Тут нужно уточняться в терминах и про ОРСУБД. Некоторый отход от "реляционного ядра" не означает отказ от РМД? Или что под этим скравается? Alexey Rovdo Versant VDS, Versant FastObjets, GemStone, O2, Objectivity ... - истинно объектные СУБД, вся структура ядра, формат хранения и обработки данных целиком ориентированы на работу с объектами Да, наверное, они признанные ООСУБД. Но то почему они относятся к таким СУБД нуждается в уточнении. Но главное - полный отказ от РМД. Alexey Rovdo Т.е. для настоящих объектных СУБД разработки структуры базы данных как таковой не производится - есть некий API и/или расширения языка которые позволяют полностью оттранслировать объектную структуру приложения в структуру базы данных. Это не совсем понятно. Вы говрите о чем? О способе создания структуры БД? Так и реляционную создают - на клиенте запускают команды языка БД по созданию БД. Или Вы про что? Alexey Rovdo Именно поэтому любой профессионал ОО-программирования может научиться работать с ООСУБД за очень незначительное время. Да и с реляционными многие быстро научаются работать даже не профессионалы ни в чем. Какое имеет значение чему научается легко профессионал ОО-программирования? Разве поставлена задача срочно их всех обучить работать с СУБД? Обыкновенно работе с БД учат в вузах не профессионалов ОО-программирования. И именно профессионалы в БД для работы с любой СУБД предпочтительнее наспех обченных профессионалов ОО или любого другого программирования. Поскольку в БД данные первичны, а для проггеров первичны проги - они готовы всяко упрощать проектирование БД и компенсировать это программными ухищрениями. Но считается, что никакие программные ухищрения не помогут ИС с плохо спроектированной БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 21:02 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vadiminfoЭто Вы так между делом в один ход объявили ОРСУБД потерпевшей крах? Возможно Вы торопитесь. Именно с ней по мненю некоторых авторов и приходится бороться ООСУБД, а не только с РСУБД. А Вы как бы между делом, под шумок заранее приписали им не успех, чтобы бороться только с РСУБД? В надежде что многие, кто не долюбливают ОО откажутся от ОРМД? Но есть и сторонники РМД, которые не собираются отказываться от использования ООП. Нас не так просто одурачить. Не пойдет. Нужна конкретика. Не борются ООСУБД с реляционными. Это не так. Oracle - очевидно мощнейшее средство для работы с данными. Но с помощью ООСУБД можно решать определенный спектр задач более эффективно. Эффективно с точки зрения бизнеса, в первую очередь. Ведь любое коммерческое приложение для разработчика должно принести доход. Если можно повысить скорость и качество разработки для задач со сложной объектной моделью (а это одно из основных декларируемых преимуществ ООСУБД), то значит можно заработать больше денег. vadiminfoДа и с реляционными многие быстро научаются работать даже не профессионалы ни в чем. Какое имеет значение чему научается легко профессионал ОО-программирования? Разве поставлена задача срочно их всех обучить работать с СУБД? Обыкновенно работе с БД учат в вузах не профессионалов ОО-программирования. И именно профессионалы в БД для работы с любой СУБД предпочтительнее наспех обченных профессионалов ОО или любого другого программирования. Поскольку в БД данные первичны, а для проггеров первичны проги - они готовы всяко упрощать проектирование БД и компенсировать это программными ухищрениями. Но считается, что никакие программные ухищрения не помогут ИС с плохо спроектированной БД. Чем сложнее объектная модель, тем сложнее спроектировать БД. И технология, позволяющая оптимизировать этот процесс, а также снизить издержки при работе с такими данными, и есть ООСУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 22:33 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Alexey Rovdo Раз Вы даете рекламу, то давайте с ней разбираться. >Рекомендую почитать здесь: http://www.softkey.ru/catalog/program.php?ID=7275&CID=950&progdesc=long возможно вы лучше поймете то, о чем я говорю. Лучше не стало, стало только хуже. Привожу ПОЛНОСТЬЮ раздел "Средства обеспечения безопасности" Средства обеспечения безопасности FastObjects t7 защищает данные от компрометации и неавторизованного доступа с помощью опционального средства шифрования, которое шифрует данные в хранилище. FastObjects t7 позволяет защитить данные на этапе их передачи от сервера базы данных в приложение с помощью опционального средства шифрования на базе SSL. Ну и где тут "средства"? Во первых то, о чем вы пишете это не средства а методы, а во-вторых это еще не вся безопастность, есть еще разграничение доступа, к прмеру, и там все гораздо сложнее. Если это все, то довольно убого как для серьезного продукта. Но и это еще не все. Оказывается что Включение средства шифрования базы данных и коммуникаций увеличивает стоимость серверных лицензий на 50%. За эту пародию на безопасность еще и платить нужно. Хотя передача по сети через SSL в юнихе, например, обеспечивается в случае необходимости без всяких усилий со стороны приложения, причем задаром. Ну как это называется как не развод лохов? И потом оказывается, что никаких "средств" нет, а есть единственное "средство". Поэтому раздел о безопасности должен по-честному называеться не "Средства ..." а "Средство обеспечения безопасности". И то за деньги. Поддерживаемые платформы Среда исполнения: Windows 98/NT/2000/XP/2003, Windows CE, Linux, Solaris, HP-UX, AIX, WxWorks и др. Мне, например, понравилось это "и др.". Как я понимаю списка поддерживаемых платформ у этого, безусловно очень серьезного продукта, не существует. Это то, что бросилось в глаза. А вообще впечатление от документа - агитка для менеджеров, не информация для технического персонала, сплошные прокламации. Зачем ссылаться? >Вообще существует постоянная путаница, вызванная тем, что объектные СУБД всегда сопровождаются объектным инструментарием разработки, который можно было бы рассматривать и как нечто отдельное. Вот и распутайте путаницу. Только не нужно начинать с середины, начните с начала, как Вам и предлагали. Хотя по-видимому мало надежды, что кто-нибудь сможет сказать что-нибудь в этом вопросе по-сути. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 05:29 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
все то, что тут так активно продвигается, написано на сях, так что насчет др. делайте выводы сами... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 15:29 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Lankaster Не борются ООСУБД с реляционными. Это не так. Вообще-то за рынок они вынуждены бороться. Другое дело, что они могут его поделить. Но задачи ставятся захватить весь рынок. Кроме того, Вы игнорируете ОРСУБД. А это имеет значение для дальнейших аргументов. Lankaster Но с помощью ООСУБД можно решать определенный спектр задач более эффективно. Более адекватно. Но я писал выше, а Вы не обращаете совсем внивания - производители РСУБД ответили на это ОРМД. И тут уже не все так очевидно с этими специализированными приложениями. Lankaster Эффективно с точки зрения бизнеса, в первую очередь Вот насчет бизнес приложений - там РМД успешна. И в этом одна из проблем ООМД. Так как если она не претендует захватить весь рынок, то встает, например, проблема интеграции сильно отличающихся систем. Что же объединять две системы разные системы в одну? Теперь админы должны знать и РСУБД и ООСУБД? Это не желательное усложнение. Lankaster Если можно повысить скорость и качество разработки для задач со сложной объектной моделью (а это одно из основных декларируемых преимуществ ООСУБД), то значит можно заработать больше денег. А если вместо ООСУБД можно применть ОРСУБД, то можно заработать еще больше денег, поскольку, например, остается под рукой и РМД: и круг тех задач, где они хороши, и те продукты которые теперь хороши и для тех и для других задач, и те же спецы. Я не хочу сказать, что ОРСУБД уже победили - у них есть недостатки, как, впрочем, и у всех. Но и игнорировать их рановато. Lankaster Чем сложнее объектная модель, тем сложнее спроектировать БД. И технология, позволяющая оптимизировать этот процесс, а также снизить издержки при работе с такими данными, и есть ООСУБД. Или ОРСУБД. Но все равно не совсем все так просто. Известно, что плохо спроектированная ООП мнохо хуже процедурной парадигмы в плане издержек на сопровождение. Т.е. там проектирование все равно сложнее. Кроме того, ни ООСУБД, ни ОРСУБД не есть технология. Это все-таки системы управления БД, позволяющие использовать те или иные технологии работы с данными. Ну, да теоретически ООМД как бы используется и для концептуального и для логического проектирования - это наверное выглядит как упрощение. А РМД и, судя по всему, ОРМД нуждаются в дополнительных объективных моделях инфологического уровня типа EER. Но на много ли выигрыш - не ясно. Все равно в большом проекте это разные спецы делают (хотя это может быть один и тот же человек, но владеющий обеими спец), да и эти модели успешно транслируются друг в друга. В любом случае каждый проект по своему уникален - это отличает его от чего-то хорошо поддающегося технологии. Обращаю Ваше внимание еще раз на учет ОРСУБД. Вы упорно сравниваете ООСУБД только с РСУБД, и потому не все возможности учитываете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 16:37 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Московская Секция ACM SIGMOD приглашает на очередное заседание семинара Секции. Семинар состоится 23 декабря 2004 года в 16 часов 20 мин. во 2-м учебном корпусе МГУ в аудитории 685 (ст. метро "Университет", угол ул. Лебедева и Ломоносовского проспекта, 6 этаж). Тема: Объектно-ориентированные базы данных и объектные расширения языка SQL Выступает: С.Д Кузнецов , Институт системного программирования РАН, kuzloc@ispras.ru Используя расширенные возможности языка SQL, специфицированные в стандартах SQL:1999 [1] и SQL:2003 [2], можно создать базу данных, синтаксическая форма SQL-запросов к которой будет почти совпадать с формулировкой OQL-запроса к соответствующей объектной базе данных, построенной в соответствии с объектной моделью ODMG 3.0 [3]. Это обстоятельство может навести на мысль о том, что модели данных SQL и ODMG сближаются, что модель SQL становится более “объектной” (если критерием “объектности” модели данных считать уровень ее соответствия модели ODMG). Цель доклада состоит в том, чтобы показать, что имеется лишь синтаксическая близость языков запросов SQL и OQL. На уровне моделей остается принципиальное различие. В частности, мультимножество объектов в модели ODMG означает совсем другое понятие, нежели типизированная таблица в модели SQL, типизированная таблица не является аналогом экстента класса, а строку типизированной таблицы (“экземпляр” соответствующего структурного UDT) никак нельзя воспринимать как “объект”. Очень важно, что эти различия являются не реализационными, а именно модельными. Единственное, что объединяет модели данных SQL и ODMG, -- развитая система типов с возможностью определения новых типов с произвольно сложной структурой значений. “Объектные” же расширения SQL, по сути, представляют собой дальнейшую синтаксическую маскировку операций естественного соединения. Доклад не ориентирован на критику той или иной модели. Цель состоит лишь в том, чтобы предельно прояснить существующую ситуацию. Литература: Jim Melton. “Advanced SQL:1999. Understanding Object-Relational and Other Advanced Features”. Morgan Kaufmann Publishers, 2003 Сергей Кузнецов. Наиболее интересные новшества в стандарте SQL:2003. http://www.citforum.ru/database/sql/sql2003/ The Object Data Standard: ODMG 3.0. Edited by R.G.G. Cattel, Douglas K. Barry. Morgan Kauffmann Publishers, 2000 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 16:43 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Может стоит пред. пост выделить в отдельный топик, который смело можно стереть после проведения семинара (т.е. 23-го)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 16:46 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Мимо пробегал.. “Объектные” же расширения SQL, по сути, представляют собой дальнейшую синтаксическую маскировку операций естественного соединения. Хотя бы С.Д Кузнецов, ради придания тексту большего наукообразия, построил эту фразу в форме предположения. А так получается, что он умней тех, кто это придумал, и сразу текст выглядит как рекламная пропаганда ООМД. Тем более насчет операций, да еще и естественного соединения. Все-таки те претендуют на структурирование данных, какое-то ООП там намечается, а не маскировка наиболее старых и простейших операций РМД. Я же говорил, что есть борьба меду ООСУБД и ОРСУБД. И она включает приемы далеко выходящие за сферу чисто технических. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 16:59 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 vadininfo С. Д. Кузнецов на меня производит впечатление человека, которому "приемы далеко выходящие за сферу чисто технических" и даже "приемы далеко выходящие за сферу чисто научных" глубоко пофигу :). И, кстати, фраза "“Объектные” же расширения SQL, по сути, представляют собой дальнейшую синтаксическую маскировку операций естественного соединения", как раз таки не выглядит как "как рекламная пропаганда ООМД". Скорее наоборот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 18:16 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Мимо пробегал... И, кстати, фраза "“Объектные” же расширения SQL, по сути, представляют собой дальнейшую синтаксическую маскировку операций естественного соединения", как раз таки не выглядит как "как рекламная пропаганда ООМД". Скорее наоборот. Ну как же? Ее можно понять как то, что в ОРМД объекты в лучшем случае праздно присутствуют, а в худшем только мешают - маскируют синтаксис естественного отношения. Т.е. теперь сложнее понимать смысл запроса - надо преодолевать маскировку. Т.е. ОРМД не конкурент ООМД. Стало быть ООМД осталось додавить только РМД. И все. Сторонники ООМД этого очень хотят. ОРМД их реально раздражает. Ведь РМД - шники в наглую взяли преимущества ООП и пытаются привистовать их РМД. Если получится, то у них будет и преимущество ООМД и РМД, а у сторонников ООМД - только ОО. А Вы говорите - это антиреклама. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 20:01 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
с127 Поддерживаемые платформы Среда исполнения: Windows 98/NT/2000/XP/2003, Windows CE, Linux, Solaris, HP-UX, AIX, WxWorks и др. Мне, например, понравилось это "и др.". Как я понимаю списка поддерживаемых платформ у этого, безусловно очень серьезного продукта, не существует. "и др." осначает ВСЕГО-ЛИШЬ, что корпорация Versant готова выполнить любой ваш каприз, если вы готовы его оплатить. Поскольку FastObjects часто используется как встраиваемая система для разнообразного оборудования, то и потребности в адаптации этой системы под требования различных платформ и сред исполнения возникают регулярно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 21:24 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
РМД-ОРМД-ООМД Кому-то кажется, что это совершенно естественная цепочка. А я вот с этим не согласен. ОРМД слишком разнообразна. Да в ней можно найти нечто, присущее и ООМД и РМД, но в целом ОРМД - целый спектр продуктов. Многие из них (например, М-системы) вполне заслуживают признания и являются оптимальным выбором для ряда специфических задач (например временны'е БД). Также важно понять, что сами данные могут свободно перетекать из одной модели в другую без всяких потерь. Так что наличие или отстутствие в той или иной конкретной СУБД поддержки объектно-ориентированной работы не означает ничего. Надо смотреть на то, как хранятся и обрабатываются данные в ядре системы, а вот по этому критерию большинство относит Oracle и MS SQL к реляционным системам. Возможно это и не вполне корректно - действительно существуют определенные оговорки, но какими бы они ни были, все равно данные системы не имеют истинно объектного ядра. Как результат обработка больших массивов табличной информации с использованием индексов на Oracle (РМД) всегда происходит быстрее, чем на FastObjects (ООМД). И наоборот - в FastObjects быстрее будет работать навигация по объектным сетям (графам), поскольку объектное ядро оптимизировано именно для такой работы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 21:51 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vadiminfo Lankaster Не борются ООСУБД с реляционными. Это не так. Вообще-то за рынок они вынуждены бороться. Другое дело, что они могут его поделить. Но задачи ставятся захватить весь рынок. Кроме того, Вы игнорируете ОРСУБД. А это имеет значение для дальнейших аргументов. Lankaster Но с помощью ООСУБД можно решать определенный спектр задач более эффективно. Более адекватно. Но я писал выше, а Вы не обращаете совсем внивания - производители РСУБД ответили на это ОРМД. И тут уже не все так очевидно с этими специализированными приложениями. Lankaster Эффективно с точки зрения бизнеса, в первую очередь Вот насчет бизнес приложений - там РМД успешна. И в этом одна из проблем ООМД. Так как если она не претендует захватить весь рынок, то встает, например, проблема интеграции сильно отличающихся систем. Что же объединять две системы разные системы в одну? Теперь админы должны знать и РСУБД и ООСУБД? Это не желательное усложнение. Lankaster Если можно повысить скорость и качество разработки для задач со сложной объектной моделью (а это одно из основных декларируемых преимуществ ООСУБД), то значит можно заработать больше денег. А если вместо ООСУБД можно применть ОРСУБД, то можно заработать еще больше денег, поскольку, например, остается под рукой и РМД: и круг тех задач, где они хороши, и те продукты которые теперь хороши и для тех и для других задач, и те же спецы. Я не хочу сказать, что ОРСУБД уже победили - у них есть недостатки, как, впрочем, и у всех. Но и игнорировать их рановато. Lankaster Чем сложнее объектная модель, тем сложнее спроектировать БД. И технология, позволяющая оптимизировать этот процесс, а также снизить издержки при работе с такими данными, и есть ООСУБД. Или ОРСУБД. Но все равно не совсем все так просто. Известно, что плохо спроектированная ООП мнохо хуже процедурной парадигмы в плане издержек на сопровождение. Т.е. там проектирование все равно сложнее. Кроме того, ни ООСУБД, ни ОРСУБД не есть технология. Это все-таки системы управления БД, позволяющие использовать те или иные технологии работы с данными. Ну, да теоретически ООМД как бы используется и для концептуального и для логического проектирования - это наверное выглядит как упрощение. А РМД и, судя по всему, ОРМД нуждаются в дополнительных объективных моделях инфологического уровня типа EER. Но на много ли выигрыш - не ясно. Все равно в большом проекте это разные спецы делают (хотя это может быть один и тот же человек, но владеющий обеими спец), да и эти модели успешно транслируются друг в друга. В любом случае каждый проект по своему уникален - это отличает его от чего-то хорошо поддающегося технологии. Обращаю Ваше внимание еще раз на учет ОРСУБД. Вы упорно сравниваете ООСУБД только с РСУБД, и потому не все возможности учитываете. Все зависит от задачи. Есть задачи, для которых использование ОРСУБД будет более рациональным. Причем причина будет не в неких гипотетических достоинствах самой технологии, а в том, что используемая именно конкретной ОРСУБД внутренняя модель представления данных будет наиболее близко отвечать потребностям конкретной решаемой задачи. Использование же ОРСУБД в тех случаях, когда модель данных лучше представима и/или создается в рамках классического ООП будет неверным (по крайней мере в тех случаях, когда данная модель достаточно сложна). Еще раз повторяю ни ООСУБД, ни РСУБД не охватывают всего многообразия, встречающихся на практике проблем, и я вижу ОРСУБД, как некий набор разнообразных технологий, которые имеют полное право на существование, но не являются наилучшим выбором, если ваша модель может быть представлена в рамках объектно-ориентированного подхода с достаточным уровнем приближения и без внесения в нее при этом излишней сложности. Можно сравнивать ООСУБД и ОРСУБД, но в этом случае видимо нужно подходить более детально и рассматривать конкретную ОРСУБД и конкретную задачу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 22:10 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Alexey Rovdo >"и др." осначает ВСЕГО-ЛИШЬ, что корпорация Versant готова выполнить любой ваш каприз, если вы готовы его оплатить. Что, прямо-таки любой каприз будет выполнен? А я вот хочу систему под PalmOS. И почему потенциальный пользователь должен разгадывать ребусы корпорации Versant? Это же документация, а не журнал веселые картинки. Можно было бы так и написать, что постараемся адаптировать систему к требованиям заказчика, если заплатят. Вообще-то есть сильные сомнения, что корпорация, берущая дополнительно 50% за чепуховую систему безопасности, станет за разумные деньги адаптировать продукт под заланную ОС. Раз уж Вы начали комментировать мои высказывания, то будьте последовательны и прокомментируйте заодно замечание о системе безопасности. А основные определения будут даны или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2004, 07:21 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
c1272 Alexey Rovdo >"и др." осначает ВСЕГО-ЛИШЬ, что корпорация Versant готова выполнить любой ваш каприз, если вы готовы его оплатить. Что, прямо-таки любой каприз будет выполнен? А я вот хочу систему под PalmOS. И почему потенциальный пользователь должен разгадывать ребусы корпорации Versant? Это же документация, а не журнал веселые картинки. Можно было бы так и написать, что постараемся адаптировать систему к требованиям заказчика, если заплатят. Вообще-то есть сильные сомнения, что корпорация, берущая дополнительно 50% за чепуховую систему безопасности, станет за разумные деньги адаптировать продукт под заланную ОС. Можно было бы и написать, но ведь мы обсуждаем текст не на сайте корпорации Versant, а в карточке программы в интернет-магазине Softkey.ru (не вижу смысла писать там про заказные разработки, "и др." вполне достаточно). Что же касается PalmOS, то под этой системой вероятно можно использовать FastObjects j2 - чистую Java СУБД, обладающую многими возможностями FastObjects t7 и предназначенную именно для использования на носимых устройствах (т.е. возможны системы, в которых на носимых устройствах стоит j2, а в качестве центрального хранилища используется t7 и между ними происходит информационное взаимодействие). c127 Раз уж Вы начали комментировать мои высказывания, то будьте последовательны и прокомментируйте заодно замечание о системе безопасности. Что касается средств шифрования. Основное позиционирование FastObjects - встраиваемые системы (для других задач Versant позиционирует ООСУБД VDS). При таком использовании средства шифрования баз данных и коммуникаций зачастую просто не нужны. Там же, где это необходимо, за шифрование приходится платить. Но надо понимать, что возможности FastObjects идут гораздо дальше SSL. Имеющийся в FastObjects административный API позволяет применять и другие алгоритмы шифрования вплоть до любых собственных закрытых алгоритмов (в военной аппаратуре и системах это не редкость). О задании прав пользователей (из документации FastObjects): FastObjects allows a database administrator to decide who should be able to read, write, or delete objects in the database. Administering access rights is similar to administering accounts on most multi-user operating systems. If security is enabled for a database, users must log in before they can open it. If security is not enabled for a database, then there is no need to log in, and there is no need for user accounting. The database administrator can assign rights for an entire class, or for those objects in a class that contain particular values. Rights are used polymorphically: all rights that are assigned to a class also apply to all classes derived from it. When several users need to have the same access rights, the administrator can place these users in a group and assign the rights to the group. This section describes the programming interface to the user authorization system of FastObjects. Most database administrators may prefer to use the FastObjects Administrator's Workbench to assign rights. The programmer’s API is useful when the program needs to assign the rights to a database. Groups Managing the rights of each user separately can be awkward. Most of the time, each user is part of one or more workgroups, and the people in a group all need access to the same data. FastObjects allows you to create a group and assign rights to this group. These rights are granted to a user who is made a member of the group. The administrator determines which groups each user belongs to. Assigning Rights Based on Values Sometimes it can be helpful to be able to assign rights based on the values of a particular object. For instance, one account manager may be responsible for people whose names begin with the letter R, or for those people who live in Michigan. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2004, 17:47 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo РМД-ОРМД-ООМД Кому-то кажется, что это совершенно естественная цепочка. Нет о цепочке речи нет. Цепочка только РМД-ОРМД. ООМД - радикальный отказ от РМД, а ОРМД - попытка преодоления недостатков РМД для некоторых типов приложений с сохранением РМД. Alexey Rovdo в целом ОРМД - целый спектр продуктов ОРМД - модель данных и ее могут поддерживать множество производителей СУБД, как и ООМД и тем более РМД. Если Вы про это. Если про отсутствие единого стандарта, то в таком же положении и ООМД. По краней мере, была до недавнего времени. И ОРМД является частью стандарта SQL-99. Alexey Rovdo Многие из них (например, М-системы) вполне заслуживают признания и являются оптимальным выбором для ряда специфических задач (например временны'е БД). Если Вы про Кэша, то он претендует на то чтобы быть ООСУБД, а не ОРСУБД. А сами М системы - вообще иерархические, насколько я понял на этом форуме. Т.е. дореляционные. А ООСУБД и ОРСУБД относят к постреляционным. Alexey Rovdo Также важно понять, что сами данные могут свободно перетекать из одной модели в другую без всяких потерь. Так что наличие или отстутствие в той или иной конкретной СУБД поддержки объектно-ориентированной работы не означает ничего. Вообще-то кое-что они могут потерять. Но в любом случае имеет значение модель данных. Иначе тем более можно было бы обойтись РМД, если все остальные ей эквивалентны. Зачем тогда они нужны? Наличие поддержки ОО может кое-что означать для тех специализированных приложений, где РМД не совсем адекватна. Alexey Rovdo Надо смотреть на то, как хранятся и обрабатываются данные в ядре системы, а вот по этому критерию большинство относит Oracle и MS SQL к реляционным системам. Обыкновенно, имеет значение какую модель данных поддерживает СУБД. Как можно данные структурировать, организовывать ограничения целостности и манипулировать данными. Не знаю о каком большинстве Вы говорите, но Оракл называет себя ОРСУБД. И в литре по БД его приводят среди прочих кто пошел по пути ОР. В какой мере он поддерживает ОО в настоящее время - второй вопрос. Но то что в какой-то поддерживает это факт. Более того, он поддерживает кроме средств ОО парадигмы и спец типы для разных таких типов приложений как Геоинфмационных, XML - т.е. нет сомнений в намерениях. Типы (структура данных) поддерживаются (есть даже специальный тип таблиц -объектные, но объектные типы поддерживаются и в обычных), те или иные принципы ООП поддерживаются, манипулирование такими данными поддерживается. Этого всего достаточно с точки зрения авторов литры по БД, чтобы относиться к ОРСУБД. Лучше или хуже, соответствует стандартам или нет, но это ОРСУБД. А лично я не понимаю - кто может быстрей продвинуться в создании ОРСУБД чем ведущие производители РСУБД. Напомню Вам, что в толстой книге "Database Systems: The Complete Book" Hector Garcia_Molina, Jeffery D. Ullman, Jennifer Windom Depertment of Computer Science Standord University упоминается о том, что "ныне проекты ООМД находятся на грани полного краха. Вместо перехода от реляционных к "чистым" оо системам, предсказываемого в начале 90-х годов, производители рел систем сделали ставку" на ОРМД. "В итоге многие программные продукты, ранее называвшиеся "реляционными", теперь приобрели статус "объектно-реляционных". Возможно большинство их просто по старинке называет реляционными, или считают ОО вообще чем-то не нужным (игнорируют). Alexey Rovdo - действительно существуют определенные оговорки, но какими бы они ни были, все равно данные системы не имеют истинно объектного ядра. Термин Ядро - нуждается в уточнении. Кроме того, мы же говорим о перспетиве. Ну доделают ядро (пока интуитивно понимаю под этим некие подсистемы СУБД), главное что модель данных уже присутсвует. На свое заре и реляционных СУБД, ядра были мягко говоря не лучшие. Они до сих пор усовершенствуются. Alexey Rovdo Можно сравнивать ООСУБД и ОРСУБД, но в этом случае видимо нужно подходить более детально и рассматривать конкретную ОРСУБД и конкретную задачу. И нужно сравнивать ООСУБД с ОРСУБД, считая сравнение ООСУБД с РСУБД частным случаем сравнеия ООСУБД с ОРСУБД. Это все меняет. Потому что круг типов приложений где есть преимущество у ООСУБД над РСУБД за счет ОО, теперь может пропасть. Потому что у ОРСУБД тоже есть ОО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2004, 17:55 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vadiminfoВот насчет бизнес приложений - там РМД успешна. Для зарабатывания денег пишутся не только бизнес-приложения :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2004, 21:16 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vadiminfoВы упорно сравниваете ООСУБД... Не хотелось бы вообще сравнивать абстрактно. У каждой технологии есть свои преимущества. Мне кажется, чтобы наше обсуждение было конструктивным, нам надо определиться, по каким параметрам задачи сравнивать СУБД. Я попробую начать. 1. Модель данных - реляционная, объектная, иерархическая.... 2. Принцип получения данных - запросы, навигация... 3. Специфика дальнейшей эксплуатации - бизнес-приложение, встроенное приложение, мобильное устройство... 4. Требования к разграничению доступа - по логике СУБД, по логике приложения... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2004, 21:23 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Alexey Rovdo >Что же касается PalmOS, то под этой системой вероятно можно использовать FastObjects j2 - чистую Java СУБД, обладающую многими возможностями FastObjects t7 и предназначенную именно для использования на носимых устройствах Врядли. Не все так красиво в мире джавы, как об этом пишут. На палмах проблемы. >Что касается средств шифрования. Средства шифрования никого не интересуют. Я спрашивал о системе безопасности, или как говорится в Вашей же ссылке: "Средства обеспечения безопасности". Где тут речь о шифровании? Почувствуйте разницу. >Managing the rights of each user separately can be awkward. Most of the time, each user is part of one or more workgroups, and the people in a group all need access to the same data. FastObjects allows you to create a group and assign rights to this group. These rights are granted to a user who is made a member of the group. The administrator determines which groups each user belongs to. Группы, администраторы это все замечательно. Это сделано чтоб управлять доступом пользователей. Вопрос только: доступом к ЧЕМУ? В РСУБД это таблицы, SP, представления, доступ бывает на чтение, запись и т.д. Доступом пользователя к каким ресурсам системы можно управлять в FastObjects и какой бывает доступ? >но ведь мы обсуждаем текст не на сайте корпорации Versant, а в карточке программы в интернет-магазине Softkey.ru Мы обсуждаем ту ссылку, которую Вы сочли ныжным выложить, Вас ведь за язык не тянули. Выложите другую - пообсуждаем ее. Желательно чтоб там все-таки были основные определения: класс, объект (хотя-бы как они понимаются в вашей системе), ООСУБД и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 03:20 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
c127 Группы, администраторы это все замечательно. Это сделано чтоб управлять доступом пользователей. Вопрос только: доступом к ЧЕМУ? В РСУБД это таблицы, SP, представления, доступ бывает на чтение, запись и т.д. Доступом пользователя к каким ресурсам системы можно управлять в FastObjects и какой бывает доступ? В FastObjects управлять доступом можно на уровне классов. Т.е. для пользователя (или группы) задаются права на доступ (чтение/запись/модификация) к классам объектов, хранимым в БД. Кроме этого есть возможность большей детализации за счет разграничения доступа внутри одного класса по значениям самих данных (например, можно дать права на редактирование объектов с адресом "Москва" и просмотр объектов с адресом "Ст.Петербург"). И наконец существует возможность разместить объекты в разных хранилищах и задавать права на доступ для этих хранилищ по разному. c127 Мы обсуждаем ту ссылку, которую Вы сочли ныжным выложить, Вас ведь за язык не тянули. Выложите другую - пообсуждаем ее. Желательно чтоб там все-таки были основные определения: класс, объект (хотя-бы как они понимаются в вашей системе), ООСУБД и т.д. Наиболее полная и корректная информация по FastObjects расположена Здесь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 11:19 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
LankasterМне кажется, чтобы наше обсуждение было конструктивным, нам надо определиться, по каким параметрам задачи сравнивать СУБД. Я попробую начать. 1. Модель данных - реляционная, объектная, иерархическая.... 2. Принцип получения данных - запросы, навигация... 3. Специфика дальнейшей эксплуатации - бизнес-приложение, встроенное приложение, мобильное устройство... 4. Требования к разграничению доступа - по логике СУБД, по логике приложения... Совершенно согласен. Постоянно возникает путаница, вызванная тем, что не учитываются конкретные параметры и специфика. К указанному списку я бы добавил технологию разработки, выбор которой значительно предопределяет выгодность использования той или иной СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 11:22 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
ООП, как и структурное программирование, и декларативное программирование, не имеют отношения ни к моделям данным, ни к базам данных. Термин "объектно-ориентированная" применялся к моделям данных ДО появления ООП и его "интеграции" с базами данных. Он стал использоваться после появления понятия "реляционная модель данных", чтобы отличать ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ модели данных (иерархическую, сетевую, объектную) от ЗАПИСЕ-ОРИЕНТИРОВАННОЙ реляционной модели данных. В последствии из-за утраты знаний при смене поколений некоторые авторы стали допускать грубейшую ошибку, относя иерархическую и сетевую модели данных к записе-ориентированным. Объектно-ориентированные модели данных отличают (и объединяют) два фундаментальных понятия: идентификация и навигация. Объектная модель ------------------ Основные понятия: объект, связь, экземпляр объекта, экземпляр связи, характеристика объекта, характеристика связи. Фундаментальное понятие: идентификатор. Идентификаторы обычно есть не только у экземпляров объектов, но и у объектов, связей, характеристик. Связи непосредственно реализуются между идентификаторами экземпляров, которые не являются просто одной из характеристик объекта. Важнейшим элементом любой объектной системы является объектный навигатор, обеспечивающий пользователям универсальный (прямой) доступ к данным. Разновидности объектных систем начали появляться в середине 70-х годов, когда разработчики осознали возможности MUMPS. Они начали создавать объектные инструменты для себя, для разработки своих приложений. Подобно тому, как считалось хорошим тоном написать свой текстовый процессор, опытные (или просто смелые) программисты, увидев MUMPS, считали своим долгом написать собственную СУБД. Впрочем, как я уже говорил, MUMPS, как технология, именно для этого и предназначен. Сетевая модель ---------------- Это "теоретическая предшественница" объектной модели. Ее терминология (вместо объектов и связей использовались "коллекции" и "наборы", а "вместо" идентификаторов загадочные "указатели") была ориентирована на обработку абстрактных данных, а не на моделирование окружающего мира, что только осложняло работу пользователей на всех уровнях. Иерархическая модель ----------------------- Это объектная модель, в которой одни объекты (коллекции) являются подчиненными по отношению к другим (родительским) объектам (коллекциям), причем каждый элемент (экземпляр) подчиненного объекта (коллекции) связан только с одним элементом (экземпляром) только одного родительского объекта (коллекции). Иерархическая модель (в отличие от сетевой, которая полностью заменена объектной моделью) находит применение, и, конечно, будет и в дальнейшем находить применение во многих практических задачах (особенно, когда не предполагаются непредусмотренные запросы), так как обеспечивает высокую производительность приложений. Реляционная модель --------------------- После долгих исследований и метаний между ориентацией на моделирование окружающего мира (особенно в ранних работах) и заманчивой перспективой "математизации" обработки абстрактных данных, и после очевидной неудачи с ключами, Кодд пришел к "суррогатной позиции". Этот, последний вариант реляционной модели данных отличался от объектной модели так: а) идентификаторы экземпляров помещены в записи; б) предложен математический аппарат манипулирования множествами записей. В результате концепции идентификации и навигации, а "заодно" и семантика данных, были практически полностью утрачены, а на первое, и, к сожалению, единственное место вышел "аспект манипулирования". И стало модным считать "ручную навигацию" "устаревшей" по сравнению с "автоматической навигацией". Последствия ------------- 1. "Автоматическая навигация", как и следовало ожидать, мало что дала. Жаль, что в практической плоскости этот "вопрос" участники форума рассматривать отказались. 2. А идентификация, навигация и семантика данных утрачены. В результате "Р"СУБД показывают предсказуемую неповоротливость при реализации сложных информационных систем (например, систем класса ERP), когда множеству пользователей требуется находить конкретные экземпляры конкретных объектов, чтобы выполнить над ними, и связанными с ними экземплярами других объектов, некоторые действия. И, в то же время, "Р"СУБД не получили никаких преимуществ "на своем поле", поскольку непредусмотренные запросы выполняются (оптимизируются) в дореляционных ОСУБД не менее эффективно, чем в "Р"СУБД. P.S. Конечно, нельзя сказать, что любая технология программирования одинаково "подходит" к любой модели данных. С уверенностью можно сказать только о том, что - ни так называемые "реляционные" системы; - ни так называемые "объектно-реляционные" системы; - ни так называемые "объектно-ориентированные (в смысле ООП)" системы; не позволяют использовать один (интегрированный) язык программирования для разработки приложений. Только объектные системы, основанные на принципах идентификации и навигации, позволяют использовать один, причем очень мощный, язык программирования. В том числе и поэтому даже очень сложные приложения, разработанные в среде таких систем, оказываются простыми и надежными ы эксплуатации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 17:07 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичТолько объектные системы, основанные на принципах идентификации и навигации, позволяют использовать один, причем очень мощный, язык программирования. В том числе и поэтому даже очень сложные приложения, разработанные в среде таких систем, оказываются простыми и надежными ы эксплуатации. Могу только полностью согласиться и добавить к этому описанию то, что я выложил Здесь . Возможно именно исторический взгляд на вещи поможет кому-то понять, что дискутируемые здесь объектные системы не появились из ниоткуда и вовсе не собираются кануть в бездну. А представляют собой мощный пласт развития индустрии, который, хотя и конкурирует с реляционными системами в некоторых (возможно, достаточно разных и многочисленных) "пограничных" сферах, в целом имеет более чем широкий круг применения и давно признан в ряде сфер, как наиболее перспективное и удобное для решения практических задач средство. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 18:18 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
А я, к сожалению, согласиться не могу, потому что там у Вас речь идет, все-таки, об объектно-ориентированных системах именно на базе ООП. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 18:29 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидович поскольку непредусмотренные запросы выполняются (оптимизируются) в дореляционных ОСУБД не менее эффективно, чем в "Р"СУБД. А можно поподробнее об этом? Чем эта эффективность дореляционных СУБД обеспечивается? Что за приёмы оптимизации позволяют так же хорошо оптимизировать непредусмотренные запросы? А можно привести примеры? С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 18:30 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Ну вот они и встретились... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 18:43 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичА я, к сожалению, согласиться не могу, потому что там у Вас речь идет, все-таки, об объектно-ориентированных системах именно на базе ООП. Там речь собственно об истории вопроса. Но вот в моем понимании FastObjects и VDS (уже упоминавшиеся в этом топике) относятся именно к системам "основанным на принципах идентификации и навигации". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 18:47 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Lankaster Не хотелось бы вообще сравнивать абстрактно. У каждой технологии есть свои преимущества. Мне кажется, чтобы наше обсуждение было конструктивным, нам надо определиться, по каким параметрам задачи сравнивать СУБД. Я попробую начать. 1. Модель данных - реляционная, объектная, иерархическая.... 2. Принцип получения данных - запросы, навигация... 3. Специфика дальнейшей эксплуатации - бизнес-приложение, встроенное приложение, мобильное устройство... 4. Требования к разграничению доступа - по логике СУБД, по логике приложения... Вот именно, есть преимущества и недостатки. Но в теме заявлене ООМД, и автор начал ее сравнивать с РМД, упомянув вскользь про то, что на ОРМД можно и не орбращать внимания. Но в целом, тройка моделей назана. Обектную рассматривать не стоит - к этому типу относится кроме ООМД, например, инфологичексая ER. Зачем расширять круг моделей в эту сторону в этой теме? Иерархические тоже можно отбросить в этой теме, поскольку их эра прошла 30 лет тому назад, и она в этой теме может иметь только историческое значение. Остаются три: ООМД, РМД и ОРМД. Такую тему по сравнению этих трех моделей (точнее там три типа СУБД были ООСУБД, ОРСУБД и РСУБД) на этом форуме поднимали. Но она сошла на нет, продержавшись чуть ли не два года. Правда, одной из причин было, по видимому, то, что от ООМД почти никого не было. А в качестве ООМД рассматривали только Кэша. Но у Вас более классическая ООМД от Версанта. Это лучше. Хотя и Кэш продролжает представлять интерес. И традиционно именно перечислять достоинства и недостатки этих моделей, которые могут попадать и не попадать в пп 2, 3, 4. И потом уже смотреть на каких типах приложений эти недостатки или достоинства проявляются. Можно обсуждать и сами СУБД этих типов. Однако, приходится учитывать, что недостатки СУБД не всегда обусловленны недостатками моделей данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 19:32 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Чего-то лично я в Кэш"е ничего чисто объектного не увидел. Интересно, соответствует она ODMG или нет? Что-то сильно сомневаюсь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 19:47 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Sp1DerЧего-то лично я в Кэш"е ничего чисто объектного не увидел. Интересно, соответствует она ODMG или нет? Что-то сильно сомневаюсь... Лично я тоже. Хотя хранить в Cache объектные данные можно без проблем. Но если почитать рекомендации разработчиков, то оказывается, что эффективнее всего эта СУБД работает, когда вы общаетесь с ней через Cache' Direct Access. Т.е. опираетесь не на объектную модель, а на многомерную модель данных Cache. Я бы сравнил существующие в Cache объектные инструменты со средствами O/R отображения (такими, например, как Versant Open Access). Т.е. в Cache встроен объектный инструментарий, но это лишь некий внешний интерфейс к ядру системы. В действительно объектных СУБД внешний объектный интерфейс целиком соответствует внутренней структуре хранения данных. В то же время сами объектные СУБД для универсализации оснащаются своего рода R/O инструментами, позволяющими иметь реляционные интерфейсы к объектному хранилищу. Не хотелось бы ругать Cache - у этой системы достаточно много приверженцев, но на мой взгляд ее ниша уже, чем пытаются представить ее производители. Причем в большей степени она должна конкурировать с реляционными системами нежели с чистыми объектными СУБД, которые на своем поле дадут Cache большую фору. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 20:11 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
это не мое личное мнение, я просто передаю все, что мне мои френдсы про Кэш говорили, что все имеющиеся объектные приблюды никто не пользует... за неудобством и неэффективностью по большей части... но все это не есть тема этого топи, здесь мы, по-моему про ООСУБД беседуем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 20:16 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Константин Лисянский ! Да те же самые приемы. У меня сложилось впечатление, что Вас что-то удивляет. Как-будто оптимизатор запросов может существовать только в "Р"СУБД. Роли, конечно, разные. В "Р"СУБД - это, по-существу, ядро, без которого система не работает. А в ОСУБД, в первую очередь, - средство для произвольных (непредусмотренных в приложении) запросов пользователей. Только и всего. Что же Вас удивляет ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 21:31 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Sp1Der ! Именно "соответствует ODMG". Можете не сомневаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 21:36 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичSp1Der ! Именно "соответствует ODMG". Можете не сомневаться. доказательства...? где они? одни слова... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 21:42 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Извините за беспокойство, и забудьте про эти "одни слова". Конечно, видео и графика в Ваших сообщениях выглядят куда доходчивее... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 21:53 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Андрей Леонидович, Действительно интересно почему Вы так считаете. В одном Вы правы, давайте здесь об этом не будем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 21:57 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичЧто же Вас удивляет? Андрей Леонидович, меня ничего не удивляет. Просто я задал вопрос, хотел получить ответ. Я мало знаком с дореляционными оптимизаторами (работал всё время лишь с РСУБД). Хотел узнать что обеспечивает их эффективность на непредвиденных запросах. Вот и всё. Если я правильно понимаю, доступ к данным в дореляционых СУБД был больше основан на связях (сетевые и иерархические модели, если не ошибаюсь) или на индексном доступе (тут даже затрудняюсь привести названия продуктов, видать, молод ещё :). Таким образом, дореляционные СУБД должны были очень хорошо уметь работать с данными, связи в которых фиксировано прописаны. В реляционных же СУБД фактически любой запрос является непредвиденным, поскольку связи между данными создаются динамически с помощью операций соединения таблиц. Соответственно, оптимизатор СУБД должен обладать хорошими возможностями построения оптимальных планов доступа к данным в условиях, когда связи заранее не заданы. Что привело к созданию, например, стоимостных оптимизаторов, а также всевозможных индексных механизмов доступа, партишионингу, параллельной обработке и т.д. Правильно ли я понимаю, что дореляционные СУБД тоже использовали стоимостные методы построения планов запросов, или там, всё-таки, какие-то другие методы применялись? Буду благодарен за ответ. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 22:30 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Вы правильно понимаете. Только не использовали, а используют (как, например, колесо до сих пор используют). "До" я применяю чтобы соответствовать исторической справедливости, и чтобы четко отделиться от ООП, которое неизбежно приводит к "после". Здесь уже было две темы "Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД" и "СУБД CACHE" по этому поводу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 23:20 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичВы правильно понимаете. Только не использовали, а используют (как, например, колесо до сих пор используют). "До" я применяю чтобы соответствовать исторической справедливости, и чтобы четко отделиться от ООП, которое неизбежно приводит к "после". Здесь уже было две темы "Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД" и "СУБД CACHE" по этому поводу. Ага. Дореляционные ОСУБД используют стоимостные оптимизаторы. ОК. А нельзя ли чуточку подробнее на этом остановиться? Какие технологии стоимостных оптимизаторов этих самых дореляционных СУБД обеспечивают эффективность, сравнимую с РСУБД? На основе чего в них вычисляется стоимость запросов? Какие способы доступа к данным существуют? Как оптимизатором учитываются особенности аппаратной платформы? Спасибо. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 23:49 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Андрей Леонидович А на мои вопросы по-прежнему ответов нет. Что, слабо ответить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 04:09 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Alexey Rovdo >Наиболее полная и корректная информация по FastObjects расположена Здесь Я там не нашел ничего по основам FastObjects. Если можно, укажите поконкретней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 04:22 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey RovdoТ.е. в Cache встроен объектный инструментарий, но это лишь некий внешний интерфейс к ядру системы. Именно. Каше - это иерархическая база данных. А объектный и SQLный интерефейс - это лишь надстройки. В Каше все данные хранятся в глобалах, будь то объекты, будь то таблицы. Любой SQL-запрос переводится всё в тот же COS (прямой доступ к данным) и лишь потом исполняется. Причем в большей степени она должна конкурировать с реляционными системами нежели с чистыми объектными СУБД, которые на своем поле дадут Cache большую фору. Не уверен. Объектная настройка сделана более качественнее, чем реляционная, imho :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 09:47 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
c1272 Alexey Rovdo >Наиболее полная и корректная информация по FastObjects расположена Здесь Я там не нашел ничего по основам FastObjects. Если можно, укажите поконкретней. К моему сожалению рускоязычных материалов по объектным базам данных (даже по их концептуальным основам) практически нет. Для первоначального ознакомления могу предложить Введение в объектные базы данных (потребуется зарегистрироваться на сайте), можете также посмотреть саму документацию по продуктам (там достаточно много информации). Вполне допускаю, что ответов на ваши вопросы вы так и не сможете найти в тех материалах, на которые я вас отослал. Тогда следите за публикациями на www.citforum.ru . В ближайшее время (месяц-два), надеюсь, там появятся русскоязычные статьи о продуктах Versant, где будут раскрываться именно технические детали, а не только маркетинговые преимущества данных продуктов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 12:51 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Константин Лисянский ! Нельзя. Кто что считает нужным использовать, тот то и использует. Например, динамически обновляемую статистику по экземплярам, связям, индексам... Если вдруг выяснится, что необходимо учитывать завод, на котором сделан сервер, значит давайте учитывать... Что-то Вас, все-таки, смущает. Вот моя догадка: объектные системы не препятствуют декларативному программированию и оптимизации запросов, а в "реляционных" системах навигация невозможна, а идентификация и семантика данных реализованы безнадежно убого. Вопрос: что проще: реализовать идентификацию, навигацию и семантику данных в "реляционной" СУБД (когда ее кто-то сможет, наконец-то, создать) или декларативный язык запросов в объектной СУБД (если это кому-то нужно, или объективно необходимо) ? А Вы думаете мне приятен вывод, который пришлось сделать ? У меня ведь была эйфория, когда принялся изучать Р(тогда еще без кавычек)СУБД. Но года через полтора все прояснилось: бесполезная технология. P.S. Кстати, тут на Кузнецова "обижались" из-за термина "маскировка". Да, действительно, внешне выглядит так, будто идентификаторы в О"Р"СУБД находятся "за пределами отношения". А где они находятся на самом деле ? Разве не в тех же записях, где и прочие "атрибуты" "кортежа" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:42 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый с127 ! Нет, не слабо. Просто Вы прекрасно знаете на какой странице темы "Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД" изложен мой вариант формализации РМД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:44 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидович ...объектные системы не препятствуют декларативному программированию и оптимизации запросов, а в "реляционных" системах навигация невозможна, а идентификация и семантика данных реализованы безнадежно убого. Вопрос: что проще: реализовать идентификацию, навигацию и семантику данных в "реляционной" СУБД (когда ее кто-то сможет, наконец-то, создать) или декларативный язык запросов в объектной СУБД (если это кому-то нужно, или объективно необходимо) ? А Вы думаете мне приятен вывод, который пришлось сделать ? У меня ведь была эйфория, когда принялся изучать Р(тогда еще без кавычек)СУБД. Но года через полтора все прояснилось: бесполезная технология. Практически все неверно. 1. Объектные СУБД таки да, препятствуют успешному оптимизированию запросов. Поскольку до сих пор отсутсвует теория этого дела (в отличие от реляционных). Соответственно, призводителность отличается. 2. Непонятно, что вы понимаете под "семантикой и навигацией данных", но если речь идет об объектах и их представлении в СУБД, то существуют а) object-wrappers, переводящие объекты в реляционную форму хранения, и б) Informix version 9, где реализованы наследование, инкапсуляция и полиморфизм - три источника и три составные части ООП. А то, что общение программ с БД происходит через odbc/jdbc/embedded Java/C/C++ - так звиняйте, никто не обещал, что одна система объектов (программа) будет общаться с другой системой объектов (бд) на родном языке. 3. Ну и насчет бесполезности реляционных баз - это вы знатно пошутили. Мы тут, на SQL.ru, шутку оценили. Мое ХО по поводу что есть объектная и объектно-реляционные БД. ОРДБ есть привинчивание объектных рюшечек к грубой реляционной базе, как это делают все известные производители - Оракл, ИБМ, почивший Информикс. Т.е. внутри у нее неонка, т.е. таблицы, и связи между таблицами не фиксированы и не хранятся. ОБъектные БД - это свисточки и колокольчики на сетевых Бд, которые таки да, хранят связи в виде указателей, адресов и т.д. Поэтому что бы не говорили производители, а такие базы не могут быстро обрабатывать запросы, для которых не существует заранее предусмотренной связи. End of story. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:38 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
О. Я предупреждал что ОН грядет. Правда, в другом топике про то же самое, но ОН наверное уже и там. Пока не смотрел ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:43 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vybegalloТ.е. внутри у нее неонка"внутре у ей неонка" ? :) Alex.CzechЯ предупреждал что ОН грядет.Не поминай всуе... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:46 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидович Объектная модель ------------------ Основные понятия: объект, связь, экземпляр объекта, экземпляр связи, характеристика объекта, характеристика связи. Фундаментальное понятие: идентификатор. Идентификаторы обычно есть не только у экземпляров объектов, но и у объектов, связей, характеристик. Связи непосредственно реализуются между идентификаторами экземпляров, которые не являются просто одной из характеристик объекта. Важнейшим элементом любой объектной системы является объектный навигатор, обеспечивающий пользователям универсальный (прямой) доступ к данным. Разновидности объектных систем начали появляться в середине 70-х годов, когда разработчики осознали возможности MUMPS. Они начали создавать объектные инструменты для себя, для разработки своих приложений. Подобно тому, как считалось хорошим тоном написать свой текстовый процессор, опытные (или просто смелые) программисты, увидев MUMPS, считали своим долгом написать собственную СУБД. Впрочем, как я уже говорил, MUMPS, как технология, именно для этого и предназначен. Прямой доступ к данным необходим только в том случае, если работет OLTP система с выборкой одного родительского объекта с его деталями по идентификатору. При этом подразумевается, что одновременный доступ к одним и тем же объектам отсутствует. Тогда не нужен дополнительный груз в виде транзакций, обеспечения целостности чтения и т.д. Но при наличии одновременного доступа нарушалась целостность данных (MSM). Поиск по неключевым характеристикам или выборки большого количества объектов приводили (MSM) к дикому требованию "всем выйти, Чапай будет делать отчет" (грязное чтение) и долгому обходу всех данных, хотя нужны были только за один день. Достоинство - компактность и быстродействие в указанных границах. Андрей Леонидович Сетевая модель ---------------- Это "теоретическая предшественница" объектной модели. Ее терминология (вместо объектов и связей использовались "коллекции" и "наборы", а "вместо" идентификаторов загадочные "указатели") была ориентирована на обработку абстрактных данных, а не на моделирование окружающего мира, что только осложняло работу пользователей на всех уровнях. Иерархическая модель ----------------------- Это объектная модель, в которой одни объекты (коллекции) являются подчиненными по отношению к другим (родительским) объектам (коллекциям), причем каждый элемент (экземпляр) подчиненного объекта (коллекции) связан только с одним элементом (экземпляром) только одного родительского объекта (коллекции). Иерархическая модель (в отличие от сетевой, которая полностью заменена объектной моделью) находит применение, и, конечно, будет и в дальнейшем находить применение во многих практических задачах (особенно, когда не предполагаются непредусмотренные запросы), так как обеспечивает высокую производительность приложений. Вы сами описали область применимости. Она достаточно узкая и для современных информационных систем, а именно систем поиска и анализа, а не просто ввода данных мало пригодна. Слишком много нерегламентированных запросов. Андрей Леонидович Последствия ------------- 1. "Автоматическая навигация", как и следовало ожидать, мало что дала. Жаль, что в практической плоскости этот "вопрос" участники форума рассматривать отказались. Это почему же? Просто автоматическая навигация дала возможность ходить по данным в любом направлении, а не только по заданным ссылкам. Кстати, во всех СУБД используются индексы. А для чего? Для ускорения поиска по неключевым данным, как Вы прекрасно знаете. То есть не все ладно с быстродействием и в СУБД с "прямыми ссылками". В качестве примера заодно укажу, что в оракле, то есть ОРСУБД, тоже есть прямые ссылки, только с сохранением согласованности данных. Андрей Леонидович 2. А идентификация, навигация и семантика данных утрачены. В результате "Р"СУБД показывают предсказуемую неповоротливость при реализации сложных информационных систем (например, систем класса ERP), когда множеству пользователей требуется находить конкретные экземпляры конкретных объектов, чтобы выполнить над ними, и связанными с ними экземплярами других объектов, некоторые действия. И, в то же время, "Р"СУБД не получили никаких преимуществ "на своем поле", поскольку непредусмотренные запросы выполняются (оптимизируются) в дореляционных ОСУБД не менее эффективно, чем в "Р"СУБД. Вы не совсем правильно понимаете системы ERP. В этом названии главное - planning, то есть анализ данных и принятие на их основе решений. А это приводит к нерегламентированным запросам, и ввод данных - только небольшая часть ERP-систем. Например, в OEBS на ввод финансовых операций отведено в главной книге не более 25% таблиц. Остальные - для анализа и отчетности. Вас просили рассказать об оптимизаторах нерегламентированных запросов, но Вы как-то технично пропустили его. Андрей Леонидович P.S. Конечно, нельзя сказать, что любая технология программирования одинаково "подходит" к любой модели данных. С уверенностью можно сказать только о том, что - ни так называемые "реляционные" системы; - ни так называемые "объектно-реляционные" системы; - ни так называемые "объектно-ориентированные (в смысле ООП)" системы; не позволяют использовать один (интегрированный) язык программирования для разработки приложений. Только объектные системы, основанные на принципах идентификации и навигации, позволяют использовать один, причем очень мощный, язык программирования. В том числе и поэтому даже очень сложные приложения, разработанные в среде таких систем, оказываются простыми и надежными ы эксплуатации. Коммерция - вещь жестокая. А придумки одного общего языка всегда наталкивались на эффект вавилонской башни - хоть немного, да отличается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:51 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vybegallo ! 1. О какой теории оптимизации запросов в "реляционных" СУБД Вы говорите ? Когда нет даже самих реляционных СУБД. 2. Я уже много раз высказывал свое мнение про ООП и его отношение к моделям данных и базам данных. Под навигацией я понимаю исключительно навигацию, а под семантикой исключительно семантику. 3. Рад, что повеселил хорошего человека. Жаль, что на нешуточные аргументы (а я их уже много привел в трех темах) Вы не обратили внимание. 4. Про заранее непредусмотренную связь - серьезное заблуждение. С одной стороны не "не могут быстро", а ВООБЩЕ НЕ МОГУТ "родными" средствами. С другой стороны: s query(1)="h2.o1,h7.o2",query(2)="o1,o2",query(3)="h2=h7" s result=$$^%oz("query","result") где h2 - идентификатор характеристики День рождения объекта o1 Человек, а h7 - идентификатор характеристики Примечание объекта o2 Товаро-транспортная накладная И кто Вам сказал, что оптимизатор oz будет работать медленнее, чем оптимизатор какой-то "реляционной" СУБД ? Преподаватель что ли на лекции сообщил ? А вот то, что за 20 лет эксплуатации разнообразных приложений в таких запросах НИ РАЗУ не возникло необходимости - это факт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 22:13 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Al ! 1. Фрагмент "про MSM". И Вас что ли преподаватель подкачал ? Или знакомый какой? Конечно же, одновременный доступ к данным, транзакции, моментальные снимки и т.п. И компактность, и быстродействие - во всех мыслимых границах. Вы, видимо, так и не захотели плнять для чего нужен MUMPS. 2. Да, конечно, я описал область применения иерархической модели данных, которую я сам НИКОГДА не применял ни для каких приложений. 3. Я уже рассказывал о принципиально разной роли индексов в объектных и "реляционных" системах. Очень советую Вам обратить на это внимание. 4. Правильно, правильно я "понимаю системы ERP". И про "странности" OEBS ИМЕННО ПО ЭТОМУ ПОВОДУ (!) я уже говорил, причем именно знатоков процитировал. 5. Что значит "технично пропустил" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 22:33 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичИ кто Вам сказал, что оптимизатор oz будет работать медленнее, чем оптимизатор какой-то "реляционной" СУБД ? Преподаватель что ли на лекции сообщил ? Что Вы, что Вы! Никто не сомневается. Тут уже очередь выстроилась, чтобы узнать хоть что-нибудь об оптимизаторах ООСУБД. Однако, несмотря на все усилия пока об этих загадочных оптимизаторах ничего кроме: Андрей ЛеонидовичДа те же самые приемы или Андрей ЛеонидовичО какой теории оптимизации запросов в "реляционных" СУБД Вы говорите ? Когда нет даже самих реляционных СУБД. ничего узнать не удается. А жаль ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 23:09 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидовичvybegallo ! 1. О какой теории оптимизации запросов в "реляционных" СУБД Вы говорите ? Когда нет даже самих реляционных СУБД. 2. Я уже много раз высказывал свое мнение про ООП и его отношение к моделям данных и базам данных. Под навигацией я понимаю исключительно навигацию, а под семантикой исключительно семантику. 3. Рад, что повеселил хорошего человека. Жаль, что на нешуточные аргументы (а я их уже много привел в трех темах) Вы не обратили внимание. 4. Про заранее непредусмотренную связь - серьезное заблуждение. С одной стороны не "не могут быстро", а ВООБЩЕ НЕ МОГУТ "родными" средствами. С другой стороны: s query(1)="h2.o1,h7.o2",query(2)="o1,o2",query(3)="h2=h7" s result=$$^%oz("query","result") где h2 - идентификатор характеристики День рождения объекта o1 Человек, а h7 - идентификатор характеристики Примечание объекта o2 Товаро-транспортная накладная И кто Вам сказал, что оптимизатор oz будет работать медленнее, чем оптимизатор какой-то "реляционной" СУБД ? Преподаватель что ли на лекции сообщил ? А вот то, что за 20 лет эксплуатации разнообразных приложений в таких запросах НИ РАЗУ не возникло необходимости - это факт. Извините, но "когда вы говорите, такое впечатление, что вы бредите". 1. "Реляционность" субд определяется тем, хранит ли она связи между сущностями (таблицами, объектами, кортежами). Все остальное - изыски теоретиков, "глубокомысленное ковыряние в носу". 2. Я рад, что под навигацией вы понимаете исключительно навигацию, а под семантикой - только семантику. Но если вам лень в двух словах изложить свою позицию - то мне тем более лень рыться в трех темах, пытаясь выловить суть в длинных выдержках из научно-популярных статей, причем многие утверждения в этих статьях, мягко говоря, спорны. 3. "Нешуточных" аргументов я как-то не заметил - одни слабо обоснованные утверждения. Например, "1. "Автоматическая навигация", как и следовало ожидать, мало что дала. " - это вы так обозвали непроцедурность SQL ? И, значит, считаете, что курсорные методы доступа, "ручная навигация" в вашем новоязе - гораздо круче ? Ну понятно, почему "этот "вопрос" участники форума рассматривать отказались" - потому что для людей, зарабатывающих деньги программированием, а не расуждениями о нем, тут вопроса нет. 4. Тут я в вашей нотации, извиняюсь, нихрена не понял. Смешались в кучу дни рождения и товарно-транспортные накладные. 5. И кто вам сказал, что в ООБД вообще есть оптимизатор, преподаватель ? Ручная навигация - она ж гораздо круче, программист просто берет и лабает цикл за циклом, условие за условием, пока не доберется до результата. 6. В каких запросах не возникало необходимости за 20 лет ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 23:51 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Терпеливый ! Оптимизаторы по стоимости при выполнении запроса используют автоматически обновляемые статистические данные об объектах, связях, индексах. Какая еще очередь ? Чего узнать не удается ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 00:07 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичТерпеливый ! Оптимизаторы по стоимости при выполнении запроса используют автоматически обновляемые статистические данные об объектах, связях, индексах. Какая еще очередь ? Чего узнать не удается ? План запроса не приведете для примера ? А то это пока общие слова. Кстати, автоматически обновлять статистику - занятие не очень совместимое с обработкой больших потоков транзакций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 00:26 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vybegallo ! Ваша позиция мне очень хорошо знакома. Я к ней уже привык на этом форуме настоящих специалистов. Вы чего-то не поняли. Вам лень разбираться. Следовательно я говорю бред. Ничего страшного. Рано или поздно разберетесь в этом "бреде". Я "не рассуждаю о программировании", а просто сообщаю Вам то, о чем Вы не знали. А насчет "тут вопроса нет" я уже говорил: это я сразу понял по количеству тем и сообщений на этом форуме... Так что Вы хотели сказать про связывание отношений не по ключам ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 00:30 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичОптимизаторы по стоимости при выполнении запроса используют автоматически обновляемые статистические данные об объектах, связях, индексах. А какой характер имеет эта статистика? Приведу пример - в реляционных базах данных (с кавычками или без, сейчас не очень важно, приведу просто пару названий в пример - Oracle, Teradata), насколько мне известно, статистика - это гистограммы, характеризующие распределение данных в столбцах или группах столбцов. Эти гистограммы помогают оптимизатору выбирать оптимальные (на его оптимизатора взгляд, и тут надо признать, он не всегда так уж и оптимален) пути доступа к данным (если речь, например идёт о проекции или фильтрации) или способы выполнения соединений таблиц (если речь идёт о таковых). Как правило (но есть и исключения, и, по-моему, это DB2 на AS/400, кто-нибудь поправит, если это не так), статистика не обновляется автоматически (если "автоматически" подразумевает "при каждом изменении данных в таблице СУБД сама изменяет статистику"). И это понятно - при изменении одной строки таблицы вряд ли нужно как-то менять план запроса, если в таблице миллионы строк). Вместо этого данная задача переносится (и это, надо признать, неудобно, но за всё нужно платить) на разработчика или администратора БД, который должен время от времени собирать её, если значения столбцов в таблице сильно изменяются. Соответственно, у меня к Вам вопрос - а как с этим обстоят дела в так назваемых ООСУБД, о которых здесь идёт речь? Что Вы имели в виду под автоматическим обновлением статистики, и что это за статистика в ООСУБД? Как она выглядит и как помогает оптимизатору при нерегламентированных запросах? Спасибо. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 00:34 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидович Оптимизаторы по стоимости при выполнении запроса используют автоматически обновляемые статистические данные об объектах, связях, индексах. Уф-ф. Значит, оптимизаторы все-таки есть. Примечательно, что отличия от РСУБД намечаются существенные, т.к. в большинстве из них статистика динамически не собирается. Андрей Леонидович Какая еще очередь ? Три участника форума повторили этот вопрос, прежде чем Вы ответили. Андрей Леонидович Чего узнать не удается ? 1) Какая именно статистика собирается по объектам? 2) Какие именно индексы используются (B-tree, bitmap, и т.д.)? Можно сразу с примерами в каких ООСУБД, какие индексы используются? 3) Как выглядит план выполнения запроса? 4) Какие этапы обработки запроса могут выполняться параллельно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 00:35 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Здесь я с Вами, vybegallo, согласен. В "реляционных" СУБД сложно найти хоть что-то "совместимое". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 00:35 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидович Вам лень разбираться. Вовсе нет. Приведите пример достойной, по Вашему мнению, реализации ОО парадигмы, и я с удовольствием почитаю документацию по архитектуре этой СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 00:43 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
1) Необходимая и достаточная статистика. 2) Нужные индексы. 3) Симпатично выглядит. 4) Все запросы выполняются параллельно. А из фразы "значит оптимизаторы все-таки есть" можно сделать вывод, что я не врал. Замечательно... "Пример реализации ОО парадигмы" ??? Какой "ОО парадигмы" ??? Вы MUMPS хорошо знаете. Мне кажется нет. Вот и изучите. Что Вам мешает ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 00:56 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 vybegallo, Терпеливый, AI: Ребята, не тратьте зря время. Все запросы выполняются параллельно, необходимая и достаточная статистика собирается, связи рулят, идентификаторы фундаментальны. Что вам ещё надо? Более детальных ответов не будет. 2 Андрей Леонидович: Спасибо за содержательную беседу. Я многое узнал. Как в той песне про бермудский треугольник :)) С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 01:04 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Константин Лисянский ! Все так и есть. Именно такого же характера статистика (количество экземпляров объектов, количество связанных экземпляров, распределение количества экземпляров по значениям индексов и др.). Администратор указывает количество фоновых заданий сбора статистики и время их запуска. Далее все именно автоматически... И еще раз напоминаю, что собственно приложение может вообще не использовать оптимизатор запросов (в отличие от "реляционных" СУБД). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 01:09 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Андрей Леонидович >Нет, не слабо. Просто Вы прекрасно знаете на какой странице темы "Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД" изложен мой вариант формализации РМД. Нет, не знаю. И потом я задавал Вам не только этот вопрос. Еще Вы утверждаете, что отвчаете на все вопросы подробно и с цитатами, безотносительно, знает ли ответ автор вопроса или нет. Так что Вы говорите неправду - не на все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 01:13 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичЗдесь я с Вами, vybegallo, согласен. В "реляционных" СУБД сложно найти хоть что-то "совместимое". То есть вы считаете, что автоматическое обновление статистики совместимо с обработкой потока транзакций, или, того пуще, с массированными удалениями-вставками ? Или вам просто реляционные базы лягнуть хотелось ? Так ведь у нас, худо-бедно, но наименьший общий делитель имеется - стандарт SQL называется. Поддерживается всеми основными производителями. Как насчет такового у "совместимых" ООБД ? А скажите мне, Андрей Леонидович, как художник художнику - вы хоть один план запроса в глаза видели ? Inner Join от Outer Join без гугла отличить сможете ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 01:16 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Извините, Константин Лисянский ! Оказывается Вам уже все ясно. Я очень хорошо понимаю как здесь всем хотелось бы, чтобы запросы не выполнялись, статистика не собиралась, связи не рулили, а первичные ключи были бы лучше и фундаментальнее идентификаторов. А Вы просто считайте, что так оно и есть. И все у Вас будет хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 01:17 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичУважаемый Константин Лисянский ! Все так и есть. Именно такого же характера статистика (количество экземпляров объектов, количество связанных экземпляров, распределение количества экземпляров по значениям индексов и др.). Администратор указывает количество фоновых заданий сбора статистики и время их запуска. Далее все именно автоматически... И еще раз напоминаю, что собственно приложение может вообще не использовать оптимизатор запросов (в отличие от "реляционных" СУБД). Очень радует, что администратор запускает задачу сбора статистики, "а дальше оно автоматически". А то мы тут, в реляционных, замаялись уже на бумажечке подсчитывать и тумблерами вводить... Но эта вся статистика, почему-то, относится только к доступу "по значению". Хотелось бы еще при этой жизни увидеть план запроса "по ссылкам", постороенный оптимизатором. Ну, скажем, один объект попадает в две иерархии - и умная программа выбирает, с какого корневого объекта начинать ходить по указателям. Их есть у вас ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 01:26 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Нет, vybegallo, не хотелось мне никого лягать... Видел ли я хоть один план ? Написал ли я хоть одну программу ? Спроектировал ли я хоть одну базу данных ? Не Вы первый здесь очень хочет, чтобы я оказался не компетентным... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 01:33 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Да, "их есть". И я это написал черным по белому. А Вы опять спрашиваете, как ни в чем не бывало... Спокойной ночи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 01:37 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vybegallo Андрей Леонидовичvybegallo ! 1. О какой теории оптимизации запросов в "реляционных" СУБД Вы говорите ? Когда нет даже самих реляционных СУБД. 2. Я уже много раз высказывал свое мнение про ООП и его отношение к моделям данных и базам данных. Под навигацией я понимаю исключительно навигацию, а под семантикой исключительно семантику. 3. Рад, что повеселил хорошего человека. Жаль, что на нешуточные аргументы (а я их уже много привел в трех темах) Вы не обратили внимание. 4. Про заранее непредусмотренную связь - серьезное заблуждение. С одной стороны не "не могут быстро", а ВООБЩЕ НЕ МОГУТ "родными" средствами. С другой стороны: s query(1)="h2.o1,h7.o2",query(2)="o1,o2",query(3)="h2=h7" s result=$$^%oz("query","result") где h2 - идентификатор характеристики День рождения объекта o1 Человек, а h7 - идентификатор характеристики Примечание объекта o2 Товаро-транспортная накладная И кто Вам сказал, что оптимизатор oz будет работать медленнее, чем оптимизатор какой-то "реляционной" СУБД ? Преподаватель что ли на лекции сообщил ? А вот то, что за 20 лет эксплуатации разнообразных приложений в таких запросах НИ РАЗУ не возникло необходимости - это факт. Извините, но "когда вы говорите, такое впечатление, что вы бредите". ... Вы не первый тут и еще пару страниц назад всё тоже самое :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 01:42 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичДа, "их есть". И я это написал черным по белому. А Вы опять спрашиваете, как ни в чем не бывало... Спокойной ночи. "Тут мне карта и поперла !" (С) Не надо нам рассказывать - вы нам ПОКАЖИТЕ хоть один такой план. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 01:44 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
SergSuper vybegallo Андрей Леонидовичvybegallo ! 1. О какой теории оптимизации запросов в "реляционных" СУБД Вы говорите ? Когда нет даже самих реляционных СУБД. ... А вот то, что за 20 лет эксплуатации разнообразных приложений в таких запросах НИ РАЗУ не возникло необходимости - это факт. Извините, но "когда вы говорите, такое впечатление, что вы бредите". ... Вы не первый тут и еще пару страниц назад всё тоже самое :) Нда... :-( примета времени - раньше на изобретении вечного двигателя крышей съезжали, теперь - на объектных субд... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 01:52 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидович 1. Фрагмент "про MSM". И Вас что ли преподаватель подкачал ? Или знакомый какой? Конечно же, одновременный доступ к данным, транзакции, моментальные снимки и т.п. И компактность, и быстродействие - во всех мыслимых границах. Вы, видимо, так и не захотели плнять для чего нужен MUMPS. Мне не нужны были шашечки, мне надо было ехать. Пока куча операционистов работала на вводе вкладных операций (я работал в банке), все было нормально. Но подготовки отчетов, регламентированных заметьте, выполнялись крайне долго. А для нерегламентированных отчетов вообще каждый раз надо было писать длинную программулину, хотя все могло решиться обычным селектом с 3-4 связками таблиц. Даже фокспро отчет по таким объемам данных давало за минуту, а MSM - за полчаса. Андрей Леонидович 3. Я уже рассказывал о принципиально разной роли индексов в объектных и "реляционных" системах. Очень советую Вам обратить на это внимание. Я, кажется, упустил это. Не могли бы Вы дать ссылку. Почему-то я считал, что роль индексов - это ускорение доступа к данным. Можно обращаться по адресам, хранящимся в индексах, но можно просто и сами индексированные данные достать. А тут - принципиально разная роль. Андрей Леонидович 4. Правильно, правильно я "понимаю системы ERP". И про "странности" OEBS ИМЕННО ПО ЭТОМУ ПОВОДУ (!) я уже говорил, причем именно знатоков процитировал. Ссылку, пожалуйста, дайте. Я опять что-то пропустил. В OEBS отчетов больше, чем форм ввода, да и при внедрении требуется написать кучу отчетов и немного формочек ввода и утилит взаимодействия с внешними системами. Я уж не говорю о всяких системах типа discoverer или integrator, которые ничего не вводят, но показывают данные пользователям. В R3 аналогичное деление по функционалу. Андрей Леонидович 5. Что значит "технично пропустил" ? То и значит. Ответ типа "оптимизатор есть, отстаньте от меня" - это не ответ. Насколько я помню, но могу и ошибаться, первый в мире стоимостной оптимизатор появился где-то в начале 90-х в базе от sybase. А знатоки разные бывают. Один линуксолог на мой вопрос, почему редхат порушил мне диск и как с этим бороться, ответил "только идиоты используют редхат, надо использовать сусе". Ваши ответы примерно такие же. Никаких планов выполнения, никаких фактов, только реклама. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 10:14 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Насколько я помню, но могу и ошибаться, первый в мире стоимостной оптимизатор появился где-то в начале 90-х в базе от sybase. СУБД Teradata существует уже 25 лет и там всегда был стоимостной оптимизатор. Так что первенство Sybase можно, как минимум, оспорить. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 10:36 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo Возможно именно исторический взгляд на вещи поможет кому-то понять, что дискутируемые здесь объектные системы не появились из ниоткуда и вовсе не собираются кануть в бездну. А представляют собой мощный пласт развития индустрии, который, хотя и конкурирует с реляционными системами в некоторых (возможно, достаточно разных и многочисленных) "пограничных" сферах, в целом имеет более чем широкий круг применения и давно признан в ряде сфер, как наиболее перспективное и удобное для решения практических задач средство. Все-таки надо выделять из объектных объекно-ориентированные. Кроме того, реляционные и ОО могут не только конкурировать, но сочетаться - ОРМД. И это для перспекивы "чистых" ООМД может иметь критическое значение. Возможна ситуация, когда на смену уже придут новые подходы, а ООМД так и не займет на рынке существенного места, так как ОРМД будут позволять реализовывать специализированные приложения (плохие для РМД), а типовые (бизнес приложения) - РМД. Вот Вы эту возможность не рассмвтриваете в Ваших прогнозах, и напроснано: с ней многие авторы толстых книг по БД считаются. Вы слишком упростил ситуацию в Ваших оценках, и поэтому доводы имеют существенные изъяны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 10:48 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Al ! 1. При чем здесь конкретное, неудачное приложение ? Какое это имеет отношение к ОСУБД на MUMPS ? Приложения в среде этих ОСУБД не имеют таких проблем в принципе. 2. Про индексы см. стр. 3 в теме "СУБД CACHE". 3. Про OEBS см. стр. 9 в теме "СУБД CACHE". "При внедрении нужно написать кучу отчетов". Блеск ! 4. Итак, с оптимизаторами по стоимости разобрались. Работают они везде примерно одинаково. Ясно какая статистика поддерживается автоматически, а какая собирается автоматически. Очевидно, что - количество экземпляров объектов; - количество экземпляров других объектов, связанных с конкретным экземпляром объекта по конкретной связи; - количество экземпляров для каждого значения в индексах именно поддерживаются автоматически при вводе/удалении/обновлении экземпляров. Не сомневаюсь, что в любой "реляционной" СУБД количество записей в таблицах и количество записей для каждого значения в индексах поддерживаются автоматически при вводе/удалении/обновлении записей. Не сомневаюсь, что в любой "реляционной" СУБД количества записей в индексе по полю "Фамилия" слева и справа от значения "Сидоров" не поддерживаются автоматически при вводе/удалении/обновлении записей. Так чем же "реляционные" СУБД отличаются в лучшую сторону от дореляционных ОСУБД ? В худшую понятно чем. Объяснил подробно. А в лучшую чем ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 13:37 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидович Далее ASCRUS странно прореагировал на то, что при использовании ОСУБД сводится к минимуму программирование нерегламентированных отчетов. И я понимаю откуда "растут ноги" у такой реакции. Вот, например, цитата из учебника-руководства по внедрению Oracle Applications 11i (приложение класса ERP): "Если программист имеет опыт работы с инструментами Developer 2000 и Developer 6i и хорошо знаком со схемой данных Oracle Applications и языком SQL, то создание пользовательских отчетов для приложений Oracle Applications будет относительно простой задачей. Однако, следует помнить, что конечный пользователь не должен заниматься созданием пользовательских отчетов." Вот как ! Наверное и Выши приложения так "организованы" ? ПОЛЬЗОВАТЕЛЬСКИЕ отчеты должны создавать ПОЛЬЗОВАТЕЛИ. Так и есть, когда приложение работает в ОСУБД. И в тех, очень редких, случаях, когда невозможно получить нужный отчет с помощью объектного генератора отчетов, я стараюсь сделать все возможное, чтобы программисты ничего не программировали. В результате: 1) программисты решают более важные и интересные задачи; 2) пользователи могут создать МНОЖЕСТВО отчетов в данной "области", а не ОДИН, который им был нужен. Вы занимаетесь только теоретическими выкладками для специализированных задач. На практике все выглядит несколько по-другому. А уж говорить о том, о чем имеете в высшей степени смутное представление и заранее враждебное настроение, не стОит. Разумеется, в OEBS есть построитель отчетов. Да не один. Я упоминал discoverer и gldi. Но проблема в том, что для каждого предприятия и каждой страны есть своя уникальная отчетность, которая не вписывается в достаточно жесткие рамки стандартных средств. Эти отчеты все являются очень нетривиальными (можете мне поверить), и ни один пользователь не сможет их построить, а тем более, обеспечить нормальную производительность. Я уже не говорю о том, что бизнес-смысл различных параметров настройки любых (не специализированных) приложений разный, что делает невозможным использование только штатных средств построения отчетов самими пользователями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 14:21 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vadiminfo Все-таки надо выделять из объектных объекно-ориентированные. Кроме того, реляционные и ОО могут не только конкурировать, но сочетаться - ОРМД. И это для перспекивы "чистых" ООМД может иметь критическое значение. Возможна ситуация, когда на смену уже придут новые подходы, а ООМД так и не займет на рынке существенного места, так как ОРМД будут позволять реализовывать специализированные приложения (плохие для РМД), а типовые (бизнес приложения) - РМД. Вот Вы эту возможность не рассмвтриваете в Ваших прогнозах, и напроснано: с ней многие авторы толстых книг по БД считаются. Вы слишком упростил ситуацию в Ваших оценках, и поэтому доводы имеют существенные изъяны. Да в принципе и сегодня никто не мешает работать с наиболее распространенными РСУБД в стиле ООП - точно также, как это происходит и с ООСУБД. В состав многих современных средств разработки активно встраиваются средства O/R связывания (Borland - ECO II, Microsoft - Visul Studio 2005 ... ). Существуют и специализированные инструментарии с более богатыми возможностями (Open Access .NET, Open Access JDO). Все эти средства ориентированы в первую очередь на ускорение и упрощение разработки и в таких, например, сферах как ERP и MSM системы начинают преобладать. А вот дальше и возникает вопрос. Если ваша система разработана на базе принципов ООП и оперирует данными как связанными объектами, а сами данные через O/R отображение размещаются в реляционных таблицах (Oracle, SQL Server ...), то следующий вполне очевидный шаг - это перенос базы данных в ООСУБД. Сам перенос в таком случае вообще не требует усилий разработчика и сводится к замене сервера (программы переписывать нет нужды). В чем же выйгрыш? А в том, что система, спроектированная в стиле ООП, будет значительно производительнее при использовании именно ООСУБ. Но напрактике таких ситуаций пока мало. Обычно приходится иметь дело с унаследованными системами (установленными ранее СУБД), где приложения уже написаны и ориентированы именно на парадигму РСУБД. А в таком случае, когда имеет место смешанная архитектура (объектно-реляционная), переход на ООСУБД может быть и не оправдан (все зависит от конкретной ситуации). И наконец, очередной раз повторяю. Объектные СУБД позволяют делать все то же самое, что позволяют и реляционные системы. Отличия только в производительности тех или иных решений на разных платформах. И SQL, и индексы, и оптимизаторы запросов, и транзакции и все остальное в рамках современных ООСУБД функционируют так же. Что касается перспективы ОРМД, то про нее мне говорить сложнее. Тем не менее мне кажется, что эти системы гораздо более уязвимы, чем РМД и ОМД. И именно потому, что пытаются сидеть на двух (а то и трех) стульях сразу. В свое время они возникли как альтернатива нараставшей войне между объектной и реляционной концепциями. Но сейчас, когда по моему мнению большинство специалистов уже признало право на существование за обеими концепциями (РМД и ОМД), роль ОРМД стоит под вопросом, и в первую очередь из-за того, что для конечного пользователя (разработчика) функционал большинства ООСУБД и РСУБД становится практически идентичным (SQL-интерфейс + ОО-интерфейс). И что получается в итоге? Есть две принципиально разных методики разработки (с опорой на объекты и модели предметной области, и с опорой на данные и ER-инструментарий), каждая из этих методик логически приводит к выбору типа хранилища - объектного или реляционного. А вот какая методика разработки сочетается с ОР-системами мне неизвестно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 14:21 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичНе сомневаюсь, что в любой "реляционной" СУБД количество записей в таблицах и количество записей для каждого значения в индексах поддерживаются автоматически при вводе/удалении/обновлении записей. В индексах - да, в статистиках - нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 15:13 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Да и в индексах вообще говоря нет... потому что там информация такого рода хранится тоже в виде статистик, по крайней мере в MS SQL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 15:19 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo Если ваша система разработана на базе принципов ООП и оперирует данными как связанными объектами, а сами данные через O/R отображение размещаются в реляционных таблицах (Oracle, SQL Server ...), то следующий вполне очевидный шаг - это перенос базы данных в ООСУБД. Сам перенос в таком случае вообще не требует усилий разработчика и сводится к замене сервера (программы переписывать нет нужды). В чем же выйгрыш? А в том, что система, спроектированная в стиле ООП, будет значительно производительнее при использовании именно ООСУБ. Вы все время ссылаетесь на "реляционные таблицы" и часто приводите в пример оракл. А Вы знаете, как именно хранит данные тот же оракл? Таблица может жить в виде "обычного набора записей"; может в виде индекса то есть принципиально иной организации данных, когда в блоках данных (страницах) имеется еще и деревообразующие структуры, указатели; может храниться в кластере - в одном и том же блоке хранятся данные нескольких таблиц (мастер и детали вместе); может храниться в секциях - фактически, в нескольких таблицах. Когда дело доходит до ОР свойств, то в дело вступают еще и адреса объектов. Поскольку есть наследование (версия 9 и выше), проблем с хранением потомков других типов нет. Сами данные в зависимости от типов хранятся в разных представлениях и, возможно, отдельно от основной части строки. А в том же каше все объекты собраны в деревья и данные хранятся в текстовом виде. Кажется, что это все как-то победнее, чем в реляционных базах, а уж в объектно-реляционных... И не очень хочется переходить на непонятно что с надежной системы проверенной временем. Информационная система не сводится к максимально быстрому доступу на одну запись, как тут пропагандируется. Она всегда требует нерегламентированных запросов, с которыми иерархические или сетевые организации данных справляются плохо. Именно этот факт и стал причиной популярности РСУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 15:26 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey RovdoИ SQL, и индексы, и оптимизаторы запросов, и транзакции и все остальное в рамках современных ООСУБД функционируют так же. Ничем не подкреплённое утверждение. То, что оптимизатор в ООСУБД есть мы тут уже с горем пополам выяснили, а вот, как он функционирует, на основе чего принимает решения, насколько он продвинут все апологеты ООСУБД отказываются нам рассказать. Похоже, ни один из них не знает о том, как этот оптимизатор устроен. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 15:54 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Al ! Почему Вы думаете, что я занимаюсь "только теоретическими выкладками" ? Я вот не считаю, что Вы занимаетесь только теоретическим выкладками. Значит эти специалисты ОШИБЛИСЬ !? Кладовщицы, мастера и начальники цехов, все-таки, делают отчеты с помощью discoverer и gldi ? Так прямо и скажите. Какой конкретно мой аргумент говорит о "смутном и заранее враждебном отношении" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 16:56 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Константин Лисянский Alexey RovdoИ SQL, и индексы, и оптимизаторы запросов, и транзакции и все остальное в рамках современных ООСУБД функционируют так же. Ничем не подкреплённое утверждение. То, что оптимизатор в ООСУБД есть мы тут уже с горем пополам выяснили, а вот, как он функционирует, на основе чего принимает решения, насколько он продвинут все апологеты ООСУБД отказываются нам рассказать. Похоже, ни один из них не знает о том, как этот оптимизатор устроен. С уважением, Константин Лисянский http://lissianski.narod.ru Так же с точки зрения пользователя/разработчика. Разумеется, если мы лезем вглубь всех этих технологий, то ничего не остается как дать длинные выдержки из документации (данная документация идет в составе продукта и доступна для скачивания здесь ). Итак Versant Developer Suite 6.0: Concepts Index purpose Indexes allow routines that query, create, and update objects to have quick access to the values of a particular attribute of a class. Query routines can use indexes to filter objects so that only objects of interest within a specified range are fetched from disk. This can improve query performance in many situations. Create and update routines can use indexes to enforce uniqueness constraints on attribute values. Index structure An index is set on a single attribute of a class and affects all instances of the class. It is a list of pairs consisting of key values and associated object identifiers. There are two kinds of index structures: b-tree and hash table. Both types of structures maintain a separate storage area containing attribute values, only their organization is different. The type of structure that you want to use depends upon the types of queries you will be making. Index constraints There are two kinds of index constraints: "normal" and "unique." A "normal" index places no constraints on attribute values. A "unique" index requires that each instance of a class has a value in the indexed attribute that is unique with respect to the values in that attribute in all other instances of the class. If you want to create a unique index, you can use either a b-tree or hash table structure. The only difference is that when you create the index, you specify that you want unique values. General Rules Indexes do not have names. Indexes are maintained automatically. Once created, indexes are maintained automatically, which means that they may somewhat slow the creation, updating, and deletion of instances. ... Attributes can have two indexes. An attribute can have up to two indexes, a b-tree index (normal or unique) and a hash table index (normal or unique). Each database has its own set of indexes. When you migrate an object to a database in which its class is not defined, the class definition, index definition, and index behavior are also migrated. When you migrate an object to a database in which its class is already defined, the migration will fail if the target database does not have the same class definition, index definition, and index behavior as the source database. An index is set on one attribute in one class. When you create an index, that index is created on an attribute of a class and not on an attribute in any other class. In other words, indexes are not inherited. To index subclass attributes, you need to specifically set indexes on each subclass. This is important to remember if you are using multiple inheritance and/or are querying over members of a class and its subclasses. The general caution is that if you use multiple inheritance but treat inheriting classes separately, then you may get anomalies. Indexes should be consistent. Because indexes are set only on one attribute in one class, you should set corresponding indexes on all classes that have an inheritance relationship. For example, in the above, if you set an index on Person, then set the same index on Customer, Employee, Developer, and Intern. Query Costs One of the costs of a query is fetching data pages from disk so that the server process can evaluate objects. Once objects are in memory, applying the predicate happens quickly. If you use no indexes, a query will fetch all data pages for a class and evaluate all objects in a single pass through the data pages. This approach optimizes the disk fetch and is appropriate if you want to return a relatively large proportion of the instances of a class. If you have a large number of objects and want to return, say, a quarter or less of all instances, then an index can improve query performance. The tradeoff is improved query speed versus index overhead, as indexes are automatically updated when objects are added, changed, or dropped. An index might logically be set on attributes related to domains, subclasses, and links for queries that evaluate substructures. Alternately, they may be set on a first-level attribute used frequently as a search condition or on logical object identifiers. A b-tree index is useful for value-range comparisons, and a hash index is useful for direct comparisons of values. A b-tree index will return objects in ascending order; to access objects in descending order, access the returned vstr or array from its end rather than beginning. However, if a query evaluates a class and its subclasses, objects are returned in ascending order in each subclass, which means that the set of all objects are not necessarily in ascending order. If you will only be making equality comparisons, generally a hash table is better; otherwise, use a b-tree index. Following is additional detail on how indexes are used. Indexable Predicate Term The system optimizer will automatically use an index in a query if a predicate term is "indexable." A predicate term is indexable if all of the following are true. • The evaluation attribute has an index on it. • The evaluation attribute is not expressed in terms of a path. • The comparison operator is appropriate to the type of index. The following types of comparison operators can use the following types of indexes. O_EQ Scalar equal to Can use either a hash or b-tree index. If there are both kinds of indexes on the evaluation operator, the hash index will be used. ... Query Evaluation and B-tree Indexes A query can use a b-tree index in an exact match or range predicate. When a b-tree index exists, each object has an entry on a leaf page of the b-tree. These leaf pages are sorted on the b-tree attribute and doubly linked. Exact match predicate By definition, an exact match predicate has the form (attribute == key_value). A query with an exact match predicate will traverse a b-tree index on an attribute starting from the root page down through interior node pages, if any, to a leaf page with an entry for the key value. If the key value cannot be located, then no object satisfies the predicate, and the query is finished. If an entry for the key value is found, then the object is retrieved into server memory from the corresponding data page whose location is stored inside the entry for the key value. If there are other predicate terms, the retrieved object is further evaluated and returned to the application if it satisfies all predicate terms. If the index is a unique index, the query is finished. If the index is not unique, then all objects with the key value are retrieved, evaluated, and returned if they satisfy all predicate terms. Range predicate By definition, a range predicate has the form (attribute >= lower_bound and attribute <= upper_bound). An exact match predicate is a special form of a range predicate where the lower_bound is the same as the upper_bound. Like the exact match case, a query with a range predicate traverses a b-tree index searching for an entry on a leaf page whose key value is greater than or equal to the lower bound. As in the exact match case, as each entry that matches the range predicate is found, its corresponding object is retrieved, further evaluated, and returned if it satisfies all predicate terms. If the last entry of a leaf page is processed and the upper bound has not been reached, the query follows the next pointer of the doubly linked entries to the right-hand neighbor and resumes sequential processing with the first entry. This continues until either the upper boundary, u, is reached, or the last leaf page has been processed. Predicate using a set operator A set predicate has the form: attribute set_operator key_links where attribute has the type: link, array of link, or link vstrs. The operator options for a set_operator are: O_INTERSECT O_NOT_INTERSECT ... If the operators O_INTERSECT, O_SUPERSET, or O_EQUIVALENT_SETS are used, a B-tree index can be created on the attribute. The B-tree index can then be used to drive the predicate evaluation. Instead of scanning the entire class, the targets to be examined can be reduced by searching the B-tree index from key_links, reducing the time and resource costs because the number of links in key_links is generally much smaller than the number of links in the class. When a query traverses a B-tree index, frequently referenced pages, such as the root page and its directly descendent interior node pages, are likely to remain in the buffer cache. As a result, the cost of b-tree overhead for a query includes a couple of node pages down the traversed path, and a list of leaf pages covered by the key values. Query Usage of Indexes Various types of queries use indexes differently. Query with a single predicate term Suppose that your predicate consists of a single predicate term, and that it is indexable. In this case, index pages are brought into memory and read sequentially on its leaf pages. If an index value satisfies the predicate term, then the data page for the corresponding object is fetched. Query with terms concatenated only with AND Suppose you have a predicate such as: ( A and B and C and ... ) where A, B, and C... are "terms," such as color=="Red" or age>=65 . In this case, the query terms will be read from left to right. If none of the terms are indexable, then all objects will be fetched and evaluated in a single pass through the data pages. If there is only one indexable term, then the index pages are brought into memory and read sequentially from its leaf pages. If an index value satisfies the indexable term, then the data page for the corresponding object is fetched, and the object is evaluated further using the rest of the predicate terms. If there are multiple indexable terms, then the terms will be evaluated to determine which one to use. If any of the indexable terms uses the equals operator, then the first term using the equals operator, reading from left to right, is used. If none of the indexable terms use the equals operator, then the first term found, reading from left to right, will be used. (The reasoning for preferring the equals operator is that it will likely produce fewer objects for evaluation.) Once an indexable term is chosen, index pages for that term will be brought into memory and read sequentially. If an index value satisfies the predicate term, then the data page for the corresponding object is fetched, and the object is evaluated further. Knowing that access paths are chosen with left-to-right, equality-preference logic, you can phrase your query to use the indexable term that you want. For example, suppose that you have an indexable term with an equality operator, such as (sex=='M'). To avoid having it used as the access path, you can rewrite this term as a range predicate, such as (sex >= 'M' and sex <= 'M'), and then move it to the right end of your predicate. Query with terms concatenated with OR If your query uses terms concatenated with the OR operator, then what happens is more complex. First your query is converted to disjunctive normal form, which means that mathematical conversions are done so that the query is expressed in a left-to-right format such as: ( A and B and C ) or ( D and E ) or ( F ) ... where A, B, C... are "terms" and groups like (A and B and C) are called "orterms". If you write your query in this form to begin with, its components will be evaluted left-to-right per the following discussion. If your query has to be converted to disjunctive normal form, DeMorgan's rules and the distributive rule of boolean algebras will be applied, but the basic left-to-right ordering of elements in your query is preserved as much as possible. If any orterm lacks an indexable term, then the entire class extent will be walked, one object at a time, evaluating the query on each object (with shortcut optimization when an orterm is true or a term inside an orterm is false). In this case, all objects are traversed, because if all objects need to be evaluated, it is faster to do it in one pass. If each orterm has at least one indexable term, then the entire query is indexable, and an index is used to traverse each orterm in succession. This means that objects in each orterm are returned in ascending order with respect to the index attribute, and that all objects in the result set are not necessarily sorted in a particular order. Within each orterm, there may be multiple indexable terms concatenated with AND. If so, the terms are evaluated to determine which one to use. This evaluation occurs as described above for a query with terms concatenated with AND. In each index traversal of each orterm, data pages for objects whose indexes satisfy the query are fetched for further evaluation. Although the automatic index choices are made in a way that optimizes most queries, you can control the choice by phrasing your query so that your first choice of index appears in the left-most term of each "orterm." If you have a range expressed in two terms, such as x>=42 and x<=54, put these two terms on the left. Knowing these behaviors, you can customize your indexes and queries to your needs. To evaluate the impact of various query strategies, you can monitor disk activity with performance monitoring statistics. For further information on statistics, see the chapter "Statistics Collection." ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 17:12 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Alex.Czech ! Извините, но я Вам не верю. Из того, что Вы говорите, следует, что MS SQL - это не совсем СУБД. Не может этого быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 17:19 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
AI... с которыми иерархические или сетевые организации данных справляются плохо А что значит плохо? Я утверждаю, что современные ООСУБД справляются с ними точно так же, как и реляционные. Правда производительность будет немножко ниже. AIТаблица может жить в виде "обычного набора записей"; может в виде индекса то есть принципиально иной организации данных, когда в блоках данных (страницах) имеется еще и деревообразующие структуры, указатели; может храниться в кластере - в одном и том же блоке хранятся данные нескольких таблиц (мастер и детали вместе); может храниться в секциях - фактически, в нескольких таблицах. Когда дело доходит до ОР свойств, то в дело вступают еще и адреса объектов. Поскольку есть наследование (версия 9 и выше), проблем с хранением потомков других типов нет. Сами данные в зависимости от типов хранятся в разных представлениях и, возможно, отдельно от основной части строки. Действительно современный Oracle содержит средства в чем-то приближающие его к объектным СУБД. Тем не менее эти средства по своим возможностям уступают тому же FastObjects. Причем уступают не в функционале, а в элементарном быстродействии на обработке объектных данных. Положить то эти данные в Oracle так или иначе можно. Не стану зарекаться и говорить, что так будет всегда, возможно когда-нибудь Oracle и станет истинно объектно-реляционной системой, которая позволит разработчику самому выбирать способ размещения его данных в базе (в виде таблиц или в виде объектов с возможностью навигации по связям). Но вот в чем я уерен, так это в том что скрестить ежа с ужем никогда в полной мере не удастся, т.е. все равно разработчику нужно будет четко решить - либо объекты, либо таблицы - и затем уже использовать соответствующий его выбору инструментарий для разработки приложений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 17:25 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Al ! Информационная система не сводится к максимально быстрому доступу на одну запись, как тут пропагандируется. Она всегда требует нерегламентированных запросов, с которыми объектные организации данных справляются хорошо. Именно поэтому и непонятно зачем нужны "Р"СУБД с туманной идентификацией и семантикой данных, и совсем без навигации. Причем чем дальше читаешь высказывания специалистов на sql.ru, тем не понятнее. Если меня попросят (а если еще и заплатят !), я смогу объяснить зачем они нужны. Но почему это не может объяснить ни один их сторонник ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 17:25 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичУважаемый Alex.Czech ! Извините, но я Вам не верю. Из того, что Вы говорите, следует, что MS SQL - это не совсем СУБД. Не может этого быть. Тем не менее это так. При отключенном режиме "auto update statistics" (который на промышленной базе рекомендуется таки отключать) статистики автоматически не пересчитываются. Хотите - верьте, хотите - нет. Возлагается на администратора или на maintenance plan ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 17:36 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
В свою очередь позволю высказать сомнение, что тот же Каше аналогичные системные цифры типа количества записей на уровне иерархии апдейтит при каждой операции записи, больно это накладно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 17:42 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo AIТаблица может жить в виде "обычного набора записей"; может в виде индекса то есть принципиально иной организации данных, когда в блоках данных (страницах) имеется еще и деревообразующие структуры, указатели; может храниться в кластере - в одном и том же блоке хранятся данные нескольких таблиц (мастер и детали вместе); может храниться в секциях - фактически, в нескольких таблицах. Когда дело доходит до ОР свойств, то в дело вступают еще и адреса объектов. Поскольку есть наследование (версия 9 и выше), проблем с хранением потомков других типов нет. Сами данные в зависимости от типов хранятся в разных представлениях и, возможно, отдельно от основной части строки. Действительно современный Oracle содержит средства в чем-то приближающие его к объектным СУБД. Тем не менее эти средства по своим возможностям уступают тому же FastObjects. Причем уступают не в функционале, а в элементарном быстродействии на обработке объектных данных. Положить то эти данные в Oracle так или иначе можно. Не стану зарекаться и говорить, что так будет всегда, возможно когда-нибудь Oracle и станет истинно объектно-реляционной системой, которая позволит разработчику самому выбирать способ размещения его данных в базе (в виде таблиц или в виде объектов с возможностью навигации по связям). Но вот в чем я уерен, так это в том что скрестить ежа с ужем никогда в полной мере не удастся, т.е. все равно разработчику нужно будет четко решить - либо объекты, либо таблицы - и затем уже использовать соответствующий его выбору инструментарий для разработки приложений. Вопрос в том, что работает лучше и надежнее: Надстройки на тот же Оракл, призванные добавить ему "объектности", или системы, изначально созданные объектными? Возьмем, к примеру, танк, приделаем к нему все, чтобы заставить его плавать (со скоростьую узла 2 :) ) и начнем сравнивать с катером, который сразу был сделан для того, чтобы плавать... Как вы считаете, что из этого выйдет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 19:43 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Терпеливый1) Какая именно статистика собирается по объектам? Андрей ЛеонидовичНеобходимая и достаточная статистика. Терпеливый2) Какие именно индексы используются (B-tree, bitmap, и т.д.)? Можно сразу с примерами в каких ООСУБД, какие индексы используются? Андрей ЛеонидовичНужные индексы. Терпеливый3) Как выглядит план выполнения запроса? Андрей ЛеонидовичСимпатично выглядит. Терпеливый4) Какие этапы обработки запроса могут выполняться параллельно? Андрей ЛеонидовичВсе запросы выполняются параллельно. На что Вы здесь после таких ответов рассчитываете? На понимание? На уважение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 20:34 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Alex.Czech ! Спасибо, что поддерживаете серьезный разговор. Зря сомневаетесь. Только Cache здесь не причем. Я говорю про ОСУБД на MUMPS. Именно "апдейтит при каждой операции". И все прекрасно работает, но уже именно тщательной реализации MUMPS в Cache. Итак, чтобы банально посмотреть сколько у нас Сидоровых (и т.п.) нужно делать запрос на языке SQL. В OEBS, как нам тут сообщили, конечные пользователи делают это с помощью discoverer и gldi. А в R/3 на MS SQL с помощью чего ? Вам не кажется, что чем дальше, тем ужаснее ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 21:14 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Да, Терпеливый, я рассчитываю на уважение. Вы читайте, пожалуйста, все ответы, а не только нужные Вам. А вот на понимание я уже давно не рассчитываю. Для этого нужно, все-таки, чтобы мои оппоненты знали предметы сравнения (см. название раздела). Я считаю, что они не знакомы с ОМД и ОСУБД. Они считают, что я не знаком с РМД и "Р"СУБД. Когда я перевел разговор на конкретные аспекты РМД и "Р"СУБД, выяснилось, что "единого мнения" (мякго говоря) по этим, казалось бы, очень формальным "конструкциям", не существует. Выяснилось, что даже РМД не существует, что уж говорить про СУБД. А Вы говорите "понимание". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 21:36 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Alexey Rovdo Я вижу целых три больших недостатка в системе индексирования : 1. Подкласс не наследует индексы родителя 2. Нельзя создавать композитные индексы (но при этом зачем-то можно создавать два индекса на одном атрибуте !) 3. Сортировка ломается при выборке из наскольких классов, нельзя указать порядок сортировки по убыванию. Кроме того, практика индексирования шагнула далеко вперед за это время - разные R-индексы, битмап индексы, выборка нужных значений прямо из индексов без доступа к данным, фрагментация, параллельная обработка фрагментов - что из этого есть в наличии ? Как насчет регулируемой степени оптимизации ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 22:10 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
To Alexey Rovdo Слушайте, я вчитался в порядок использования индексов в AND выражениях - вы ЭТО называете оптимизатором ? Он не то что cost-based, он просто отсутствует как класс. "Будет выбираться первое условие на равенство, а если таких нет - то первое условие слева" - это, блин, новое слово в оптимизации запросов ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 22:23 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичВы читайте, пожалуйста, все ответы, а не только нужные Вам. После столь пренебрежительного отношения к собеседнику на уважение Вам рассчитывать не придется. Андрей ЛеонидовичКогда я перевел разговор на конкретные аспекты РМД и "Р"СУБД, выяснилось, что "единого мнения" (мякго говоря) по этим, казалось бы, очень формальным "конструкциям", не существует. "Единого мнения" в терминогии информационных технологий никогда не было. Даже однозначного определения СУБД не существует. Сколько именитых авторов, столько и определений и все чем-то, да отличаются. К томуже из Ваших постов следует, что Ваши познания в области "существующих" и "несуществующих" СУБД весьма ограничены и дальше модели данных не распространяются. Поэтому и понимания здесь Вы не находите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 22:58 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Извините, Терпеливый ! Не думал, что просьба читать все ответы - это неуважение к собеседнику. Еще раз, извините. Итак, я про КОНКРЕТНЫЕ АСПЕКТЫ РМД и "Р"СУБД, а мне про "терминологию информационных технологий". Красиво ! Из какого моего "поста" следует ограниченность моих познаний в области "существующих" и "несуществующих" СУБД ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 23:25 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичУважаемый Alex.Czech ! Спасибо, что поддерживаете серьезный разговор. Зря сомневаетесь. Только Cache здесь не причем. Я говорю про ОСУБД на MUMPS. Именно "апдейтит при каждой операции". И все прекрасно работает, но уже именно тщательной реализации MUMPS в Cache. Итак, чтобы банально посмотреть сколько у нас Сидоровых (и т.п.) нужно делать запрос на языке SQL. В OEBS, как нам тут сообщили, конечные пользователи делают это с помощью discoverer и gldi. А в R/3 на MS SQL с помощью чего ? Вам не кажется, что чем дальше, тем ужаснее ? В принципе, наверное, можно лучше. В принципе, вы утверждаете что вы (или авторы MUMPS, или другие разработчики и пользователи ООСУБД) сделали лучше, и теперь каждый начальник цеха, доярка или учитель труда могут в любой момент времени абсолютно самостоятельно узнать сколько у нас Сидоровых или почем фунт лиха в разрезе по кварталам с себестоимостью рассчитанной по методу среднего. Я всей душой готов вам поверить, но увы - вы не предоставляете мне такого шанса. Объясните хотя бы принципиально, как начальник цеха и доярка этого добиваются... вы ж этого не сделали, хотя вас уже не раз и не два спрашивали ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 23:40 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Alex.Czech ! Ну мы же буквально на этой странице нормально с Вами общались. Что случилось-то, вдруг ? Опять корпоративная солидарность ? Количество экземпляров для значений индексов обновляется автоматически. Поэтому пользователь ПРОСТО ВИДИТ количество Сидоровых (и т.п. данные) в объектном навигаторе. Что объяснить принципиально ??? Итак, чтобы банально посмотреть сколько у нас Сидоровых (и т.п.) в "Р"СУБД нужно делать запрос на языке SQL. В OEBS, как нам тут сообщили, конечные пользователи делают это с помощью discoverer и gldi. А в R/3 на MS SQL с помощью чего ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 00:02 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vybegalloTo Alexey Rovdo Слушайте, я вчитался в порядок использования индексов в AND выражениях - вы ЭТО называете оптимизатором ? Он не то что cost-based, он просто отсутствует как класс. "Будет выбираться первое условие на равенство, а если таких нет - то первое условие слева" - это, блин, новое слово в оптимизации запросов ! Согласен на 100%. Интеллектом этот оптимайзер не блещет. Действительно, современные реляционные СУБД имеют гораздо более сильный арсенал средств индексирования и оптимизации запросов. Хотелось бы сделать несколько комментариев и задать вопросы: It is a list of pairs consisting of key values and associated object identifiers Т.е. индекс представляет собой не указатель на физическое местоположение данных класса на диске, и его идентификатор? А как, интересно, по идентификатору определяется физическое местоположение экземпляров класса? There are two kinds of index structures: b-tree and hash table Интересно, как устроен этот hash table. Нельзя ли привести краткое описание? Я представляю себе очень неплохо, что можно делать с помощью хэширования, и какие особенности имеются (поскольку СУБД Teradata, которой я занимаюсь, использует хэширование как фундаментальный принцип). Indexes do not have names Это не очень удобно, на мой взгляд. По крайней мере в РСУБД имя индекса может понадобиться, если индекс нужно удалить, или по нему нужно собрать статистику. Или посмотреть план запроса (если, конечно, план запроса показывает имя индекса, который используется при выборке). An index is set on a single attribute of a class Это явный недостаток. Композитные индексы иметь полезно. Ну, или хотя бы иметь возможность динамического битмапа индексов, имеющих по отдельности низкую селективность, но высокую совокупную. Because indexes are set only on one attribute in one class, you should set corresponding indexes on all classes that have an inheritance relationship. For example, in the above, if you set an index on Person, then set the same index on Customer, Employee, Developer, and Intern. Отсутствие гибкости. Неплохо было бы иметьвозможность проиндексировать атрибут только того класса, к которому наиболее часто выполняются запросы. Например, если запросы по индексированному атрибуту делаются только к Person и Employee, зачем его индексировать для всех остальных классов? Suppose that your predicate consists of a single predicate term, and that it is indexable. In this case, index pages are brought into memory and read sequentially on its leaf pages. If an index value satisfies the predicate term, then the data page for the corresponding object is fetched. Query with terms concatenated only with AND Suppose you have a predicate such as: ( A and B and C and ... ) where A, B, and C... are "terms," such as color=="Red" or age>=65 . In this case, the query terms will be read from left to right. If none of the terms are indexable, then all objects will be fetched and evaluated in a single pass through the data pages. If there is only one indexable term, then the index pages are brought into memory and read sequentially from its leaf pages. If an index value satisfies the indexable term, then the data page for the corresponding object is fetched, and the object is evaluated further using the rest of the predicate terms. If there are multiple indexable terms, then the terms will be evaluated to determine which one to use. If any of the indexable terms uses the equals operator, then the first term using the equals operator, reading from left to right, is used. If none of the indexable terms use the equals operator, then the first term found, reading from left to right, will be used. (The reasoning for preferring the equals operator is that it will likely produce fewer objects for evaluation.) Once an indexable term is chosen, index pages for that term will be brought into memory and read sequentially. If an index value satisfies the predicate term, then the data page for the corresponding object is fetched, and the object is evaluated further. Knowing that access paths are chosen with left-to-right, equality-preference logic, you can phrase your query to use the indexable term that you want. For example, suppose that you have an indexable term with an equality operator, such as (sex=='M'). To avoid having it used as the access path, you can rewrite this term as a range predicate, such as (sex >= 'M' and sex <= 'M'), and then move it to the right end of your predicate. Здесь мне хочется отметить тот факт, что поведение оптимизатора описывается серией конструкций IF ... THEN ... Мне это очень сильно напоминает rule based оптимизатеор, а вовсе не cost based. Тем более, что ни единого упоминания стоимости запроса в этом фрагменте я не нашёл. К тому же на разработчика перекладывается перефразирование запроса. Оптимизаторы РСУБД это делают самостоятельно. Если используется инструмент, который генерирует запросы (BusinessObjects, Microstrategy, Cognos, Crystal), не факт, что они будут перефразировать условие sex='M' в sex >= 'M' and sex <= 'M'. Это к вопросу о нерегламентированных запросах. Если я не прав по поводу отсутствия стоимостного оптимизатора, есть ли фрагмент доки, описывающей то, как рассчитываеться стоимость запроса? In this case, index pages are brought into memory and read sequentially on its leaf pages А это к вопросу о параллелизме. Почему это индексные страницы читаются последовательно, а не параллельно? To Alexey Rovdo: Спасибо, что потрудились выложить это описание. Было интересно познакомиться немного с внутренним устройством ООСУБД. Здесь они явно уступают реляционным, но ничего, скорее всего, в чём-то другом выигрывают. Не сочтите за труд, приведите, пожалуйста, фрагмент доки, которая описывает принципы параллельной обработки в ООСУБД. Это тоже, на мой вгляд, немаловажный критерий качества любой (не только ОО) СУБД. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 00:46 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Андрей Леонидович >Из какого моего "поста" следует ограниченность моих познаний в области "существующих" и "несуществующих" СУБД ? Я уже приводил многократно. Это вообще перлы из перлов и свидетельствуют они не только об ограниченности познаний в области баз данных, но и об ограниченности вообще. Итак, читаем: Андрей Леонидович> ОБЪЕКТ - все, что противостоит субъекту в его предметно-практической и познавательной деятельности. Понятно? Всем программистам с понедельника в работе руководствоваться этим определением объекта. А чтоб и математики с физиками тоже не скучали, вводится следующее определение: Андрей Леонидович> ПРОСТРАНСТВО и ВРЕМЯ - всеобщие формы существования материи и сознания. Пусть и они теперь ломают голову над тем, что бы это значило. Человек говорит это на полном серьезе в докладе перед профессиональной аудиторией, и выкладывает ссылку на этот доклад в программистском форуме. (http://www.informx.ru/doclad.zip) А вот перлик попроще, зато совсем свежий: Андрей Леонидович>чтобы отличать ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ модели данных (иерархическую...) от ЗАПИСЕ-ОРИЕНТИРОВАННОЙ реляционной модели данных Это по какой классификации иерархическиая модель попала в объектно-ориентированные, по классификации Андрея Леонидовича? Так привели бы ее, а мы бы обсудили. Ага, вот ответ нашелся: >В последствии из-за утраты знаний при смене поколений некоторые авторы стали допускать грубейшую ошибку, относя иерархическую и сетевую модели данных к записе-ориентированным. Теперь все встало на свои места. Оказывается знания были утеряны. И только Андрею Леонидовичу, хранителю сокровенных знаний, истина осталась открытой, а мы отринули ее и бредем впотьмах по тропе к пропасти. Много лет уже бредем. Поэтому когда Андрей Леонидович тут прилюдно изрекает глупости, нам, слепцам, нужно помнить, что это может и не глупости вовсе, а утерянные знания, другим недоступные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 02:44 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичУважаемый Alex.Czech ! Ну мы же буквально на этой странице нормально с Вами общались. Что случилось-то, вдруг ? Опять корпоративная солидарность ? Количество экземпляров для значений индексов обновляется автоматически. Поэтому пользователь ПРОСТО ВИДИТ количество Сидоровых (и т.п. данные) в объектном навигаторе. Что объяснить принципиально ??? Итак, чтобы банально посмотреть сколько у нас Сидоровых (и т.п.) в "Р"СУБД нужно делать запрос на языке SQL. В OEBS, как нам тут сообщили, конечные пользователи делают это с помощью discoverer и gldi. А в R/3 на MS SQL с помощью чего ? Да все нормально, никакой корпоративной солидарности, просто чтобы не заснуть приходится себя развлекать вычурностью стиля в такое время :) С R/3 признаться не знаком... в MS SQL без R/3 эти данные несомненно надо получать запросом на SQL, если есть индекс по фамилии - то запрос этот пройдет достаточно быстро и безболезненно для окружающих. Если нету... ну если в иерархической СУБД иерархия по этому полю не выстроена, там тоже все будет нехорошо я так подозреваю. Меня интересует другое - если скажем вам нужно в объектном навигаторе показать не сколько Сидоровых, а сколько Иванов, вы что делаете в MUMPS ? Еще одну иерархию строите ? Все руками перебираете ? И это все делают начальники цехов или программисты все-таки ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 09:42 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Правильнее будет наверное сказать, что я не знаком с термином R/3... я почему-то сразу подумал о SAP R/3, возможно вы какой-то другой смысл в это вкладывали ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 09:58 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Sp1Der Вопрос в том, что работает лучше и надежнее: Надстройки на тот же Оракл, призванные добавить ему "объектности", или системы, изначально созданные объектными? Возьмем, к примеру, танк, приделаем к нему все, чтобы заставить его плавать (со скоростьую узла 2 :) ) и начнем сравнивать с катером, который сразу был сделан для того, чтобы плавать... Как вы считаете, что из этого выйдет? Ваш пример не очень удачный: давайте теперь к катеру приделаем пушку (возможность выполнения запросов, требующих движения не только по ссылкам), гусеницы (SQL-интерфейс) и защитим броней (добавим контроль согласованности данных и защиты от сбоев). После этого сравним не только скорость плавания по течению, но и непотопляемость после попадания вражеского снаряда, дальность стрельбы самого катера, скорость плавания против или поперек течения и т.д. Давайте сделаем так, как я уже несколько раз предлагал: расскажите, как хранятся данные в "объектных" СУБД, как хранится код, каким образом обеспечивается изолированность транзакций, каким образом строятся индексы, как работают оптимизаторы и выполняются запросы. Потом сравним с тем же ораклом. Его я знаю достаточно хорошо и могу привести соответствующие дампы данных, планов выполнения запросов и т.д. Пока я не увидел ничего нового в высказываниях ООСУБДшников, например про индексы. Дерево с ключами и указателями, уникальное или неуникальное - стандартное решение во всех СУБД, объектные они или нет. После этого сразу будет видно, за счет чего будет обеспечиваться большая/меньшая производительность СУБД, в каких условиях, при каких нагрузках. Какие алгоритмы более эффективны, какие менее, где возникают дополнительные расходы на обеспечение отказоустойчивости или их просто нет. Причем рассматривать надо именно СУБД. Мне тут уже сказали, что я приводил в пример неудачную базу данных. Расскажите, как работают удачные. Как пример. Говорят, что в каше есть транзакционные битовые индексы. Расскажите, как они устроены, почему не вызывают таких блокировок, как оракловские. Почти наверняка найдутся и недостатки выбранной схемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 10:38 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Константин Лисянский vybegallo [quot ]It is a list of pairs consisting of key values and associated object identifiers Т.е. индекс представляет собой не указатель на физическое местоположение данных класса на диске, и его идентификатор? А как, интересно, по идентификатору определяется физическое местоположение экземпляров класса? Object location table - содержит соответствия идентификаторов и физических адресов. Все это тесно связано с работой механизма кэширования и целиком я здесь его писание не привожу. Константин Лисянский There are two kinds of index structures: b-tree and hash table Интересно, как устроен этот hash table. Нельзя ли привести краткое описание? Я представляю себе очень неплохо, что можно делать с помощью хэширования, и какие особенности имеются (поскольку СУБД Teradata, которой я занимаюсь, использует хэширование как фундаментальный принцип). A b-tree index is useful for value-range comparisons, and a hash index is useful for direct comparisons of values. A b-tree index will return objects in ascending order; to access objects in descending order, access the returned vstr or array from its end rather than beginning. However, if a query evaluates a class and its subclasses, objects are returned in ascending order in each subclass, which means that the set of all objects are not necessarily in ascending order. If you will only be making equality comparisons, generally a hash table is better; otherwise, use a b-tree index. (Подробнее пока не нашел) Константин Лисянский Indexes do not have names Это не очень удобно, на мой взгляд. По крайней мере в РСУБД имя индекса может понадобиться, если индекс нужно удалить, или по нему нужно собрать статистику. Или посмотреть план запроса (если, конечно, план запроса показывает имя индекса, который используется при выборке). Поскольку индексу всегда соответствует только один атрибут (обычный или виртуальный см. ниже), то нет смысла в назначении индексу специального имени - его имя фактически соответствует имени этого атрибута. Атрибуту может соответствовать два индекса, но только разного типа (b-tree и hash). Константин Лисянский An index is set on a single attribute of a class Это явный недостаток. Композитные индексы иметь полезно. Ну, или хотя бы иметь возможность динамического битмапа индексов, имеющих по отдельности низкую селективность, но высокую совокупную. Virtual Attribute Virtual Attribute is a derived attribute, built on one or more normal attributes of a class. As the Virtual Attributes are computed at runtime, they are not part of the schema of a class, but can be indexed. The indexes on Virtual Attributes are maintained during normal operations like insert, delete and update and used during query processing. This release will support only b-tree index on Virtual Attribute of a Class. Т.е. можно создать композитный виртуальный атрибут, а уже ему назначить индекс. Константин Лисянский Because indexes are set only on one attribute in one class, you should set corresponding indexes on all classes that have an inheritance relationship. For example, in the above, if you set an index on Person, then set the same index on Customer, Employee, Developer, and Intern. Отсутствие гибкости. Неплохо было бы иметьвозможность проиндексировать атрибут только того класса, к которому наиболее часто выполняются запросы. Например, если запросы по индексированному атрибуту делаются только к Person и Employee, зачем его индексировать для всех остальных классов? Разумеется когда речь идет только о выборке данных, то так поступить можно. На самом деле в руководстве все это написано именно с целью показать, что индексы не наследуются. Т.е. определив индекс в классе Person вы не можете его использовать при запросах к классу Customer - вам нужно определить корреспондирующий индес и в этом классе. Кроме этого могут возникнуть проблемы, когда вы определяете уникальный индекс в родительском классе и не определяете такого же индекса в дочерних классах (проблемы при создании объектов дочерних классов с неуникальными значениями соответствующего поля). Константин Лисянский Suppose that your predicate consists of a single predicate term, ... as (sex >= 'M' and sex <= 'M'), and then move it to the right end of your predicate. Здесь мне хочется отметить тот факт, что поведение оптимизатора описывается серией конструкций IF ... THEN ... Мне это очень сильно напоминает rule based оптимизатеор, а вовсе не cost based. Тем более, что ни единого упоминания стоимости запроса в этом фрагменте я не нашёл. К тому же на разработчика перекладывается перефразирование запроса. Оптимизаторы РСУБД это делают самостоятельно. Если используется инструмент, который генерирует запросы (BusinessObjects, Microstrategy, Cognos, Crystal), не факт, что они будут перефразировать условие sex='M' в sex >= 'M' and sex <= 'M'. Это к вопросу о нерегламентированных запросах. Если я не прав по поводу отсутствия стоимостного оптимизатора, есть ли фрагмент доки, описывающей то, как рассчитываеться стоимость запроса? Стоимостный оптимизатор в VDS отсутствует - действительно эта работа перекладывается на программиста. Развитый механизм сбора статистики для анализа поведения системы присутствует, так что тонкая оптимизация возможна, но требует некоторой ручной работы. В этом смысле VDS отстает от Oracle. Константин Лисянский In this case, index pages are brought into memory and read sequentially on its leaf pages А это к вопросу о параллелизме. Почему это индексные страницы читаются последовательно, а не параллельно? Не сочтите за труд, приведите, пожалуйста, фрагмент доки, которая описывает принципы параллельной обработки в ООСУБД. Это тоже, на мой вгляд, немаловажный критерий качества любой (не только ОО) СУБД. The back-end server is completely under Versant’s realm of control, and is inherently multi-threaded, with a separate thread being used to manage each database connection. The primary motivation for making the server multi-threaded is to support highly concurrent accesses to the database with the lightest possible process footprint on the server. Of far more importance than Versant’s multi-threaded server, however, is the granularity of critical sections of database code. The simplest and most common approach is what is termed single-latch, which implies that all critical sections of code have been grouped together within a single semaphore-protected unit of execution. While it is the easiest to implement, a shortcoming of this approach is that once the critical section of code has been entered, all other processes or threads that want access to that section must wait until that section has been exited. Versant, by comparison, has implemented an approach that divides the server application space into a fine-grained collection of units of atomic execution that allows many threads to be executing simultaneously and significantly reduces the length of time that a particular process or thread might be forced to wait when contention for a particular resource or section of code does occur. Подробнее С уважением, Алексей Ровдо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 14:20 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
AI Пока я не увидел ничего нового в высказываниях ООСУБДшников, например про индексы. Дерево с ключами и указателями, уникальное или неуникальное - стандартное решение во всех СУБД, объектные они или нет. Типовые объектные СУБД не содержат каких-то уникальных решений в части индексации (про Cache мне ничего не известно). Наоборот - все, что в них есть, заимствовано из реляционных систем. И это так именно потому, что механизмы индексации в ООСУБД носят второстепенный характер и введены для увеличения быстродействия нетипичных для них запросов "по значению". Стандартным же является механизм навигации, которого в РСУБД вообще нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 14:34 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo AI Пока я не увидел ничего нового в высказываниях ООСУБДшников, например про индексы. Дерево с ключами и указателями, уникальное или неуникальное - стандартное решение во всех СУБД, объектные они или нет. Типовые объектные СУБД не содержат каких-то уникальных решений в части индексации (про Cache мне ничего не известно). Наоборот - все, что в них есть, заимствовано из реляционных систем. И это так именно потому, что механизмы индексации в ООСУБД носят второстепенный характер и введены для увеличения быстродействия нетипичных для них запросов "по значению". Стандартным же является механизм навигации, которого в РСУБД вообще нет. Один в один похоже на описание какого-нибудь Парадокса или xBase, если честно. То есть ООСУБД можно отнести к этому замечательному классу систем, вознесенных на новый уровень абстракции с применением модных слов "полиморфизьм", "инкапсуляцыя" и "наследование" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 14:38 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alex.Czech[quot Alexey Rovdo] Один в один похоже на описание какого-нибудь Парадокса или xBase, если честно. То есть ООСУБД можно отнести к этому замечательному классу систем, вознесенных на новый уровень абстракции с применением модных слов "полиморфизьм", "инкапсуляцыя" и "наследование" ? Ну если "полиморфизьм", "инкапсуляцыя" и "наследование" воспринимается вами только лишь как модные слова, то комментировать что-то сложно. Надо понимать, что за этой "модностью" стоят десятки лет исследований, дискуссий, разработок, а также люди, имена которых говорят сами за себя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 15:06 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Гы - немного в оффтоп: я вот по себе лично знаю, что если на какой то вопрос точно ответа не знаю, то лезу в RTFM, читаю, понимаю, потом оттуда кусок прямо на инглишь и выкладываю (лень двигатель прогресса). Если же я точно и практически знаю ответ на вопрос, то пишу своими словами вкратце, так как опять же согласно лени открывать и искать чего то в RTFM не хочется. Поэтому чисто по дружески рекомендую Alexey Rovdo если он не полностью обладает познаниями во всех этих хитрых тонкостях ООСУБД лучше не связываться со спецами РСУБД, уж они то точно на те вопросы, которые Вам задают сейчас в RTFM не смотрят - а то попадете в просак и честно говоря этого никому здесь не хочется, так как мы искренне и с интересом слушаем Ваши мысли и готовы дискутировать :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 15:20 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo Alex.Czech[quot Alexey Rovdo] Один в один похоже на описание какого-нибудь Парадокса или xBase, если честно. То есть ООСУБД можно отнести к этому замечательному классу систем, вознесенных на новый уровень абстракции с применением модных слов "полиморфизьм", "инкапсуляцыя" и "наследование" ? Ну если "полиморфизьм", "инкапсуляцыя" и "наследование" воспринимается вами только лишь как модные слова, то комментировать что-то сложно. Надо понимать, что за этой "модностью" стоят десятки лет исследований, дискуссий, разработок, а также люди, имена которых говорят сами за себя. Честно говоря, для меня переход от навигации к SQL в смысле продвижения вперед в работе с СУБД гораздо важнее чем переход от процедурного к объектно-ориентированному программированию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 15:21 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Alex.Czech ! Да, конечно, именно о SAP R/3 я и говорил. Но это уже не актуально, так как по OEBS ответа все равно не последовало. Видимо и в том, и в другом случае сами пользователи данных не получат. Нужно звать "специалиста, зарабатывающего на SQL"... Извините, там у Вас ошибочка в тексте. Я понял так: "не сколько Сидоровых, а сколько Ивановых". И сколько наименований товара на складе, и, наоборот, на скольких складах есть этот товар, и т.д. и.т.п. Ну причем же здесь программисты, если это автоматически поддерживается. Все ЭТО видно в той части схемы данных (в объектном навигаторе), к которой ЭТО относится. И ведь это всего лишь "ПОБОЧНЫЙ ЭФФЕКТ" ! Мы же говорили о статистиках для стоимостного оптимизатора запросов. И о том какие из этих "статистик" поддерживаются автоматически при вводе/удалении/обновлении экземпляров, а какие собираются автоматически. И выяснилось, что, например, MS SQL не имеет данных о количестве записей для значения индекса. Честное слово, до сих пор не могу поверить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:56 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo Alex.Czech[quot Alexey Rovdo] Один в один похоже на описание какого-нибудь Парадокса или xBase, если честно. То есть ООСУБД можно отнести к этому замечательному классу систем, вознесенных на новый уровень абстракции с применением модных слов "полиморфизьм", "инкапсуляцыя" и "наследование" ? Ну если "полиморфизьм", "инкапсуляцыя" и "наследование" воспринимается вами только лишь как модные слова, то комментировать что-то сложно. Надо понимать, что за этой "модностью" стоят десятки лет исследований, дискуссий, разработок, а также люди, имена которых говорят сами за себя. Именитые люди, о которых Вы говорите, служат лишь прикрытием для того, чтобы откатиться в использовании СУБД на 20-30 лет назад. Объект в программистском смысле (ООП) - это запись с методами и дополнительной совместимостью разных типов. Но все авторы ООП и, особенно, их последователи стали считать, что программистский объект действительно является самым правильным методом отбражения реальных объектов. При этом полностью игнорируется тот факт, что все СУБД работают именно с записями, как бы их не называли (объект с полями или атрибутами). В РСУБД эти записи были жестко отделены от ссылочной организации доступа к данным, к которой так привыкли "классические" программисты. В программировании без указателей (деревьев, списков) просто не удастся получить доступ к динамически порождаемому или уничтожаемому объекту. А в БД они хранятся в виде простой последовательности байтов (плюс служебная информация, словари, защита данных и т.п.). И, зная структуру записи, можно легко найти нужные записи по некоторым критериям. ПРичем все равно, одну или много. Простой перебор иногда работает быстро, но, чаще всего, работает медленно. Поэтому понадобились вспомогательные структуры для ускорения доступа к данным типа индексов, кластеров индексных или хэш и т.д. Здесь все предельно ясно. Не хватало только совместимости типов между наследником и родителем, которая нужна для расширения системы. Она появилась в ОРСУБД. Но ООПники никак не могут забыть про типичные алгоритмы работы с динамическими объектами в памяти. Почему нужна "простота навигации"? Да потому, что привыкли так программировать доступ к объектам в памяти! Доступ по ключу будет работать быстро, а вот с полным перебором или диапазоном по неключевым данным все совсем не так. Приходится работать точно так же, как и в РСУБД, то есть строить дополнительные индексы. И оптимизаторы поэтому недоразвитые. Не надо было работать с большими объемами данных. Забывается также и то, что код не хранится вместе с данными. Иначе размеры записей были бы слишком большие. Есть просто таблицы методов и коды самих методов. По этим таблицам в зависимости от типа объекта вызывается нужный код. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:57 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2Андрей Леонидович Я понимаю, что для каких-то из разрезов эта информация постоянно хранится в виде статистической информации... но не для всех же ! Если в таблице (глобали, объекте) 50 полей-атрибутов, то не может же информация такого рода храниться по всем 50 полям и быть постоянно up-to-date, это же будут глобальные тормоза ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:59 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый с127 ! Каким образом ограниченность моих познаний в области "существующих" и "несуществующих" СУБД, и моя ограниченность вообще следует из: 1) определения (при чем здесь "программисты с понедельника" ???): ОБЪЕКТ - все, что противостоит субъекту в его предметно-практической и познавательной деятельности. 2) определения (почему математики и физики должны ломать голову ???): ПРОСТРАНСТВО и ВРЕМЯ - всеобщие формы существования материи и сознания. 3) выкладывания кем-то (а вовсе не мной) ссылки на мой доклад на семинаре в 1999 году "в программистком форуме"; против чего я, конечно, не возражаю, так как доклад очень хорош; 4) факта утраты знаний ????? Вы можете хоть что-то сказать по-существу ? Хотя бы по одному из обсуждаемых здесь вопросов ? Здорово Вас, все-таки, задели мои аргументы по РМД и "Р"СУБД. Вместо того, чтобы так расстраиваться, лучше займитесь изучением баз данных. И я всегда готов Вам помочь, и ответить на любой Ваш вопрос в этой области. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:09 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Alex.Czech ! И это мы уже обсудили. Просто напоминаю: - количество экземпляров объектов; - количество экземпляров других объектов, связанных с конкретным экземпляром объекта по конкретной связи; - количество экземпляров для каждого значения в индексах поддерживаются автоматически при вводе/удалении/обновлении экземпляров. По неиндексированным характеристикам ТАКИХ данных нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:15 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo The back-end server is completely under Versant’s realm of control, and is inherently multi-threaded, with a separate thread being used to manage each database connection. The primary motivation for making the server multi-threaded is to support highly concurrent accesses to the database with the lightest possible process footprint on the server. Of far more importance than Versant’s multi-threaded server, however, is the granularity of critical sections of database code. The simplest and most common approach is what is termed single-latch, which implies that all critical sections of code have been grouped together within a single semaphore-protected unit of execution. While it is the easiest to implement, a shortcoming of this approach is that once the critical section of code has been entered, all other processes or threads that want access to that section must wait until that section has been exited. Versant, by comparison, has implemented an approach that divides the server application space into a fine-grained collection of units of atomic execution that allows many threads to be executing simultaneously and significantly reduces the length of time that a particular process or thread might be forced to wait when contention for a particular resource or section of code does occur. Подробнее С уважением, Алексей Ровдо. Малтитредность реализована в Информиксе начиная с версии 6 (1993 г.) (а так же в, насколько я знаю, Сайбейсе и MS SQL Server-е). За 11 лет эксплуатации на паре десятков юниксов, нескольких сотнях платформ и в самых требовательных окружениях она всяко-разно вылизана и оптимизирована получше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:19 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Кстати, еще вопрос - а асинхронный ввод-вывод ваша база поддерживает ? Есть ли у вас отдельный процесс, занимающийся вводом-выводом, или каждая нить сама выполняет чтение-запись, блокируя всех остальных ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:23 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичУважаемый Alex.Czech ! И это мы уже обсудили. Просто напоминаю: - количество экземпляров объектов; - количество экземпляров других объектов, связанных с конкретным экземпляром объекта по конкретной связи; - количество экземпляров для каждого значения в индексах поддерживаются автоматически при вводе/удалении/обновлении экземпляров. По неиндексированным характеристикам ТАКИХ данных нет. Прошу прощения, я не все тут читал... а в MS SQL такие данные по неиндексированным характеристикам есть. Точнее, могут быть, если завести статистику. И это часто делается, причем именно для тех данных, для которых индекс заводить смысла нет - скажем, чтобы SQL Server, как и я, человек, всегда знал, что процент выполненных проводок в таблице оных проводок на реальной работающей системе обычно равен 90-100% и таким образом условие WHERE Accepted=1 ни в коем случае не следует воспринимать как такое, с которого надо победоносно начинать выполнять запрос ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:27 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vybegalloКстати, еще вопрос - а асинхронный ввод-вывод ваша база поддерживает ? Есть ли у вас отдельный процесс, занимающийся вводом-выводом, или каждая нить сама выполняет чтение-запись, блокируя всех остальных ? Если я адекватно понял ваши вопросы то в отношении VDS ответ всюду будет утвердительным. Но можете пояснить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 18:09 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vybegallo Малтитредность реализована в Информиксе начиная с версии 6 (1993 г.) (а так же в, насколько я знаю, Сайбейсе и MS SQL Server-е). За 11 лет эксплуатации на паре десятков юниксов, нескольких сотнях платформ и в самых требовательных окружениях она всяко-разно вылизана и оптимизирована получше. Ну если говорить о VDS, то эта система изначально проектировалась именно малтисредовой и именно для эксплуатации на множестве платформ (т.е. иного даже не предполагалось). Само проектирование и выпуск первых коммерческих версий велись в 1987-1991гг. 1987г. - основание Versant Corporation 1992г. - выход первых крупных продуктов с использование Versant (телефонные станции, медицинское оборудование). 1994г. - VDS 4.0 2003г. - VDS 6.0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 18:20 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo vybegallo Малтитредность реализована в Информиксе начиная с версии 6 (1993 г.) (а так же в, насколько я знаю, Сайбейсе и MS SQL Server-е). За 11 лет эксплуатации на паре десятков юниксов, нескольких сотнях платформ и в самых требовательных окружениях она всяко-разно вылизана и оптимизирована получше. Ну если говорить о VDS, то эта система изначально проектировалась именно малтисредовой и именно для эксплуатации на множестве платформ (т.е. иного даже не предполагалось). Само проектирование и выпуск первых коммерческих версий велись в 1987-1991гг. 1987г. - основание Versant Corporation 1992г. - выход первых крупных продуктов с использование Versant (телефонные станции, медицинское оборудование). 1994г. - VDS 4.0 2003г. - VDS 6.0 Пардон, но вы плохо знаете свой продукт : "Beginning with Release 5, database connections start threads rather than processes." (VERSANT Database Fundamentals Manual ) И я что-то не вижу в параметрах насторойки сервера числа запускаемых процессов - похоже, создается всего 2 процесса на одну базу данных, так что на многопроцессорных машинах большая часть ресурсов будет простаивать. Это так ? Кстати, Informix, к примеру, рекомендует иметь buffer flush threads не меньше числа дисков - а у вас он всего один на БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 19:30 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
А что, пардон, Информикс под Виндами (речь именно о Виндах идет как я понимаю) на каждую клиентскую коннекцию создает новый процесс ? А у него ничего не трескается когда коннекций становится скажем 500 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 22:26 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo The back-end server is completely under Versant’s realm of control, and is inherently multi-threaded, with a separate thread being used to manage each database connection. The primary motivation for making the server multi-threaded is to support highly concurrent accesses to the database with the lightest possible process footprint on the server. Отсюда пока следует, что на один коннект запускается тред. А как насчёт параллелизма внутри запроса? Пока видно, что параллелизм существует только между отдельными конектами. Умеет ли VDS обрабатывать данные параллельно в одном запросе? И если да, то как он это делает? С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 22:34 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Alex.Czech ! Я считаю, что даже для "Р"СУБД эта идея - архитектурное излишество. А для ОСУБД, в которой принципиально нет понятия "настройка приложения", и в которой индексы являются полноценной частью данных (в отличие от "реляционных" систем) - это абсолютно не нужно. Если уж Вы привели этот пример с проводками... В Вашей таблице могло бы быть поле, в котором хранится значение как раз для не выполненных проводок, с типом индекса "пустые не хранить". Это проще, надежнее и не менее "экономично", чем поддержка статистики без индекса. Ведь Вам, насколько я понял, нужно быстро получать не выполненные проводки, чтобы их выполнить ? Извиняюсь, конечно, что "полез" в приложение, не зная его. Да и MS SQL я перестал тщательно изучать после 6.5, когда стало ясно, что с "реляционностью" уже больше ничего не изменится. Может там до сих пор нет типа индекса "пустые не хранить" ? В Oracle, по крайней мере до 9-ки, не было даже банального индексирования пустых значений... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 22:38 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alex.CzechА что, пардон, Информикс под Виндами (речь именно о Виндах идет как я понимаю) на каждую клиентскую коннекцию создает новый процесс ? А у него ничего не трескается когда коннекций становится скажем 500 ? Алекс, как я уже утверждал в этой дискуссии, Informix написан в multithread-ном стиле начиная с версии 6. Это, как я посмотрел, случилось аж в 1990 году. Так что ни о каких выделенных процессах для клиентского соединения ни под Юниксом, ни тем более под Виндами (которые сами по себе вместо процессов создают нити) речь не идет. Кстати, можете спросить ораклистов и дибитушников - как у них, ничего не трескается при росте числа коннектов - поскольку они написаны именно в такой архитектуре. Я спрашивал - мне сказали "нормально, константин !" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 22:49 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Тогда я не понимаю такого повышенного внимания к фразе "Начиная с версии 5 для каждой клиентской коннекции вместо процесса стал создаваться thread". Переделка правильная, и фраза правильная :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 22:58 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичУважаемый Alex.Czech ! Я считаю, что даже для "Р"СУБД эта идея - архитектурное излишество. А для ОСУБД, в которой принципиально нет понятия "настройка приложения", и в которой индексы являются полноценной частью данных (в отличие от "реляционных" систем) - это абсолютно не нужно. Если уж Вы привели этот пример с проводками... В Вашей таблице могло бы быть поле, в котором хранится значение как раз для не выполненных проводок, с типом индекса "пустые не хранить". Это проще, надежнее и не менее "экономично", чем поддержка статистики без индекса. Ведь Вам, насколько я понял, нужно быстро получать не выполненные проводки, чтобы их выполнить ? Извиняюсь, конечно, что "полез" в приложение, не зная его. Да и MS SQL я перестал тщательно изучать после 6.5, когда стало ясно, что с "реляционностью" уже больше ничего не изменится. Может там до сих пор нет типа индекса "пустые не хранить" ? В Oracle, по крайней мере до 9-ки, не было даже банального индексирования пустых значений... Нет, вы не совсем правильно поняли... мне надо получить отчет типа оборотной ведомости за неделю. И естественно в этом отчете должны фигурировать только "выполненные" проводки, невыполненные в него не включаются. Разумный человек, считая это самостоятельно по бухгалтерской книге, сначала отберет проводки за неделю, а потом уже начнет суммировать, по ходу дела отбрасывая "неисполненные" проводки, если будет знать, что их там одна на 1000. И SQL Server сделает ровно то же самое. Если будет знать что проводок 1 на 1000. А откуда ему это узнать ? Из статистики, разумеется. Так что в системах, где оптимизатора запросов нету в виде отсутствия запросов, и роль оптимизатора выполняет специальный программист, пишущий программы обхода деревьев, статистики не нужны, конечно. Вместо статистики там тот самый специальный программист, знающий что "неисполненных" проводок всего 1 на 1000 и проверять это условие надо в последнюю очередь. Но лично мне больше нравится идея со статистикой, чем с увеличением фонда оплаты труда ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 23:04 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alex.CzechТогда я не понимаю такого повышенного внимания к фразе "Начиная с версии 5 для каждой клиентской коннекции вместо процесса стал создаваться thread". Переделка правильная, и фраза правильная :) Я придирался к фразе "Ну если говорить о VDS, то эта система изначально проектировалась именно малтисредовой ". А оказывается, она стала таковой только с версии 5. Я что-то не могу найти, когда эта версия вышла - но экстраполируя даты версий 4 и 6, это где-то в 1998-99 годах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 23:31 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Ну в принципе создавать процесс вместо thread-а - это даже несомненно круче :) Только очень накладно для Виндов Тем более что речь идет о клиентских коннекциях... Оракл вообще вон можно так настроить что у него все коннекции будут через 1 thread настроить, было бы желание Это ж не говорит о том, что он не мулти-thread-овый ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 23:38 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Alex.Czech ! Идея со статистикой увеличит фонд оплаты труда. Так как нужен опытный администратор, помимо программиста (если, конечно, это не один и тот же человек в случае простых приложений). Почему же не правильно понял ? Я сказал об одной задаче на этой таблице (которую Вы пока не "отменили"), а Вы - о другой, о которой в первом сообщении ничего не сказали. Ну что же, давайте рассмотрим Вашу задачу. Итак, "SQL Server сделает ровно то же самое": 1. "Сначала отберет проводки за неделю". Чтобы это сделать статистика по "Вашему" полю "Выполненные проводки" не поможет. Значит есть индекс по Дате ? 2. "По ходу дела отбрасывая невыполненные проводки". Здесь используется "мое" поле "Невыполненные проводки", на которое Вы, почему-то, не обратили внимания. Так что Ваши слова о специальном программисте, пишущем программы обхода деревьев, мне не понятны. Может быть потому, что я никогда не использовал иерархические СУБД, а Вы использовали, и у Вас есть печальный опыт обхода деревьев ? Но, в любом случае, причем здесь объектные СУБД ? И как обстоит дело с типом индекса "пустые не хранить" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 23:44 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
По поводу индексов "NULL не хранить" - сдается мне, вы прекрасно знаете, что таких индексов нету в MS SQL :) Индекс по дате разумеется есть, иначе говорить не о чем. Поле "Невыполненные" вместо "Выполненные" не поможет, потому что тогда условие примет вид WHERE NotAccepted=0, и это условие все равно будет выполняться для 90-99% проводок и применять его надо в последнюю очередь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 23:51 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
И еще - мне с вами трудно что-то обсуждать в смысле сравнения "Р"СУБД и ООСУБД, потому что вы про "Р" что-то знаете (хотя и далеко не все, но многое), а я про ОО ничего. Только не предлагайте приходить на семинар, я зубы-то полечить не могу найти времени сходить :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 23:54 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Я же честно сказал, что после 6.5 ПРЕКРАСНО уже не знаю. WHERE NotAccepted=1 (а не 0). Получается из-за того, что нет элементарного типа индексирования "пустые не хранить", приходится городить статистики по неиндексированным полям, которые рекомендуется отключать на промышленных приложениях... Мне, из-за возраста, еще хуже - нет времени вставить зубы, а не то что залечить... Но если будет желание что-то обсудить в области теории и проектирования баз данных, я всегда готов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 00:05 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичЯ же честно сказал, что после 6.5 ПРЕКРАСНО уже не знаю. WHERE NotAccepted=1 (а не 0). НЕТ. Это "невыполненные" проводки, а мне надо для оборотной ведомости выполненные. Или вы предлагает мне сначала посчитать по всем, потом по невыполненным, а потом вычесть из первого второе ? Это дольше будет, даже если на бумажке вручную считать, а в СУБД-то тем более :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 00:09 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Так Вы хотите сказать, что оптимизатор при условиях на индексированное поле "Дату" и неиндексированное и без статистики поле "Выполненные проводки" будет сначала использовать "Выпоненные проводки" ? А Вам не кажется, что реализация Вашей логичной фразы "по ходу дела, отбрасывая лишние проводки", была бы не лишней в любой СУБД ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 00:28 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alex.CzechНу в принципе создавать процесс вместо thread-а - это даже несомненно круче :) Только очень накладно для Виндов Тем более что речь идет о клиентских коннекциях... Оракл вообще вон можно так настроить что у него все коннекции будут через 1 thread настроить, было бы желание Это ж не говорит о том, что он не мулти-thread-овый Я что-то перестал понимать вашу логику изложения. При чем тут крутизна ? И, кстати, вы хотите сказать, что Оракл - multithread-ный ? Т.е. одному соединению соответствует одна или более нить, а не один или более процесс ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 00:33 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Под Windows (грубо говоря) да. Грубо, потому что есть MTS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 00:35 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vybegalloЯ что-то перестал понимать вашу логику изложения. При чем тут крутизна ? И, кстати, вы хотите сказать, что Оракл - multithread-ный ? Т.е. одному соединению соответствует одна или более нить, а не один или более процесс ? Под Виндами - несомненно. Под Виндами одному instance-у Ораклу несомненно и безусловно соответствует один процесс oracle.exe. Не верите - посмотрите в task manager-е ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 00:35 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичТак Вы хотите сказать, что оптимизатор при условиях на индексированное поле "Дату" и неиндексированное и без статистики поле "Выполненные проводки" будет сначала использовать "Выпоненные проводки" ? А Вам не кажется, что реализация Вашей логичной фразы "по ходу дела, отбрасывая лишние проводки", была бы не лишней в любой СУБД ? Не будет, а "может быть будет". Причем, что характерно, может быть он будет и прав - если запрос будет не за неделю, а за 10 лет, и процент "выполненных" проводок не 90, а 5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 00:36 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Откуда же он знает, что 5 БЕЗ СТАТИСТИКИ ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 00:42 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alex.Czech vybegalloЯ что-то перестал понимать вашу логику изложения. При чем тут крутизна ? И, кстати, вы хотите сказать, что Оракл - multithread-ный ? Т.е. одному соединению соответствует одна или более нить, а не один или более процесс ? Под Виндами - несомненно. Под Виндами одному instance-у Ораклу несомненно и безусловно соответствует один процесс oracle.exe. Не верите - посмотрите в task manager-е Я как-бы немного в курсе что то, что в юниксе процесс, в виндах нить. Как насчет юникса ? Оракл и там многонитевый, или таки многопроцессный ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 00:50 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичОткуда же он знает, что 5 БЕЗ СТАТИСТИКИ ? Так е-мое - с того ж разговор и начался, что не знает ! Зато по индексу знает, какой процент проводок попадет в диапазон. И он может ПРЕДПОЛОЖИТЬ, что выгоднее начать с условия Accepted=1, тем более что там равенство, а тут диапазон. Вот чтобы он не предполагал, а знал, и нужна статистика по полю Accepted. А индекс, очевидно, не нужен, только место занимать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 01:05 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vybegallo Alex.Czech vybegalloЯ что-то перестал понимать вашу логику изложения. При чем тут крутизна ? И, кстати, вы хотите сказать, что Оракл - multithread-ный ? Т.е. одному соединению соответствует одна или более нить, а не один или более процесс ? Под Виндами - несомненно. Под Виндами одному instance-у Ораклу несомненно и безусловно соответствует один процесс oracle.exe. Не верите - посмотрите в task manager-е Я как-бы немного в курсе что то, что в юниксе процесс, в виндах нить. Как насчет юникса ? Оракл и там многонитевый, или таки многопроцессный ? В Юниксе многопроцессный... но насчет того что там на отдельную коннекцию, процесс или нить, я не в курсе. Концепция нитей в Юниксе для меня вообще немного нова, когда я изучал SCO Unix в институте, там вроде вообще никаких нитей не было. Оракл под Юниксом никогда на предмет его внутреннего устройства тоже не трогал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 01:07 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Андрей Леонидович >Вместо того, чтобы так расстраиваться, лучше займитесь изучением баз данных. И я всегда готов Вам помочь, и ответить на любой Ваш вопрос в этой области. Не льстите себе. Я 8 раз задавал Вам очень простые вопросы на эту тему, а ответа все нет. Ладно, чтоб не быть голословным повторяю один из них в девятый раз. "А где бы посмотреть формализацию так называемой ОМД, ... или какая там альтернатива РМД осуждается?" Держите слово, отвечайте. >Каким образом ограниченность моих познаний в области "существующих" и "несуществующих" СУБД, и моя ограниченность вообще следует из: 1) определения ...: ОБЪЕКТ - все, что противостоит субъекту в его предметно-практической и познавательной деятельности. 2) определения ...: ПРОСТРАНСТВО и ВРЕМЯ - всеобщие формы существования материи и сознания. Из этих "определений" Ваша ограниченность следует по той причине что эти фразы определениями не являются. Определениями это может назвать только глубоко необразованный человек, основываясь на том, что они на его неотягощенный образованием взгляд вроде бы ВЫГЛЯДЯТ как определения. Например Вы определяете объект через субъект, а определения субъекта не даете. Такое определение бессмыселнно, его невозможно применить. Я Вам уже объяснял эти элементарные вещи, но либо до Вас не доходит, либо Вы делаете вид что не доходит. И из этого факта также следует Ваша ограниченность. > 3) выкладывания кем-то (а вовсе не мной) ссылки на мой доклад на семинаре в 1999 году "в программистком форуме"; против чего я, конечно, не возражаю, так как доклад очень хорош; Прямо великолепен! Замечателен! Неповторим! Похвалите хоть сами себя, раз никто больше не хвалит. Доклад, в котором фигурируют такие определения (а это основные определения) - полный бред и свидетельствует только о безграмотности докладчика. Кроме того этот доклад - бесстыдный плагиат, поскольку Вы не указали авторов основных определений и выдали их за свои. Об этом я Вам тоже говорил. >Вы можете хоть что-то сказать по-существу ? Это и есть по-существу. Объяснение не слишком сложно для Вас, все ли понятно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 01:49 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vybegalloТ.е. одному соединению соответствует одна или более нить, а не один или более процесс ?Нет, понятие соединения в MS SQL, в некотором роде, логическое, это некая физическая структура в памяти. Грубо говоря, нить подключается к соединению только тогда, когда соединение выполняет запрос. Соответственно, нет запроса, нет нити. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 02:47 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Константин Лисянский Alexey Rovdo The back-end server is completely under Versant’s realm of control, and is inherently multi-threaded, with a separate thread being used to manage each database connection. The primary motivation for making the server multi-threaded is to support highly concurrent accesses to the database with the lightest possible process footprint on the server. Отсюда пока следует, что на один коннект запускается тред. А как насчёт параллелизма внутри запроса? Пока видно, что параллелизм существует только между отдельными конектами. Умеет ли VDS обрабатывать данные параллельно в одном запросе? И если да, то как он это делает? С уважением, Константин Лисянский http://lissianski.narod.ru Увы,такой информации у меня нет. И нет ее ни в какой документации по продуктам Versant. Есть только косенные признаки, что что-то все-таки параллелится, но что и как - загадка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:11 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Alex.Czech ! Интересно, все-таки, "добить" этот простой приме, у которого Вы, правда, все время меняете начальные условия задачи... Так как индексированного поля "Невыполненные проводки" у Вас нет, можно предположить, что используется такая технология выполнения проводок (видимо с "закрытием дней"), при которой невыполненными будут проводки только за последний день. То есть, все-таки, сначала Вы правильно сформулировали: 99% выполненных. Хорошим решением было бы поле "Невыполненные проводки" с: - индексом типа "пустые не хранить" (но в MS SQL это не поддерживается); - и автоматической поддержкой количества записей для значений индекса (но в MS SQL это не поддерживается). Тогда оптимизатор знал бы сколько выполненных, а сколько не выполненных проводок с минимальными затратами (места) (или в MS SQL не известно и количество записей в таблице ?). Но я не сомневаюсь, что и существующая технология оптимизации по стоимости эффективна и "разумна" (ведь оптимизатор - это "сердце" "Р"СУБД). Поэтому опять же вопрос: при каких условиях (хотя бы теоретически) оптимизатор начнет перебирать все проводки в таблице проводок в Вашем отчете по диапазону дат (если есть индекс по полю дата и нет ни индекса, ни статистики по полю "Выполненные проводки") ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 17:14 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый с127 ! Ну Вы уже совсем запутались: сначала говорите, что это НЕ ОПРЕДЕЛЕНИЯ, а потом - что я не указал авторов этих ОСНОВНЫХ ОПРЕДЕЛЕНИЙ... Так что Вам не понятно "про формализацию ОМД" из наших с Вами обсуждений ? Что Вы в них искали, но не нашли ? С удовольствием отвечу на все Ваши вопросы. Как, впрочем, и про РМД. Ведь формализованного описания РМД, как мы выяснили, не существует. И мы тоже сможем формализовать ее (или ее разновидность ?) только обсуждая... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 17:19 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичУважаемый Alex.Czech ! Интересно, все-таки, "добить" этот простой приме, у которого Вы, правда, все время меняете начальные условия задачи... Так как индексированного поля "Невыполненные проводки" у Вас нет, можно предположить, что используется такая технология выполнения проводок (видимо с "закрытием дней"), при которой невыполненными будут проводки только за последний день. То есть, все-таки, сначала Вы правильно сформулировали: 99% выполненных. Хорошим решением было бы поле "Невыполненные проводки" с: - индексом типа "пустые не хранить" (но в MS SQL это не поддерживается); - и автоматической поддержкой количества записей для значений индекса (но в MS SQL это не поддерживается). Тогда оптимизатор знал бы сколько выполненных, а сколько не выполненных проводок с минимальными затратами (места) (или в MS SQL не известно и количество записей в таблице ?). Но я не сомневаюсь, что и существующая технология оптимизации по стоимости эффективна и "разумна" (ведь оптимизатор - это "сердце" "Р"СУБД). Поэтому опять же вопрос: при каких условиях (хотя бы теоретически) оптимизатор начнет перебирать все проводки в таблице проводок в Вашем отчете по диапазону дат (если есть индекс по полю дата и нет ни индекса, ни статистики по полю "Выполненные проводки") ? Уважаемый Андрей Леонидович ! Вы меня конечно извините, но это ВЫ все время меняете условия у МОЕЙ задачи на свои по непонятной мне честно говоря причине. Задача "найти все невыполненные проводки и выполнить их" мне неинтересна, была бы интересна - я бы сделал индекс по этому полю. Но для той задачи которая интересна (мне, а не вам) - получения суммарных оборотов за период только по выполненным проводкам индекс по этому полю НЕ НУЖЕН. А статистика НУЖНА. Вот и все, собственно. Если вы так и не понимаете, почему так, то я боюсь, я уже не смогу объяснить - мы пойдем по второму кругу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 17:32 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
По вопросу "при каких условиях" - это сильно зависит от объема данных и соотношения дат, но скажем если в диапазон дат будет попадать более 50% проводок, он очевидно будет перебирать их все. И будет прав ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 17:34 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alex.Czech В Юниксе многопроцессный... но насчет того что там на отдельную коннекцию, процесс или нить, я не в курсе. Концепция нитей в Юниксе для меня вообще немного нова, когда я изучал SCO Unix в институте, там вроде вообще никаких нитей не было. Оракл под Юниксом никогда на предмет его внутреннего устройства тоже не трогал Алекс, нити можно сделать и в досе, написав соответствующую библиотеку. Поскольку это внутреннее дело процесса. К сожалению, оракловские жлобы :-) не дают доступа к библиотеке документации, чтобы быстро проверить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 22:17 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Alex.Czech ! Не нужно нам идти по второму кругу. Ни в коем случае. Я говорю исключительно о Вашей задаче ! Просто сначала Вы сказали о 99%, а потом о 5. И в моем "предложении" (к сожалению не реализуемом на MS SQL) и Ваша задача просто решается. При любом проценте выполненных проводок. НО В ЛЮБОМ СЛУЧАЕ: если оптимизатор может перебирать именно те проводки, у которых "Выполнена"=1 без индекса по этому полю, я просто снимаю шляпу. И ем эту шляпу. А если не может, то зачем нужна статистика ? Вот в чем заключался мой вопрос. Вы не раздражайтесь, пожалуйста. Мы ведь в разделе "Сравнение СУБД". И на этом простом примере могли бы посмотреть как можно решать эту же задачу в ОСУБД. И Вы будете понимать их не хуже, чем я понимаю "Р"СУБД (скорее даже лучше). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 23:31 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидович, давайте я еще раз изложу свою программную речь "Зачем нужны статистики в MS SQL на частном примере оборотной ведомости" в одном посте, возможно проблема в том что мысль размазалась. Если и в одном посте будет непонятно - очевидно, я еще хуже умею объяснять свои знания, чем я думаю. Итак, есть задача - получить обороты за диапазон дат по таблице проводок. В таблице проводок есть сумма, дата и признак "выполнена" (всякие счета дебета, кредита и прочее мы проигнорируем для простоты изложения). Пусть есть индекс по дате IX_Date.Запрос естественно выглядит так: SELECT SUM(Amount) FROM Transaction WHERE TransDate BETWEEN @date_from AND @date_to AND Executed=1 Этот запрос попадает в руки к оптимизатору. Перед оптимизатором встает проблема - какое из двух условий применять в первую очередь ? Он может по значениям @date_from и @date_to определить какой процент проводок можно отфильтровать по дате (примерно или точно - смотря насколько актуальна статистика в составе индекса, но допустим актуально и посчитана по всем записям), но определить насколько эффективна фильтрация по второму условию - он НЕ МОЖЕТ. У него нет для этого данных ! Поэтому из каких-то своих соображений уже даже может и не стоимостного (cost-based), а "правильного" (rule-based) характера он может взять и применить сначала фильтр по полю Executed ! Что неоднократно и наблюдалось мною в практической деятельности, и я так подозреваю что не мной одним, на MS SQL. Есть подозрение, что в оптимизаторе наличествует 2 правила: "константа лучше чем переменная" и "равенство лучше, чем range". Бог ему судья, мне надо проблему решить Какие могут быть тут решения ? 1) "Зафиксировать" план запроса хинтом: SELECT SUM(Amount) FROM Transaction WITH (INDEX(IX_Date)) WHERE TransDate BETWEEN @date_from AND @date_to AND Executed=1 Решение всем хорошо, если у вас одна база или вы уверены что на всех ваших базах все пользователи будут использовать этот запрос по относительно небольшому промежутку дат, и при этом процент "выполненных" проводок очень велик. Однако лично у меня есть примерно 40 баз, куда написанные мною процедуры и запросы размножаются с переменной скоростью с оригинала. Более того, эти базы и функционал в них не подвластен мне, и я не могу дать гарантии, что в какой-то из баз не нагенерили плановых проводок в количестве сотни-другой тысяч, против 5 тысяч уже выполненных. 2) Построить индекс по полю Executed. Этот индекс имеет смысл для моей задачи только в случае, описанном мною в конце пункта 1 - а это случай все-таки довольно экзотический, и пусть для него автор индексы строит. В "обычном" же случае этот индекс будет жрать место и время при изменениях в таблице Transaction, притом что функциональность его как индекса будет не востребована. 3) Построить статистику по полю Executed И вот этот вариант я в случае, описанном выше, и выбираю. Потому что статистика даст возможность оптимизатору оценить распределение величины Executed, и в то же время не окажет абсолютно никакого влияния на скорость выполнения операций изменения данных (если только безумный админ не включит Auto update statistics) Вот ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2004, 02:03 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
То есть статистика нужна не в процессе выполнения запроса, в этот момент она уже бесполезна, а только в момент построения плана его выполнения - похоже, вот эта мысль от вас ускользнула. В языке MUMPS, где план выполнения есть плод творчества программиста, несомненно совершенно бесполезная вещь (никакого сарказма) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2004, 02:08 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Андрей Леонидович >Ну Вы уже совсем запутались: сначала говорите, что это НЕ ОПРЕДЕЛЕНИЯ, а потом - что я не указал авторов этих ОСНОВНЫХ ОПРЕДЕЛЕНИЙ... Нет, Андрей Леонидович, основными определениямя они называются у ВАС, в Вашей замечательной и великолепной статье. Это ВЫ их по необразованности считаете определениями. Андрей Леонидович: "В противоположность общему определению объекта, используемому в рамках гипотезы 2, ..." (Чернышев А.Л., "Сравнительный анализ моделей данных современных СУБД и новые идеи в области моделирования данных. Роль и перспективы М в развитии СУБД", стр.4, параграф 1.2. "Гипотезы и модели", http://www.informx.ru/doclad.zip). Это очевидно, что других авторов Вы не читаете, так читайте хотя-бы себя, любимого. >Так что Вам не понятно "про формализацию ОМД" из наших с Вами обсуждений ? Что Вы в них искали, но не нашли ? С удовольствием отвечу на все Ваши вопросы. Не съезжайте. Вопрос был задан, дайте на него ответ, как обещали. >Как, впрочем, и про РМД. Ведь формализованного описания РМД, как мы выяснили, не существует. И мы тоже сможем формализовать ее (или ее разновидность ?) только обсуждая... Эти утверждения кстати тоже свидетельствуют о Вашей дремучей ограниченности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2004, 02:27 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Alex.Czech ! Огромное спасибо за ясный и подробный ответ ! Итак: 1. "Из каких-то своих соображений" оптимизатор может перебирать все проводки при наличии индекса по полю "Дата" ДАЖЕ ПРИ ЗАВЕДОМО НИЗКОМ проценте проводок в диапазоне дат. То есть оптимизатор может ошибаться. Очень важное разъяснение. 2. Не применяем прямое указание оптимизатору, так как ЭТА таблица и ЭТОТ запрос используются в РАЗНЫХ прикладных системах, и данные в этой таблице обновляются по-разному в этих разных прикладных системах. Очень важное раъяснение. 3. Поэтому применяем решение, которое у хорошего (не ошибающегося, в отличие от оптимизатора) администратора должно хорошо работать. Меня только немного смущает что при "некачественном сборе статистики" (даже у хорошего администратора) оптимизатор все равно может ошибиться, как в п.1. Что касается ОСУБД, то Вы не совсем правы. Вы ведь уже знаете, что там существует два способа решения этой (как и других) задачи: SQL и "ручная навигация". Благодаря изложенным мной ранее особенностям индексации и автоматической поддержки статистики в ОСУБД, оптимизатор (при использовании SQL) не ошибется. Но давайте рассмотрим "ужасную" "ручную навигацию". Тем более, что в данной задаче я и не стал бы использовать SQL, так как очевидно, что индекс по характеристике "Дата" объекта "Проводка" является ПОЛНОЦЕННОЙ ЧАСТЬЮ ДАННЫХ. В ОМД и ОСУБД под этим понимается что: а) приложение не будет работать без индекса, так же как оно не будет работать без объекта; б) к индексу, как и к объекту, должен быть доступ (у программиста - в языке манипулирования данными, а у пользователя - в объектном навигаторе) В ТЕРМИНАХ МОДЕЛИ ДАННЫХ. Поэтому я написал бы этот "запрос" "вручную" (в том числе, чтобы не использовать два разных языка программирования): s sum=0,date=df f s date=$$oci("T",1,date) q:date>dt!(date="") d .s ex="" f s ex=$$oca("T",1,date,ex) q:ex="" i $$g("T",ex,2)=1 s sum=sum+$$g("T",ex,3) где T - идентификатор объекта "Проводка" с характеристиками 1 Дата 2 Выполнена 3 Сумма Как видите, прикладной программист работает с данными в терминах объектной модели. Можно изменить структуру и место хранения объекта и индексов - прикладные программы не изменятся (а Кодд почему-то считал, что изменятся). Но здесь есть один недостаток: при большом диапазоне дат может оказаться, что быстрее перебрать ВСЕ проводки в объекте. Однако: 1) у нас приложения везде работают одинаково (приведенный Вами пример с 40 базами с разным функционалом выглядит, действительно, впечатляюще; и, окажись я в такой ситуации, возможно тоже применял бы SQL в ОСУБД); 2) поэтому ради редких экспериментов бухгалтеров (вероятность которых с течением времени стремится к нулю) я, конечно, не стану применять SQL; 3) но ради чистоты эксперимента (последний раз я такой эксперимент делал лет 20 назад в DSM, чтобы потом сравнить с Oracle 5) в понедельник обязательно проверю и сообщу результат: - время перебора всех проводок в объекте "Проводка"; - время перебора проводок через индекс по характеристике "Дата", когда диапазон дат охватывает все проводки. P.S. И еще, у меня к Вам вопрос: что нужно написать на SQL, чтобы пользователь мог прервать запрос (SELECT), когда после старта запроса увидел, что неправильно ввел диапазон дат (1004 вместо 2004 в дате начала), и вернуться в бланк ввода условий отчета ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2004, 17:12 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый с127 ! Нет, основными определениями они являются у Вас. Не отклоняйтесь, пожалуйста, от НАШЕЙ с ВАМИ основной темы. Но, если, все-таки, хотите обсуждать по-существу различные темы в разделе "Сравнение СУБД", то я на Вашей стороне, то есть тоже хочу. Так что Вам не понятно "про формализацию ОМД" из наших с Вами обсуждений ? Что Вы в них искали, но не нашли ? С удовольствием отвечу на все Ваши вопросы. Как, впрочем, и про РМД. Ведь формализованного описания РМД, как мы выяснили, не существует (вниманельно почитайте все, что мы уже обсуждали в двух предыдущих темах). И мы тоже сможем формализовать ее (или ее разновидность ?) только обсуждая... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2004, 17:23 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Андрей Леонидович! А вот я тоже тут читал, читал... ух йо!.. А можно я у Вас ничего не буду спрашивать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2004, 20:26 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый lazy fox ! Так Вы же уже поняли, что у меня просто не о чем спрашивать. Но не все же такие проницательные, как Вы... На самом деле мои сообщения адресованы, в первую очередь, специалистам, не знакомым с реляционной теорией, которые часто попадали и продолжают попадать под "коммерческий гнет" реляционной моды (теперь уже - объектно-реляционной), или, как здесь говорилось, "эпохи реляционных СУБД". Я просто обращаю их внимание как много в "реляционных" системах проблем, связанных с "неизбежными альтернативами": создавать или не создавать отдельную таблицу при связи 1:М; использовать суррогаты, или ключи, определяемые пользователями; использовать кластеризованный или некластеризованный индекс; использовать кластеризованные таблицы или нет; и т.п. На первый взгляд: "мощный функционал". А на второй: концептуальная беспомощьность. На мой взгляд, конечно. Поэтому старательно аргументирую... А то, что Вы итак все прекрасно понимаете - это здорово. Желаю творческих успехов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2004, 23:13 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Андрей Леонидович >Так что Вам не понятно "про формализацию ОМД" из наших с Вами обсуждений ? Что Вы в них искали, но не нашли ? Ничего не искал, при чем тут искал? Предлагалось задать вопрос ("Андрей Леонидович>И я всегда готов Вам помочь, и ответить на любой Ваш вопрос в этой области."). Вот я и задал. Вопрос такой (в 10-й раз задается): "А где бы посмотреть формализацию так называемой ОМД, ... или какая там альтернатива РМД осуждается?" Извольте ответить, как неоднократно обещано. Хотя возможно пустозвону позволительно звонить по-пусту и за слова не отвечать, а Вы, как мы тут неоднократно выясняли, есть пустозвон. >Нет, основными определениями они являются у Вас. Цитату из Вашей статьи, в которой Вы называте эту чушь определениями я привел, поэтому тут спорить не о чем, это ВЫ их называете определениями. Мою же фразу об "основных определениях" Вы по-привычке вырвали из контекста а полностью она звучало так: c127> Доклад, в котором фигурируют такие определения (а это основные определения) - полный бред и свидетельствует только о безграмотности докладчика. Если Вы согласились, что это основные определения (первая часть высказывания), то Вам нужно согласиться и со второй частью, что ваш доклад - "полный бред и свидетельствует только о безграмотности докладчика". А вообще Вы сами достаточно точно оценили себя: Андрей Леонидович>Уважаемый lazy fox! Так Вы же уже поняли, что у меня просто не о чем спрашивать. Но не все же такие проницательные, как Вы... Андрей Леонидович>На самом деле мои сообщения адресованы, в первую очередь, специалистам, не знакомым с реляционной теорией, И это тоже правильно: специалистам, знакомым с РМД, Ваш бред читать смешно, а лохи может и поведутся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2004, 02:40 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичP.S. И еще, у меня к Вам вопрос: что нужно написать на SQL, чтобы пользователь мог прервать запрос (SELECT), когда после старта запроса увидел, что неправильно ввел диапазон дат (1004 вместо 2004 в дате начала), и вернуться в бланк ввода условий отчета ? Чтобы прервать выполнение запроса в клиентском приложении, очевидно нужно и написать что-то в клиентском же приложении. В частности, в ADO, которое я использую, если запрос выполняется асинхронно, его исполнение можно прервать, если синхронно - нельзя по довольно-таки понятным причинам. Но это уже вопрос, совершенно с СУБД не связанный (по крайней мере для технологий клиент-сервер в том виде, в каком я их понимаю) По поводу оптимизатора, который ошибается - вы же понимаете, что ситуация может быть гораздо сложнее, и если оптимизатор не имеет полной информации, то он конечно может ошибаться. Впрочем, трудно не признавать что он может ошибаться и когда полная информация есть :) Но я хочу обратить внимание на следующий факт: у меня есть возможность с помощью хинтов "зафиксировать" план выполнения запроса, а есть возможность положиться на "разум" оптимизатора. У вас ровно тот же набор возможностей, но существующие оптимизаторы для ООСУБД, насколько я понимаю, еще "слабее" существующих для РСУБД, потому что это - не ключевой блок ООСУБД ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2004, 19:36 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый с127 ! Хорошо, пусть я пустозвон, говорю полный бред, и безграмотен. И специалистам, знакомым с РМД, мой бред читать смешно. Но ведь пока здесь еще не появился специалист, знакомый с РМД, который мог бы опровергнуть мои аргументы. Одни (как Вы, например) считают все, что я говорю, бредом, просто потому что так удобнее, экономичнее (не нужно спорить по-существу). Другие сначала считали полным бредом, а потом, когда поняли о чем я говорю, сказали классическое "ну и что ?" (да, конечно, ничего - просто раньше они не знали, что "реляционные" системы не имеют никаких преимуществ перед дореляционными, а теперь узнали - только и всего). А третьи, может быть таких и мало совсем, изначально не считали и не считают меня безграмотным шизофреником. Но пока еще никто не признался, что он специалист, знакомый с РМД. Вот такая тонкость ускользнула от Вашего внимания. Поэтому, по-прежнему, готов Вам помочь. Так что Вам не понятно "про формализацию ОМД" из наших с Вами обсуждений, настолько, на мой взгляд, подробных, что дальше некуда (мы здесь уже программировать начали, а Вы все еще с теорией разбираетесь) ? Что Вы в них искали, чтобы понять, но не нашли, и не поняли ? С удовольствием отвечу на все Ваши вопросы. Как, впрочем, и про РМД. Ведь формализованного описания РМД, как мы выяснили, не существует (вниманельно почитайте все, что мы уже обсуждали в двух предыдущих темах - выяснилось, что существует некоторое семейство "реляционных" моделей, а не реляционная модель, как многие думали). И мы тоже сможем формализовать ее (или ее разновидность ?) только обсуждая... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2004, 19:59 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Alex.Czech ! Да, в целом согласен. Не исключено, что в целом "еще слабее". Но: 1) та технология индексации и автоматической поддержки и сбора статистики, которую мы частично обсудили, все-таки, не говорит, что ОСУБД в этом слабее; но будем считать, что мы просто СЛУЧАЙНО "наткнулись" на такое "место", где ОСУБД выглядит по-лучше (Вы правы - ситуация может быть гораздо сложнее); 2) множество отчетов и запросов, которые в приложении на базе "Р"СУБД, программируются программистами, пользователи приложений в ОСУБД получают самостоятьльно в объектном навигаторе и с помощью объектного генератора отчетов (здесь еще и семантика данных, конечно, проявляется, о чем мы вообще не говорили). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2004, 20:19 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей Леонидович2) множество отчетов и запросов, которые в приложении на базе "Р"СУБД, программируются программистами, пользователи приложений в ОСУБД получают самостоятьльно в объектном навигаторе и с помощью объектного генератора отчетов (здесь еще и семантика данных, конечно, проявляется, о чем мы вообще не говорили). Такого рода системы (генераторы отчетов для пользователей, а не программистов) существуют и для РСУБД. Я точно знаю - я участвовал в разработке одного из них :) Результатом их работы как правило является SQL-запрос, выдающий нужную пользователю информацию, для упрощения работы пользователя делается некая прослойка между физическими именами таблиц и терминами предметной области... так что ничего особенного в таких системах в принципе нету. Вы, видимо, хотите сказать что в ООСУБД они выглядят более "естественно" ? Возможно, и так. Однако больших дивидендов на сегодняшнем этапе развития информационных комплексов это не принесет - тут ситуация как была лет 10 назад с компьютерами на платформе Intel vs. Apple Macintosh: когда уже написано столько кода под одну из платформ, и переход с одной платформы на другую сильно затруднен, весьма маловероятно, что разработчики и пользователи дружной толпой побегут к новым технологиям, скорее всего они будут ждать пока "старые" почерпнут из новых все лучшее, а пока потерпят немного :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 00:15 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
И еще - все-таки язык M ужасен (вы вероятно давно его используете и просто этого не ощущаете)... такой язык НИКОГДА не сможет достигнуть такого уровня использования как SQL (в виде его диалектов) по вполне понятным тем кто его видит в первый раз причинам. Подробно на эту тему писал Garya в том, старом, топике, лучше чем он тогда я написать не смогу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 00:17 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Андрей Леонидович >Хорошо, пусть я пустозвон, говорю полный бред, и безграмотен. Это посылка. >Но ведь пока здесь еще не появился специалист, знакомый с РМД, который мог бы опровергнуть мои аргументы. А это утверждение. Но оно ложное, ибо если бред ПОЛНЫЙ, то в нем не может быть разумных аргументов. Опровергать нечего, потому и не опровергли. Если Вы дейтсвительно БЕЗГРАМОТНЫ, то вы не поймете, что Вас опровергли. И наконец из того, что Вас не опровергли, не следует что Ваши аргументы весомы. >Так что Вам не понятно "про формализацию ОМД" из наших с Вами обсуждений, ... ? С нашими обсуждениямя все ясно. Мне непонятно только где можно прочитать эту самую формализацию. Я утверждаю, что ее нет. Вы согласны? Если не согласны, то приведите ссылки на формализацию ОМД, ООБД и т.д. Если же формализации ОМД действительно нет, то бессмысленно кричать, что формализация РМД плохая, она все равно лучше чем все остальное, которого нет. >Как, впрочем, и про РМД. Ведь формализованного описания РМД, как мы выяснили, не существует Пока что мы выяснили только, что Вы безграмотный пустозвон, не отвечающий за базар. Вы можете либо попытаться исправиться, дав ссылку на формализацию ОМД или же признав, что такой формализации нет в природе, либо же продолжать звенеть попусту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 04:04 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
О, как же я хочу услышать ответ на этот вопрос! Я тоже хочу узнать "А где бы посмотреть формализацию так называемой ОМД, ... или какая там альтернатива РМД осуждается?" Дайте мне информацию! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 06:39 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Павел ВоронцовО, как же я хочу услышать ответ на этот вопрос! Я тоже хочу узнать "А где бы посмотреть формализацию так называемой ОМД, ... или какая там альтернатива РМД осуждается?" Дайте мне информацию! Уважаемые господа с127 и Андрей Леонидович! Надоело читать вашу перебранку и обсуждение генеалогии друг друга. Всем же остальным хотелось бы напомнить тему данного топика: "А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий". Даже по названию темы можно понять, что в вопросе идентификации ОМД нет каких-то общепризнанных стандартов. По крайней мере я придерживаюсь такой точки зрения. А ехидные вопросы типа "где бы посмотреть формализацию так называемой ..." имеют очень простой ответ. Любой производитель СУБД, который относит свою систему к объектной или объектно-реляционной понимает под термином "объектная" что-то вполне определенное, так что каждый может почитать документацию на Oracle, Sybase, Versant, Postgress, ... и узнать о том как понимают объектную ориентацию СУБД разработчики конкретной системы. Те же, кто это сделает, могут увидеть, что понимают то они это по разному. Поэтому и нет ничего удивительного в том. что здесь высказываются различные точки зрения на данный вопрос, и нет ничего удивительного в том, что такие монстры как Oracle, IBM и Sybase пытаются продвинуть свое видение этого вопроса (каждый в свою пользу). Но было бы любопытно отделить зерна от плевел и понять то, какие же критерии являются наиболее универсальными и подходящими для идентификации любой отдельно рассматриваемой СУБД (отнесения этой системы к объектной). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 10:47 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Константин ЛисянскийА если не секрет, зачем Вы этот вопрос задали? Пытаетесь что-то понять, или чему-то нас научить? С уважением, Константин Лисянский http://lissianski.narod.ru Возможно, я пытаюсь чему-то научиться у вас? Ко всему прочему у меня есть и другая цель - мне хотелось бы понять именно то, что людям приходит в голову в первую очередь, когда они слышат термин "объектная СУБД" (и то, насколько это соответствует реальному в моем понимании положению вещей). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 10:52 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdoчто людям приходит в голову в первую очередь, когда они слышат термин "объектная СУБД" Ну мне приходяд менеджеры... параноики... жопа... Извините, я всегда о ней думаю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 11:06 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey RovdoУважаемые господа с127 и Андрей Леонидович! Надоело читать вашу перебранку и обсуждение генеалогии друг друга. Всем же остальным хотелось бы напомнить тему данного топика: "А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий". Даже по названию темы можно понять, что в вопросе идентификации ОМД нет каких-то общепризнанных стандартов. По крайней мере я придерживаюсь такой точки зрения. А ехидные вопросы типа "где бы посмотреть формализацию так называемой ..." имеют очень простой ответ. Любой производитель СУБД, который относит свою систему к объектной или объектно-реляционной понимает под термином "объектная" что-то вполне определенное, так что каждый может почитать документацию на Oracle, Sybase, Versant, Postgress, ... и узнать о том как понимают объектную ориентацию СУБД разработчики конкретной системы. Те же, кто это сделает, могут увидеть, что понимают то они это по разному. Поэтому и нет ничего удивительного в том. что здесь высказываются различные точки зрения на данный вопрос, и нет ничего удивительного в том, что такие монстры как Oracle, IBM и Sybase пытаются продвинуть свое видение этого вопроса (каждый в свою пользу). Но было бы любопытно отделить зерна от плевел и понять то, какие же критерии являются наиболее универсальными и подходящими для идентификации любой отдельно рассматриваемой СУБД (отнесения этой системы к объектной).Вот потому и хочется знать точно - а что же оно такое, это самое О в аббривеатурах ООП, ОСУБД, ОДМ? Чтобы идентифицировать нечто как подходящее под некий класс, хорошо бы иметь формальное описание. Можно конечно пойти и тем путём, который Вы тут обозначили, но тогда не надо говорить о "провале РМД" как это любит делать Андрей Леонидович. Равное надо сравнивать с равным. Модель данных (реляционную) с моделью данных (где она?) Теорию (реляционную) - с теорией. А есть только практика. И предлагается попытаться вычленить теорию из рекламных заявлений разных производителей. Спасибо, не хочу. ЗЫ. Только не сочтите за личный наезд - у нас тут с Андреем Леонидовичем собственные религиозные войны, вы просто под руку подвернулись. Извините если что не так. Удачи в поисках "наиболее универсальных и подходящих для идентификации" критериев. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 12:07 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo Если ваша система разработана на базе принципов ООП и оперирует данными как связанными объектами, а сами данные через O/R отображение размещаются в реляционных таблицах (Oracle, SQL Server ...), то следующий вполне очевидный шаг - это перенос базы данных в ООСУБД. По-видимому, все еще не достаточно очевидный этот шаг. Я писал выше, что основные производители СУБД не перешли на ООСУБД, как это ожидалось. Даже из-за этого считают, что проект ООСУБД на грани полного краха. Приводил литературу. Есть и другие более осторожные оценки. Вместо этого они пошли на создание ОРСУБД для ответа на неадекватность РМД для некоторых специализированных типов приложений. Т.е. есть что-то что сдерживает от этого шага. Alexey Rovdo В чем же выйгрыш? А в том, что система, спроектированная в стиле ООП, будет значительно производительнее при использовании именно ООСУБ. Это как раз то и не совсем очевидно. Поскольку объектов то много в БД. И потому в этом плане, возможно, зависит не только от модели данных. Модель в принципе этим не "занимается" - это все-таки больше физический аспект, хотя, конечно, влияние есть. Alexey Rovdo Но напрактике таких ситуаций пока мало. Обычно приходится иметь дело с унаследованными системами (установленными ранее СУБД), где приложения уже написаны и ориентированы именно на парадигму РСУБД. А в таком случае, когда имеет место смешанная архитектура (объектно-реляционная), переход на ООСУБД может быть и не оправдан (все зависит от конкретной ситуации). Что касается оценки ситуаций на практике, то тут нужно приводить ссылки на тех, кто проводил подобные исследования. Ведь речь идет о проектах. Но, известно, что только Оракл, DB2 и MS SQL более 86% всех инсталляций СУБД. Еще море других РСУБД. Оправданность перехода на ООСУБД с РСУБД определяется не только легкостью перехода, но и целесообразностью его. Поскольку существую типы приложений - бизнес приложения, где до сих пор РСУБД успешней ООСУБД. Не забывайте, что у РМД есть кое-что очень ценное, чего у других нет: теор. Мат. обоснование, простота в проектировании для этих типов, высокая независимость данных от приложений и т.д. Alexey Rovdo И наконец, очередной раз повторяю. Объектные СУБД позволяют делать все то же самое, что позволяют и реляционные системы. Отличия только в производительности тех или иных решений на разных платформах. И SQL, и индексы, и оптимизаторы запросов, и транзакции и все остальное в рамках современных ООСУБД функционируют так же. Боюсь что все сложнее. С++ тем более все позволяет, включая и создание самого СУБД. Но мы же это не рассматриваем. И отличие не только в производительности. Я тоже повторюсь, что в модель данных производительность вообще не входит. Даже индексы в нее не входят. Они вообще суть архитектуры аппаратной платформы - если бы ОП была такой большой как внешняя память, то индексы были бы вообще не нужны. Поскольку их главная задача уменьшить число чтений с жесткого диска. А модели данных все это по барабану. Alexey Rovdo Что касается перспективы ОРМД, то про нее мне говорить сложнее. Согласен. Alexey Rovdo Тем не менее мне кажется, что эти системы гораздо более уязвимы, чем РМД и ОМД. И именно потому, что пытаются сидеть на двух (а то и трех) стульях сразу. Но можно сказать, что они пытаются использовать преимущества и РМД и ООМД. Почему Вы пишите ОМД? Ведь в ОМД входит и ERR, например, а не только ООМД. А ERR точно ничего и не хочет знать ни о какой производительности – она инфологическая (потому абстрагируется от компов). Alexey Rovdo В свое время они возникли как альтернатива нараставшей войне между объектной и реляционной концепциями. Но сейчас, когда по моему мнению большинство специалистов уже признало право на существование за обеими концепциями (РМД и ОМД), роль ОРМД стоит под вопросом, и в первую очередь из-за того, что для конечного пользователя (разработчика) функционал большинства ООСУБД и РСУБД становится практически идентичным (SQL-интерфейс + ОО-интерфейс). И что получается в итоге? А я вам приводил лит-ру, в которой пришли ровно к обратному. Т.е. насчет большинства специалистов есть сомнения. И , скорее всего, война не закончена. Да, ОРМД стоит под вопросом, но ООМД тоже под вопросом и пока, возможно, еще большим. Поскольку ОРМД пытаются реализовать ведущие производители СУБД, которые однозначно бы уцепили ООСУБД, если бы все обстояло как Вы говорите. То что «ф-л ООСУБД и РСУБД практически идентичный», может выглядеть как довод а пользу ОРСУБД. Потому до получения итогов еще далековато. Alexey Rovdo Есть две принципиально разных методики разработки (с опорой на объекты и модели предметной области, и с опорой на данные и ER-инструментарий), каждая из этих методик логически приводит к выбору типа хранилища - объектного или реляционного. А вот какая методика разработки сочетается с ОР-системами мне неизвестно. На счет методик не знаю, а вот насчет моделей данных и их реализаций в СУБД – есть три типа СУБД. Логически или нет, но претендуют на использование при создании разных типов приложений. Две из них ООСУБД и ОРСУБД – претендуют на то, чтобы прийти на смену реляционным. Первая радикально отказывается от РМД, вторая пытается его развивать. Первая выкидывает много ценного, что есть в РМД и потому, судя по Вашим словам, делает шаги в сторону РМД. (Вы писали про возможность SQL в них). Так или иначе, скорее всего, будущее не так очевидно как Вы пишете. Более того, если Вы признаете, что есть типы приложений, где вытеснить РМД будет сложно (а это основной тип приложений – бизнес приложения), то у ООМД нет возможности захватить весь рынок. А это существенная проблема в ее будущем, поскольку для БД имеет значение интеграция данных и все такое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 13:03 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Alex.Czech ! Не просто "выглядят естественнее", а прослойки НЕТ. По поводу "ужасности" языка было написано уже много с обеих сторон. И я тоже ничего нового сказать не смогу. Кроме того, что я увидел первый раз MUMPS и SQL практически ОДНОВРЕМЕННО (!). И после всестороннего анализа, многие аспекты которого я уже приводил, выбрал, все-таки, MUMPS. Кстати, когда я показываю "мампсистам" (конечно, уже "привыкшим") настоящие запросы на SQL (на MUMPS одна конструкция, которую Вы уже видели, и сложнее уже ничего не может быть), то "абракадабра" - это наиболее ласковое определение. Раз обещал: эксперимент. Количество экземпляров объекта "Проводка" = 1'074'659 Дата первой проводки = 01.01.1996 Дата последней = 16.11.2001 Средний результат по 10 опытам: время "нашего" "запроса" в случае перебора экземпляров непосредственно в объекте "Проводка" составило 89% от времени выполнения приведенного текста "запроса" с перебором проводок через индекс по характеристике "Дата" (когда заданный диапазон дат охватывает все проводки). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 20:09 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый Alexey Rovdo ! Я достаточно подробно ответил на вопрос в заголовке темы. Если нужно что-то уточнить, с удовольствием уточню. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 20:11 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Уважаемый с127 ! Автор темы попросил нас прекратить "перебранку" (хотя я, вроде, не бранился), и я его слушаюсь. Откройте, пожалуйста, для перебранки со мной специальный раздел, раз "Сравнение СУБД" Вас не интересует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 20:16 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Андрей ЛеонидовичУважаемый Alex.Czech ! Не просто "выглядят естественнее", а прослойки НЕТ. По поводу "ужасности" языка было написано уже много с обеих сторон. И я тоже ничего нового сказать не смогу. Кроме того, что я увидел первый раз MUMPS и SQL практически ОДНОВРЕМЕННО (!). И после всестороннего анализа, многие аспекты которого я уже приводил, выбрал, все-таки, MUMPS. Кстати, когда я показываю "мампсистам" (конечно, уже "привыкшим") настоящие запросы на SQL (на MUMPS одна конструкция, которую Вы уже видели, и сложнее уже ничего не может быть), то "абракадабра" - это наиболее ласковое определение. "Прослойки НЕТ" меня не устраивает по ряду причин... у меня все равно прослойка ЕСТЬ :) Про MUMPS и его "ужасность" спорить, конечно, глупо... это просто мое субъективное мнение против вашего. Разве что опрос провести какой-нибудь :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 10:16 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vadiminfo Alexey Rovdo В свое время они возникли как альтернатива нараставшей войне между объектной и реляционной концепциями. Но сейчас, когда по моему мнению большинство специалистов уже признало право на существование за обеими концепциями (РМД и ОМД), роль ОРМД стоит под вопросом, и в первую очередь из-за того, что для конечного пользователя (разработчика) функционал большинства ООСУБД и РСУБД становится практически идентичным (SQL-интерфейс + ОО-интерфейс). И что получается в итоге? А я вам приводил лит-ру, в которой пришли ровно к обратному. Т.е. насчет большинства специалистов есть сомнения. И , скорее всего, война не закончена. Да, ОРМД стоит под вопросом, но ООМД тоже под вопросом и пока, возможно, еще большим. Поскольку ОРМД пытаются реализовать ведущие производители СУБД, которые однозначно бы уцепили ООСУБД, если бы все обстояло как Вы говорите. То что «ф-л ООСУБД и РСУБД практически идентичный», может выглядеть как довод а пользу ОРСУБД. Потому до получения итогов еще далековато. Alexey Rovdo Есть две принципиально разных методики разработки (с опорой на объекты и модели предметной области, и с опорой на данные и ER-инструментарий), каждая из этих методик логически приводит к выбору типа хранилища - объектного или реляционного. А вот какая методика разработки сочетается с ОР-системами мне неизвестно. На счет методик не знаю, а вот насчет моделей данных и их реализаций в СУБД – есть три типа СУБД. Логически или нет, но претендуют на использование при создании разных типов приложений. Две из них ООСУБД и ОРСУБД – претендуют на то, чтобы прийти на смену реляционным. Первая радикально отказывается от РМД, вторая пытается его развивать. Первая выкидывает много ценного, что есть в РМД и потому, судя по Вашим словам, делает шаги в сторону РМД. (Вы писали про возможность SQL в них). Так или иначе, скорее всего, будущее не так очевидно как Вы пишете. Более того, если Вы признаете, что есть типы приложений, где вытеснить РМД будет сложно (а это основной тип приложений – бизнес приложения), то у ООМД нет возможности захватить весь рынок. А это существенная проблема в ее будущем, поскольку для БД имеет значение интеграция данных и все такое. 1. Война миров Начну опять с истории (я вообще считаю, что многие противоречия и споры гораздо легче разрешить, если не отрываться от причин их возникновения). Итак в конце 80-х - начале 90-х появились первые объектные СУБД. Тогда действительно казалось, что такие системы могут прийти на смену реляционным СУБД - шли жесточайшие споры на этот счет, а производители ООСУБД постоянно заявляли о скорой и полной победе и позиционировали себя очень высоко и гордо. Но через некоторое время стало ясно, что ООСУБД не всегда удобны и не всегда оптимальны. Этим воспользовались уже производители реляционных систем, которые, с одной стороны, реализовали в составе своих продуктов некие рудиментарные механизмы, призванные закамуфлировать реляционное ядро и создать видимость объектной-ориентированности, а с другой - стали продвигать линию, согласно которой надобности в чистых ОО-системах вообще никакой нет и их судьба - скорый крах и забвение. Надо отметить, что они в этом преуспели и где-то к 95-98гг. ОО-системы действительно были на грани вымирания именно по идеологическим соображениям. Вся эта борьба нашла непосредственное отражение и в популярной литературе. Самый яркий пример я уже приводил здесь - это книга Дейта и Дарвина, которая стала своего рода символом эпохи и подвела определенную черту под проигранным объектными системами сражением. [http://www.sql.ru/forum/actualthread.aspx?tid=146505&pg=-1#1191875]Выше вы привели в пример другое авторитетное издание - "Database Systems: The Complete Book". Давайте теперь посмотрим на то, когда была написана эта книга. Итак опубликована она 10.02.2001. Но ей предшествовали две книги этих же авторов: "A First Course in Database Systems" (опубликована где-то в 1997г.) "Database System Implementation" (опубликованна 6.11.99), которые и стали для нее основой ( подробнее ). А если копнуть глубже и пойти на страницу авторов, то оказывается, что книги писались на базе курсов, читавшихся в Стэнфордском университете в 1995-1996гг. Что тут можно сказать? Книга то хорошая и правильно отражает всю ситуацию на тот момент и именно в том ключе, который я представил выше. Но мы уже живем в 2004 (скоро 2005) году, а "динозавры" (ООСУБД) все-таки не вымерли. Почему? 2. Новый взгляд Упорное нежелание упрямых разработчиков удовлетвориться теми урезанными объектными функциями, которые были встроены в массовые системы (Oracle, Sybase ...), привело к пониманию важного факта - реляционный и объектный подходы не могут полностью заменить друг друга. Создать некий универсальный механизм, удовлетворяющий критериям обоих миров, никому пока не удалось (и скорее всего не удастся). Что же получается? А получается, что правая рука борется с левой , утверждая всем, что она (РСУБД) одна может делать все то же, что делает левая рука (ООСУБД), причем многое гораздо эффективнее. Оно и логично - ложкой (в правой руке) всегда больше можно с тарелки загрести, чем вилкой (в левой руке). А если на правой руке вырастить еще пяток новых пальцев и суставов, так и оба предмета можно держать одной рукой (ОРСУБД). Но на то и нужна голова, чтобы думать и правильно применять ОБЕ руки. Ведь как ни ухищрайся, гвоздь забить одной рукой не выйдет. 3. Позиция производителей Все сказанное выше - лишь лирические замечания, если рассматривать их вне контекста развития рынка. Поэтому важнейшее значение имеет позиция производителей разных систем. Тут особого разнообразия не наблюдается. Все крупнейшие игроки заявляют (всячески продвигают идею), что их системы пригодны и удобны для всех случаев жизни, а системы конкурентов - отстой и скоро вымрут. Что Oracle, что Microsof, что Versant - все хотят отхватить кусок побольше. Но это не удивляет и является совершенно нормальным. Удивляет поведение тех людей, которые освоив одну из популярных систем, предпочитают закрывать глаза на достоинства других. Причем делают это с удивительным упорством, граничащим с некомпетентностью. 4. Резюме Возможно, апологеты Oracle или DB2 сочтут все сказанное мною пустыми нападками на их любимые системы. Кому-то покажется, что я агитирую за переход на ООСУБД. Но моя позиция довольно банальна - быть прагматичным, помнить о наличии левой руки и "включать голову" прежде чем "трясти". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 11:40 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Alexey Rovdo По первому пп Война миров. Я оговарился, что есть и другие более осторожные взгляды, чем в той литре. Согласно, которым еще ничего не ясно. И что возможно разделение рынка. Но из-за проблем интеграции данных характерных для приложений БД имеет значение захват всего ранка. Кроме того, при всей важности исторических аспектов, нельзя не учитывать технических. А они таковы, что есть преимущества и недостатки тех или иных подходов для определенных типов приложений. И в основном этот технический аспект и используется при оценке ситуации в постреляционную эпоху. Но и сам исторический аспект может трактоваться по разному. Однако, факт остается фактом - ведущие производители перейдут на более передовую технологию БД. Например, IBM поддерживала, а может и поддерживает и РМД и иерархическую модель - производит для них разные СУБД. Но пока еще не производит ООСУБД. Это может считаться важным критерием положения дел с этим проектом. Как Вы это объясняете? Естественно, что конкурировать с ними в РМД, менне богатые производители не могут в тех моделях данных, что первые поддерживают. Но помятую историю с РМД пытаются использовать модели, которыми не занимаются ведущие производители. Успех РМД обогатил таких новичков в свое время. Вот и новые на это расчитывают, но с ООМД. Но тогда IBM быстро включилось в коммерческий проект РСУБД (правда, РМД придумали именнов в IBM). Второй пп. Новый взгляд. Тут у Вас не достаточно строгий подход. Мы ведь говорим о перспективе. Производители ОРСУБД возможности ОО вводят осторожно. Так как с ОО не все ясно. Нет хорошего теор обоснования. В каждой новой версии продукта появляются новые возможности. Есть вероятность, что еще в ОО в принципе чего-то не хватает для полноценногоприенения в технолгиях БД. Действительно, само ведь ООП хорошо ориентировано на множество классов, но огромное, характерное для БД количество самих объектов в самом ООП не присутствует. Там есть массивы, списки и все такое, характерное для прог и менее характерное для БД. В Оракле есть объектные таблицы, которые можно рассматривать как множество объектов. А в ООСУБД - например массивы - индексированные множества. Чем они лучше? Вот и ждут. Про руки - это сравнение, которое нуждается в доказательстве его адекватности реальной ситуации: не все что верно для рук обязательно верно для ОРМД. Это может быть и одна рука или нога, но более ловкая, с большими возможностями. Такие сравнения, мне кажется, только сбивают с толку. Что-то в них верно, а что-то нет, и нужно еще отделять верное от неверного. Кто-то скажет, что ООМД это вообще протез. Мне кажется, лучше говорить о достоинствах и недостатках, и там уже, может быть, сравнивать лучше с мерседесами и тракторами или чем-то поближе к транспорту или электростанциям. А про руки нужно все-таки еще из анатомии читать. 3 пп. Позиция производителей. Вот тут еще раз обращаю внимание на то, что ведущие производители именно из за куска побольше, в том числе, могут себе позволить перейти на новый проект. Ведь они все равно добавляют ОО. Но в виде ОРМД. А Версант все_таки не может конкурировать с ними, если попытается создавать РСУБД. Ему и остается только ООСУБД, потомо что лидеры его не осваивают. Вот почему не осваивают? Чего то все-таки в нем не хватает? Или что? Вот по этому поводу что Вы думаете? Четверты пп Резюме. Ну, есть такое - кажется что Вы заинтересованы в успехе ООСУБД, а не над их схваткой с ОРСУБД или РСУБД. Аполагеты Оракла или DB2 тоже могут придерживаться аналогичной позиции про левую руку, голову и т.д. Но все-таки это пока еще не совсем резюме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 13:01 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 vadiminfo Согласен с тем, что единого общепризнанного мнения по поводу ООСУБД и ОРСУБД сегодня не существует. Согласен и с тем, что не существует такой же красивой математической модели для объектных систем, как есть для систем реляционных. И осторожное отношение ведущих производителей также обусловлено рядом важных факторов, которые нельзя игнорировать. Я даже могу подтвердить то, что лично я не стою над схваткой и имею определенные интересы (впрочем, впереди я всегда ставлю здравый смысл). Но касаемо конкретных реализаци и конкретных фирм мое видение вполне конкретно: 1. В качестве базового описания ОМД и работы с объектными хранилищами данных вполне подходят стандарты ODMG 3.0 и JDO. К сожалению в свободном доступе я ODMG 3.0 не видел. Но вполне содержательная выдержка есть здесь . 2. Перспективы существования самих объектных СУБД в обозримом временном промежутке мне не кажутся очень уж туманными. Надо понимать, что сам по себе метод хранения данных волнует не многих. А вот способ и трудоемкость разработки информационных систем - есть вопрос большой важности. Во многом всплеск интереса к ООСУБД в последние годы обусловлен развитием Java, XML и сервисно-ориентированной архитектуры. Оказалось, что методики разработки, всегда сопутствовавшие ООСУБД, очень хорошо подходят для создания информационных систем в указанной парадигме. Поэтому в ближайшие годы ООСУБД обеспечен подъем (по крайней мере до тех пор, пока в состав традиционных систем от Microsoft, Oracle и IBM не будут встроены столь же удобные механизмы, облегчающие разработку). В частности, обладая информацией о продуктах Versant, могу смело утверждать, что не вижу никаких причин для их ухода с рынка в ближайшие 5-10 лет. Если компания пережила 15 лет борьбы и сумела набрать столько серьезных клиентов, то вряд ли возможен ее быстрый уход (хотя бы потому, что количество существующих инсталляций достаточно велико и пользователи не заинтересованы в срочном переходе на другие решения). 3. Если бы я был совершенно беспристрастен, то мне бы не стоило упоминать о преимуществах каких-то конкретных систем (Versant). Но я пристрастен. Но пристрастен я и потому, что вижу - там, где применение ООСУБД Versant Developer Suite будет более эффективным и рациональным, используют Oracle или DB2. А MS SQL я вижу там, где логичнее поставить Versant FastObjects. А вот примеры обратного мне в России не известны (хотя в мировой практике они наверняка присутствуют). Представьте себе, что вы пришли в кинотеатр, а ваше место занято - вполне логично, что вы будете кричать и добиваться его освобождения (и осуждать вас за это я не стану). Так и объектные СУБД. Обладая хоть и небольшим, но вполне заметным кусочком мирового рынка, они совершенно незаслуженно игнорируются в России - а зря - за это приходится расплачиваться (например, покупая западные информационные системы вместо систем собственной разработки, чье развитие зашло в тупик не в последнюю очередь из-за неверного выбора платформы). Здесь я уже достаточно удалился от темы классификации ООСУБД, поэтому хотел бы вернуться в это русло и спросить у тех, кто с этим знаком. Было бы интересно поподробнее рассмотреть объектные функции, имеющиеся в Oracle и/или DB2 с тем, чтобы понять их основные отличия от чистых ООСУБД именно по этим параметрам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 15:40 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Ну вот опять началась продажа.... Алексей я сам работаю в компании в названии которой три буквы и восемь полосок. Но стараюсь всетаки больше говорить на технические темы, а не о продаже. Ибо если мы начнем о продаже надо бутет открывать еще один топик. А оно надо??? Не надо за комунизм агитировать и говорить что ОО это лучше всего и это крутая альтернатива... Большинство бизнес задач можно и без ОО решить. Объектные возможности не есть _самоцель_. Они нужны одним для быстрее разработать, другим заработать. (что не факт) По поводу рассмотреть вопрос, а зачем. Давай ты посмотришь на OO расширения DB2/Informix/Oracle (в алфавитном порядке) и расскажешь нам... :) Ломать копья и говорить что моя религия лучше чем твоя это абсурд... Тебе хочется поддержать этот топик живым (ты его начал) Ты и действуй. P.S. Вышесказанное моя личная точка зрения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 15:57 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo И осторожное отношение ведущих производителей также обусловлено рядом важных факторов, которые нельзя игнорировать Какие факторы Вы имеете ввиду? Ведь об этом тема. Мне интересно Ваше мнение на этот счет. Alexey Rovdo Надо понимать, что сам по себе метод хранения данных волнует не многих. А вот способ и трудоемкость разработки информационных систем - есть вопрос большой важности. Что Вы имеете ввиду под методом хранения данных? Что каксается трудоемкости разработки, то для приложений где РМД адекватна она заведомо в этом плане выигрышна, поскольку один из недостатков ООМД как раз в том, что проектирование БД сложней, последствия ошибок при проектировании тяжелей. Требуется достаточно большой опыт проектировщика. иначе он наваяет таких классов и так свяжет между собой, что мало не покажется при сопровождении. Просто можнРазве что ООМД может использоваться и для концептуального и логическое проектирования. Alexey Rovdo Во многом всплеск интереса к ООСУБД в последние годы обусловлен развитием Java, XML и сервисно-ориентированной архитектуры. Оказалось, что методики разработки, всегда сопутствовавшие ООСУБД, очень хорошо подходят для создания информационных систем в указанной парадигме. Вообще-то XML - полуструктурированная модель данных в отличии и от ООМД и от РМД и ОРМД. Поэтому особо для ОО врядли что дает сама по себе. Вот насчет того, что оказалось с методиками разработки, пока еще как раз и трудно что-то сказать. Мне все еще кажется, что для полного счастья в ИС ООМД чего-то не хватает. Какой-то важной идеи. Не так просто она воспринимается. Разобраться в такой модели сложнее. Alexey Rovdo вижу - там, где применение ООСУБД Versant Developer Suite будет более эффективным и рациональным, используют Oracle или DB2. А MS SQL я вижу там, где логичнее поставить Versant FastObjects. А вот примеры обратного мне в России не известны (хотя в мировой практике они наверняка присутствуют). Как Вы это видите? Ведь это требует какого-то сложноватого анализа - выбор СУБД для проекта. Все-таки выбор ООМД в серьезном проекте на сегодняшний день выглядит как большой риск. Alexey Rovdo Представьте себе, что вы пришли в кинотеатр, а ваше место занято - вполне логично, что вы будете кричать и добиваться его освобождения (и осуждать вас за это я не стану). Так и объектные СУБД. Все-таки Ваши сравнения сбивают меня с толку. Представьте, что не известно чье это место, и номеров у мест нет. Вместо "Так и объектные СУБД" можно сказать "Так и любое СУБД". Alexey Rovdo покупая западные информационные системы вместо систем собственной разработки, чье развитие зашло в тупик не в последнюю очередь из-за неверного выбора платформы. Вообще, это требует серьезных исследований. Версант - тоже не русского производства. Неверный выбор платформы - нужно долго обосновывать. Информационных систем собственной разработки у нас не так и мало. Смотря что за системы. Их развитие определяется в большей степени развитием СУБД на западе. А своих СУБД у нас нет, и достижений в этой области не может быть заметных. Мы проиграли в этом плане в восьмидесятые окончательно. До этого у нас были СУБД, и даже СУБЗ для каких-то доисторических машин. Но в машинах мы тоже проиграли. И ООМД нас никак не спасает. Нужно что-то более весомое. Alexey Rovdo я уже достаточно удалился от темы классификации ООСУБД, поэтому хотел бы вернуться в это русло и спросить у тех, кто с этим знаком. Было бы интересно поподробнее рассмотреть объектные функции, имеющиеся в Oracle и/или DB2 с тем, чтобы понять их основные отличия от чистых ООСУБД именно по этим параметрам. Классификации ООСУБД? Какие там есть классы? К какому классу относится Версант? Она построена на существующем каком-то ОО языке программирования? Каком? Вот я вычитал, что этот язык она не расширяет, а использует дополнительные библиотеки классов, поддерживающие перманентность, агрегирование, объектные типы данных, транзакции и т.д. А Вы слышали что-нибудь про SIM, которая пошла по пути создания совершенно нового языка баз данных и СУБД, обладающее ОО возможностями? Там используется собственная семантическая модель данных. Что Вы про это думаете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 22:00 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
vadiminfo Какие факторы Вы имеете ввиду? Ведь об этом тема. Мне интересно Ваше мнение на этот счет. Боюсь, что откровенный ответ на этот вопрос приведет к удалению топика :) Но ко вторичным факторам я могу отнести следующее: Сфер, где объектные СУБД имеют значительные преимущества, относительно не много и этот кусок рынка большой тройке просто не интересен (он мал). Судьба объектных систем через 10-15 лет действительно не ясна, в то время как в будущем систем реляционных можно не сомневаться по крайней мере лет 30. Например, IBM уже имеет опыт одновременного развития двух ветвей - иерархической (IMS) и реляционной (DB2). Вероятно издержки довольно высоки и прежде, чем кидаться в омут приходится просчитывать очень многое. На мой взгляд, сами попытки внесения объектной функциональности в существующие системы показали, что сделать это очень сложно - возможно гораздо сложнее, чем разработать заново чисто объектную СУБД. Более того под сомнением сама возможность такой интеграции (до определенной степени она возможна, но затем возникают препятствия, и совместить оба подхода в одной системе оказывается нереальным). (Только не спрашивайте меня "какие препятствия", т.к. я сам не знаю - полагаю только, что раз до сих пор нет полной аналогии между объектными и объектно-реляционными системами, значит препятствия есть и они значительны.) vadiminfo Что Вы имеете ввиду под методом хранения данных? Что касается трудоемкости разработки, то для приложений где РМД адекватна она заведомо в этом плане выигрышна, поскольку один из недостатков ООМД как раз в том, что проектирование БД сложней, последствия ошибок при проектировании тяжелей. Требуется достаточно большой опыт проектировщика. иначе он наваяет таких классов и так свяжет между собой, что мало не покажется при сопровождении. Просто разве что ООМД может использоваться и для концептуального и логическое проектирования. А я вообще считаю, что ОМД и РМД - это вопрос десятый. Главное - это методика разработки информационной системы, т.е. технология решения поставленной задачи. Если есть инструментарий, позволяющий разрабатывать системы быстро, снижающий издержки по сравнению с другими методами, облегчающий сопровождение и доработки, то я перейду на использование этого инструментария (разумеется вопросы быстродействия систем имеют значение, но +/- 50% обычно можно игнорировать). И вот тут то я все время наталкиваюсь на проблему - большинство ассоциирует модель данных с методикой разработки столь тесно, что рассматривать эти вопросы независимо друг от друга совершенно не получается. А зря - ведь современные системы, построенные как на РМД, так и на ОМД и ОРМД содержат инструментарий, позволяющий использовать любой подход (а если они его не содержат сами, то он существует как самостоятельный продукт). По всей видимости это обусловлено тем, что разработчики привыкли к тому, что систему надо в значительной степени подгонять под возможности конкретной СУБД, а создание универсальных переносимых систем наталкивается на несовместимости и сопряжено с большими трудностями. В какой-то мере это имеет место и в мире объектных систем. Тем не менее в плане стандартизации очень неплохо продвинулись Java-разработчики. И сегодня программы, написанные в рамках стандарта JDO оказываются легко адаптируемыми практически под любые СУБД (объектные, реляционные, объектно-реляционные). А если моя информационная система развертывается и работает на любой базе, так ли уж меня должно волновать то, как внутри этой базы будут лежать данные - в виде таблиц или в виде объектов? Так что подход к разработке и выбор инструментария, если еще и не стал, то в ближайшее время станет делом вкуса и пристрастий конкретного разработчика. Причем ваши высказывания о трудоемкости проектирования в ОО-парадигме для тех. кто в этой парадигме все время работает, выглядят просто вызывающе - им то как-раз проще только так. vadiminfo Вообще-то XML - полуструктурированная модель данных в отличии и от ООМД и от РМД и ОРМД. Поэтому особо для ОО врядли что дает сама по себе. Вот насчет того, что оказалось с методиками разработки, пока еще как раз и трудно что-то сказать. Мне все еще кажется, что для полного счастья в ИС ООМД чего-то не хватает. Какой-то важной идеи. Не так просто она воспринимается. Разобраться в такой модели сложнее. Ну полного счастья не было и не будет никогда - сие, знаете ли, закон природы. :) Что же касается XML, то сама по себе эта модель конечно ничего ОО не дает. Но вот в связке с популярными нынче Web-сервисами, Java и сериализацией объектов доставляет полный и удобный инструментарий, который очень хорошо приспособлен к использованию в ОО-программировании (впрочем, не только в нем). vadiminfo Как Вы это видите? Ведь это требует какого-то сложноватого анализа - выбор СУБД для проекта. Все-таки выбор ООМД в серьезном проекте на сегодняшний день выглядит как большой риск. Вот анализа то я и не вижу. Разумеется я не могу однозначно утверждать, что вот в такой-то и в такой-то системах вместо РСУБД надо было использовать ООСУБД. Но я знаком с тем, как вообще принимаются подобные решения. И если позицию руководителя, который может вообще не брать в расчет технические факторы можно объяснить, то технари меня удивляют регулярно, впрочем я уже высказывался по этому поводу. То же самое могу сказать и о рисках - риски рискам рознь. И мнение о том, что существующие сегодня реализации ООСУБД в чем-то менее надежны и менее проверенны ошибочно (см. здесь , здесь и здесь ). vadiminfo Классификации ООСУБД? Какие там есть классы? К какому классу относится Версант? Она построена на существующем каком-то ОО языке программирования? Каком? Вот я вычитал, что этот язык она не расширяет, а использует дополнительные библиотеки классов, поддерживающие перманентность, агрегирование, объектные типы данных, транзакции и т.д. А Вы слышали что-нибудь про SIM, которая пошла по пути создания совершенно нового языка баз данных и СУБД, обладающее ОО возможностями? Там используется собственная семантическая модель данных. Что Вы про это думаете? Так вот мне самому интересно, в чем Versant отличается от объетных возможностей других СУБД и где тот водораздел, который позволяет отнести одни системы к объектным, а другие к объектно-реляционным. Вот, например, про Cache очень любят писать, что она объектная. Но мне то кажется, что это не так. Я также много узнал о том, что в Oracle и DB2 тоже есть функционал для работы с объектами, но какой? Я с объектной функциональностью этих систем не работал и мое мнение сформировано на базе обзоров и статей на эту тему. Судя по общению в этом форуме, многие знают о наличии каких-то объектных расширений в названных системах, но судя по всему никто с ними реально не работает. А вывод я могу сделать из этого такой - все это еще находится в рудиментарном состоянии и работать с этим неудобно, зато есть чисто объектные системы, в которых инструментарий вылизывался десятки лет и которые строятся на базе стандартов. И здесь я могу ответить и на ваш вопрос по поводу SIM. Я не знаю, что такое SIM, но мугу высказать свое мнение по поводу специальных языков - очень тяжелое направление. Причем языки могут быть очень хороши о подходы великолепны, но как только разработчик видит, что ему прийдется изучать какой-то новый язык - он отворачивается и забывает о существовании этой системы. А чтобы он этого не делал ему нужен пряник неимоверной величины. Возможно, языки разрабатываемые сегодня смогут завоевать популярность, но это случится не раньше чем через 20-30 лет. Сегодня же мы имеем стандарты ODMG 3.0 и JDO , которые вполне адекватно определяют методы интеграции в C++, Java и Smalltalk (C# и другие языки платформы .NET расширяются по аналогии) функциональности для обеспечения сохраняемости объектов (object persistence). И выглядит это довольно просто - вы объявляете любой класс как класс "поддерживающий сохраняемость" и после этого объекты такого класса могут быть сделаны сохраняемыми (т.е. они будут записаны в БД). Манипулируя с сохраняемыми объектами в рамках транзакций вы обеспечиваете сохранение всех изменений в БД. Изменяя объекты вне транзакций вы изменяете их только в памяти приложения. С уважением и с наступающим Новым Годом, Алексей Ровдо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 12:24 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Я вот одного не пойму... автор...объекты такого класса могут быть сделаны сохраняемыми (т.е. они будут записаны в БД)... предположим, я хочу найти нечто вроде SELECT ...что-то... FROM SomeClass WHERE SomeClass.Method() = ...чему-то... Это что, все объекты класса SomeClass должны будут .....мммм..... актуализироваться на клиенте, дабы выполнить Method()? Или СУБД такая смартная, что может это у себя делать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 18:11 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Мимо пробегал...Я вот одного не пойму... автор...объекты такого класса могут быть сделаны сохраняемыми (т.е. они будут записаны в БД)... предположим, я хочу найти нечто вроде SELECT ...что-то... FROM SomeClass WHERE SomeClass.Method() = ...чему-то... Это что, все объекты класса SomeClass должны будут .....мммм..... актуализироваться на клиенте, дабы выполнить Method()? Или СУБД такая смартная, что может это у себя делать? Ну а чего собственно в этом такого смартового ? Никого же не удивляет что запросы типа SELECT * FROM SomeTable WHERE fn(SomeTable.ID) = 5 зашибись выполняются без всякой актуализации на клиенте. Чем ООСУБД хуже ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 23:49 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Андрей Леонидович >Уважаемый с127 ! Автор темы попросил нас прекратить "перебранку" (хотя я, вроде, не бранился), и я его слушаюсь. Откройте, пожалуйста, для перебранки со мной специальный раздел, раз "Сравнение СУБД" Вас не интересует. Перебранка с Вами, конечно, дело веселое и несет положительные эмоции, но специальный топик ради нее открывать лень. Вы опять съехали. Одна ссылка топик бы не засорила, да и к перебранке вроде отношения бы не имела, если ссылка по-делу. А если нет ссылки по-делу то так и скажите. Alexey Rovdo >"А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий". Даже по названию темы можно понять, что в вопросе идентификации ОМД нет каких-то общепризнанных стандартов. В таком случае обсуждать "кто как понимает ООСУБД" равнсильно обсуждению "кто как понимает вкусную еду" или "кому какие бабы нравятся", тоже ведь нет очщепризнанных стандартов. Потрепаться конечно можно, особенно если с примерами и демонстрацией (особенно баб), но друзьям навязывать не стОит. Вы же предлагаете нам свою любимую СУБД в качестве промышленного решения, а кто будет отвечать за базар перед заказчиком? Опять же мы. Что касается отсутсвия стандартов, то по-крайней мере внутри каждого серьезного проекта должен быть стандарт, хотя бы внутренний. Это для того, чтоб хотя бы собственные разработчики компании не путались и понимали друг-друга. Иначе на каком языке они там внутри разговаривают и как СОВМЕСТНО создают программный продукт? Что называется объктом, что классом, что еще чем. Без деталей реализации. Это информация не секретная. Если ее нет, или она вдруг страшно засекречена, то продукт ламерский и с ним лучше вообще не связываться, ибо потом все равно будет хуже. Так вот нельзя ли тут выложить ссылку на эти внутренние стандарты Вашего любимого продукта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 02:48 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
c127 В таком случае обсуждать "кто как понимает ООСУБД" равнсильно обсуждению "кто как понимает вкусную еду" или "кому какие бабы нравятся", тоже ведь нет очщепризнанных стандартов. Потрепаться конечно можно, особенно если с примерами и демонстрацией (особенно баб), но друзьям навязывать не стОит. Вы же предлагаете нам свою любимую СУБД в качестве промышленного решения, а кто будет отвечать за базар перед заказчиком? Опять же мы. Что касается отсутсвия стандартов, то по-крайней мере внутри каждого серьезного проекта должен быть стандарт, хотя бы внутренний. Это для того, чтоб хотя бы собственные разработчики компании не путались и понимали друг-друга. Иначе на каком языке они там внутри разговаривают и как СОВМЕСТНО создают программный продукт? Что называется объктом, что классом, что еще чем. Без деталей реализации. Это информация не секретная. Если ее нет, или она вдруг страшно засекречена, то продукт ламерский и с ним лучше вообще не связываться, ибо потом все равно будет хуже. Так вот нельзя ли тут выложить ссылку на эти внутренние стандарты Вашего любимого продукта? В первом абзаце вы поставили вопрос, а во втором сами же на него ответили - внутри каждого серьезного проекта существует стандарт. Но это вовсе не означает, что все внутренние стандарты в различных СУБД одинаковы и/или общепризнаны. Я подхожу к вопросу в меру своих знаний отдельных продуктов и могу аргументированно показать почему эти продукты относятся к категории действительно объектных систем. Опять таки, только про эти продукты я могу сказать, что они соответствуют спецификациям ODMG 3.0 и JDO (можно ли считать именно соответствие этим спецификациям критерием объектности той или иной системы ?). Тем не менее существуют и другие системы, подробной информацией о которых я не располагаю. Я предложил тему, рассказал о продуктах Versant, узнал много нового об оптимизаторах запросов и преимуществах SQL (причем на примере тех задач, которые никогда и не считал сильной стороной объектных систем), но так ничего и не узнал об объектных функциях и стандартах иных систем (Cache, DB2, Oracle ... ). Зачем это все? Дело в том, что именно ответ на поставленный вопрос сам по себе уже несет достаточно много информации о том, в каких случаях имеет смысл использовать объектные системы (разные, а не только "мои любимые"). Спор в терминах "крутизны" того или иного продукта и оперирование лишь сущностями терминологического характера (РСУБД/ОРСУБД/ООСУБД) интересен только до определенного предела и имеет скорее эмоциональную окраску. Тем более, что спорить можно только понимая реальные различия и ограничения систем. Так что мне по-прежнему интересно - что же, кроме идеологической ненависти приходит в голову разработчика при словах "объектные СУБД". Полагаю, что мне прийдется самому исследовать эти отличия и снова предложить свою трактовку. Обращаю, однако, ваше внимание на то, что мое предположение о том, что с объектными функциями популярнейших ОРСУБД просто никто не работает, пока не опровергнуто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 12:30 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Мимо пробегал...Я вот одного не пойму... автор...объекты такого класса могут быть сделаны сохраняемыми (т.е. они будут записаны в БД)... предположим, я хочу найти нечто вроде SELECT ...что-то... FROM SomeClass WHERE SomeClass.Method() = ...чему-то... Это что, все объекты класса SomeClass должны будут .....мммм..... актуализироваться на клиенте, дабы выполнить Method()? Или СУБД такая смартная, что может это у себя делать? На примере Versant FastObjects: Сами методы не хранятся в FastObjects вместе с объектами. Т.е. вы можете выполнить такой запрос и все объекты действительно должны будут актуализироваться на клиенте. Но если этот клиент является сервером приложений, то никакой проблемы в этом нет - актуализировавшись они попадут в кэш и при повторном доступе к этим объектам сервер приложений к серверу БД обращаться не станет. Это концептуальная особенность FastObjects, предполагающая отделение хранения данных, их описания (описания классов для хранимых объектов находятся в отдельной базе данных) и методов. Следует учесть, что сама база данных вообще может находиться на множестве серверов, а доступ к хранимым объектам можно получить из разных программ, написанных на разных языках программирования. Существуют ООСУБД хранящие методы вместе с объектами, но такой подход накладывает свои ограничения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 13:20 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo А если моя информационная система развертывается и работает на любой базе, так ли уж меня должно волновать то, как внутри этой базы будут лежать данные - в виде таблиц или в виде объектов? Расскажите подробнее, как хранятся данные в виде объектов. Я это прошу сделать ужу не первый раз, но Вы очень технично уклоняетесь от этого. Кроме того, я еще раз для Вас повторяю, что в том же оракле "таблица" - понятие логическое, поскольку данные реально могут храниться в виде совершенно различных структур. Расскажете мне, что в объектных свойствах оракла Вас не удовлетворяет, кроме того, что оракл - все-таки еще и РСУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 13:58 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
AI Расскажите подробнее, как хранятся данные в виде объектов... Кроме того, я еще раз для Вас повторяю, что в том же оракле "таблица" - понятие логическое, поскольку данные реально могут храниться в виде совершенно различных структур. Расскажете мне, что в объектных свойствах оракла Вас не удовлетворяет, кроме того, что оракл - все-таки еще и РСУБД. Уважаемый Al, я вовсе не хочу поставить под сомнение то, что у оракла есть объектные функции. Возможно, они очень даже хороши. Но какие функции вы, например, относите к "объектным"? И с какикими из них вам действительно приходилось работать? Вообще вы здесь чуть ли не единственный, кто хоть что-то сказал по поводу того, как в оракле хранятся данные ( здесь ). Можно ли понимать так, что вы согласны, например, с тем, что отнесение системы к ОСУБД определяется именно способом размещения объектных данных в хранилище? Или же вы полагаете, что здесь нужно рассматривать некую совокупность характеристик (каких)? PS: По поводу хранения данных в Versant я после праздников обязательно что-нибудь отвечу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 16:13 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
2 Alexey Rovdo >В первом абзаце вы поставили вопрос, а во втором сами же на него ответили - внутри каждого серьезного проекта существует стандарт. Но это вовсе не означает, что все внутренние стандарты в различных СУБД одинаковы и/или общепризнаны. Я и не утверждал, что стандарт общепризнанный. Мой вопрос звучал так: "Так вот нельзя ли тут выложить ссылку на эти внутренние стандарты Вашего любимого продукта?" Поймите, что мы тут можем обсуждать оптимизаторы и прочие прелести РСУБД только благодаря тому, что все одинаково понимаю слова "таблица", "запись" и т.д. А это в свою очередь происходит благодаря тому, что РМД хорошо (в разумных пределах) формализована. Иначе мы бы просто не поняли друг-друга, как не понимаем друг-друга когда речь заходит об ОМД или какой-то ее реализации. Я ведь тоже не из вредности повторяю этот вопрос, все-таки надеюсь, что кто-нибудь ответит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.12.2004, 02:19 |
|
||
|
А кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo А я вообще считаю, что ОМД и РМД - это вопрос десятый. Это Вы зря. МД - это то, что превращает технологию БД из ремесла в науку. Она призана снизить зависимость данных от приложений. И имеет важное значение для многих аспектов ИС, начиная от проектирования и заканчивая решением главной задачи - максимально упростить получение необходимой для принятия решения информации. Скорее всего это все-таки одно из первейших дел. Alexey Rovdo Главное - это методика разработки информационной системы. Это имеет значение для проектирования БД и успеха проекта в целом, но не может устранить важность модели данных в БД. Как бы не проектировали самые первые БД (плоская модель, СУБД, можно сказать, вообще нет), мы знаем, что кончилось это депрессией программного обеспечения. Alexey Rovdo А если моя информационная система развертывается и работает на любой базе, так ли уж меня должно волновать то, как внутри этой базы будут лежать данные - в виде таблиц или в виде объектов? Это как? БД - ядро ИС, т.е. БД входит в состав ИС. Если из ИС вынуть БД, то то что останется (оболочка ИС) будет работать с любой другой БД? Имеется в виду независимость от СУБД? Ну РМД обеспечивает относительную независимость от СУБД. Однако, в реальных проектах используются серверные приложения, различные расширения РМД. В общем, тут, наверное, я не до конца понял Вашу мысль. Alexey Rovdo Причем ваши высказывания о трудоемкости проектирования в ОО-парадигме для тех. кто в этой парадигме все время работает, выглядят просто вызывающе - им то как-раз проще только так. Вот я обращал Ваше внимание, что между проггерами и проектировщиками БД есть разница, а Вы не обратили внимания, и не прокомментировали это. Проггеры, пришедшие из далеких от БД проблемных областей, не видят большой разницы между данными к их прогам, что они писали, и БД. И потому относятся с пренебрежением к БД (как простым данным из файлов их прежних прог), стремятся упростить процесс ее разработки, и компенсировать это программными ухищрениями. Например, в РМД вместо нескольких нормализованных они могут запросто предложить одну не нормализованную, а потом все решать с помощью кода. Они в принципе способны взять таблы из РМД, но только как способ форматирования, а способ интерпретации придумать свой, так что ни какой SQL потом не поможет, потому что это не реляционная БД, или реляционная, но отвратно спроектированная. Т.е. простота извлечения инфы может сильно пострадать. Даже после них юзера отрицательно относятся вообще к идее к ИС. В ИС - БД часто является чем-то значительно более важным, чем проги. Ее структура достаточно статичная часть системы: злоупотреблять ее переделками, особенно на стадии эксплуатации не всегда желательно. А если она плохо спроектирована, то никакие программные ухищрения не помогут. Поэтому мнение тех, кто работает в ОО-парадигме, если это не проектировщики БД, никакого значения не имеют в ИС. Они должны переучиваться. То, что сложность проектирования ООБД - это недостаток по сравнению с РМД придумал не я. Это как бы известный факт. Alexey Rovdo Я также много узнал о том, что в Oracle и DB2 тоже есть функционал для работы с объектами, но какой? Вот Вам к стати подтверждение того, что существует барьер при переходе от РМД к ОРМД и тем более ООМД. Если про РМД можно сказать что будет, то включение объектов оставляет больше неопределенностей, насчет возможных сюрпризов в последствии. Например, написание SQL уже усложняется. или, объекты могут в данной версии не реплицироваться или еще какие-нибудь ограничения могут всплыть в дальнейшем при развитии проекта. Т.е. мы захотим что-то добавить, например, репликацию, а из-за объектов этого нельзя будет сделать. Это и основной сдерживающий фактор. Например, в одном проекте еще на восьмерке был объектный тип в табле. А потом другие работали с этой таблой (она использовалась в других проектах) и постоянно натыкались на сюрпризы: ошибки непонятные на ровном месте (там мат стоял несусветный из-за этого), природа которых в том, что присутствие такого типа в табле не допускает чего-то там или баг Оракла при работе с таким типом. Объектные типы там пока еще далеки от идеала. Только крайняя нужда заставляет их использовать. Хотя может и сама модель ОРМД не очень хороша. Больше времени на то, чтобы ее понять нужно. У Оракла функционал приближается потихоньку к поддержке известных принципов ООП. Кроме того, есть разные рел стуктуры для них: они могут быть типами данных колонок обычных табл, но может быть табла построенная на объектном типе (в ОРМД не используется термин класс, вместо этого типы - пользовательские, объектные - кто во что горазд, еще не сложилась терминология). Кроме того, у Оракла есть специальные предопределенные объектные типы для некоторых специальных типов приложений. Например, геометрических и геоинформационных, XML. Но, я думаю, на это там стоит смотреть в перспективе. Однако, в стандарте SQL99 есть про такие типы. Alexey Rovdo . А вывод я могу сделать из этого такой - все это еще находится в рудиментарном состоянии и работать с этим неудобно, зато есть чисто объектные системы, в которых инструментарий вылизывался десятки лет и которые строятся на базе стандартов Да состояние еще не очень, хотя стандарту 5 лет (см. выше). Однако боюсь что, и ООСУБД состояние не на много далеко ушло. Тут нельзя путать ООП в универсальном программировании и в модели данных. Это две большие разницы. В программировании данные вторичны, в БД проги вторичны, а данные первичны. Alexey Rovdo Причем языки могут быть очень хороши о подходы великолепны, но как только разработчик видит, что ему прийдется изучать какой-то новый язык - он отворачивается и забывает о существовании этой системы Это же и еще одна трудность для ООСУБД. Недостаток, связанный с недостаточным опытом применения таких БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.12.2004, 17:38 |
|
||
|
|

start [/forum/topic.php?all=1&fid=35&tid=1553970]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
30ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
134ms |
get tp. blocked users: |
1ms |
| others: | 217ms |
| total: | 424ms |

| 0 / 0 |
