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

примеры:
1 массив 100х50х20 набит цифрами
2 2000 хаотически связанных таблиц с непонятными именами и неизвестного назначения
- вопрос что это ? (ответ знает только приложение)
31 июл 08, 17:28    [6012089]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
любапыцтвующий
Вопрос в том, может ли СУБД представлять семантику и правильно ей пользоваться для рассуждений (запросы к данным).

Нет, не может и не должна. Это роль приложений. То, что называют по недоразумению "ООСУБД" чаще всего и есть специфические приложения. Любая СУБД имеет дело с формальной МД и оперирует формальными методами.
31 июл 08, 17:32    [6012117]     Ответить | Цитировать Сообщить модератору
 Re: БАЯН!  [new]
_мод
Guest
U-gene
кааааак моооолоодыыыы мы былииииии

Дык ведь новые молодые подросли - демонстрируют тягу к знаниям :)
31 июл 08, 17:34    [6012134]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Хоть вопрос и не мне я отвечу.

любапыцтвующий

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

Вопрос в том, может ли СУБД представлять семантику и правильно ей пользоваться для рассуждений (запросы к данным).


ИМХО может, только теоретически,

Это будет не совсем субд , а ассоциативная база знаний.

1.С точки зрения ресурсов, это будет очень сильно затратно.

2. Для начала нужно построить метематическую модель работы человеческого мозга. что бы БД и человек были похожи в рассуждениях.

3. Очень интересна тема о регулируемой семантике, когда один человек переубеждает СУБД в чем то.
Она соглашается, при этом с другим человеком ведет себя по старому.
То есть уже анализируются свойства самой семантики относительно того кто к ней обращается.

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

5. Каким образом она должна избавляться от старых данных, которые потеряли актуальность
и на основании чего.

......

Я все еще предполагаю что диф исчесление способно смоделировать все это, только понадобтся
для этого минимум десяток лет и минимум пару десятков психологов и математиков постоянно работающих над темой.


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

Создание такой системы не достижимая цель( во всяком случае для меня) на данном этапе.
Я не хочу расходовать ресурсы на недостижимые цели.
31 июл 08, 17:35    [6012142]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
_мод
onstat-

примеры:
1 массив 100х50х20 набит цифрами
2 2000 хаотически связанных таблиц с непонятными именами и неизвестного назначения
- вопрос что это ? (ответ знает только приложение)


"все что один человек создал , другой всегда сможет разобрать " (С) Формула любви
за дословность не ручаюсь.


Иногда даже в меньшем количестве цифр можно запутаться, вспомните анекдот про штурмана.
31 июл 08, 17:59    [6012323]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Я тут вот о чем подумал, допустим создаст Бред(ЧАЛ) такую систему,
а она на все вопросы дает ответ "Меньше знаешь- лучше спишь"
)

Впору фантастические повести по мотивам Матрицы писать.
31 июл 08, 19:25    [6012647]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
MX -- ALEX

Вы не поверите
но на нереляционной в принцине CACHE (на стандарте MUMPS)
разработанном Американской фирмой и используемой сейчас
чаще всего именно в США
(где сумасшедших нет по определению :)

блокировки ставятся именно так почти дословно


Я в курсе что разработчики Каши прилепили к ней реляционную морду. Осталось только мампсы запретить и ограничить модель данных до реляционной, и лет через 10 оно заработает по нормальному.

Что касается внедрений Каши в США, ее доля рынка в пределах статистической погрешности измерения. Сделайте поиск по ключевым словам SQL и Cache в том же Dice и вам все станет понятно.

Про отсутствие сумасшедших имелось ввиду не конкретно США а программерское сообщество в целом. Умалишенные есть, но руководить проектами им как правило не дают. Когда дают - заканчивается как в Kaiser Permanente, где внедряли мампсы. Довнедрялись.
31 июл 08, 21:26    [6012893]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Зл0й
MX -- ALEX

Вы не поверите
но на нереляционной в принцине CACHE (на стандарте MUMPS)
разработанном Американской фирмой и используемой сейчас
чаще всего именно в США
(где сумасшедших нет по определению :)

блокировки ставятся именно так почти дословно


Я в курсе что разработчики Каши прилепили к ней реляционную морду. Осталось только мампсы запретить и ограничить модель данных до реляционной, и лет через 10 оно заработает по нормальному.

Что касается внедрений Каши в США, ее доля рынка в пределах статистической погрешности измерения. Сделайте поиск по ключевым словам SQL и Cache в том же Dice и вам все станет понятно.

Про отсутствие сумасшедших имелось ввиду не конкретно США а программерское сообщество в целом. Умалишенные есть, но руководить проектами им как правило не дают. Когда дают - заканчивается как в Kaiser Permanente, где внедряли мампсы. Довнедрялись.

Жалкая пропаганда бессмысленных "современных архитектур" продолжается на последнем издыхании): То есть, пошли уже грубейшие ошибки даже на уровне любимых 70-ых и 80-ых. mumps был практически первым стандартным языком, в который интегрировали SQL. И "разработчики Каши" не имели к этому никакого отношения): Вы даже не понимаете что, в действительности, сделали "разработчики Каши". Лучше бы Вы продолжали рассказывать сказки про системы восстановления навигации и смысла данных): И опять примитивное вранье про "кайзеров"):
Мы уже хорошо видим кому дают "руководить проектами"):
31 июл 08, 22:38    [6013042]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Зл0й
Бред

Опять уходите в другую тему. Теперь данные из разных источников): О чем-то о наболевшем? Зачем Вы нам рассказывате про AFS??? Это сделано в ОСУБД что ли???

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

Бред

Опять о любимых 70-х?

Употребляемый вами термин "навигация" придумал лауреат премии Тьюринга 1973 года Чарльз Уильям Бахман. В 70х были реализованы "навигационные" СУБД в частности IDMS одним из основных разработчиков и идеологов являлся Чарльз Бахман.

Бред

Не смешите людей, цена поддержки "реляционных решений" всегда дороже):

Цифры в студию, кто сравнивал, что сравнивал, с чем сравнивал и самое главное - как сравнивал. 85% рынка СУБД это СУБД реляционные, а остальные 15% - это legacy системы разработанные в 70х годах прошлого века.

Бред

Оптимизатор входит в состав СУБД и никогда не пишется для приложения.

не возражаю.

Бред

Однако восстанавлением смысла и навигации данных Вы занимаетесь каждый раз при написании даже самого простого приложения.

Восстановлением смысла мы не занимемся, потому что в этом нет никакой необходимости. Он никуда не "терялся" соответсвенно его не нужно "восстанавливать". Помнится я вам приводил определение термина "семантика" которым вы воспользовались пару лет тому назад. После чего мы пришли к выводу что она в Реляционных СУБД есть. Теперь вы прячетесь за расплывчатым и неопределенным словом "смысл".

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


Бред

Вот я Вас и спрашиваю: почему бы не быть последовательным в желании программировать, и почему бы не программировать и оптимизаторы под каждое приложение?): Вместо того, что бы ответить, опять что-то про "зашивание в процедурную логику"):

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

Ближе всех к решению задачи "реализовать оптимизатор запросов и язык высокого уровня для нереляционной СУБД" подошли разработчики IDMS. Задача эта существенно сложнее чем разработка оптимизатора для реляционной СУБД. Ежу понятно почему, в принципе. Вы утверждаете обратное - потрудитесь аргументировать свою точку зрения.

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

Вы беретесь гарантировать непротиворечивость данных в "ОСУБД"? Докажите.

Последний "гвоздь" в гроб нереляционных СУБД заколотили разработки работы в области поддержки конкурентных транзакций. Для реляционных СУБД существуют алгоритмы обработки конкурентных транзакций (например читатели-писатели) корректность которых математически доказуема. Желающих убедиться отсылаю к классической книге Джима Грея.

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

Вы беретесь продемонстрировать алгоритм обработки конкурентных транзакций в ОСУБД и доказать его корректность?


Опять не хотите отвечать на элементарные вопросы по теме. Ну ничего - подождем):
1. В Mumps нет никакой модели данных - стыдно этого не знать.
2. При чем здесь "термин"??? Вы употребляете "70-е" чуть ли не в каждом сообщении совершенно не к месту. Хотите порассуждать о навигации - давайте. Есть тема, где этот вопрос обсуждался. Я не против продолжить, чтобы было понятно, что работ Бахмана Вы не читали):
3. Я сравнивал. И цифры приводил. Ваша беда в том, что Вы знакомы, весьма посредственно, только с одной технологией, и, конечно, ничего сравнить не можете): А я могу.
4. Нет, еще как занимаетесь. Поэтому и уходите от конкретных вопросов и примеров. Смысл именно теряется при переходе от концептуального уровня к логическому. Не поможет Вам аппеляция к терминам "семантика" и "смысл". Наберитесь мужества и возвращайтесь к конкретике - Вы же не виноваты, что приходиться применять системы восстановления навигации и семантики данных в дополнение к "Р"СУБД, в которых эти важнейшие свойства БД утрачиваются (а идентифкацию уже просто невозможно восстановить).
5. Все Вы прекрасно понимаете: если каждый раз при создании приложения Вам приходиться восстанавливать навигацию и семантику данных, то почему бы каждый раз не писать свой оптимизатор и свой "SQL"? Что же тут не понятного??? В ОСУБД не нужно каждый раз обеспечивать ни навигацию, ни семантику, ни оптимизацию, ни "SQL". В "Р"СУБД не нужно каждый раз обеспечивать оптимизацию и "SQL". Но нужно каждый раз обеспечивать навигацию и семантику. Это безнадежно устаревшая технология, а Вы ее выдаете за "современную"):
6. Я уже все тщательно аргументировал и доказал. Не уходите от конкретных вопросов про связи и смысл данных.
7. Очередное отвлечение - теперь на "транзакции" - Вам не поможет. С транзакциями ситуация абсолютно ничем не отличается от "Р"СУБД, и, собственно, не может отличаться даже теоретически. Хватит рассказывать сказки, иначе Вам самому придется доказывать все эти "корректности"): Предлагаю еще раз не отклоняться от связей и веса Сидорова - Вы же не виноваты в ущербности той технологии, которую Вам навязали):
31 июл 08, 23:14    [6013113]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Бред

Не забывайте, что реальные системы на основе РМД пишутся медленнее и работают менее качественно, чем системы на основе ОМД):

Судя по всему вы идете по стопам рейхсминистра пропаганды доктора Йозефа Геббельтса который говорил "Самая ужасная ложь, повторенная тысячу раз, начинает звучать, как правда."

Я берусь утверждать что данное утверждение - наглая ложь. Вся базоданновая практика за крайние 30 лет опровергает ваше утверждение. Если вы предпочитаете жить в выдуманном вами иллюзорном мире, потому что вам там удобно, то мне вас искренне и по человечески жаль.


Бред

Ведь в случае РМД возникает необходимость в дополнительных системах восстановления навигации и семантики, с чем Вы уже вроде бы согласились):


Я нагло украл из википедии определение семантики:
Википедия

Сема́нтика — в программировании — система правил определения поведения отдельных языковых конструкций. Семантика определяет смысловое значение предложений алгоритмического языка.


Из этого определения любому кто читал хоть какой-нибудь учебник по реляционным СУБД должно быть понятно что она в Реляционных СУБД есть. Если ее нет - потрудитесь доказать.
1 авг 08, 01:24    [6013311]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Вдогонку, про семантику.

Народ, ну откройте же книжку Дэйта наконец, там же все написано. Ну или сюда загляните:


Возьмите оттуда пример:

"Существует такой customer что
его id = 1234567890
его Tax id = 555-5512222
его Имя = Munmun
его Адрес = 323 Broadway"

- истинное высказывание.

Все же элементарно, второй курс средней руки технического ВУЗа.

Хотите деталей и подробностей - лезете в словарь и смотрите камменты на наблицу и колонки.

В реляционной СУБД все упорядочено и по правилам. Поэтому все и работает, причем с языком высокого уровня, поддержкой конкурентных транзакций и прочими пирогами. Если же модель не упорядоченная а типа "бардак валяется", то это мы уже проходили. Рекомендую заглянуть в какую-нибудь книжку по Базам Знаний двадцатилетней давности. Если правила не нормализованы как в реляционных СУБД то такая система БЗ затыкается при количестве правил от 200 до 500 примерно. Причем на любой железяке, потому что происходит
"комбинаторный взрыв".

Найти единственную реально и широко применяемую в индустрии СУБД сегодня нереляционную модель оставляю внимательному читателю в качестве упражнения. Сразу оговорюсь что речь не про иерархическую, сетевую и объектную. Первые две уже история в объектная не прижилась по целому ряду причин, в частности ввиду отвратительной масштабируемости продуктов (точнее отсутствию масштабируемости).
1 авг 08, 01:50    [6013342]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Заглядывать сюда:

Википедия
1 авг 08, 01:53    [6013345]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
DBjob
Member

Откуда:
Сообщений: 29
Зл0й
Первые две уже история в объектная не прижилась по целому ряду причин, в частности ввиду отвратительной масштабируемости продуктов (точнее отсутствию масштабируемости).

Какую объектную модель Вы имеете в виду и в чем состоят её родимые пятна из-за которых она не масштабируется?
1 авг 08, 02:18    [6013376]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
DBjob
Зл0й
Первые две уже история в объектная не прижилась по целому ряду причин, в частности ввиду отвратительной масштабируемости продуктов (точнее отсутствию масштабируемости).

Какую объектную модель Вы имеете в виду и в чем состоят её родимые пятна из-за которых она не масштабируется?


Как гритца "Listed in no particular order":

O2, ObjectStore, GemStone, Versant, Matisse

Ни один из указанных продуктов не масштабируется даже близко к реляционным СУБД в случае наличия конкурентных транзакций. Продавцы обещают с три короба (10X performance of relational databases), но реально это туфта.
1 авг 08, 02:52    [6013411]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
DBjob

Какую объектную модель Вы имеете в виду и в чем состоят её родимые пятна из-за которых она не масштабируется?


Про модель читайте "Database Systems: The Complete Book"
авторы Hector Garcia-Molina, Jeff Ullman, and Jennifer Widom.

мне стэнфордский учебник в конфу перепечатывать лень.
1 авг 08, 02:55    [6013419]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
сосед. был акцессник
Guest
весь топик не читал, только последние пару страниц, поэтому, может быть, получится
несколько невпопад.

2 _мод
по поводу отсутствия семантики в модели данных (по контексту понял, что утверждение о реляционной модели).
Это вопрос о курице и яйце.
Не бывает "баз данных всего на свете", да еще таких, где одни и те же данные сначала (в одном приложении) интерпретируются как температура на Марсе, а потом ровно они же (в другом приложении) - как цены на Нью-Йоркской бирже.
Не полностью определенная "семантика" и ее отсутствие - это не совсем одно и тоже в практическом смысле.
(Мне представляется, что это подразумевал U-gene)

2 Бред
Бред
<...>
Это же очевидно. Кто об этом спорит? Только в случае применения РМД мы сначала "деградируем" (ради алгебры) концептуальную схему для предметной области в логическую, а потом восстанавливаем навигацию и смысл данных с помощью дополнительных систем):


Про навигацию:
Крайне затруднительно понять, что именно Вы называете "навигацией".
Если это как-то соотносится с обычным для меня пониманием "навигации" как стратегии доступа к данным (= алгоритм их извлечения), то посмею напомнить Вам, что РМД такой темы просто нет.
Это на краю здравого смысла - заниматься восстановлением того, чего просто нет для внешнего наблюдателя. И нет независимых от реализации способов такого "восстановления".
"восстановление навигации" - это отсутствующая в темной комнате черная кошка.
РМД в своем теоретическом виде не предоставляет для конечного пользователя (прикладного программиста) средств "навигации", понимаемых как набор императивных инструкций.
Вместо этого она предполагает к использованию те или иные способы декларативного описания получаемого набора данных.
Термин "восстановление смысла" в той части, в которой он касается непосредственного доступа к хранимым данным, в РМД также затруднительно простереть за рамки возможностей допустимых реляционных операторов, которые, в переводе на sql просто окажутся выборками с соединениями.

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

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

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

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

-----------------------------
ясен пень, что все вышесказанное есть мое скромное мнение (сугубо).
Требуется также учесть, что я не могу считать себя специалистом в обсуждаемых вопросах.
1 авг 08, 03:04    [6013431]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
сосед. был акцессник

Сам термин "семантика" приложим только к ЯП.
1 авг 08, 09:34    [6013784]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
сосед. был акцессник




под навигацией Бред имеет ввиду алгоритм по которому будут отсекаться лишние связи
и востанавливаться смысл (семантика, контекст).

Если говорить математическими терминами
Это первая производная от функции которая описывает данные( как таковые).

Тут такая же зависимость как между расстоянием и скоростью в контексте времени в физике .
1 авг 08, 10:33    [6014189]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
onstat-
сосед. был акцессник




под навигацией Бред имеет ввиду алгоритм по которому будут отсекаться лишние связи
и востанавливаться смысл (семантика, контекст).

Если говорить математическими терминами
Это первая производная от функции которая описывает данные( как таковые).

Тут такая же зависимость как между расстоянием и скоростью в контексте времени в физике .


Что бы было понятнее что я имею ввиду есть банальный пример.

Если мы говорим о скорости, то контекстом подразумевается речь об растоянии и времени,
то есть числовое выражение в деньгах или литрах мы рассматривать не будем
это нам даже в голову не придет.
Если мы говорим об растоянии и времени контекст выводит нас на скорость.

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

Если найти зависимость между дельтой диференцирования и теорией множеств,
тогда можно будет говорить дальше об описании всей мат модели поддержания семантики.
1 авг 08, 12:57    [6015479]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
DBjob
Member

Откуда:
Сообщений: 29
Зл0й
DBjob
Зл0й
Первые две уже история в объектная не прижилась по целому ряду причин, в частности ввиду отвратительной масштабируемости продуктов (точнее отсутствию масштабируемости).

Какую объектную модель Вы имеете в виду и в чем состоят её родимые пятна из-за которых она не масштабируется?


Как гритца "Listed in no particular order":

O2, ObjectStore, GemStone, Versant, Matisse

Ни один из указанных продуктов не масштабируется даже близко к реляционным СУБД в случае наличия конкурентных транзакций. Продавцы обещают с три короба (10X performance of relational databases), но реально это туфта.

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

Кстати являются ли тесты ТPC общепринятыми метриками при сравнении различных СУБД? Есть ли в области DWH какие то свои тесты?
1 авг 08, 13:16    [6015651]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
любапыцтвующий
Guest
_мод
Сам термин "семантика" приложим только к ЯП.

Вы это повторяете как мантру

Куда и как это термин (по вашему) приложим никак не мешает большому и солидному сообществу исследовать семантику именно данных.
1 авг 08, 13:19    [6015679]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Зачем столько буков?
Почему бы не обсудить какой-нибудь небольшой проблем типа:
select T.SYS_TABLE_NAME , T.* 
from T 
where 
   T.SYS_TABLE_NAME like 'HEAD%' and 
   T.SUM < 0 and
   (T.ParentID.SYS_REFERENCED_TABLE).Date >'2008-01-01'
и убедиться, что и где выиграем/проиграем,
стоит игра свеч или нет.

Гипотетический язык второго порядка, где:
1) доступны метаданные таблиц и колонок (SYS_xxx),
2) на месте имен таблиц и атрибутов допустимы переменные.
1 авг 08, 14:05    [6016090]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
ModelR
Зачем столько буков?
Почему бы не обсудить какой-нибудь небольшой проблем типа:
select T.SYS_TABLE_NAME , T.* 
from T 
where 
   T.SYS_TABLE_NAME like 'HEAD%' and 
   T.SUM < 0 and
   (T.ParentID.SYS_REFERENCED_TABLE).Date >'2008-01-01'
и убедиться, что и где выиграем/проиграем,
стоит игра свеч или нет.

Гипотетический язык второго порядка, где:
1) доступны метаданные таблиц и колонок (SYS_xxx),
2) на месте имен таблиц и атрибутов допустимы переменные.


Согласен, Я за такой подход.

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

Я написал это для Бреда, который в удаленных сегодня утром сообщениях
пытался воззвать меня к понимаю того что нужно стремиться
к тому что бы семантика данных представлялась сама собой(во как закрутил ;)).

Я попытался на пальцах объяснить один из фундаментальных ( на мой взгляд)
законов по которым работает семантика.
Что бы сформулировать сам закон у меня не хватает математических знаний.
1 авг 08, 15:05    [6016624]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
ModelR
1) доступны метаданные таблиц и колонок (SYS_xxx),
2) на месте имен таблиц и атрибутов допустимы переменные.

1 - это есть
2 - этого нет по причине проверки PL/SQL на этапе компиляции, однако фича полезная (в клиппере есть :)
1 авг 08, 16:26    [6017328]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
сосед. был акцессник
Guest
_мод
сосед. был акцессник

Сам термин "семантика" приложим только к ЯП.

ОК.
Еще раз просмотрел контекст появления замечания.
Позиция принята в ее узком смысле.

2 onstat-
по поводу "навигации":
Это должно быть что-то совершенно простое и неотвратимо понятное.
Если я "не попал", и Бред захочет здесь уточнить использованный термин, то, думаю, ему хватит на это одного - двух предложений.
Тем не менее, спасибо за экспрессивное изложение своей версии.
2 авг 08, 03:01    [6019229]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 18 19 20 21 22 23 [24] 25 26 27   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить