Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 58 59 60 61 62 [63] 64 65 66 67 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
tygra
Эти ответы можно узнать в книжках про СУБД, у коллег или из собственного опыта.
Иначе - это уже репетиторская деятельность и она должна оплачиваться


Т.е. кроме как повторять мои высказывания в перевернутом стиле вы ни на что не способны. Ведете себя как попугай. Таким образом, tygra - бот.
Печально, а я с ним по-честному обсуждать что-то пытался :-( .
29 мар 05, 17:08    [1424074]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Dimonische
Тигра, вы, возможно правы, но мой работатодатель (что для меня намного важнее) с вами не согласен.

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

Не знаю зачем. Бабки щас на всем делают - таблетки от смерти продают, не то что апп-сервера.
автор
и почему это гигантский рынок.

Гигантский? Насколько?
автор
Наверняка он состоит не из полных идиотов . Просто вы не знаете что это такое - апп.сервера.

Ну как-то знаю, что это такое. Но никак не пойму - зачем? Нет, в нескольких процентах случаев я могу понять, но в остальных - нет. И не пойму, зачем их пихать в каждую дыру?
автор
Не знаете ни J2EE, ни COM+ и пр.

Честно, J2EE (тьфу-тьфу-тьфу нечистая) не знаю. Это же Java!!!! Чур меня, чур, этого зверя я даже на фото видеть не хочу.
COM+ тоже не знаю. И не хочу знать. Ну не хочу - почему-то (правда я не задумывался - почему) у меня и без этих зверей все работает. Может потому и работает, что не задумывался. А то бы надумал чего, воплотил в жизнь - и все, копец.
автор
Я знаю базы на уровне ессно не ДБА, но каждый день работаю с Ораклом и нашим ДВА.

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

Да немного знаю. Немного. А вот про стандарты - не, не знаю.
И даже и знать не хочу.
Не могу понять - зачем мне узнать то, чего мне не нужно? У меня все хорошо работает и так, причем достаточно хорошо работает, зачем мне узнавать что-то из других миров, если оно мне не нужно и безполезно?
=============================================================
Ответ БОТа к Alexey Rovdo:
Ваш вопрос поставлен в очередь........................... Ждите......пиииик..... Ждите.... ...пииик...

-- Tygra's --
29 мар 05, 17:32    [1424167]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Непрограммист
Guest
tygra
автор
Выше я уже отмечал, что приличная часть функциональности этих продуктов (VOA) рассчитана именно на то, что применять их будут в трех- (и более) звенных приложениях (трехзвенный кэш, кэширование блокировок, группирование запросов и т.п.). В иных случаях она просто оказывается невостребованной.

Т.е. уже 63 страницы идет речь о продуктах, которые востребованы всего в 0.1% рынка?

Какие-то упрощенные у Вас представления о рынке...
29 мар 05, 17:50    [1424231]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Непрограммист
Guest
tygra
Не могу понять - зачем мне узнать то, чего мне не нужно? У меня все хорошо работает и так, причем достаточно хорошо работает, зачем мне узнавать что-то из других миров, если оно мне не нужно и безполезно?

Ага. У нас в бухгалтерии банк-клиент досовский стоит. Хорошо работает. Только убогий очень...
29 мар 05, 18:02    [1424286]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
Непрограммист
tygra
Не могу понять - зачем мне узнать то, чего мне не нужно? У меня все хорошо работает и так, причем достаточно хорошо работает, зачем мне узнавать что-то из других миров, если оно мне не нужно и безполезно?

Ага. У нас в бухгалтерии банк-клиент досовский стоит. Хорошо работает. Только убогий очень...

свою работу выполняет? От замены на окончатого денег больше станет?
29 мар 05, 18:08    [1424313]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Итак, вопрос "SQL сервер - это СУБД или не СУБД?" остался без ответа.

На вопрос "Вы хотите сказать, что объекты хранимые VERSANT'ом доступны для множества разных приложений?" был получен ответ "ДА". Однако, при ближайшем рассмотрении выяснилось, что доступны не объекты, а данные объектов это как "потрогать дам, но удовольствиие не получишь". При этом, для того, что бы получить значение одного атрибута, надо забубенить несколько объектов акссесеров. Я боюсь задать вопрос что делать, если нужен конкретный объект....ой....данные объекта. и как получить данные по ссылке.... ой....по данным, которые обозначают в хранилище ссылку...то есть может быть это и возможно, но коду будет на 20 экранов.... цимес же в том, что эти данные придется интерпретировать(в смысле понимать) как ссылку в самом другом приложение. . На самом деле разговор можно заканчивать уже после того, что методы на сервере не храняться: нет методов -нет объектов (хотя возможно имеются сложные структуры данных).Другими словами правильный ответ - "НЕТ, для множества разных приложений объекты недоступны."

Концептуальна следующая фраза
автор
Как уже сказано неоднократно, в Версанте есть триггеры/хп, но они к объектам никакого отношения не имеют
показывающая некую несистемность мышления. Обясню. Обычно поклонники ООП (к коим я сам отношусь) говорят о том, что методы (то есть то, что без сомнения имеет отношение к объектам) позволяют создать ...бла-бла.... в общем адекватную ..мммм....активную модель предметной области. И это хорошо - с этим никто не спорит! Вопрос - а нафига тогда в Versante триггеры, если уже методы есть? Единственное, что приходит на ум - потому, что в ем, родимом, нельзя работать с методами на стороне сервера, и что бы хоть как-то выразить ограничения на данные, насущные в силу необходимости адекватно и безошибочно описать ту же предметную область, пришлось забубенить триггеры. К сожалению, насколько я понял эти триггеры с классами и с методами классов никак не соотносятся (если соотносятся, то хорошо).

По мелочам :) Вот тут товарсчи грят - берем один язык, берем другой язык, из описания для одногоязыка получим описание для другого языка. Но какт о получается, что из описания для С++ описание для Java сделать не получиться. Слишком уж сложные в С++ структуры возможны, опять же множественное наследование и т.д.

Наконец....На вопрос
автор
зачем существуют апп-сервера,
ответ прост! что бы бизнес логика была централизована - то есть что бы она не была на клиенте! Я про это и говорю. ИМХО, что когда сервера БД станут более мощными в плане манипулирования и обработки данных, необходимость в выделенных АПП-серверах отпадет. Останется двузвенка: клиент - сервер...ммм...назовем его серверам моделирования описываемой предметной области.
29 мар 05, 18:14    [1424331]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Непрограммист
Guest
Alexey Sh
свою работу выполняет? От замены на окончатого денег больше станет?

Окончатый удобнее. Меньше ошибок в работе бухгалтерии. Быстрее все происходит. В итоге - дешевле.
Да и админских проблем с этим компом тьма... Win95...
Вот. Ставим окончатый...
29 мар 05, 18:15    [1424340]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Непрограммист
Guest
U-gene
Итак, вопрос "SQL сервер - это СУБД или не СУБД?" остался без ответа.... (Далее длинный ответ)

Все смешалось - кони, люди... серверы, объекты и их данные, базы данных, триггеры, методы.
Такое ощущение, что иногда спор здесь идет исключительно ради спора.
29 мар 05, 18:27    [1424364]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
serg99
Member

Откуда:
Сообщений: 422
U-gene
Будь моя воля, я бы целиком предметную область со всеми ее объектами и зависимостями реализовывал бы на сервере, а на клиента получал данные о существующих на сервере объектах и управлял этими объектами. Но нет таких инструментов! Пока нет, но видимо лет через , что лет через ...цать именно так и будет. Потому как так проще всего.
Кстати интересный вопрос. Действительно разные приложения могут работать с разными сторонами объекта как единицей хранения в БД. Скажем программа "Бухгалтерия" использует такую характеристику "Товара" как стоимость, а программа "Логистика" например использует габариты/вес и совсем не использует стоимость. С другой стороны ООП объект "Товар" в разных приложениях может иметь разные индивидуальные неперсистентные свойства, которые не имеют эквивалентов в БД и используются клиентским приложением во время ран-тайма. Конечно было бы удобно иметь прикладные объекты/классы/сборки... в самой БД. Но тогда напрашивается и само приложение иметь в БД, тем более что при этом упрощается администрирование всей информационной системы (пользователь всегда работает с последней версией приложения). Как бы Вы представляли себе идеальный (можно гипотетически) симбиоз БД и инструментов разработки ПО, что бы разработка, а главное (сейчас зачастую независимое) развитие этого ПО и предметной области в БД происходило наиболее гладко, эффективно и интуитивно понятно для программистов?
29 мар 05, 18:31    [1424379]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Ув непрограммист, я не берусь утверждать, ради чего здесь идет спор, но то, что Ваш пи.деж идет только ради Вашего же пи.дежа - это точно!
29 мар 05, 18:32    [1424380]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Непрограммист
tygra
Не могу понять - зачем мне узнать то, чего мне не нужно? У меня все хорошо работает и так, причем достаточно хорошо работает, зачем мне узнавать что-то из других миров, если оно мне не нужно и безполезно?

Ага. У нас в бухгалтерии банк-клиент досовский стоит. Хорошо работает. Только убогий очень...
...
Вот. Ставим окончатый...

Так вам на Java ставят новй? Или апп-сервер клиент-банка, через который будет работать сам клиент? :)) Или новый клиент из "других миров"? :))
Нет? А тады какое отношение это имеет к моей цитате? :))

2 U-gene
Поддерживаю пост.
И в добавок:
Так и сейчас нет особой надобности в апп-серверах. Распределенная нагрузка - Оракл умеет работать в кластерном варианте. Хотя я не вижу никаких задач (ну есть некоторые специфические, но их в сторону, говорим то об общем), чтобы понадобилось ставить два или пять апп-серверов из-за того, что БД не справляется. А почему она справится то с таким количеством апп-серверов? На нее что, нагрузка упадет так сильно (если вообще упадет)? Селектов/апдейтов уменьшится? Или чудо свершится? Или руки разработчиков выпрямятся? Никак нет, ничего такого не случится. Самообман.

ЗЫ Заодно спрошу у знатока апп-серверов: чего такого они могут, что не может сервер СУБД? Вот такое, которое жизненно важное и необходимое хотя бы в 50% случаев.

-- Tygra's --
29 мар 05, 18:34    [1424390]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 serg99
Так в Оракле же есть возможность создавать типы данных и работать с ними через pl/sql обычным образом (sql). Хотя конечно это не объекты с методами, но все же как-то.
Вот и MS SQL 2005 такое будет уметь.

Но конечно работать прямо в БД с объектами, используя именно методы (ХП, но для объекта так сказать), это наверное было бы действительно хорошо. Но работать именно через обычный sql. Чтобы никакого изврата не городить на клиенте.

-- Tygra's --
29 мар 05, 18:38    [1424403]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Непрограммист
Guest
U-gene
Ув непрограммист, я не берусь утверждать, ради чего здесь идет спор, но то, что Ваш пи.деж идет только ради Вашего же пи.дежа - это точно!

Словарный запас у Вас богат. Спору нет.
А если по сути. Скажите, чем отличается описанный в ваших мечтах сервер БД от "апп.сервера"?
29 мар 05, 18:41    [1424412]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
U-gene

Однако, при ближайшем рассмотрении выяснилось, что доступны не объекты, а данные объектов это как "потрогать дам, но удовольствиие не получишь". При этом, для того, что бы получить значение одного атрибута, надо забубенить несколько объектов акссесеров. Я боюсь задать вопрос что делать, если нужен конкретный объект....ой....данные объекта. и как получить данные по ссылке.... ой....по данным, которые обозначают в хранилище ссылку...то есть может быть это и возможно, но коду будет на 20 экранов....


Вы попросили пример для приложения, которое не знает возможной структуры хранимых объектов на этапе компиляции. Я привел вам код для такого, достаточно редкого, случая. Теперь, кивая на этот код, вы делаете обобщения на все случаи. Но это же полная туфта.

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

U-gene

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


Некоторые ООСУБД (GemStone) поддерживают хранение методов вместе с данными и выполнение этих методов на сервере БД. Но Versant придерживается мнения, что такой подход вызывает еще больше вопросов и в конечном счете имеет больше минусов, чем плюсов в практическом плане (хотя теоретически он, полагаю, более обоснован и больше следует объектной парадигме). Как я уже писал - в идеале у нас должен быть выбор.
29 мар 05, 18:41    [1424413]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
автор
Вы попросили пример для приложения, которое не знает возможной структуры хранимых объектов на этапе компиляции. Я привел вам код для такого, достаточно редкого, случая. Теперь, кивая на этот код, вы делаете обобщения на все случаи. Но это же полная туфта


Но тогда встает задача согласования разных приложений. Если бы в БД хранила объект - этого не было бы. В конце концов, мой вопрос изначально именно про хранение разделяемых объектовя уж не говорю про хранение и ..ммм... выполнение - т.е. про активный сервер, а не про хранение данных плюс досуп к библиотекам, хранимым вне БД.
29 мар 05, 18:50    [1424438]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
А я ведь уже задавал вопрос? Почему то некоторым кажется, что апп-сервер чем-то фундаментально отличается от ХП. Но что такое ХП, если не встроенный в СУБД апп-сервер? Т.е. используем мы встроенный (ХП) или внешний (JBoss и т.п.) сервер приложений сути никак не меняет.

Что если завтра Oracle решит интегрировать апп-сервер в состав СУБД и продавать это единым пакетом? Только тогда некоторые согласятся с тем, что приложение, обрабатывающее данные, и база данных, которая их хранит, на самом деле могут рассматриваться как нечто единое вне зависимости от деталей реализации?

И как в этом контексте смотреть на MS SQL? Для MS SQL 2000 .NET-приложение - внешняя конструкция, и если мы в нее выносим бизнес-логику, то это зло. А вот то же самое приложение в MS SQL 2005 уже можно исполнить "внутри" СУБД и тогда - честь ему и хвала - оно правильное.
29 мар 05, 18:53    [1424443]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
U-gene

Но тогда встает задача согласования разных приложений.


Ну и где здесь по-вашему проблема? Что мешает разным приложениям использовать при компиляции одну библиотеку с описаниями хранимых классов? Или, по-крайней мере, несколько увязанных между собой библиотек - каждая для своего языка программирования (C++, Java)? Что мешает им в последующем обращаться к одним и тем же объектам?

Что же касается неувязок между C++ и Java, то разумеется, если мы хотим иметь универсальное решение, то ограничения одного языка тут же будут переноситься на описания хранимых класов в другом языке.
29 мар 05, 19:03    [1424475]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Что мешает разным приложениям использовать при компиляции одну библиотеку с описаниями хранимых классов?

Повтор :)

Причины есть. Называется "забыли", "перепутали", "в лом было спец.средствами пользоваться" и вообще "достали эти версии" :) Если Вам это незнакомо, то Вы откуда то неотсюда....
29 мар 05, 19:08    [1424491]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
U-gene

Причины есть. Называется "забыли", "перепутали", "в лом было спец.средствами пользоваться" и вообще "достали эти версии" :) Если Вам это незнакомо, то Вы откуда то неотсюда....


А здесь вы почему-то игнорируете мое замечание о том, что приложение, откомпилированное с неоригинальной (не отвечающей метаданным, которые есть в ООБД) библиотекой классов, просто не заработает (фактически - это вообще не проблема).

Т.е. никаких фундаментальных проблем нет. Есть вопросы удобства и привычек разработчика. Кому-то кажется, что работая с ХП ему труднее будет "забыть", "перепутать" и т.п.
29 мар 05, 19:17    [1424507]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Как я себе этот гипотетический сервер представляю? С трудом... но все же как то представляю. Слегка. У меня на этот счет пара тараканов в голове имеется, но прям так сразу их демонстрировать общественности стрёмно, посколько дохлые они пока, и совсем какие то замороченные - мутанты одним словом:) Но сразу скажу - они совсем какие то не такие. Вообще. Я про такое нигде даже не слышал. Одним словом, блажь редкостная:))
29 мар 05, 19:32    [1424539]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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

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

Лично я думаю, что даже в случае одного приложения переносом ограничений целостности из БД в приложение мы ухудшаем связность функций в модулях системы, и тем самым создаем предпосылки для возрастания энтропии программного обеспечения: появление всяких заплаток, примочек кода, которые в конце концов приведут к сокращению жизненного цикла ИС. Т.е. проще будет создать новую, чем подправлять старую. Потому что ограничения целостности присущи данным (я писал в пред посту). А функционалу приложения они сами по себе не присущи. Т.е. они не на своем месте там так же как и схема БД.

Alexey Rovdo

Что же оказывается? В первом случае для обеспечения целостности нам триггер в принципе не обязателен, а во втором – реализовать все необходимые вычисления даже в рамках триггера проблематично, да и не факт, что это будет разумно с точки зрения распределения вычислительной нагрузки между серверами и клиентами.

Может всякое оказаться, но часто оказывается, что триггер обязателен и реализовать его не проблематично. Это же не транзакция - все или ничего? Если мы найдем проблемы написать триггер для какого-то случая, то откажемся от них раз и на всегда? Знаете, так пришлось бы и от БД отказаться.
Вот я Вам привел пример про идентификционный номер ПФ. Там триггер обязателен и не проблематичен.

Если ограничение целостности можно выразить в СУБД декларативно, то оно имеет много преимуществ перед триггером. Особенно выразительность - декларация легче читается, чем тело триггера. Да и др. Но есть всякие нюансы в конкретных СУБД, т.е. декларативные средства могут иметь какие-то противопоказания. Например, для репликации. Но так или иначе триггеры важным образом дополняют возможности поддержки.

Концептуально это выглядит так.
Есть прописанные в рел модели ограничения целостености: целостность отношения или целостеность ключей, ссылочная целостность, ограничения на значения - это для декларативных средств.
Есть не прописанные в рел модели ограничения. Оганичения общего вида (у них могут быть и др названия - я писал). Это для триггеров.

Alexey Rovdo

Где же та граница, за которой мы можем говорить, что вот «это» относится к целостности данных и должно отрабатываться внутри СУБД (с помощью триггеров, ХП или как-то еще), а вот «то» уже нет и имеет право быть перенесенным в приложение? По какому критерию мы относим одни правила к модели предметной области, а другие готовы признать функцией приложения?

Если это логическое правило, которым должны отвечать данные БД во всех ее состояниях, то это ограничения целостности. Они присущи данным так же как и схема.

Alexey Rovdo

Мне кажется, что нет никаких четких критериев, по которым мы можем относить одни ограничения и правила к компетенции СУБД, а другие – к компетенции приложения. На практике все определяется задачами разделения вычислительной нагрузки и удобством разработчика.

Что касается критерия ограничений целостности, то попытался привести его выше. Что касается распределения, то несомненно у приложения может быть серверная и клиентская часть. Я под серверной имею в виду, все что уже не относится непосредственно к модели данных, а направлено на функционал приложения. Здесь с критериями, наверное, сложнее и что-то зависит от искусства проектировщика. Хотя какие-то есть. Вы, например, говорите про рациональное распределение вычислительных ресурсов. Это критерий, хотя иногда четкий.

Alexey Rovdo

На мой взгляд вполне можно смотреть на связку «СУБД+сервер приложений» как на единое хранилище данных и методов и именно эту пару рассматривать, как систему, обеспечивющую непротиворечивость и целостность данных, а также как на собственно реализацию модели предметной области.

Наверное, при таком подходе можно ослабить некоторые преимущества многозвенки. Например, модульную независимость. Если 2 и 3 звено один модуль, то первое звено зависит от этого единого (2+3) и стал быть от 3. А нам хочется чтобы 1 и 3 не зависели друг от друга. Кроме того, такой подход ведет в идеале к тому, чтобы разместить серверное приложение в БД (и это в Оракле 8 присутствовало), так как она имеет моного хорошего в плане хранения. И Вы придете к тому, что говорили Вам в этой ветке - все должно быть в БД. А Вы как я понял против этого.
Для меня же термин хранилище данных - уже зарезервирован для других целей. Для хранения исторических, а не оперативных данных. И главное оно может быть ядром системы поддержки принятий решений. И там могут быть и есть, движки для оперативного анализа данных или даже того, что называют интеллектуальной обработки данных. Поэтому связку «СУБД+сервер приложений» лучше назвать пока как-то по другому, до выяснения насколько это хорошо подходит к тем концепциям с которыми уже связан этот термин. Иначе мы запутаем терминологию до предела. С ней и так полено сложностей в инфотехнологиях.
29 мар 05, 22:45    [1424821]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Недоучка

Недоучка>>> Любопытно, чем они отличаются ПРИНЦИПИАЛЬНО?

c127>> Ничем.

Недоучка> Вы меня совсем запутали - поясните, что такое разные объекты, которые ничем не отличаются? ;-)

С Вами спорить не интересно. Читайте внимательно хотя бы себя, любимого, раз книжки читать не хотитие.
30 мар 05, 03:23    [1424964]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Alexey Rovdo

>А здесь вы почему-то игнорируете мое замечание о том, что приложение, откомпилированное с неоригинальной (не отвечающей метаданным, которые есть в ООБД) библиотекой классов, просто не заработает (фактически - это вообще не проблема).

Тогда уже не откомпилированное, а слинкованное, раз речь идет о библиотеке.

И в джаве тоже? Там же великий шаг вперед - позднее связывание, если метод отсутсвует или не соответвует, то ошибка может вылезти только во время исполнения и только при попытке вызвать метод.

>Задайте внятно вопрос - получите ответ.

Вопросы были заданы неоднократно и совершенно конкретно, есть ли шансы получить ответы, вот в чем вопрос.
30 мар 05, 05:06    [1424978]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Недоучка
Guest
c127
2 Недоучка

Недоучка>>> Любопытно, чем они отличаются ПРИНЦИПИАЛЬНО?

c127>> Ничем.

Недоучка> Вы меня совсем запутали - поясните, что такое разные объекты, которые ничем не отличаются? ;-)

С Вами спорить не интересно. Читайте внимательно хотя бы себя, любимого, раз книжки читать не хотитие.


А Вы со мной не спорьте, Вы мне тупенькому объясните, или книжку подскажите, где написано, что "В ПОЛЬЗОВАТЕЛЬСКОМ ПРИЛОЖЕНИИ И В ООБД ОБЪЕКТЫ РАЗНЫЕ"...
А я книжечку прочитаю, на картинки полюбуюсь и более внимательно буду внимать великому Гуру - c127.
30 мар 05, 06:19    [1424990]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Недоучка
Guest
2 Alexey Rovdo:
На днях скачал FastObjects Trial. Прикольная весчь... Одного пока не нашел - а как определить декларативную целостность? Или я плохо искал?
30 мар 05, 06:25    [1424992]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 58 59 60 61 62 [63] 64 65 66 67 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить