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


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



Теорема(Гипотеза):

Уровень ассоциативного восприятия ( Качество навигации по Бреду(ЧАЛу) )
системы ограничен номером нормальной формы РМД,
который может себе позволить понимать эта система.

Система сможет достигнуть уровня вселенского разума когда сама сможет
вывести нормальную форму N+1 .
(N- максимальный номер нормальной формы РМД используемый системой) .

Кто хочет Нобилевскую премию - доказывайте(опровергайте).


з.ы. Что то меня на философию потянуло.

И хорошо, что потянуло):
24 июл 08, 22:37    [5983403]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
2Бред

К вопросу о качестве представления реального мира моделью данных.

Ваши связи, по сути есть денормализация данных о реальном мире, для
упрощения представления фактов, которые нельзя объяснить.

При дальнейшем анализе это может пролить свет почему вы не можете
придумать не банальные примеры.
ИМХО У Вас в голове не складывается логическая картина, Вы не можете даже себе объяснить
почему все должно быть так как вы пытаетесь преподнести Вашу модель обществу.

То есть она(Ваша модель) не логична для Вас же.

Анекдот в тему
автор

Василий Иванович, на ликбезе задали вопрос сколько будет 0.5 + 0.5.
- Будет литра, Петька.
- Я понимаю, что будет литра, а цифрами сказать не могу.


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

Если хотите доказать, что все не так как я описал - опровергайте гипотезу.

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

Связи, по сути, денормализация данных о реальном мире. Интересно!
Для упрощения (!?) представления фактов (!?), которые нельзя объяснить (!!??).
То есть РМД слишком сложно представляет факты которые нельзя объяснить?
Очень интересно!
Я все Ваши гипотезы легко опровергаю конкретными примерами): Причем абсолютно любой сложности - какой пожелаете):
Но мне очень нравиться, что Вы начали размышлять - видимо это заслуга модераторов):
24 июл 08, 22:42    [5983411]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
мимопробегал
Бред
мимопробегал
про колеса - это сильно

ЧАЛ когда зарплату получает, он в ведомости пишет
получил бумажку достоинством 5000,
бумажку достоинством 5000
...
бумажку достоинством 5000
бумажку 5000
бумажку 100
бумажку 50
...
монетку 5коп
монетку 1коп


а всего сколько не пишет - это ему нафиг не нужно.

Отлично! Поняли о чем речь идет, а вот onstat- говрит: съехал, мол, в другую предметную область):
Неужто на Балабановской фабрике так и есть?

Забыли, кто у нас главный спец по фабрикам?
24 июл 08, 22:44    [5983417]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
Если чесно я сам в шоке от того что вчера написал(Какоето прозрение произошло).

Все описанное очень многое обьясняет, например:

1. Почему ООСУБД тяжелее поддерживать.
2. Почему их тяжелее развивать.
3. Почему "кругу неограниченных людей" (С) Бред их легче проектировать.
4. Какой ценой дается навигация по Бреду(ЧАЛу). И почему она есть причиной неконтролируемого роста информационной энтропии в системе.

И главное почему ООСУБД до сих пор не могут выйти на масштабы массовых промышленных СУБД.
Потому что основная масса проектировщиков систем все это знали до меня.

Умница! Все (ну не все, но многое) очень правльно про ООСУБД. Но меня-то к ООСУБД за что приплели???
24 июл 08, 22:46    [5983421]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
недостатки иерархических
vadiminfo
Декларативный язык предполагает, что достаточно указать какая нужна инфа. А императивный и то как ее извлеч. Проще говоря циклы там. В результате инфу извлекать с помощью декларативного проще. А доступность инфы и является наиболее важной целью создания БД.

Извините, но как-то не очень связанно.
Чем отличается императивный язык от декларативного, я знаю.
Циклы как-то не очень при деле при сравнении императивного языка и декларативного.
Ну и как вы связали утверждения "инфу извлекать с помощью декларативного проще" и "доступность инфы и является наиболее важной целью создания БД" - это два независимых утверждения.
При чём первое не совсем корректно сформулированное.

Я всё больше склоняюсь к мысли, что основное отличие иерархических/сетевых баз от RDBMS есть отсутсвие оптимизатора.
Из этого факта вытекает всё - как достоинства, так и недостатки.
И только условия конкретного проекта могут выявить соотношения достоинств и недостатков для выбора базы. Тривиально, конечно...
Но а как сказать по-другому, когда с той же императивностью - если нужно с predictable (не знаю, как на великом и могучем) скоростью извлекать данные, то императивный язык плюс отсутсвие оптимизатора плюс жесткая структура данных (связи в виде указателей) обставляет декларативный...
А если нужно извлекать данные по не известным на момент создания системы запросам, или структура данных не жёсткая (нет связей в виде указателей, да ещё и сама структура данных может изменятся со временем) то лучше иметь декларативный язык, на основе которого оптимизатор будет писать программу доступа к данным. С циклами (nested loop join). Без участия человека.
Но время доступа к данным будет unpredictable.

Может, и сумбурно, в виде потока мыслей. Происходит процесс оформления мыслей...

Оптимизаторы в ОСУБД эффективнее, чем в "Р"СУБД, что вполне очевидно): Это в свое время обсуждалось. Что за "отсутсвие"):
24 июл 08, 22:49    [5983423]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
декларативный или императивный

Без "и то", а просто "как" ее извлечь. А то, что будет получено объявляется правильным, хотя заранее мы не знаем, что именно будет получено.

Ну, Вы можете и не знать, что хотели получить. Но все еще есть практика, когда заранее знают, чего хоЧут.

декларативный или императивный

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

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

декларативный или императивный

Просто РМ рейдерски захватила понятие декларативный (как и понятие модели данных) и связала его с множество-ориентированностью. Декларативность в РМ вырождена (нет логического вывода), а множество-ориентированность есть во многих обычных (ОО, императивных) языках без всякой декларативности.

Понятие декларативности не захвачено ни кем. Просто язык может быть декларативным. Связанность такого языка с РМ не обязательна. Понятие модели данных тоже не захватывала - есть и другие МД. Хотя понятие ввел автор РМД КОДД. Рм не связывала понятие декларативности с множество-ориентированностью (она построила алгебру, для коией множества обязательны, а алгебра позволила строить декларативный язык БД). Это Вы пытались связать эти понятия в первом абзаце. А во втором типа сами же себя стали опровергать, отрицая эту связь.


декларативный или императивный
Это в рекламный отдел, пожалуйста.

Ну, возможно, в рекламном отделе тоже могут интересоваться достоинствами и недостатками.
Может автор топика для этого одела собирает инфу про недостатки. Может для другого.
Но в данном случае ясно все же кое-какое достоинство декларативного языка перед императивным.
24 июл 08, 23:11    [5983462]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

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

Оптимизаторы в ОСУБД эффективнее, чем в "Р"СУБД, что вполне очевидно): Это в свое время обсуждалось. Что за "отсутсвие"):

Я рыдаль (С)

Для начала потрудитесь пожалуйста привести конкретный пример ОСУБД, коллега. Ато мы теряемся в догадках о чем речь уже второй год подряд. Мне например непонятно чем принципиально ОСУБД отличается от модели CODASYL, ООСУБД и старых добрых мампсов. Насколько я помню ваша контора под названием "Информ Икс" - не путать с Informix - построила некий объектный навигатор который работал поверх Cache?

Так же просьба ссылочку на ваш пост где вами (или кем то еще) было дано формальное (как у Кодда и Дэйта для реляционной) описание модели данных. Формальное - значит не просто с применением математического аппарата такого как например теория множеств или исчисление высказываний, а еще и строгое. Как в Математике принято.

Хотелось бы ссылочку на статейку, на тему как работает оптимизатор в ОСУБД. Или хотя бы основные принципы его работы, в общих чертах. В свое время разработчики IDMS сломались как раз на задаче сделать рабочий оптимизатор для своей СУБД (на модели CODASYL). Да и у разработчиков РСУБД долго "не выходил каменный цветок". Колитесь, коллега как вы разрубили сей гордиев узел.

До самой интересной темы - обработки конкурентных транзакций мы еще не дошли. Вот где веселье-то начнется! После оптимизатора просьба рассказать как в ОСУБД решаются классические проблемы типа конкуренции читатели-писатели при доступе к одним и тем же данным. В отсутсвии такого понятия как запись, блокировка записи, различные по времени версии записи, итп.
25 июл 08, 06:02    [5983839]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Декларативный язык - это когда я говорю ЧТО нужно сделать, но не говорю как. Например в случае SQL:

UPDATE my_table
     SET my_attribute='some new value'
 WHERE my_key=123

Я не говорю СУБД как ей находить записи, удовлетворяющие предикату my_key=123. Это оптимизатор решает, например может решить прочитать ему индекс, отыскать в B*Tree физические номера блоков и записей и дальше поменять там данные. А может просканировать всю таблицу целиком.

В данном (и большинстве) случаев я не говорю СУБД в мелких деталях и подробностях где и как ей блокировать записи, создавать версии записей итп. Я ей говорю ЧТО я хочу:

SET TRANSACTION ISOLATION READ COMMITTED

А как это делать решает сама СУБД. Это - декларативный язык.

Императивный язык это когда на для решения подобной задачи пишутся циклы на коболе и многое из того что реляционная СУБД "решает сама" делается "ручками" т.е. пишется код который определяет КАК это будет делаться.
25 июл 08, 06:31    [5983845]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

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

Императивный язык это когда на для решения подобной задачи пишутся циклы на коболе ...

Естественно код может писаться не только на коболе, но и например на Клиппере или Мампсах. Сути дела это не меняет.
25 июл 08, 06:46    [5983849]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
xz321
Guest
Есть хороший пример для незнающих, про разницу императивных и декларативных языков.

Задача: Поиск слона в Африке

Императиный язык
If Limpopo.hasElephant = true 
    then return Elephant
Else If
   Nil.hasElephant = true 
      then return Elephant
Else If
   Sahara.hasElephant = true 
      then return Elephant
.....
Декларативный язык
select Elephant from Africa
25 июл 08, 09:22    [5984092]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Всех причастных к админству поздравляю с праздником.


Ну поехали,
Бред

onstat-
2Бред

К вопросу о качестве представления реального мира моделью данных.

Ваши связи, по сути есть денормализация данных о реальном мире, для
упрощения представления фактов, которые нельзя объяснить.

При дальнейшем анализе это может пролить свет почему вы не можете
придумать не банальные примеры.
ИМХО У Вас в голове не складывается логическая картина, Вы не можете даже себе объяснить
почему все должно быть так как вы пытаетесь преподнести Вашу модель обществу.

То есть она(Ваша модель) не логична для Вас же.

Анекдот в тему
автор

Василий Иванович, на ликбезе задали вопрос сколько будет 0.5 + 0.5.
- Будет литра, Петька.
- Я понимаю, что будет литра, а цифрами сказать не могу.


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

Если хотите доказать, что все не так как я описал - опровергайте гипотезу.

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

Связи, по сути, денормализация данных о реальном мире. Интересно!
Для упрощения (!?) представления фактов (!?), которые нельзя объяснить (!!??).

То есть РМД слишком сложно представляет факты которые нельзя объяснить?
Очень интересно!


Куда уж проще, РМД описывает эти факты в денормализованом виде,
Вы знаете что такое денормализация в РМД?


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

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

Можете сказать мне каких связей не хватает Петьке для правильного ответа на вопрос
сколько будет 0.5+0.5 без введения связей многие ко многим?

Бред

Я все Ваши гипотезы легко опровергаю конкретными примерами): Причем абсолютно любой сложности - какой пожелаете):


Опровергайте.
25 июл 08, 11:33    [5984926]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
MX -- ALEX
Guest
xz321
Есть хороший пример для незнающих, про разницу императивных и декларативных языков.

Задача: Поиск слона в Африке

Императиный язык
If Limpopo.hasElephant = true 
    then return Elephant
Else If
   Nil.hasElephant = true 
      then return Elephant
Else If
   Sahara.hasElephant = true 
      then return Elephant
.....
Декларативный язык
select Elephant from Africa



Процедуры поиска в Императивных пишем один раз !
и навсегда

Поэтому у нас поиск слона выглядит точно так же

искать "слон" в "Африка"

Кажется Вы недооцениваете Императивщиков и Империалистов:)
25 июл 08, 11:49    [5985082]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Бред

Вы упорно уходите от сути вопроса о связях,


Меня не интересуют связи, мне интересно что вы в них полезного нашли.

Бред

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


Какой структуры?
Я вижу связи только как аспект бардака в системе.

Бред

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


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

з.ы. ALL, Вы верите в то, что такую чушь может нести говорит человек, который доводит до ума проекты?
25 июл 08, 12:27    [5985412]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
onstat-
Вы верите в то, что такую чушь может нести говорит человек, который доводит до ума проекты?
Не до ума, а до сдачи заказчику. Это разные вещи. Верю. Доводит.
25 июл 08, 12:42    [5985534]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
2Бред

На досуге задумайтесь не о навигации как таковой, а о качестве навигации
и как это качество собирается контролировать ваша модель.

анекдот в тему

- Штурман, скорость?
-5!
-Что 5?
-Что скорость?


Навигация сама по себе не имеет смысла.

з.ы. Вы находясь в кругу неограниченных людей очень сильно сами себя ограничили,
или он(круг) Вас ограничил.
Само по себе понятий круг(область) это уже ограничение, посмотрите на жизнь с другой стороны.
25 июл 08, 12:51    [5985611]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Бред

Я все Ваши гипотезы легко опровергаю конкретными примерами): Причем абсолютно любой сложности - какой пожелаете):



Можете начать опровержения гипотезы с использования очень простых примеров
из приведенных мною анекдотов:
1. Про Петьку ( связи один ко многим и многие к многим)
2. Про штурмана ( закольцовка связей)
25 июл 08, 16:14    [5987239]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
декларативный или императивный
Просто все языки выделяются по критерию
- поддерживает операции с множествами
- не поддерживают (а посему нужны циклы)

+1
РМД изначально придумана для операций с множествами.
Ее предшественники - на операции с записями, в т.ч. навигацию по ссылкам.

2 недостатки иерархических
Является ли это "для операций с множествами" преимуществом всегда? Наверно нет:

select 
   DETAIL.* 
from 
   DETAIL , 
   (select header_id, sum (amount) from DETAIL having sum (amount) >100) D2
where 
   DETAIL.header_id = D2.header_id
--Строки тех документов, где сумма строк по полю amount больше заданного лимита.
Очевидно, процедурно- навигационно это был бы однопроходный алгоритм. Догадается ли оптимизатор - вопрос....
Поэтому кроме чисто "множественного" SQL в СУБД встроены во-первых процедурные PL\SQL и др., а также специальные предопределенные алгоритмы (ORACLE - analytic functions ). Последние кстати - вполне в рамках манипулирования множествами.
25 июл 08, 17:01    [5987577]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Зл0й
Бред

Оптимизаторы в ОСУБД эффективнее, чем в "Р"СУБД, что вполне очевидно): Это в свое время обсуждалось. Что за "отсутсвие"):

Я рыдаль (С)

Для начала потрудитесь пожалуйста привести конкретный пример ОСУБД, коллега. Ато мы теряемся в догадках о чем речь уже второй год подряд. Мне например непонятно чем принципиально ОСУБД отличается от модели CODASYL, ООСУБД и старых добрых мампсов. Насколько я помню ваша контора под названием "Информ Икс" - не путать с Informix - построила некий объектный навигатор который работал поверх Cache?

Так же просьба ссылочку на ваш пост где вами (или кем то еще) было дано формальное (как у Кодда и Дэйта для реляционной) описание модели данных. Формальное - значит не просто с применением математического аппарата такого как например теория множеств или исчисление высказываний, а еще и строгое. Как в Математике принято.

Хотелось бы ссылочку на статейку, на тему как работает оптимизатор в ОСУБД. Или хотя бы основные принципы его работы, в общих чертах. В свое время разработчики IDMS сломались как раз на задаче сделать рабочий оптимизатор для своей СУБД (на модели CODASYL). Да и у разработчиков РСУБД долго "не выходил каменный цветок". Колитесь, коллега как вы разрубили сей гордиев узел.

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

Ну что же Вы опять отвлеклись от веса Сидорова в килограммах?):
Рыдайте на здоровье, тем не менее оптимизация действительно давно обсуждалась, и никаких других выводов и быть не могло):
А Вы не теряйтесь в догадках, а ответьте хотя бы на один конкретный вопрос, причем для этого ответа не нужны никакие "ссылочки", а нужно лишь набраться мужества):
Плохо, что Вам ничего не понятно про ОСУБД и ООСУБД (на основе ООП). При чем здесь mumps. Эта среда не поддерживает никакой модели данных, и предназначена для создания СУБД - стыдно этого не знать):
У меня никогда не было и нет никакой конторы):
Все формально и строго. Мне надоело "давать ссылочку", тем более, что примеры все перед Вами. Не отвлекайтесь, пожалуйста. Если нужно, уточните сколько я Вам должен заплатить, чтобы Вы не дурачились):
Будет Вам про все, и про оптимизаторы (у несчастных "сломавшихся" разработчиков IDMS не было среды разработки СУБД, так же, как и у несчастных разработчиков "Р"СУБД), и про навигаторы, и про "конкурентные транзакции". Заканчивайте с этим детским лепетом - Вы же серьезный человек - ввязались в разговор о семантике данных, так давайте уж - разговаривайте):
Не отвлекайтесь, пожалуйста, от нашего с Вами разговора о системах восстановления навигации и смысла данных, утраченных в РБД. Пожалуйста, расскажите на рассмотренных примерах о нескольких связях между двумя объектами и просто о Весе, кг): Чего Вы стесняетесь-то - Вы же не виноваты в этих кошмарных "современных" архитектурах. Правильно?
25 июл 08, 20:31    [5988420]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
xz321
Есть хороший пример для незнающих, про разницу императивных и декларативных языков.

Задача: Поиск слона в Африке

Императиный язык
If Limpopo.hasElephant = true 
    then return Elephant
Else If
   Nil.hasElephant = true 
      then return Elephant
Else If
   Sahara.hasElephant = true 
      then return Elephant
.....
Декларативный язык
select Elephant from Africa
Хорошая шутка):
К сожалению, "сначала" структура, а "потом" манипулирование, а в данном случае неизвестно что такое Limpopo, Nil, Sahara, Africa, Elephant. У Дейта (в 8-м издании на стр.115) тоже есть "замечательный пример" про "автоматическую" и "ручную" навигацию. А можно было поднатужиться, и еще десяток строк приписать):
25 июл 08, 20:46    [5988455]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
Всех причастных к админству поздравляю с праздником.


Ну поехали,
Бред

onstat-
2Бред

К вопросу о качестве представления реального мира моделью данных.

Ваши связи, по сути есть денормализация данных о реальном мире, для
упрощения представления фактов, которые нельзя объяснить.

При дальнейшем анализе это может пролить свет почему вы не можете
придумать не банальные примеры.
ИМХО У Вас в голове не складывается логическая картина, Вы не можете даже себе объяснить
почему все должно быть так как вы пытаетесь преподнести Вашу модель обществу.

То есть она(Ваша модель) не логична для Вас же.

Анекдот в тему
автор

Василий Иванович, на ликбезе задали вопрос сколько будет 0.5 + 0.5.
- Будет литра, Петька.
- Я понимаю, что будет литра, а цифрами сказать не могу.


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

Если хотите доказать, что все не так как я описал - опровергайте гипотезу.

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

Связи, по сути, денормализация данных о реальном мире. Интересно!
Для упрощения (!?) представления фактов (!?), которые нельзя объяснить (!!??).

То есть РМД слишком сложно представляет факты которые нельзя объяснить?
Очень интересно!


Куда уж проще, РМД описывает эти факты в денормализованом виде,
Вы знаете что такое денормализация в РМД?


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

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

Можете сказать мне каких связей не хватает Петьке для правильного ответа на вопрос
сколько будет 0.5+0.5 без введения связей многие ко многим?

Бред

Я все Ваши гипотезы легко опровергаю конкретными примерами): Причем абсолютно любой сложности - какой пожелаете):


Опровергайте.

Вы чересчур переживаете (хотя очень хорошо, что переживаете), и это мешает Вам понимать основы БД):
"Описание фактов в денормализованном виде" и "денормализация в РМД". Вы о чем? Видите как плохо уходить от конкретных примеров): Если не было "нормализации", то как Вы осуществляете "денормализацию"? Я то очень хорошо знаю что такое нормализация и денормализация и в ОМД и в РМД. Этому вопросу уже была посвящена не одна тема):
Успокойтесь, и возвращайтесь к практике.
Связи "многие-ко-многим" естественным образом поддерживаются во многих реализациях ОСУБД, я Вам это несколько раз сообщил. То есть в "моей" существующей модели. В "моей" будущей модели им, вероятнее всего, места не найдется, так как, в действительности, их нет):
"Косвенные связи многие-ко-многим" - очень хорошо. Вы мыслите! Давайте о них поговорим конкретно, с удовольствием.
"Закольцовка связей" - я буду считать, что Вы понимаете о чем говорите. Это очень протой частный случай для связи "сам с собой" - разрешается автоматически, конечно же, и я считаю, что Вы это понимаете, но тот факт, что в РМД с этим проблема, а Вас РМД "всячески устраивает", мешает Вам рассуждать объективно):
Залезть, то ли в мозг, то ли в душу к Петьке, и сказать каких связей ему не хватает действительно не просто): А у Вас это получилось?):
Давайте не отвлекаться, а?
25 июл 08, 21:03    [5988501]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
Бред

Вы упорно уходите от сути вопроса о связях,


Меня не интересуют связи, мне интересно что вы в них полезного нашли.

Бред

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


Какой структуры?
Я вижу связи только как аспект бардака в системе.

Бред

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


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

з.ы. ALL, Вы верите в то, что такую чушь может нести говорит человек, который доводит до ума проекты?

Оригинально! То возбужденно вопрошаете о связях, и даже высказываете собственные идеи, то - не интересуют. Ну если не интересуют, тогда понятно почему Вы уходите от аспекта структуры):
Итак - связей быть не должно - от них только вред. Я получил ясный ответ):
Точно так же идентификации, навигации и семантики данных не должно быть в базе данных. Очень хорошо - вполне в духе "тусовки"):
И в завершении очередная демонстрация полного непонимания БД. А когда непонимание, то ничего не остается, как произнести очередное заклинание про "чушь"): Ну мне не превыкать - знаете сколько чуши, подобно Вашей, здесь уже сказали Ваши коллеги по несчастью?):
25 июл 08, 21:12    [5988523]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Павел Воронцов
onstat-
Вы верите в то, что такую чушь может нести говорит человек, который доводит до ума проекты?
Не до ума, а до сдачи заказчику. Это разные вещи. Верю. Доводит.

Какие люди! Не выдержали):
Видимо onstat- сдал заказчику, а в душе-то понимает, что не довел до ума, и вот, значит, начинает доводить. Без передышки):
Не верю. Хотя, кто знает):
25 июл 08, 21:15    [5988529]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
2Бред

На досуге задумайтесь не о навигации как таковой, а о качестве навигации
и как это качество собирается контролировать ваша модель.

анекдот в тему

- Штурман, скорость?
-5!
-Что 5?
-Что скорость?


Навигация сама по себе не имеет смысла.

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

Приятно, в общем-то, что Вы не успокаиваетесь): Хотя это мешает объективно подходить к обсуждаемым вопросам. Не стоит обижаться на собственную ограниченность, всего лишь от того, что Вам об этом сказали, а не Вы сами догадались): Я вот совершенно не обижаюсь, и все время учусь):
Теперь Вы хотите вернуться к навигации? И поговорить о "качестве навигации" и о ее "бессмысленности, как навигации"? И для начала делаете вывод, что я себя ограничил???
Итак, ни одного вопроса по существу Вы обсудить просто не в состоянии): Ну хорошо - я подожду.
25 июл 08, 21:19    [5988542]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
Бред

Я все Ваши гипотезы легко опровергаю конкретными примерами): Причем абсолютно любой сложности - какой пожелаете):



Можете начать опровержения гипотезы с использования очень простых примеров
из приведенных мною анекдотов:
1. Про Петьку ( связи один ко многим и многие к многим)
2. Про штурмана ( закольцовка связей)

Вот, вот. Я и говорю - подожду, когда Вы успокоитесь, и вернетесь с эстрады (с анекдотами) в аудиторию (с базами данных)):
25 июл 08, 21:22    [5988550]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
ModelR
декларативный или императивный
Просто все языки выделяются по критерию
- поддерживает операции с множествами
- не поддерживают (а посему нужны циклы)

+1
РМД изначально придумана для операций с множествами.
Ее предшественники - на операции с записями, в т.ч. навигацию по ссылкам.

2 недостатки иерархических
Является ли это "для операций с множествами" преимуществом всегда? Наверно нет:

select 
   DETAIL.* 
from 
   DETAIL , 
   (select header_id, sum (amount) from DETAIL having sum (amount) >100) D2
where 
   DETAIL.header_id = D2.header_id
--Строки тех документов, где сумма строк по полю amount больше заданного лимита.
Очевидно, процедурно- навигационно это был бы однопроходный алгоритм. Догадается ли оптимизатор - вопрос....
Поэтому кроме чисто "множественного" SQL в СУБД встроены во-первых процедурные PL\SQL и др., а также специальные предопределенные алгоритмы (ORACLE - analytic functions ). Последние кстати - вполне в рамках манипулирования множествами.

+2
А в самом начале "спора" (четыре года назад) я приводил статистику: большинство действий в типичных OLTP-системах сводятся к выполнению операций над экземпляром объекта или над множеством экземпляров объекта B, связанных с экземпляро объекта A. Здесь от SQL никакой пользы. А для выполнения пользователями отчетов с использованием инструментального средства тоже не имеет значения как это делается. Однако декларативные языки полезны - это пока никем не оспаривалось.
25 июл 08, 21:30    [5988565]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 15 16 17 18 19 [20] 21 22 23 24 .. 27   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить