Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 20 21 22 23 24 [25] 26 27 28 29 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

Воспользовался Вашим советом, почитал теорию, действительно помогло ! Истыдно, конечно - морочил людям голову столько времени.
Спасибо за науку.
17 авг 04, 18:04    [888501]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
jvvjvv
Member

Откуда:
Сообщений: 56
Ну и что теперь ?
Я не пойму, после прочтения всей этой битвы, Cache - плохо ?
19 авг 04, 15:26    [894442]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Из всего этого следует что сache это иерархическая БД. Которая имеет свои плюсы и минусы.
19 авг 04, 17:28    [895030]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
jvvjvv

Я не пойму, после прочтения всей этой битвы, Cache - плохо ?

Там была речь пока не про Cache. Про какую-то не известную СУБД. Даже не ООСУБД, но с объектами фиксированныого типа.
20 авг 04, 15:43    [897962]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
гость1234
Guest
Вопрос к уважаемой публике.

Кто нибудь смотрел БД Matisse? (http://www.matisse.com). Из рекламы не понятно что там за внутренности. Говорят что не нужно мэппинга Объект-РМД и всё работает очень быстро.
21 авг 04, 15:09    [899256]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Guest1234567
Guest
Несколько личных соображений, прочитав изрядно длинный тред.

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

Плюсы:
- Очень высокая скорость разработки на CSP (внешний вид конечно не столь красив, как у тяжелых клиентов, но прелести отсутствия версионности перевешивают).
- Очень и очень приличная скорость выполнения (на миллионах записей и сотнях клиентов) на весьма среднем по нынешним временам оборудовании. Может и не сравнить с Ораклом, но, думаю, не хуже.
- Правильно настроенный сервер Каше практически не требует поддержки - опять же из практики - у меня есть инсталляции, которые не выключались месяцами (останавливали машину только для установки заплаток на операционки).
- Мощный и простой язык COS (да, да, это тот, на котором пишут строки, напоминающие непрофессионалу двоичный код :)) - специалист прочтет его без труда, особенно учитывая то, что программу, занимающую в С++ пару страниц, можно написать на нем в одну строчку.
- Очень компактное хранение данных - индексы сжимаются просто изумительно, набор целых чисел (не random, кончно :), допустим, небольшая выборка из 10-100 тыс. значений) хранимых в индексах глобала, при большом количестве записей может ужаться в 2-10 раз по сравнению с битовым представлением.

Минусы:
- Сложна в изучении. Не хочу устраивать флейм, но, имхо, трудно понять идеологию хранения данных в деревьях, поработав с практически любой реляционной БД - это наследие будет сильно портить Вам продуктивность и качество работы в Каше, особенно первое время.
- Совершенно идиотские объекты и не очень быстрый (по сравнению с ф-цией $O) встроенный SQL. Пожалуй, их самое главное и единственное достоинство - возможность очень легкого получения доступа к БД практически через все что угодно, на сегодня. Любые вопросы, связанные с применением кашовых объектов и SQL - не хочу даже обсуждать - это все можно, это сгодится для изучения, но это, в чистом виде, НЕ РАБОТАЕТ в промышленном использовании. Вобщем простой принцип: для изучения - объекты, для извращения - чистые глобалы, для реальной работы - золотая середина, допустим, когда библиотеки дотупа к данным реализуются через объекты, но сами данные хранятся в обычных глобалах.
- Отсутствует обратный поиск по дереву, все реализации, что я видел - иначе как извратом не назовешь. Но это, скорее, не минус, а особенности технологии B-деревьев, на них действительно трудно сделать эту задачу с приемлемым качеством. К этому же пункту относится очень медленное выполнение операций, связанных с косвенностью. Но, опять же, правильно спроектированный глобал в сочетании с $O эту проблему позволяет легко решить.

Пожалуй, вкратце, все.
24 авг 04, 21:22    [905323]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Очень уважаемые люди выразили мне сомнение в правильности прекращения дискуссии. Некоторые даже не увидели иронии в моем "прощальном" сообщении. Должен продолжать...

Guest1234567 !

Вы не совсем правильно оцениваете технологию. Строить, особенно тиражируемые, приложения "на глобалях" нельзя. Это хорошо объяснил Кодд.
MUMPS - это эффективная среда разработки СУБД. FM появилась в США сразу же после создания MUMPS. В СССР поэтические СУБД Михаила Камшицкого появились вскоре после появления ДИАМС. Да и прототип qWord, если не ошибаюсь, работал еще на СМ (PDP-11). Нужно либо использовать Cache Objects, либо сначала написать СУБД. Мы, со своей стороны, всегда готовы делиться опытом. Догадываюсь почему не хотят участвовать в семинарах специалисты по РМД и РСУБД: они полагают, что понимают РМД, и считают, что больше им ничего понимать не нужно. Теперь приглашаю на семинар тех "мампсистов", которые считают, что им еще есть что понимать...

vadiminfo !

Ваша последняя мысль про ключи - это уже просто мистика. Вы говорите, что в отношении СЛУЖАЩИЙ(ИМЯ, ФАМИЛИЯ) кортежи

Николай Петров
Николай Седов
Сергей Петров

уникальны, но у Вас в душе они не уникальны. Пока Вы будете с этой мистикой разбираться, предлагаю всем наблюдателям простой эксперимент. Запустите Access. Производитель называет ее РЕЛЯЦИОННОЙ СУБД. Откройте новую таблицу (отношение ?) и введите две строки (кортежа ?) из двух полей (атрибутов ?):

Николай Петров
Николай Петров

При записи Access порекомендует создать первичный ключ, "чтобы к талице можно было обращаться из других таблиц" (!?). Но нам не нужно "обращаться". Мы просто создаем одно ОТНОШЕНИЕ. И Access записывает в БД оба кортежа. Зачем такая серьезная фирма вводит покупателей в заблуждение, называя табличную СУБД реляционной, я не знаю. Желающие могут проверить являются ли реляционными другие реляционные СУБД...
26 авг 04, 23:35    [912555]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Guest1234567
Guest
Андрей Леонидович

Вы не совсем правильно оцениваете технологию. Строить, особенно тиражируемые, приложения "на глобалях" нельзя. Это хорошо объяснил Кодд.


Может быть Вы правы, особенно учитывая то, что Э.Кодд - автор все-таки реляционной модели БД :), а технологии MUMPS, в свою очередь, вот уже около 30 лет, причем с самого начала пути об этом никто особо и не думал, просто и тупо создавали и внедряли свои системы, в том числе и тиражируемые... :)

Да я же не предлагаю полностью отказываться от объектной модели в той же Каше, она прекрасно работает на небольших и средних задачах, тем более что все объекты хранятся в Каше в тех же самых глобалах, они (объекты) и встроенный SQL - не более чем "юзер-френдли" интерфейс (просто прокладка) к тому же COS, вернее скомпилированному из его промежуточному коду. Просто когда критична именно скорость обработки очень больших объемов данных, то выигрывает принцип "на объектах+SQL - библиотеки доступа и пользовательский интерфейс, на глобалах+COS - хранение данных и их обработка". Да Вы и без меня знаете как в кашовых объектах реализовано допустим, наследование (именно с т.з. технологии деревьев - все экземпляры и родителей и потомков валятся в _один_ глобал) - вобщем "все страньше и страньше" (с)

В небольшое резюме: Интерсистемс - вобщем случайный игрок на рынке MSM, и мне лично жаль отсутствия на нем нормальной конкуренции.
На семинар возможно зайду.
27 авг 04, 14:41    [914542]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
А давайте-ка все-таки отделим мух от котлет и модель данных от ее реализации.

Реляционная модель учит нас избавляться от избыточности. Философски говоря, если мы что-то храним в одном экземпляре а не в десяти, то задача синхронизации этих 10 экземпляров у нас не стоит. И еще она нас учит что наш код не должен оперировать физическими указателями на данные. Это за нас должна делать сама СУБД. И вся любофф-моркофф. Реляционная модель - логическая модель. То есть данные ВЫГЛЯДЯТ как таблицы, но таблицы - виртуальные. Физически данные в реляционной СУБД могут храниться как угодно. Например в листьях B*дерева, как index-organized table в Оракле, или в виде хэш-таблицы, или в виде кластера (это когда данные из нескольких таблиц лежат "вместе" по некому ключу), или в виде "кучи" т.е. традиционной heap-organized table. Если рассмотреть Оракл поподробнее и включить другие реляционные СУБД (например Teradata, Ingres) то этот список можно пополнить еще дюжиной различных способов хранения данных на диске, используемых реляционными СУБД. Реляционная модель - не религия, и не диктует нам как хранить данные на диске. РМ не регулирует физическую реализацию вообще никак.

Прошу мне объяснить, почему данные которые хранятся в листьях B*дерева в Oracle будут медленнее из него выниматься чем данные которые хранятся в листьях B*дерева в Каше? Типа пацаны написавшие Кашу круче пацанов написавших Оракл или как?

Я понимаю как делаются дутые маркетинговые заявления что СУБД Х блатнее чем СУБД У. Например берется стандартная установка Оракла, с параметрами рассчитанными на дэсктоп (мало кэша, очень мало), потом все данные бездумно сваливаются в обычные heap-organized tables без индексов. И делается многозначительное заявление что Оракл сосет. Так можно "закопать" абсолютно любую СУБД. Я понимаю зачем это делается - сотрудникам отдела маркетинга кушать хочется, как и всем остальным. Поэтому их и называют "маркетроидами". Нам, техническим специалистам, не пристало заниматься такой граничащей с обманом ерундой.
27 авг 04, 21:36    [915690]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 Guest1234567
Вроде хоть один реально работающий на кэше человек нашелся. Дык всё-таки умеет он работать с данными или мне чуть что надо циклы писать? В чем высокая скорость разработки на CSP ?
И вообще что такое COS и что такое CSP?
28 авг 04, 02:18    [915876]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Андрей Леонидович

Очень уважаемые люди выразили мне сомнение в правильности прекращения дискуссии. Некоторые даже не увидели иронии в моем "прощальном" сообщении. Должен продолжать...

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

Ваша последняя мысль про ключи - это уже просто мистика. Вы говорите, что в отношении СЛУЖАЩИЙ(ИМЯ, ФАМИЛИЯ) кортежи

Николай Петров
Николай Седов
Сергей Петров

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

Вы меня удивляете. Кортежи то уникальны, но в значениях ИМЯ и ФАМИЛИЯ есть дубликаты. Если проектировщик считает, что значения любого из этих полей должны быть уникальны, т.е. это поле ключевое, то кортежи, которые Вы привели противоречат этому правилу (нарушена целостность отношения). Проектировщик может объявить поле ИМЯ ключевым и тогда в отношении может быть только один из двух: либо Николай Петров, либо Николай Седов.
Так что уникальность кортежей не отменяет понятия ключа как Вы пытались это представить. Это следствие элементарных знаний теории множеств. Вы так можете пытаться доказывать, что дважды два не равно четырем.
Андрей Леонидович

Запустите Access. Производитель называет ее РЕЛЯЦИОННОЙ СУБД. Откройте новую таблицу (отношение ?) и введите две строки (кортежа ?) из двух полей (атрибутов ?):

Николай Петров
Николай Петров

При записи Access порекомендует создать первичный ключ, "чтобы к талице можно было обращаться из других таблиц" (!?). Но нам не нужно "обращаться". Мы просто создаем одно ОТНОШЕНИЕ. И Access записывает в БД оба кортежа. Зачем такая серьезная фирма вводит покупателей в заблуждение, называя табличную СУБД реляционной, я не знаю. Желающие могут проверить являются ли реляционными другие реляционные СУБД...


Фирма не вводит в заблуждение, это Ваши представления о РМД слишком наивны. Я Вам писал, что в расширенной РМД используются мультимножества - дубликаты допустимы. Это тем более еще больше подчеркивает роль ключей, например, для навязывания схеме функциональных зависимостей существующих в предметной области.
Вы опять пытаетесь подбросить Ваши представления о том, что есть РМД. Но почему Вы думаете, что Ваши представления более предпочтительны, чем то что написано в литературе пока не известно. Это не серьезно. Прочтите еще что-нибудь кроме введений для начинающих.
28 авг 04, 16:02    [916127]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Guest1234567
Guest
Зл0й
А давайте-ка все-таки отделим мух от котлет и модель данных от ее реализации.

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

Зл0й
Реляционная модель - логическая модель. То есть данные ВЫГЛЯДЯТ как таблицы, но таблицы - виртуальные. Физически данные в реляционной СУБД могут храниться как угодно.

Да и безусловно, - Оракл - искренне, уважаю (была небольшая личная практика, но так, ничего серьезного - не знаю по настоящему) но, имхо, учитывая рыночную стоимость его решений, - видимо рулез наверное, без дураков. Вы - правы на счет религии храненения/доступа к данным на носителе (не по Ораклу даже, а в здавом смысле) - это не суть как критично-лишь бы хорошо работало (причем, на самом деле это и есть уже, на сегодняшний день - старые технологиии, окученные абсолютно уже, людьми, не нам чета :() И в дополнение - у одной известной питерской конторы была пару лет назад системка на Оракле, где один, особено мерзкий, отчет формировался ~2 часа 40 мин. Мы их перевели на кашку, эта же задача решалась масимум за 90 сек. Это не критика Оракла, и уж, тем более, не восхваление Каше (Интерсистемс и ее пилотный продукт - искренне не люблю по очень многим причинам), просто из практики.

Зл0й
Типа пацаны написавшие Кашу круче пацанов написавших Оракл или как?...
...Я понимаю как делаются дутые маркетинговые заявления что СУБД Х блатнее чем СУБД У

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

SergSuper
2 Guest1234567
Вроде хоть один реально работающий на кэше человек нашелся. Дык всё-таки умеет он работать с данными или мне чуть что надо циклы писать? В чем высокая скорость разработки на CSP ?
И вообще что такое COS и что такое CSP?

1. Да, умеет, причет очень и очень здОрово.
2. Циклы - а куда ж без них. :). Причем часто, и внеше сложные :), зато очень быстрые...
3. CSP, aka Cache Server Pages, - это всего лишь технология, позволяющая хранить _все_ данные, настройки, защиты, GUI, вообщем - Фсе, на сервере. Технически - очень просто - Вы запускаете обычный веб-сервер (IIS или Апач) на любой, удобной Вам платформе, кладете на него почти обычные html файлы со жаба-like скриптами, но с расширением *.csp, и через обычный, всем давно понятный веб-интерфейс получаете _полный_ доступ к Вашей БД. Не буду перечислять плюсы - долго и нудно, приведу всего лишь один пример - если у Вас 1000 клиенских машин, разнесенных по 10 территориално изолированным подразделениям - сколько времени Вы затратите на обновление _любого_ "толстого" клиента? А веб-браузер есть, на сегодня, на _любом_ компе. (Вобщем - нечто похожее на связку apache+php+MySQL, только пригодное для промышленных реализаций).
4. COS - aka Cache Object Script - родной язык программирования в каше, микронетиковских реализациях MUMPS, GT.M и т.п., но, по сути, это просто ЯП, ничуть не отличающийся от С++, SQL или Жабы, пусть безумный и сложный на первый взгляд, но очень логичный, и, самое главное - _очень_ простой и быстрый ("быстрота" это, конечно, не его заслуга, а всего лишь техническая реализация технологии доступа к данным, хранимых в деревьях) - огромное к-во микрозадач на нем реализуются всего лишь одним оператором, в отличие от весьма сложных и, зачастую неоднозначных конструкций на др. ЯП (в т.ч. "классическом" SQL). Есть конечно "методы объектов", "SQL запросы" ии и др. "basic-like" альтернативы (только в каше) - но все равно любая программа сведется, в итоге, в промежуточный исполняемый код, и, имхо, эта разница зачастую бывает критична по скорости выполнения.

2All
Все вышесказанное - отнюдь не повод к религиозной войне, просто личное мнение. Я отключаюсь от форума, извините, устал.
28 авг 04, 23:26    [916320]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Guest1234567
1. Да, умеет, причет очень и очень здОрово.
2. Циклы - а куда ж без них. :). Причем часто, и внеше сложные :), зато очень быстрые...


1. Судя по 2-му пункту всё-таки не умеет.
2. А вот попробуйте это сделать циклами. Кстати интересно как это будет выглядеть и скоко по времени займёт.
29 авг 04, 01:05    [916350]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

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

К.Дейт. Введение в системы баз данных. Седьмое издание. Стр. 513:

Здесь читатель, уже знакомый с основами реляционной модели, мог бы заметить, что именно тип связи "многие ко многим" является единственным типом, представляющим истинную связь, поскольку это единственный тип связи, который требует для своего представления создания отдельной переменной-отношения. Связи типа "один к одному" и "один ко многим" всегда могут быть представлены с помощью механизма внешнего ключа, помещаемого в одну из переменных-отношений, участвующих в данной связи. Однако существуют веские причины рассмотрения связей типа "один к одному" и "один ко многим" таким же образом, как и связи "многие ко многим" [то есть с помощью отдельного отношения - А.Л.], по крайней мере из-за того [но не только из-за этого !? - А.Л.], что достаточно часто существует возможность их эволюционирования до связи типа "многие ко многим"...

А вот в сжатом виде мой план формализации РМД.

1. В отношениях DEPT(DEPT#,DNAME,BUDGET) и EMP(EMP#,ENAME,DEPT#,SALARY) внешний ключ DEPT# в отношении EMP и первичный ключ DEPT# в отношении DEPT представляют связь "Работает в" между Служащим и Отделом.

2. Если служащий может работать в нескольких отделах, то нужно создать еще одно отношение. И в этом случае именно оно и будет представлять связь "Работает в" между Служащим и Отделом. А внешние ключи этого отношения и соответствующие первичные ключи отношений EMP и DEPT уже не будут представлять какую-либо связь.

3. Проблема РМД заключается вовсе не в "перегрузке" отношения, заключающейся в том что отношения представляют и сущности и связи между сущностями. Это, как раз, выглядит вполне реляционно и, как сказал бы U-gene, даталогично. Проблема заключается в "перегрузке" ключей. Поэтому я говорю, что с ключами в РМД просто беда, а заодно в "подвешенном" состоянии оказывается и понятие "кортеж".

4. Однако "перегрузка" ключей разрешима. Для этого вместо материалистической гипотезы "мир состоит из объектов и связей между ними" я предложил идеалистическую ("математическую") гипотезу "мир состоит только из объектов".

5. В примере "доска висит на стене" (он получился сам собой, поскольку, выступая на семинаре, я стоял у доски, висящей на стене) мы имеем три объекта:

доска
стена
висение (доски на стене)

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

6. Для реализации такой, наконец-то формализованной, РМД достаточно выполнить одно ограничение:

отношение не может содержать ОДИН внешний ключ

Количество внешних ключей в отношении может быть либо 0 (простой объект), либо > 1 (составной объект).

Конечно, я доволен, что мне удалось формализовать РМД. Но никакого самостоятельного значения эта модель не имеет. Зачем, получив материалистическую модель предметной области, "перекомпилировать" ее в идеалистическую модель ? Понятно зачем - чтобы применить алгебру.
Фундаментальные недостатки РМД - отсутствие идентификации, навигации и ориентация на идеалистическую гипотезу "мир состоит только из объектов" - делают ее практически бесполезной и нереализуемой. Именно поэтому в природе не существует РСУБД, а, следовательно, и ОРСУБД.
29 авг 04, 23:47    [916713]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

Кортежи в отношении уникальны по определению. Без всяких ключей.
Если это условие не выполняется, то нужно ДОБАВИТЬ еще один атрибут, например, Отчество. Опять не выполняется ? Добавим еще один атрибут и т.д. Что Вы говорите ? Это не удобно ? А ДЛЯ ЧЕГО не удобно ? ЧТО будет удобнее, если будет (простой) первичный ключ ?
30 авг 04, 00:06    [916719]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Guest1234567 !

Я же Вам сообщил, что "об этом" ВСЕГДА ДУМАЛИ, с самого начала ! А Вы говорите "тупо создавали" ???
30 авг 04, 00:11    [916720]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Про питерских товарищей у которых запрос выполнялся 2 ч. с минутами приведу известный случай с В. Маяковским. Один особо наглый крендель "предъявил" Маяковскому такую претензию: "Вот мы с товарищем читали ваши стихи, и ничего не поняли". "Надо иметь умных товарищей" - ответил Маяковский. У меня в Oracle лежат терабайты данных. Двухчасовых запросов нет. Уверяю вас, что если взять запрос занимавший 2 с лишним часа, и как следует его (и базу если надо) потюнить, то время его выполнения будет <= такового для Каши. В бытность мою консультантом я такие "проблемы производительности" решал, за 120 долларов в час. Все что требуется - проанализаровать данные и запросы. "Малой кровью" - это или заставить статистику собирать или хинт добавить. Чуть посложнее - или сменить тип таблицы с кондовой heap на index-organized, применить partitioning, colocation, compression или добавить какой-нибудь нетривиальный function-based индекс. Все это (кроме хинта) делается даже не трогая код приложения. Бывают случаи когда "все запущено" - бестолково спроектирована БД. Тогда требуется менять логическую (ER) модель и трогать код приложения. Все это ошибки проектирования и разработки, к инструменту (Oracle, DB2, Sybase, MSSQL, ...) не имеющие отношения.
30 авг 04, 07:25    [916773]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Андрей Леонидович
Очень уважаемые люди выразили мне сомнение в правильности прекращения дискуссии. Некоторые даже не увидели иронии в моем "прощальном" сообщении. Должен продолжать...

Где можно узнать о семинарах, их расписании и тематике?
30 авг 04, 11:59    [917479]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 Андрей Леонидович
То что в РМД отношения служат и для связей и для сущностей - недостаток, который мы обсуждали раньше. К ключам отношения не имеет. И Ваша формалицация не может представлять интереса пока не будет общепризнанной. Вам ее следует защитить не на этом форуме. А так это все выглядит по детски.
Ваши доводы про бесполезность РМД Вы просто повторяете, но из предущих обсуждений пока видно, что сами эти доводы бесплозны - несостоятельны.
А раз у Вас навигация, то у Вас есть иерахическое в Ваше ОИМД. Иерархические проиграли РМД. Что же Вы хотите? Обмануть нас? РМД лучше, но Вы хотите ввести нас в заблуждение ценой сомнительных приемов пропаганды?

>Кортежи в отношении уникальны по определению. Без всяких ключей.
Если это условие не выполняется, то нужно ДОБАВИТЬ еще один атрибут, например, Отчество. Опять не выполняется ? Добавим еще один атрибут и т.д. Что Вы говорите ? Это не удобно ? А ДЛЯ ЧЕГО не удобно ? ЧТО будет удобнее, если будет (простой) первичный ключ ?

Я не понимаю. Вы не читаете, что я Вам пишу или специально искажаете мои слова? Я не говорил про неудобство, а Вы мне это приписали - это не красивый прием. Я говорил, что нужна уникальность по отдельным атрибутам или группе атрибутов как таковая. Уникальность кортежа это не обеспечивает - см математику. Убавьте атрибут в тех примерах, что были. Надо, чтобы Николай не повторялся, а он у Вас повторяется, не смотря на уникальность кортежа. Кроме того, в расширенной РМД и уникальность кортежа не обязательна. Повторяю раз уже третий. Мы с Вами обсуждаем вещи для начинающих - ликбез. Это бессмысленно.
30 авг 04, 13:05    [917781]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

1. Мы вынуждены обсуждать вещи для начинающих до тех пор пока Вы их не поймете. Только тогда можно будет перейти к более сложным вещам. Зачем же мне Вас обманывать. Я Вам помочь хочу, даже если это выглядит по детски.

2. Чтобы моя формализация была "общепризнанной", нужно, для начала, признание хотя бы одного человека. Где Вы нашли ошибку (или детский лепет) в следующих один за другим 6-ти пунктах ?
Ах это вопросы не для форума ? Я же Вам сказал это в САМОМ НАЧАЛЕ.

3. Я читаю что Вы пишете. Поэтому и спрашиваю: зачем нужна уникальность "ПО ОТДЕЛЬНЫМ АТРИБУТАМ КАК ТАКОВАЯ" ? Ведь кортежи в отношении уникальны по определению. Без всяких ключей.
30 авг 04, 16:01    [918762]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
ну я !

Я с удовольствием проведу семинар по Вашему заказу. Здесь речь шла о моделях данных. Можно провести именно такой семинар, с углубленным изучением нашей ОМД и СУБД. Назначайте время ПОСЛЕ 20 сентября. У нас даже платное обучение по технологиям Intersystems проводится по индивидуальным заявкам.
30 авг 04, 16:13    [918833]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 Андрей Леонидович

>Мы вынуждены обсуждать вещи для начинающих до тех пор пока Вы их не поймете. Только тогда можно будет перейти к более сложным вещам. Зачем же мне Вас обманывать. Я Вам помочь хочу, даже если это выглядит по детски.
Я уже говорил, что согласно стандартам Мин Образования у меня 5 по данному предмету, и от того объем знаний для начинающих меня не интересует в принципе. Когда Вы будете профессором, который принимает у меня экзамены, тогда я выслушаю Ваши мысли о том, чего я не понимаю. А до этого времени - это не технический прием доказательств. Равно как я сомневаюсь, что Вы вообще разбираетесь хоть сколько нибудь в математике. Иначе бы Вы не могли написать такие мысли про ключи и кортежи.

>Чтобы моя формализация была "общепризнанной", нужно, для начала, признание хотя бы одного человека. Где Вы нашли ошибку (или детский лепет) в следующих один за другим 6-ти пунктах ?
Ах это вопросы не для форума ? Я же Вам сказал это в САМОМ НАЧАЛЕ.

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

>Я читаю что Вы пишете. Поэтому и спрашиваю: зачем нужна
уникальность "ПО ОТДЕЛЬНЫМ АТРИБУТАМ КАК ТАКОВАЯ" ? Ведь кортежи в отношении уникальны по определению. Без всяких ключей.

Где же я писал про неудобства? Я и советовал Вам прочитать теорию, чтобы знать зачем нужна уникальность "ПО ОТДЕЛЬНЫМ АТРИБУТАМ КАК ТАКОВАЯ".
И уникальность кортежей ничего не меняет. Прочтите, что писал. Например, нужно, чтобы в отношении не было двух Николаев из того примера. Что тут еще можно сказать? И Вы мне еще про понимание что-то говорите. Я уже в какой раз пытаюсь объяснить Вам эти элементарнейшие вещи.
30 авг 04, 16:31    [918923]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

1. Где Вы нашли ошибку (или детский лепет) в следующих один за другим 6-ти пунктах ?
2. Зачем нужна уникальность "по отдельным атрибутам как таковая" ? Ведь кортежи в отношении уникальны по определению. Без всяких ключей.

Обсудите это с Вашими профессорами. Им наверняка будет приятно, что выпускники о них помнят.
30 авг 04, 18:10    [919476]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Андрей Леонидович
Вот Вы наверняка работаете где-то и получаете зарплату. И наверняка у Вас, как и у остальных работников, есть табельный номер.
Зачем? Ведь все люди уникальны

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

Вас такие вопросы не мучают?
31 авг 04, 01:29    [919886]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 Андрей Леонидович

>1. Где Вы нашли ошибку (или детский лепет) в следующих один за другим 6-ти пунктах ?


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

>Зачем нужна уникальность "по отдельным атрибутам как таковая" ? Ведь кортежи в отношении уникальны по определению. Без всяких ключей.

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

Т.е. отношение

Николай Петров
Николай Седов
Сергей Петров

Не допустимо.

Допустимо либо

Николай Петров
Сергей Петров

либо

Николай Седов
Сергей Петров

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

Обявляется поле Имя ключевым, и пользователь не сможет ввести имя Николай дважды.


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


>Обсудите это с Вашими профессорами. Им наверняка будет приятно, что выпускники о них помнят.

Такие вещи профессора обсуждают на первой, от силы на третьей лекции курса по данному предмету. Боюсь, что два бала Вам было бы обеспечено без права перездачи. РМД Вам плохо дается - это явно не Ваше крэдо.

Меня поражает с какой легкостью Вы допускаете, что те кто придумали ключи были так глупы, что не догадались бы до тех простоватых мыслей, что Вы высказываете, если бы в этих мыслях было бы хоть что-то стоящее. Почему Вы не пытаетесь опровергать мат анализ или теорию групп рассуждениями о "висение (доски на стене)" в качестве формализации?
31 авг 04, 01:31    [919887]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 20 21 22 23 24 [25] 26 27 28 29 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить