Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
to Garya
По поводу объектов: в Cache можно создавать объекты на
встроенном языке и сохранять (индексировать) их в базе.
Можно напрямую обращаться к объектам Cache из C++,Delphi...
По поводу измерений: в Вашем случае не измерения, а поля,
а таблица двухмерная: 1 - номер записи (Индекс1, Индекс 2...),
2 - номер записи ID. В Cache все по другому, но лучше это прочувствовать
попробовав или почитав на их сайте...
20 май 03, 19:13    [204411]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
Дополнение. В тех статьях, которые я сейчас усиленно читаю по Cache, меня сильно насторожило повсеместное получение объектов по ObjectID. Подразумевается, что клиенту известен этот самый ObjectID. Но ведь на практике объект приходится ИСКАТЬ по некоторой совокупности признаков, и зачастую это не один объект, а некоторое их множество. В тех примерах, где задействован поиск, в основном идет "прямая выборка по измерениям" (аналогичный примеру выше с select). Но ведь искать объекты требуется не только по равенству измерений некоторым значениям, но и по условиям >, <, <=, like и т.д. и т.п. Как эта задача решается в Cache?
ЗЫ. Пока в Cache я полный чайник, поэтому прошу сильно не пинать.
20 май 03, 19:15    [204414]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
2 Maksim UM. Пока я набивал дополнение, уже поступил ответ на предыдущий вопрос - приятная оперативность :).

> Можно напрямую обращаться к объектам Cache из C++,Delphi...

Если подразумевается использование библиотеки CacheObject, то там всего два класса - Factory и ResultSet. К ним действительно можно обращаться напрямую. А вот к объектам СУБД приходится обращаться ЧЕРЕЗ ИНТЕРФЕЙС, предоставляемый этими объектами. Не вижу принципиальной разницы, например, с обращением к объектам MS SQL через интерфейс ODBC или ADO.
Вы ведь не будете утверждать, что я смогу унаследовать класс в клиентской части от класса, объявленного в базе данных Cache?

> По поводу измерений: в Вашем случае не измерения, а поля,
а таблица двухмерная: 1 - номер записи (Индекс1, Индекс 2...),
2 - номер записи ID.

Если бы информация в MS SQL Server выбиралась бы действительно по двум измерениям, то я смог бы сделать запрос вроде "выдай мне значение столбца № 5 в строке № 123". Но в MS SQL я не могу сделать такой запрос!!! Обращение к информации по номеру строки невозможно в принципе! Информацию можно получить только задав условие выборки кортежей по значениям некоторых полей (которые в этой ситуации можно рассматривать как измерения). Измерения, поля - ИМХО, это вопрос человеческой интерпретации, не более. Кстати, Вы не ответили на вопрос о возможности поиска в Cache измерения по значению и производительности этой операции.

> В Cache все по другому, но лучше это прочувствовать
попробовав или почитав на их сайте...

Возможно, я пока не прочувствовал идеологию Cache. Но я стараюсь. Поэтому и задаю вопросы, не воспринимайте их как нападки. В данный момент изучаю материалы на сайте InterSystems.
20 май 03, 19:38    [204436]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД  [new]
c127
Guest
2 Maksim UM

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

Общие соображения.
SQL и RDBMS так долго и успешно держатся именно потому, что имеют под собой твердую математическую почву. Намомню на всякий случай, теория RDBMS изначально была записана как система аксиом, т.е. в лучших традициях. У ООП-а вообще и у Объектных ДБ в частности такой почвы пока нет, поэтому там царит такой бардак. Без аксиоматики невозможно обеспечить надежности. По-моему все критичные в смысле надежности системы имеют непосредственную математическую основу. Хороший пример - системы шифрования сигналов.

И пока не будет записана соответствующая аксиоматика соваться с ООП технологией в хранилища данных ИМХО несерьезно.
21 май 03, 01:23    [204563]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
Я все-таки решил разобраться в этом вопросе досконально. В том числе со стороны теоретической части. Для этого специально взял книжку Джена Харрингтона "Проектирование объектно-ориентированных баз данных". Читать только начал, но уже в первом абзаце введения наткнулся на такую фразу "...объектно-ориентированную модель можно считать не только шагом вперед, но и шагом назад".
21 май 03, 09:16    [204637]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
to c127
Уффф... хорошо, начнем по порядку с самого простого - DBF файлик.
В этом файлике есть определенная структура - жестко заданные
(по размеру и типу) поля. Далее в фалик можно добавлять новые записи
(последовательно). И того имеем "квадратик"! Книги - это хорошо.
Только читать нужно вдумчиво.
Пример: в DBF есть поля Поле1, Поле2, Поле3...
Ниже (образно говоря) Поля1 имеем все значения...
Ну что, не видно пока измерений?! Или мне еще картинки рисовать нужно...

Теперь по делу. 2 Garya
>Вы ведь не будете утверждать, что я смогу унаследовать класс в клиентской >части от класса, объявленного в базе данных Cache?
Буду... Можно было бы опять порекомендовать почитать умные книжки по
COM/OLE/ActiveX... Скажу, в краце, с помощью Factory в можно использовать
любой созданный класс из Cache.

>Кстати, Вы не ответили на вопрос о возможности поиска в Cache измерения >по значению и производительности этой операции.
На такие вопросы сложно отвечать, тк есть разные варианты:
можно написать query для поиска (со всеми =,<>, like...),
можно написать процедуру на встроенном языке...

Дело в том, что изначально в M системах SQL и не пахло, и все запросы писались ручками на языке M (скажу сразу писалось легко, просто и быстро).
Но в Cache добавили классы и на них легко ложится SQL.
PS Если есть возможность, я бы рекомендовал почитать книжку по Cache.
К сожалению, единственная которую я знаю, уже устарела. Но для
знакомства вполне достаточно.
21 май 03, 11:53    [204958]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД  [new]
c127
Guest
2 Maksim UM

>Уффф... хорошо, начнем по порядку с самого простого - DBF файлик.

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

Рекомендую все-таки на досуге обратиться к первоисточникам. Это как раз и будет по-порядку. В первоисточниках ты прочитаешь, что таблица есть отношение (подмножество) на прямом произведении доменов. А то, что оно иногда реализовано в виде чего-то напоминающего плоскую екселевскую таблицу, ничего не значит. Тот же DBF файл есть последовательность байт на диске или в памяти. Следуя твоей логике нужно заявить, что реляционная таблица одномерна. Более того, по той же логике Cache тоже одномерен, поскольку тоже хранит данные в файлах, а обрабатывает в одномерной памяти.
22 май 03, 00:52    [205973]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
>Мне даже как-то возражать неловко, но попробую. Но если ты RDBMS учил
>по DBF файликам, то я со всеми твоими утверждениями заранее согласен и ?
>не возражаю.

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

>Рекомендую все-таки на досуге обратиться к первоисточникам. Это как раз
>и будет по-порядку. В первоисточниках ты прочитаешь, что таблица есть
>отношение (подмножество) на прямом произведении доменов. А то, что оно
>иногда реализовано в виде чего-то напоминающего плоскую екселевскую
>таблицу, ничего не значит. Тот же DBF файл есть последовательность байт >на диске или в памяти. Следуя твоей логике нужно заявить, что реляционная
>таблица одномерна. Более того, по той же логике Cache тоже одномерен,
>поскольку тоже хранит данные в файлах, а обрабатывает в одномерной
>амяти.

Вы опять путате логическую структуру и физический способ хранения!
Реляционная модель данных не допускает естественного представления данных со сложной (иерархической) структурой, поскольку в ее рамках возможно моделирование лишь с помощью плоских отношений (таблиц). Все отношения принадлежат одному уровню, многие значимые связи между данными либо теряются, либо их поддержку приходится осуществлять в рамках конкретной прикладной программы.
Заметили слово "плоских"? В Cache логическое хранение изначально иерархическое.
22 май 03, 01:17    [205979]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
чингиз
Member [заблокирован]

Откуда: unknown
Сообщений: 1848
Если Вы не заметили, я привел DBF в качесте примера, как ниболее простой
пример реляционной базы данных..
------------

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

до гордого звания реляционной базы с трудом оракл и db2 дотягивают.

а слово "плоских таблиц" является художественной гиперболой и несет столько
же смысла сколько абракадабра например.
просто множество(отношение) не является плоским. это слово неприменимо.
его нет в теории множеств кантора.
более того, если в таблице 3 колонки, то такое отношение можно интерпертировать как
подмножество 3-хмерного пространства.
если 4 колонки - то как подмножество 4-х мерного пространства.
то есть с 4 -мя измерениями.
и в такой интерпретации есть математический смысл. а не художественные
высказывания.
22 май 03, 02:27    [205983]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД  [new]
c127
Guest
2 Maksim UM

>Если Вы не заметили, я привел DBF в качесте примера, как ниболее простой пример реляционной базы данных...

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

>Вы опять путате логическую структуру и физический способ хранения!

Когда это я их успел перепутать в первый раз? Дай ссылочку пожалуйста.

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

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

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

>Заметили слово "плоских"? В Cache логическое хранение изначально иерархическое.

"Плоские" мы уже обсудили, а насчет иерархических я тебя немного разочарую. Иерархическое хранение (точнее - иерархическиая модель данных, иерархические БД) появилось в середине-конце 60-х быстро было признано ограниченным. Сейчас используется в небольшом числе случаев (например LDAP). Модель очень легко реализуется в РДБМС (пример реализация MS LDAP-а на базе MSSQL сервера), При этом конечно в некоторых случаях теряется производительность.

Это не наезд на Cache. Я примерно представляю себе достоинства т.н. ООДБ. Удобная штука, правда не совсем понятно, что же это такое и как с ним бороться. А пока не понятно, хранить важные данные в них лучше не нужно. Это мое основное возражение.
22 май 03, 03:43    [205993]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32174
Всё-таки странно слышать про реляционные БД слово "плоская", "двухмерная".
Это про ексель можно сказать "двухмерная таблица".

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

Из этого следуют недостатки и преимущества реляционной БД по сравнению с Cache, в котором эти измерения определяются жёстко при проектировании.
Cache демонстрирует высокую производительность при использовании жёстко определённых измерений, а реляционная БД показывает ровную производительность (пусть меньшую, чем пиковая у Cache) во всех случаях.

И далее из этого всего следует понимание, почему-же используют именно реляционной БД, а не что-то другое:

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

Реляционная БД - это как раз основанное на математической модели хранилище данных. Заметьте, я говорю - Реляционная БД, а не СУБД.

Любая компания, выбравшая эту модель, уверена, что её данные будут всегда. В конце концов, переход с оракла на mssql или с mssql на db2 не так сложен - нужно всего-лишь переписать код. И не смейтесь! Это проще, чем менять общий подход к системе.

А представьте, что компания выбрала Cache или какую-то ООБД? БД, реализованная на Cache - это не БД, а программа. Представьте, что Cache кончился - и что делать? Тут придётся не просто переписать формочки на клиенте (которые и так переписываются раз в 3-5 лет), тут придётся менять всё! Сложно перенести приложение с Cache на mssql? Или с db2 на Cache? Очень.

Вот так. Т.о. Cache - неплохая система. Так-же как и ексель, и масса других программ. Но это не БД, это программа. Что лучьше - WinZip или PhotoShop? MSWord или MatchLab? Сравнивать Cache с РСУБД - нельзя, это несравнимые вещи.
22 май 03, 10:18    [206176]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
>"Плоские" мы уже обсудили, а насчет иерархических я тебя немного
>разочарую. Иерархическое хранение (точнее - иерархическиая модель
>данных, иерархические БД) появилось в середине-конце 60-х быстро было >признано ограниченным. Сейчас используется в небольшом числе случаев
>(например LDAP). Модель очень легко реализуется в РДБМС (пример
>реализация MS LDAP-а на базе MSSQL сервера), При этом конечно в
>некоторых случаях теряется производительность.

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

>Это не наезд на Cache. Я примерно представляю себе достоинства т.н. ООДБ.
>Удобная штука, правда не совсем понятно, что же это такое и как с ним
>бороться. А пока не понятно, хранить важные данные в них лучше не нужно.
>Это мое основное возражение

Похоже, что не представляете. В Cache можно спокойно работать без
объектов. И если Вам непонятно (и не пытаетесь понять), то зачем обсуждать?
22 май 03, 10:30    [206203]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Втыкаясь в вашу высокоидейную дискуссию, замечу что давеча имел точно такую-же. Я естественно на строне с127, поскольку считаю что реляционная модель - единственная РЕАЛЬНАЯ модель хранения данных.

Дело в том, что она подразумевает, что существенны только явно заданные ЗНАЧЕНИЯ. Никаких индексированных массивов, никаких указателей, адресов и чего-либо, что могло бы хоть как то привести к мысли о существенности ПЕРЕМЕНОЙ и тем более положения этой переменной относительно других перменных.

Наконец. ИМХО глубочайшай ошибка утвердать, что реляционная модель каким-то образом должна служить для описания или представления предметной области. Она описывает данные - и все. У меня был по этому поводу на другом форуме жестокий спор, где, как мне кажется, я достаточно веско эту точку зрения обосновываю. Если вас не заломает все это прочитать, то надеюсь станет ясно, о чем я.
22 май 03, 10:37    [206219]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
2 U-gene

>Втыкаясь в вашу высокоидейную дискуссию, замечу что давеча имел точно
>такую-же. Я естественно на строне с127, поскольку считаю что реляционная
>модель - единственная РЕАЛЬНАЯ модель хранения данных.
Меня настораживает уже одно только замечание "единственная РЕАЛЬНАЯ".

Да, я прочитал Вашу дискуссию.
Вы как-то забываете, что все существующие реляционные базы данных
не обходятся без использования индексов (но это к слову).
Еще раз хочу заметить, что в Cache можно работать и без использования
объектов. В базах такого рода (MUMPS системы) логическая структура глобалов (таблиц) иерархическая (древовидная). И на эту структуру
легко ложаться объекты.
Сами MUMPS системы появились еще в 70х годах и работали, обслуживая
1000 пользователей. Это к слову о практике.

PS я надеюсь, что вы не будете отрицать, что реляционные таблицы
двухмерны?
22 май 03, 11:17    [206306]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
alex_k
Member

Откуда: krasnoyarsk
Сообщений: 6694
Таблички двухмерные, базару нет. Но описывать могут объекты с множеством свойств. В том числе и многомерные координаты объекта. Это все условности.
Я вот не могу понять из ваших дискуссий и из статей что уже прочитал, что такого дает эта CASH? может это революция в базостроении да мы этого не понимаем(динозавры). Если она может делать все тоже что и реляционная база, то и бох с ней, теже яйца только в профиль. Пользуйтесь по вкусу. Если меньше то забыть про нее как про неудачную ветвь эволюции, если больше то перестраиватся и развивать это отрасль.
22 май 03, 11:25    [206324]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
2 alex_k
>Таблички двухмерные, базару нет.
А меня чуть не убедили, что это не так :)

>Но описывать могут объекты с множеством свойств. В том числе и
>многомерные координаты объекта. Это все условности.
Согласен. Но... согласитесь, что на древовидную структуру такие данные
ложаться безо всяких украшений, легко. В этом и есть прелесть Cache
(говоря Cache я подразумеваю и другие MUMPS системы).
Еще раз, в Cache древовидная логическая структура глобалов
(это сложно прочувствовать не попробовав), на эту структуру сверху
ложится объектная обертка.
22 май 03, 11:34    [206349]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
2U-gene

Это почему это реляционная модель не для описания (отражения) предметной области? А для чего? Шоб диссертации писать? Как раз иерархические БД непопулярны стали из-за того что в них труднее отразить эту самую область предметную. И все разговоры про объектные БД именно из-за того что кто-то думает что может сделать более удобную фишку чем реляционная модель. Тока не получается почему-то. Мне лично пофиг, но такова реальность.
22 май 03, 12:08    [206419]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
DimaR
Member

Откуда:
Сообщений: 1570
Я вот в свое время увлекся языком программирования FORTH,
супер, идея неограниченной расширяемости и мутируимости языка, при предельно простой идеологии и синтаксисе, компактность программ, очень быстрая интерпретация шитого кода (под 8086 в некоторых случаех работает быстрее чем скомпилированый!!!), никакие Java или C# раядом не стояли.
Вобщем просто СУПЕР.

Только вот где он сейчас?
22 май 03, 12:26    [206473]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
To 1024

Ааааа! Сам то хочешь. что бы твою систему вместе с приблудами попробовали, а самому даже по ссылке внимательно прочитать лень!

Ты прочитай внимательно - я говорю, что реляционная модель тем и сильна, что она является абсолютно абстрактным построением! Я вот (только не брызгай слюной) читая твой хелп увидил, что твои формы содержать записи из разных таблиц. Но ты представь себе , что данные так ОПИСАНЫ - объект данных как совокупность записей разных таблиц. И ты с этим объектом работаешь на языке высокого уровня, и обращаешся к этим записям как к атрибутам объекта.
22 май 03, 12:33    [206491]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 Maksim UM

Во-во и я про это. Говорю, что в реляционной модели существенны только ЗНАЧЕНИЯ - а мне про индексы. Индексы - это реализация. Удобно будет- реализуем с индексами, неудобно - реализуем без индексов. Модель от этого НИКАК не должна меняться.

Насчет двумерности. Во первых выражение "реляционные таблицы" уже показывает что Вы воспринимаете ее как таблицу. В теории рел. БД речь идет об отношениях и, дабы избежать всякой упорядоченности, отношение вводится как множество различных отображений из множества атрибутов в множество доменов. Че то я тут размерностей вообще не вижу.

Насчет того, что это рел. модель - единственная реальная модель ДАННЫХ, то могу повторить: в этой модели СУЩЕСТВЕННЫ только ЗНАЧЕНИЯ, т.е. ДАННЫЕ. Все остальные построения, о которых я когда-либо слышал, оперируют понятиями так или иначе связанными с ПЕРЕМЕННЫМИ, и, тем самым, описывают не данные, но СИСТЕМЫ ХРАНЕНИЯ данных. Понять трудно, но можно.
22 май 03, 12:51    [206526]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
2U-gene

читал я всё. Ты по-моему запутался.

что данные так ОПИСАНЫ - объект данных как совокупность записей разных таблиц


это и есть отражение предметной области в структуре БД, для чего реляционная модель хорошо подходит.

Пример Категории<-Товары->Поставщики

какая ж тут абстракция?
22 май 03, 13:03    [206557]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 1024

Не, не запутался. Более того, имею наглость утверждать, что все вокруг запутались :), ну кроме меня конечно .

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

Аналогия. В до ОО-языках вес и рост одного человека хряняться в разных переменных. Мы должны были работать с этими переменными подразумевая, что они относятся к одному человеку. В ОО языках они являются атрибутами одного объекта (так удобнее).

ИМХО рел. модель надо воспринимать как модель описывающую идеальную (потому как математически строгую) ассоциативную память. Кто-нить в курсе, были ли попытки создания ОО-компилятора для системы с ассоциативной памятью? Возможно ли это вообще?
22 май 03, 13:22    [206611]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
К предыдущему
О двух табличках для накладной. В одной храниться строка заголовка в другой строки с информацией о товаре.
22 май 03, 13:28    [206624]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
2U-gene

Я чесно говоря не въезжаю что ты хочеш сказать.

По поводу измерений человеков:
можно хранить их в табличке с полями ФИО,Рост,Вес
а можно в трёх табличках РостыЧеловеков<-Человеки->ВесыЧеловеков
в зависимости от назначения БД (например гробовщику пофиг точный рост, он делает гробы трёх размеров: маленькие, средние и большие, соответственно второй вариант БД ему для учёта продукции хорошо подойдёт).

Т.е. предметная область прекрасно ложится на реляционную модель.
22 май 03, 14:17    [206714]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД  [new]
c127
Guest
2 Maksim UM

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

Я-то как раз понимаю, почему ты так говоришь. Я хочу сказать, что твое утверждение неверно.

Таблица не двухмерна покрайней мере по одной простой причине (но есть и другие): нет первого измерения, т.е. номера записи. Его можно ввести, но это не является необходимым. В DBF файлах номер записи возможно есть, в таблицах Sybase ASA его нет.

>Похоже, что не представляете. В Cache можно спокойно работать без
объектов. И если Вам непонятно (и не пытаетесь понять), то зачем обсуждать?

Да может он работать без объектов. Ну и что? Речь не о том. Речь о том, что для построения надежной системы ПРИНЦИПОВ хранения информации нужно эти принципы формализовать. Единственный известный человечеству способ это построение аксиоматической системы. Потом нужно строить реальную систему, стараясь соблюсти как можно больше этих принципов. Тогда возможно (!) получится надежная система. Для ООДБ такая цепочка пока не построена - нет главного - аксиоматики.
23 май 03, 00:39    [207457]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить