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

А вот не надо добавлять :). Про объекты речи не было.

Надо): Была):
16 июл 08, 21:42    [5945008]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
Бред

Логический смысл связи заключается в том, что это связь между объектами, а не еще один объект):


Бред

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



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

Что вы предлагаете делать?

Изменять архитектуру БД где ребро уже будет не связью а объектом?

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


А при желании иметь достаточно масштабируемую систему, связь без свойств превращается в апендикс. И никакой разумный разработчик этими тупиками пользоваться не будет.

Как по мне, так отношения в РМД намного гибче масштабируемее связей.


Кроме того совета, который я Вам дал выше, советую так же вчитываться в Ваши собственные тексты, прежде, чем их отправлять):
После того, как Вы написали "есть объект - ребро графа", читать дальнейший Ваш текст практически невозможно. Пожалуйста, разберитесь с историей вопроса, и сформулируйте, для начала, для себя на концептуальном уровне вне зависимости от МД: есть связи или их нет. Дальше будет легче):
16 июл 08, 21:49    [5945034]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
Бред

Опять ошибаетесь из-за невнимательности): Надеюсь):
Никакая это не классическая задача): "Классическая "задача" это только
Изделие <-Состоит из/Входит в-> Изделие
Чтобы Вы (вместе с _мод) поняли продолжу список:
Изделие <-Состоит из/Входит в-> Изделие
Изделие <-Используется как комплектующее для/Является комплектующим для-> Изделие
Изделие <-Используется для упаковки/Упаковывается в-> Изделие
Изделие <-Использует в качестве аналога/Является аналогом- Изделие
И т.д.
Ну а дальше у Вас опять голые декларации про "грамотно построенную архитектуру", которая:
1) является вынужденным решением из-за недостатков РМД;
2) удлиняет сроки разработки и снижает качество приложений;
3) приводит к постоянному программированию даже самых простых приложений.
И, конечно, у этих безобразных, а не "грамотных" архитектур есть лидеры, кто бы сомневался):
Но это теория, а почему бы Вам не показать на рассматриваемых конкретных примерах, как все делается в "грамотных архитектурах"?): Вот _мод хотя бы старается показать. Может Вы ему поможете?):


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


Изделие <-Состоит из/Входит в-> Изделие
V
|
V
в количестве N штук



Такая связь в большенстве случаев будет заменена обьектом описывающим связь еще до выхода преальфа версии.

В обсуждаемом примере, который Вы опять "дернули", не подумав, речь идет о представлении множества связей между двумя объектами, и больше ни о чем): А о том, о чем Вы говорите я уже сказал в диалоге с _мод: про одну колонку Количество в "таблице" ("модели данных _мод"), представляющей сущность "Состав изделия". Пожалуйста, будьте внимательнее): Никакая связь никогда не будет заменена объектом - это очевидно. Что касается вопроса реализации связей (могут ли у связей быть характеристики), то я свое мнение ясно высказал. Советую Вам, чтобы не запутаться совсем, рассмотреть "не истинные связи" (по Дейту), и их реализацию в различных МД. Этому как раз и посвящена большая часть этой темы.
16 июл 08, 21:59    [5945059]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
применяются таблицы без колонок. Я правильно понял?

Почти правильно - в любой МД м.б. таблицы без колонок.
17 июл 08, 09:20    [5945833]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Вот как это выглядит в репозитории метаданных ОСУБД в результате проектирования БД:

То, что вы здесь пытаетесь описать есть не СУБД а приложение, ориентированное на конечного пользователя. Такие приложения разного качества не делал только ленивый. Проблема в том что с помощью такого приложения можно строить толко очень простые т.н. фактографические системы (о чем я уже говорил). К СУБД и МД это вообще не имеет никакого отношения.
17 июл 08, 09:26    [5945856]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

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

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


Извините, действиетльно я пока еще глубоко не вник.

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

Можете мне пояснить в чем смысл оставлять связь между изделиями в БД?



Бред

Пожалуйста, разберитесь с историей вопроса, и сформулируйте, для начала,


Дайте же всетаки ссылку на концепции, по другому я ознакомиться не смогу.
У меня нет времени перечитывать горы флейма.

Бред

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


На концептуальном уровне для меня все ясно, я писал:
автор

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


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

Связь - это никому не нужный баласт.

Приведите Ваши аргументы чем связь концептуально лучше отношений в РМД.
В чем ее преймущество?
17 июл 08, 10:55    [5946438]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

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

Приведите Ваши аргументы чем связь концептуально лучше отношений в РМД.
В чем ее преймущество?


прошу учесть тот факт что
Бред

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


Использование сущности "Состав изделия" есть фактом использования отношений из РМД.

Если всетаки сущьность "Состав изделия" с вашей точки зрения
не есть отношением , то чем оно концептуально является в вашей модели?
17 июл 08, 11:13    [5946608]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
что бы небыло придирок к словам и инсинуаций
следующую цитату
onstat-

Если всетаки сущьность "Состав изделия" с вашей точки зрения
не есть отношением , то чем оно концептуально является в вашей модели?



Следует читать так :

Если использование сущьности "Состав изделия" с вашей точки зрения
не есть использованием отношений РМД,
то чем концептуально является использование сущьности "Состав изделия" в вашей модели?
17 июл 08, 11:27    [5946704]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

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

А что Вы ответили???
1. Речь нигде здесь не шла о "системах построения отчетов". Вы сами, неизвестно зачем, перескочили на другую тему, не желая отвечать на конкретные вопросы по теме):

Вы не понимаете что такое реляционная СУБД. Она по определению не является:
- CASE-средством для разработки приложений
- Прикладным приложением для хранения метаданных о предметной области
- Прикладным приложением для разработки отчетов
итп.

Если поставленная задача включает построение отчетов, то этим занимается не СУБД (т.к. это не ее задача) а система для генерации отчетов, такая как например Microstrategy, Business Objects, Pentaho, Crystal Reports итп. Молоток предназначен чтобы гвозди забивать, а чтобы шурупы закручивать есть отвертка.

Бред

2. Какие метаданные, о которых Вы пишете в который раз??? Потрудитесь прочитать что я Вам написал): Смысл есть в метаданных БД или нет??? Какая моя "посылка"??? Почему Вы уходите от ответов???

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

Бред

3. Судя по Вашему очередному резкому повороту (в сторону бесплатных "систем представления смысла данных") смысла в Р"перБД, все-таки, нет. Правильно?

см. выше

Бред

4. Еще раз обратите внимание, что я конкретно объясняю почему убожество, без ссылок на каких-то пацанов. Не стоит переключаться с БД на ХД - эту абсолютно не обоснованную и бесперспективную технологию): Давайте мирно вернемся к БД, и не будем уходить от сути вопросов.

Просто в конце 70х - начале 80х годов прошлого века монолитные системы где "все в одном флаконе" начали постепенно умирать. И к 90м практически вымерли. Современные системы строятся из компонентов, таких как СУБД, система построения отчетов, хранилище метаданных, итп.

Бред

5. Замечательно, что Вам все ясно!!! За час можете ответить на кокретные вопросы без демагогии??? И я заплачу Вам 150 долларов):

без комментариев.

Бред

6. Про спичечные фабрики к vadiminfo, пожалуйста): ОСУБД на mumps, конечно, будут работать на GT.M. Но Вы опять упорно уходите от сути вопросов представления связей в частности и семантики данных в целом в различных СУБД, основанных на различных МД):

Не говорите ерунду. Приложение написанное для каши при переходе на GT.M придется переписать.

Бред

7. В какой "репозиторий метаданных" я должен лезть за своим счастьем???

В зависимости от того какое хранилище метаданных у вас установлено ответ может быть разным. Например Microstrategy.
17 июл 08, 19:01    [5950560]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
применяются таблицы без колонок. Я правильно понял?

Почти правильно - в любой МД м.б. таблицы без колонок.


А я хочу не почти, а совсем):
А Вы опять выдернули слова):
Мой вопрос на основании Вашего же сообщения:

"То есть для представления сущностей (а не связей между сущностями) в некоей "Вашей модели" применяются таблицы без колонок. Я правильно понял?"

Пожалуйста, без выдергивания слов, если можно, ответьте):
18 июл 08, 18:45    [5956994]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Вот как это выглядит в репозитории метаданных ОСУБД в результате проектирования БД:

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

Это очень глубокое заблуждение, должен сказать в очередной раз.
Это Вы здесь пытаетесь "превратить" ОСУБД в какое-то "приложение, с помощью которого можно строить системы". Опять о чем-то освоем):
Еще раз предлагаю не уходить от теории БД, моделей данных и СУБД ни к каким "приложениям", и не вырывать "нужные" слова из контекста, всего лишь из-за досады на свою недостаточную подготовку):
18 июл 08, 18:51    [5957019]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
Бред

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


Извините, действиетльно я пока еще глубоко не вник.

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

Можете мне пояснить в чем смысл оставлять связь между изделиями в БД?



Бред

Пожалуйста, разберитесь с историей вопроса, и сформулируйте, для начала,


Дайте же всетаки ссылку на концепции, по другому я ознакомиться не смогу.
У меня нет времени перечитывать горы флейма.

Бред

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


На концептуальном уровне для меня все ясно, я писал:
автор

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


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

Связь - это никому не нужный баласт.

Приведите Ваши аргументы чем связь концептуально лучше отношений в РМД.
В чем ее преймущество?


Спасибо за желание разобраться.
Сначала про "состав изделия". Что мы видим в окружающей действительности.
Давайте посмотрим на автомобиль, мимо которого мы сейчас проходим по улице. У него четыре колеса ("Вашего" автомобиля я не вижу, у "моего" - четыре). Однако очевидно, что в состав этого автомобиля входит не Колесо в Количестве 4, а
Колесо 1
Колесо 2
Колесо 3
Колесо 4
В противном случае, увидев двух братьев-близницов, идущих нам навстречу по улице, пока мы смотрим на автомобиль, мы бы сказали, что это один человек в Количестве 2. А это как-то не по-человечески): Так что будем продолжать по-человечески):
Я советовал Вам обратить пристальное внимание на "не истинные связи" по Дейту. Дейт (как и большинство других специалистов в области БД - какая-то "заколдованная" наука) не обращает внимание на высказывание академика Гинзбурга: "Наука отличается от ненауки тем, что оперирует фактами". И постоянно что-то выдумывает. В данном случае про "не истинные" и "истинные связи". Вот мы постояли рядом с автомобилем и смело можем утверждать:

1. Никаких связей "многие-ко-многим" не существует, так же как ранее мы выяснили, что не существует никаких небинарных связей.
2. Сущность не может "превратиться" в несущность.
3. А связь не может "превратиться" в несвязь.
4. "Не истинные связи" (по Дейту) не могут превратиться в "истинные", так как этих связей ("многие-ко-многим") просто не существует.
5. "Не истинные" связи как раз и являются самыми настоящими связями.
6. В РМД связи не поддерживаются, и ее нельзя назвать моделью данных. Подобно тому, как отделение атрибутов сущности от сущности с помощью атрибутов сущности является грубой ошибкой в РМД, объявление связи объекта A с объектом B путем наложения каких-то ограничений на "свойство" объекта B (!?), и, к тому же, представление объекта A как свойства объекта B, является точно такоей же грубой ошибкой. Возможно поэтому, споря с Коддом и Дейтом, местные "специалисты" несколько лет утверждали, что кортежи не представляют никаких сущностей, а "ключи" не используются для представления связей между сущностями.

Остается открытым вопрос: следует ли при моделировании в целях абстрагирования использовать концепцию "связь многие-ко-многим"? Просто потому что ее "следы" обнаруживаются в естественных языках, тоже "моделирующих" действительность. Например, Петров говорит: "Я учился в 228-ой школе, а потом я учился в МГУ". Или: "В МГУ учились мои друзья - Иванов и Сидоров". И, вроде бы естественным образом, получаем "связь":
Человек <-Учился в/В котором учился-> Учебное заведение

Я считаю, что не следует, во всяком случае во всем, что касается МД, БД и СУБД. Это намного упростит понимание БД, и сделает их намного эффективнее. А вот что действительно стоит сделать, так это типизировать объекты на "сущности" и "события (процессы)" (участниками которых являются сущности). При этом в рамках "события (процесса)" (например, рассмотренного нами процесса обучения людей в учебных заведениях) можно, среди прочего, объявлять и автоматически поддерживать на уровне приложения и "связи" между парами участников события (процесса), которые, само-собой, будут "получаться" "многие-ко-многим" (например,
Человек <-Учился в/В котором учился-> Учебное заведение)

Как я уже говорил, в известных мне реализациях ОСУБД поддерживаются связи "многие-ко-многим", и у них, конечно, могут быть характеристики. О преимуществах ОСУБД перед "Р"СУБД здесь (на sql.ru) уже говорилось подробно. Причем по всем аспектам, от навигации и семантики данных до оптимизации запросов. Сейчас я Вам вкратце изложил одно из направлений дальнейшего развития МД.
Оп, извиняюсь, выгоняют): У нас сегодня праздник на работе):
На остальные вопросы отвечу в выходные. Если, конечно, доберусь до компьютера, для которого доблестные модераторы не заблокировали возможность отправлять сообщения):
18 июл 08, 19:44    [5957222]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Бред
_мод
Бред
Вот как это выглядит в репозитории метаданных ОСУБД в результате проектирования БД:

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

Это очень глубокое заблуждение, должен сказать в очередной раз.
Это Вы здесь пытаетесь "превратить" ОСУБД в какое-то "приложение, с помощью которого можно строить системы". Опять о чем-то освоем):

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

Бред

Еще раз предлагаю не уходить от теории БД, моделей данных и СУБД ни к каким "приложениям", и не вырывать "нужные" слова из контекста, всего лишь из-за досады на свою недостаточную подготовку):

Предлагаю взглянуть на историю теории БД и моделей данных. В 70х годах СУБД были монолитные (IMS, IDMS, Mumps) с императивными языками типа кобола итп. Потом ы 80х появились реляционные СУБД с декларативными языками и к 90м монолитные системы перешли в нишу Legacy.
19 июл 08, 01:19    [5958169]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
В всем ответе на конкретный вопрос
автор

Приведите Ваши аргументы чем связь концептуально лучше отношений в РМД.
В чем ее преймущество?


прошу учесть тот факт что
Бред

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


Использование сущности "Состав изделия" есть фактом использования отношений из РМД.

Если всетаки сущьность "Состав изделия" с вашей точки зрения
не есть отношением , то чем оно концептуально является в вашей модели?

Что за детский сад? В РМД есть единственный элемент структуры - отношение. И нет никаких сущностей и никаких связей.
19 июл 08, 10:17    [5958410]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
что бы небыло придирок к словам и инсинуаций
следующую цитату
onstat-

Если всетаки сущьность "Состав изделия" с вашей точки зрения
не есть отношением , то чем оно концептуально является в вашей модели?



Следует читать так :

Если использование сущьности "Состав изделия" с вашей точки зрения
не есть использованием отношений РМД,
то чем концептуально является использование сущьности "Состав изделия" в вашей модели?

Детский сад жирным шрифтом):
От того что сущность у Вас стала "сущьностью" ее все равно нет в РМД. Нет никакого "Состава изделия". Есть бессмысленный набор данных. Вы должны в дополнение к "Р"СУБД иметь несколько систем для восстановления навигации, смысла данных, доработки смысла данных, так как он искажается в системах восстановления смысла и т.д. Это Вам здесь разъясняют _мод и ЗлОй. Вы не просто из пушки по воробьям стреляете. Вы для совершения одного выстрела по одному воробью: строите завод по производству пушки, производите пушку, даставляете ее (тяжеленную) к месту выстрела. И когда, вытерев пот со лба, Вы хотите дать команду на выстрел, воробей, естественно, улетает. Вы оставляете пушку зарастать травой, и строите новый завод): И с пафосом сообщаеете, что это "современная архитектура"): Я хочу Вас вывести из широкого круга ограниченных людей, а Вы упираетесь, да еще жирным шрифтом):
Инсинуациями здесь постоянно занимаются мои оппоненты. Вы хотя бы не занимайтесь):
А в ОМД (не моей) состав изделия описывается с помощью взаимосвязанных объектов, как это видно из примеров, то есть смысл "хранится" на уровне СУБД, а не в дополнительных системах.
19 июл 08, 10:45    [5958434]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Зл0й
Бред

А что Вы ответили???
1. Речь нигде здесь не шла о "системах построения отчетов". Вы сами, неизвестно зачем, перескочили на другую тему, не желая отвечать на конкретные вопросы по теме):

Вы не понимаете что такое реляционная СУБД. Она по определению не является:
- CASE-средством для разработки приложений
- Прикладным приложением для хранения метаданных о предметной области
- Прикладным приложением для разработки отчетов
итп.

Если поставленная задача включает построение отчетов, то этим занимается не СУБД (т.к. это не ее задача) а система для генерации отчетов, такая как например Microstrategy, Business Objects, Pentaho, Crystal Reports итп. Молоток предназначен чтобы гвозди забивать, а чтобы шурупы закручивать есть отвертка.

Бред

2. Какие метаданные, о которых Вы пишете в который раз??? Потрудитесь прочитать что я Вам написал): Смысл есть в метаданных БД или нет??? Какая моя "посылка"??? Почему Вы уходите от ответов???

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

Бред

3. Судя по Вашему очередному резкому повороту (в сторону бесплатных "систем представления смысла данных") смысла в Р"перБД, все-таки, нет. Правильно?

см. выше

Бред

4. Еще раз обратите внимание, что я конкретно объясняю почему убожество, без ссылок на каких-то пацанов. Не стоит переключаться с БД на ХД - эту абсолютно не обоснованную и бесперспективную технологию): Давайте мирно вернемся к БД, и не будем уходить от сути вопросов.

Просто в конце 70х - начале 80х годов прошлого века монолитные системы где "все в одном флаконе" начали постепенно умирать. И к 90м практически вымерли. Современные системы строятся из компонентов, таких как СУБД, система построения отчетов, хранилище метаданных, итп.

Бред

5. Замечательно, что Вам все ясно!!! За час можете ответить на кокретные вопросы без демагогии??? И я заплачу Вам 150 долларов):

без комментариев.

Бред

6. Про спичечные фабрики к vadiminfo, пожалуйста): ОСУБД на mumps, конечно, будут работать на GT.M. Но Вы опять упорно уходите от сути вопросов представления связей в частности и семантики данных в целом в различных СУБД, основанных на различных МД):

Не говорите ерунду. Приложение написанное для каши при переходе на GT.M придется переписать.

Бред

7. В какой "репозиторий метаданных" я должен лезть за своим счастьем???

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

Бесподобно!
Опять ни одного конкретного ответа, а только политические декларации и откровенная чушь про GT.M.
Но в целом, косвенно, а не на примере, Вы подтвердили все что я сказал. При этом Вы очень бодро развели руками (мол, так получилось), объясняя всю "прелесть" бессмысленного набора многочисленных систем, обеспечивающего, в конце концов смысл данных. Зачем-то опять ляпнули про монолит. И продемострировали непонимание даже "реляционной" технологии. Ну что я могу поделать - не хотите по существу говорить - не говорите. А зачем было сообщения-то сюда писать, в таком случае?):
19 июл 08, 10:56    [5958447]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Зл0й
Бред
_мод
Бред
Вот как это выглядит в репозитории метаданных ОСУБД в результате проектирования БД:

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

Это очень глубокое заблуждение, должен сказать в очередной раз.
Это Вы здесь пытаетесь "превратить" ОСУБД в какое-то "приложение, с помощью которого можно строить системы". Опять о чем-то освоем):

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

Бред

Еще раз предлагаю не уходить от теории БД, моделей данных и СУБД ни к каким "приложениям", и не вырывать "нужные" слова из контекста, всего лишь из-за досады на свою недостаточную подготовку):

Предлагаю взглянуть на историю теории БД и моделей данных. В 70х годах СУБД были монолитные (IMS, IDMS, Mumps) с императивными языками типа кобола итп. Потом ы 80х появились реляционные СУБД с декларативными языками и к 90м монолитные системы перешли в нишу Legacy.

А я предлагаю рассматривать конкретные вопросы без исторического экскурса. И не путаться постоянно:
1. "Р"СУБД - это модульная система (очень хорошо - ОСУБД тоже).
2. Есть отдельный продукт. Понятно, а как же иначе денег слупить?
3. Извлечем метаданные из одного модуля, улучшим в специальном продукте, и переложим в другой модуль. Класс!
4. Это позволяет использовать многочисленные "стандартные" отдельные продукты. Супер! Кто бы сомневался):
5. Осталось только "облегчить" интеграцию. А чего не облегчить - берем и облегчаем.
Вот теперь, пожалуйста, на конкретном, рассмотренном нами примере продемонстрируйте всю прелесть этого кошмара):
19 июл 08, 11:12    [5958459]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
ЧАЛовед со стажем
Guest
ЧАЛ
Ну что я могу поделать ...


Варианты :

1. Разобраться наконец для чего предназначена БД и в чём преемущества модульности над монолитом
2. Продолжать веселить народ ответами в стиле "сам дурак МУМПС/ООБД рулят только никто про это не знает"
3. Перестать веселить народ и вернуться к разгребанию М-козявочек и реализации самопальных транзакций и хранилищ (причём последние именовать "объектным навигатором 2000+")
4. Бросить надоевшую реляционную теорию и занятся ниспроверганием ОТО или Всемирной истории
19 июл 08, 18:20    [5959053]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Это очень глубокое заблуждение, должен сказать в очередной раз.

Это не по существу. Не вижу смысла продолжать дискуссию в таком тоне.
21 июл 08, 10:25    [5961782]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
смысл "хранится" на уровне СУБД

Это перл ! Дальше можно не продолжать
21 июл 08, 10:37    [5961849]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

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


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


В моей машине 5 колес.

Колесо переднее правое
Колесо переднее левое
Колесо задннее правое
Колесо заднее левое
Колесо запаска

И в данном случае количество колес определяется подсчетом count(*) по атрибуту моя машина.

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

Бред

В противном случае, увидев двух братьев-близницов, идущих нам навстречу по улице, пока мы смотрим на автомобиль, мы бы сказали, что это один человек в Количестве 2. А это как-то не по-человечески): Так что будем продолжать по-человечески):


То же самое

Бред

Я советовал Вам обратить пристальное внимание на "не истинные связи" по Дейту. Дейт (как и большинство других специалистов в области БД - какая-то "заколдованная" наука) не обращает внимание на высказывание академика Гинзбурга: "Наука отличается от ненауки тем, что оперирует фактами". И постоянно что-то выдумывает. В данном случае про "не истинные" и "истинные связи". Вот мы постояли рядом с автомобилем и смело можем утверждать:

1. Никаких связей "многие-ко-многим" не существует, так же как ранее мы выяснили, что не существует никаких небинарных связей.



Дайте ссылку на документацию в конце концов.
Без ссылки на документацию я не буду дальше продолжать дискуссию,
Мы находимся на разных уровнях понимания в соответствии с законом мухи( который я не просто так приводил) и без выравнивания уровней понимания я считаю данную дискуссию зря потраченным
временем. Я могу потратить это время с более предсказуемым положительным результатом.
21 июл 08, 11:01    [5962038]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

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

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


Сходите лучше в форумы по искуственному интелекту и(или) ассоциативным базам знаний.
Думаю там Вы найдете единомышленников.

з.ы. А потом еще раз прикиньте кто и из чего стреляет по воробьям.
21 июл 08, 11:34    [5962289]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
мимопробегал
Member

Откуда:
Сообщений: 20
про колеса - это сильно

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


а всего сколько не пишет - это ему нафиг не нужно.
21 июл 08, 13:36    [5963225]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
недостатки иерархических
Guest
Вот про то, что хранилища данных это бред - это сильно задвинуто.
То, что само понятие аналитики данных (по разным глубоко научным мат.стат алгоритмам и прочая, прочая) стало возможным только с появлением РСУБД, про это чал предпочитает не знать, и не задумываться. Целая отрасль индустрии возникла благодаря тому, что RDBMS на основе реляционной теории, и язык работы с данными позволили работать не с записями, как в иерархических/сетевых или объектных базах, а с множествами! И пусть чал до посинения утверждает, что РСУБД "записеориентированные" - это ложь, потому как они "множество-ориентированные". А вот его любимые мумпсы - записе-ориентированные.
Ну нет в ОМД и базах на её основе аналитики, и не нужна она там. Никому не интересно, сколько каких объектов есть, и в каких таких сочетаниях, и что делать, если каких-то объектов больше/меньше чем ожидалось, и прочая, и прочая.
21 июл 08, 14:09    [5963508]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
мимопробегал
Member

Откуда:
Сообщений: 20
Целая отрасль индустрии возникла...
Это Вы, братец, неаккуратно сказали. С ЧАЛом так низя. Он теперь начнет утверждать , что Вы фактически подтвердили, что это всё специальные выдумки империалистов, что бы с пользователей побольше бабок срубить.
21 июл 08, 16:44    [5964892]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 12 13 14 15 16 [17] 18 19 20 21 .. 27   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить