Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
|
|||
|---|---|---|---|
|
#18+
Alexey RovdoМожно согласиться с тем, что задачи для ООСУБД имеют четко выраженный нишевый характер, но в своей нише ООСУБД вне конкуренции и агитация за использование Oracle или MS SQL во всех ситуациях является ошибкой и свидетельствует о непрофессионализме тех, кто за это ратует. Нельзя, впрочем, и утверждать, что эта агитация не имеет под собой основания. Универсальные продукты, проигрывая нишевым по технологии, дают другие преимущества. Среди которых наличие большого количества специалистов, снижение издержек за счёт корпоративнх лицензий, сокращение издержек на администрирование, использование распространённых средств разработки и т.д. И с этим нельзя считаться. Я сам занимаюсь нишевой СУБД (реляционной) и эти аргументы являются наиболее распространёнными среди потенциальных клиентов. И с ними нельзя не считаться. Нужно уметь правильно спозиционировать сильные стороны нишевого решения и показать, что затраты по его использованию легко окупаются. А это, кстати, нужно делать, показывая деньги потенциальным клиентам (и, наверное, партнёрам в Вашем случае). Вы же избрали миссионерский подход, что, на мой взгляд является ошибочным. Здешней аудитории это никогда нравиться не будет. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 22:12 |
|
||
|
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
|
|||
|---|---|---|---|
|
#18+
Виталий Гаврилов И если для Вашей конкретной задачи необходимо именно такое индексирование (по строке или по строке и набору других параметров) то никто не мешает вам построить свой класс или набор классов и реализовать в нем тот поиск, который будет для Вас более эффективен. Инструментария БД Вам хватит а объектная субд упростит Вашу работу по созданию этого класса. И не говорите мне что РСУБД сделает это лучше т.к. ВСЕ универсальное работает медленнее специального. Надеюсь с этим утверждением никто спорить не будет? Программы, написанные специалистами, за большие деньги, отлаживаемые десяток лет, работают лучше, чем написанные дидетантами на коленке. С этим утверждением спорить будете ? Это я про "реализовать самостоятельно поиск, который будет более эффективен". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 22:42 |
|
||
|
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
|
|||
|---|---|---|---|
|
#18+
Виталий Гаврилов SergSuperОднако ж запрос на SQL Вы привели, а для объектной СУБД - нет :) Запрос я привел для реляционной СУБД для того чтоб показать сложность задачи. Для объектной это выглядит так: Select * from A Вернет все объекты класса А и потомки классов В и С Причем параметрами запроса можно выбрать только Объекты класса А Select * from B Вернет все объекты класса В Select * from C вернет все объекты класса С Выглядит проще, не так-ли? Выглядит-то он проще, но смысла не имеет. Зачем выбирать ВСЕ объекты класса А ? Так лихо и я могу - "селект все из таблицы А". Вы нам нарисуйте запрос на выборку _одного_ определенного объекта из класса А и всех его потомков. С учетом того, что в классе А может быть десятки и сотни миллионов записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 22:46 |
|
||
|
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
|
|||
|---|---|---|---|
|
#18+
Виталий ГавриловSelect * from A Вернет все объекты класса А и потомки классов В и С Лукавите. Для SQL вы ставили задачу с деревом, т.е. надо бы выбрать еще и подчиненные записи. Т.е. должны быть как-то указаны связи, по которым они подчиняются. Я сомневаюсь что оъектные ООСУБД читают Ваши мысли и ищут по нужным связям. Виталий Гаврилов И если для Вашей конкретной задачи необходимо именно такое индексирование (по строке или по строке и набору других параметров) то никто не мешает вам построить свой класс или набор классов и реализовать в нем тот поиск, который будет для Вас более эффективен. Т.е. вместо того чтоб добавить индекс мне надо реализовывать поиск? Виталий ГавриловSergSuper SergSuper Например надо выбрать объекты в определённом квадрате определённого типа. В зависимости от размера квадрата и типа оптимальный порядок в какой последовательности искать (сначала по координатам, а потом по типу или наоборот) может быть разный. Оптимизатор РСУБД это учтёт (во всяком случае попытается), вы же должны жестко задавать алгоритм поиска (либо сами расписывать варианты). А зачем искать если вся информация Вам доступна по ссылкам? Ну а как еще из миллионов объектов выбрать по нужным мне критериям? Какие могут быть связи если мне надо выбрать, допустим, все города в определённом квадрате? Т.е. связи могут быть но как они помогут? Давайте всё-таки на чем-то конкретном рассмотрим. для начала допустим есть структура: сотрудник, начальник, заплата. У начальника естественно тоже может быть начальник. Надо посчитать общую сумма зарплаты. Продемонстрируйте мне : Виталий ГавриловВ объектной СУБД любая из задач - один запрос безо всяких если. И запрос гораздо более простой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 11:17 |
|
||
|
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
|
|||
|---|---|---|---|
|
#18+
Константин Лисянский Универсальные продукты, проигрывая нишевым по технологии, дают другие преимущества. Среди которых наличие большого количества специалистов, снижение издержек за счёт корпоративнх лицензий, сокращение издержек на администрирование, использование распространённых средств разработки и т.д. И с этим нельзя считаться. В отношении продуктов Versant могу констатировать следующее. О специалистах: Действительно слабый пункт в настоящее время. Специалистов по этим продуктам в России мало. Но они достаточно просты в изучении (особенно FastObjects), опираются на промышленные стандарты (JDO, OQL), и любой ОО-программист может освоить работу с ними очень быстро. Корпоративные лицензии и издержки: Лицензии, разумеется, доступны разные. Ситуация в России с продуктами Versant вообще такова, что затраты на лицензирование у тех, кто их сейчас станет использовать, будут минимальными (возможны большие скидки от публикуемых цен - было бы понятно кому и для чего). Да и сами продукты весьма специфичны и опубликовать полный список возможных вариантов лицензирования затруднительно. К примеру, Versant часто продается в составе других продуктов (таких как Borland Caliber RM, некоторые продукты PeopleSoft, J.D.Edwards и др.), а также в составе промышленного оборудования. Издержки на администрирование: Продукты серии FastObjects ориентированы на встраивание в оборудование, рядом с которым годами может не находиться никаких администраторов, поэтому они при правильном проектировании вообще не требуют никакого администрирования и это отдельно отмечается как одно из важнейших достоинств. Versant VDS чуть более требователен, но и здесь издержки не велики. Средства разработки: FastObjects .NET интегрируется с Visual Studio .NET FastObjects t7 и Open Access JDO предлагают Java-программистам интегрированные средства для всех популярных сред разработки (Borland JBuilder, Sun One Studio, IBM WebSphere App. Dev. и другие среды на платформе eclipse). Для С++ программистов поддерживается куча компиляторов для самых разных платформ. Versant VDS с недавнего времени также поддерживает JDO и также содержит средства интеграции с Visual Studio. А в итоге - сегодня использование ООСУБД и O/R mapping средств Versant не только оправдано с технической точки зрения, но и позволяет получить большой выигрыш в деньгах (за счет сокращения сроков и трудоемкости разработок). Любое универсальное решение эффективно только на самых распространенных типовых задачах, в тех же сферах, где требования выходят за среднестатистические рамки универсальные решения могут стать просто золотыми и при этом низкоэффективными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 12:01 |
|
||
|
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
|
|||
|---|---|---|---|
|
#18+
Alexey Rovdo А в итоге - сегодня использование ООСУБД и O/R mapping средств Versant не только оправдано с технической точки зрения, но и позволяет получить большой выигрыш в деньгах (за счет сокращения сроков и трудоемкости разработок). Любое универсальное решение эффективно только на самых распространенных типовых задачах, в тех же сферах, где требования выходят за среднестатистические рамки универсальные решения могут стать просто золотыми и при этом низкоэффективными. Да не надо нам рекламные ролики гнать! Понятно, где более эффективны объектные/сетевые/иерархические базы данных. Там где не надо проводить сложный анализ больших объемов информации из-за нерегламентированных запросов. То есть все запросы точно известны и ориентированы на скорейшее получение одной мастер-записи, возможно, с "потомками". Тогда и прямые адреса используются эффективно (кстати, в оракле есть такие адреса да еще с проверками ссылочной целостности, чтобы не появились висячие ссылки). Запросы на поиск потомков без участия мастер-объектов по некоторым критериям или полный перебор мастер-записей (объектов по-Вашему) вместе с деталями приведут систему в ступор. Именно для решения таких задач и были созданы реляционные базы, которым все равно, в каком направлении иерархии объектов идет поиск информации. А метод решения поиска по неключевым полям в нереляционных базах тот же, что и в реляционных - добавляем индексы. Иначе - ступор системы. Когда же начинается словоблудие о методах объектов, сразу возникает вопрос - а методы (код) хранится в объектах, или нет? Если в объектах, то разработчики идиоты, если один и тот же код дублируют многократно. Если нет, то есть код отдельно, а данные отдельно, то чем это, кроме внешних интерфейсов вызовов, отличается от реляционных или иерархических/сетевых баз? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 13:04 |
|
||
|
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
|
|||
|---|---|---|---|
|
#18+
AI Если нет, то есть код отдельно, а данные отдельно, то чем это, кроме внешних интерфейсов вызовов, отличается от реляционных или иерархических/сетевых баз? Код отдельно, данные отдельно. При этом код остается ОО, и не содержит ни SQL выражений, ни O/R mapping'а. По-моему это и есть главное преимущество ООСУБД"ов (для девелоперов, точно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 19:33 |
|
||
|
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
|
|||
|---|---|---|---|
|
#18+
Sp1Der AI Если нет, то есть код отдельно, а данные отдельно, то чем это, кроме внешних интерфейсов вызовов, отличается от реляционных или иерархических/сетевых баз? Код отдельно, данные отдельно. При этом код остается ОО, и не содержит ни SQL выражений, ни O/R mapping'а. По-моему это и есть главное преимущество ООСУБД"ов (для девелоперов, точно). Но ведь все равно есть доступ на экземпляр объекта, реализованный не тем кодом, который хранится в методах. Это код самой базы данных, который еще вызывает код методов. Код базы данных никуда не пропадает, а код методов в данном случае второстепенный (интерфейсный). Кстати, SQL запросы тоже выполняет код базы данных, и "ОСУБД навигации" - тоже. Если же код базы отсутствует, то мы имем дело с файл-серверной базой, то есть с архитектурой, признанной давным-давно неэффективной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 13:10 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=32836402&tid=1553979]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
31ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 182ms |
| total: | 304ms |

| 0 / 0 |
